|
Mogući problemi sa performansama sledećeg rešenja?
U activeCollabu svi objekti koji pripadaju projektu (taskovi, milestonei, poruke, fajlovi itd) dele neka zajednička svojstva:
obavezna: - project_id - parent_id - name - body - visibility - created_on - created_by_id - updated_on - updated_by_id - version - position samo za assignable objekte: - due_on - priority - assignee_id - resolution - resolved_on - resolved_by_id Jedno rešenje koje mi je palo na pamet je da koristim inehritance mogućnosti ORM-a (Doctrine) i sve project objekte smestim u jednu tabelu. Dakle, da se odlepim od one table one class principa i sve project objekte smestim u jednu tabelu s tim da se razmikuje tip. Znači, ta tabela bi imala sva navedena polja uz dodatak ID i TYPE_ID polja. Ono što me interesuje je koliko velike tabele (sa dosta polja i relativno velikim brojem upisa) utiču na performanse? Kada kažem relativno velika mislim na situaciju u kojima jedna klasična web aplikacija može da se nađe (do milion recorda recimo). Kako takva tabela scaluje (10K recorda, 100K recorda, 1M recorda itd)? Kontam da ne bi smelo biti problema ako dobro rešim indekse i ne izvlačim sve kolone kada mi nisu potrebne. Pošto je InnoDB requirement nema table lockinga tako da je i rad sa celom tabelom oslobođen čekanja. Razlog zašto mi se ovo rešenje izuzetno sviđa su agregacija podataka i mogućnost kreiranja složenih izveštaja: "Daj mi sve nerazrešene zadatke (taskovi ili milestonei) koji su assigneovani Iliji ili njegovoj kompaniji u tom i tom projektu, a pri tom pripadaju Feature requests listi i nisu markirani kao draft ili private i grupiši ih po prioritetu". Krajnji benefit je za korisnike: uz dobar interfejs activeCollab bi mogao imati strašno moćan reporting engine - definitivno jedan od boljih među dostupnim web rešenjima. Interesuje me samo MySQL, 4.1+ with InnoDB support. |
Ja koristim slicno rjesenje u svom internom frejmvorku, gdje imam glavni objekat/tabelu items, i u njoj cuvam slicne podatke kao sto ti hoces. Ostali objekti u tabelama imaju samo ono sto imaju dodatno u odnosu na items. Prilikom svakog citanja onda citas iz barem dvije tabele. Meni ovo zaista radi posao lijepo, i neke stvari bas olaksava.
Drupal koristi slicno rjesenje, i u njihovoj terminologiji to se zove node. Uz dobro uradjene indekse i upite mislim da nema problema. |
Ponasa se OK cak i za mnogo 'sire' tabele, limit je 32 indexa.
|
sa InnoDb ne bi trebalo da imas problema zbog lockinga tabele kod upisa/izmena, a cak i myISAM radi select sasvim ok sa milion recorda, dok god imas upite koji mogu da koriste indexe.
Eventualna optimizacija bi bila da u toj tabeli koristis samo fixed-width polja (znaci ID-jevi i razni flagovi, timestamps i tako to, samo ono sto ti u sustini i treba za WHERE deo), a da sav text drzis zasebno, pa ga joinujes po potrebi. |
Citat:
I mislio sam da je ovo prilično common rešenje kada imaš tonu sličnih objekata sa malim razlikama, ali ipak da proverim iskustva. |
racunaj samo da join-ovanje nad velikim datasetom u mysql-u (~1m rec) moze biti prilican bottleneck cak i sa dobro postavljenim index-ima, ne znam da li se nesto promenilo po tom pitanju (pricalo se o boljoj implementaciji posto je imao prilicno primitivno realizovane join-ove sa nested loop-ovima sto znaci mnogo udaranja po index-ima), ali sumnjam da se nesto promenilo do sada.
|
taj se problem da resiti tako sto se joinovi zamene sub-selectima.. oni ok koriste indexe...
|
Ček, zar sub-select (u opštem slučaju) nije opasniji za perfomanse baze u odnosu na join?
|
jeste, nisam siguran da su sub-selectovi resenje na velikom broju record-a, mada kod mysql-a su moguca razna iznenadjenja ;)
|
Čisto me interesuje --- kakvo je to crno ORM rešenje gde ti brineš o tome koji objekti/polja u koju tabelu i slično?
Tj. zašto se uopšte smaraš sa tim "problemom" ako si već odlučio da koristiš ORM alat? |
| Vreme je GMT +2. Trenutno vreme je 22:02. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.