|
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? |
Citat:
PHP kôd:
|
Citat:
u opstem slucaju da, ali u opstem slucaju ni join ne bi smeo da bude problem na indexiranim tabelama :) evo ovde jedan zanimljiv text gde se pominju i jedni i drugi slucajevi optimizacija: http://www.xaprb.com/blog/2006/04/30...oins-in-mysql/ zao mi je sto sam uvek lenj da zapisem negde kad naletim na tako nesto cudno, tako da sad nemam ni jedan primer, ali desilo mi se par puta da vidim tako neke skroz neocekivane rezultate...tako da ako vidis da je upit spor i da mora da se optimizuje, treba probati sve alternativne verzije pa videti sta je realno najbrze, posto su ponekad neke naizgled bezvezne stvari, potpuno nenadano, brze od skolskih resenja, a teporetski je to vrlo tesko predvideti.. |
evo iskopao sam u bookmarks jos jednu stranu sa lepim primerima: http://www.onlamp.com/pub/a/onlamp/2...m_clauses.html
[Edit ne radi posle 30 minuta, zato pisem posebnu poruku, sorry..] |
Eksperimentisi dosta sa EXPLAIN, i uveri se da ti upiti koriste odgovarajuce indekse... Desilo mi se jednom da sam greskom napravio vise slicnih indeksa, pa je mysql koristio najgoru varijantu (ne secam se tacnog scenarija), ispalo je da je sporije sa indeksima nego bez indeksa. Naravno, uklanjanjem jednog suvisnog indeksa, sve je proradilo.
|
aj se vratite na temu, jer i mene interesuje :)
da li ce perfomanse biti slabije kod tabele koja ima manje polja u odnosu na tabelu koja ima vise polja? [a pri tome ne koristim ta polja za WHERE i ORDER, i polja su fixed-width]. da li postoji neki broj do koga broj polja nije problematican, a odakle vec pocinje da utice na perfomanse? prostije, da li ce tabela sa 10 i 100 polja imati iste perfomanse? [indeksi isti za obe tabele] |
Ako imas Data Warehouse bazu, onda ti je bolje imati jednu tabelu sa vise polja, nego nekoliko tabela sa manje polja, jer je tada full table scan brzi od visestrukog index lookup join-a (npr. star transformation join).
Ako imas OLTP bazu, onda ti je bolje imati tabele sa manje polja. Ako imas objekt sa vise atributa od kojih su samo par atributa kljucni, onda kreiraj dvije ili vise tabela: jednu manju sa kljucnim atributima (poljima) i jednu ili vise njih sa sekundarnim atributima, koje ces medjusobno povezati preko kljuceva. Mozes potom tu sekundarnu tabelu i kompresovati ukoliko ne radis cesto update na njoj, jer se pri selektovanju dobija na brzini. Nije dobro stavljati previse indexa na tabelu (tzv. overindexed table), jer se pri DML operacijama (INSERT, UPDATE i DELETE) usporava cijeli proces zbog aktualizovanja indexa. Pogotovo nakon ucestalog UPDATE-a ili DELETE-a pozeljno je uraditi rebuild indexa i OPTIMIZE tabele, jer se stvaraju rupe (gaps) izmedju zapisa. Uprkos dobro dizajniranoj strukturi baze, vecina programera napise lose i neperformantne upite, kojima usporavaju cijelu aplikaciju. U vecini slucajeva se prepravljanjem SQL upita moze puno dobiti na brzini. Osim toga, ako imas svoj server, mozes podesavati i konfiguracijske parametre (cache buffer, file-per-table, uraditi stripping tabela na vise hard diskova i td.). U svakom slucaju bez obzira sta kazu teorija i EXPLAIN PLAN, samo uzastopnim testiranjem i mijenjanjem postavki i SQL upita mozes doci do opipljivih rezultata. |
Citat:
sa 10 i 10000 recorda nema neke bitne razlike. Ali za 3-4 miliona ima razlike, cak i na indexiranim poljima, jer indexi postanu glomazni. Preko 3-4 miliona recorda i 2GB velicine na disku nije zdravo raditi sa myISAM tabelama, to znam iz iskustva (za INNODB ne znam). Takodje joinovi na tako velikim tabelama pocnu da se vuku uzasno.. sto se broja kolona tice, tu su male razlike, mislim da ne pravi nikakvu razliku, sem ako napravis previse indexa sto usporava upis i izmene... |
Nemam mjerenja, ali cini mi se da sam procitao da nije preporucljivo imati ni ogroman broj kolona (recimo 100+). I da to utice na performanse. Nisam probao, tako da pisem iz sjecanja...
|
| Vreme je GMT +2. Trenutno vreme je 05:36. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.