|
SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka |
|
Alati teme | Način prikaza |
|
22. 01. 2007. | #1 |
Direktor Kombinata
Invented the damn thing
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
|
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.
__________________
activeCollab - Project Management and Collaboration Tool iz domaće kuhinje | area51.rs - Blog |
22. 01. 2007. | #2 |
Vladan Zirojević
Grand Master
|
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. |
22. 01. 2007. | #3 |
Igor Marinović
Expert
|
Ponasa se OK cak i za mnogo 'sire' tabele, limit je 32 indexa.
__________________
marinowski.com |
22. 01. 2007. | #4 |
Ivan Dilber
Sir Write-a-Lot
|
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.
__________________
Leadership is the art of getting people to want to do what you know must be done. |
22. 01. 2007. | #5 | |
Direktor Kombinata
Invented the damn thing
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
|
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.
__________________
activeCollab - Project Management and Collaboration Tool iz domaće kuhinje | area51.rs - Blog |
|
22. 01. 2007. | #6 |
profesionalac
Qualified
Datum učlanjenja: 10.02.2006
Poruke: 181
Hvala: 2
20 "Hvala" u 11 poruka
|
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.
Poslednja izmena od caboom : 22. 01. 2007. u 15:03. |
22. 01. 2007. | #7 |
Ivan Dilber
Sir Write-a-Lot
|
taj se problem da resiti tako sto se joinovi zamene sub-selectima.. oni ok koriste indexe...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
|
|
Slične teme | ||||
Tema | Početna poruka teme | Forum | Odgovori | Poslednja poruka |
Dajte predlog rešenja - Photo voting community | istok | Web aplikacije, web servisi i software | 2 | 22. 01. 2009. 11:47 |
www.askeet.com - Web 2.0 servis od ideje do gotovog rešenja | Ilija Studen | PHP | 1 | 26. 12. 2005. 19:06 |
Jednostavan php album sa sledećim opcijama | mungos | PHP | 9 | 24. 06. 2005. 15:21 |