[ Mister_rap @ 09.08.2009. 15:47 ] @
Pozdrav,

Naime radim na jednoj aplikaciji koja predstavlja specificnu arhivu slika i video sadrzaja.
Imam jedan konceptualni problem pa rekoh da pitam...

Koristim InnoDB pa me zanima (izmedju ostalog) da li bi trebao da se prebacim na MyISAM zbog preformansi ?

Dijargam koji vidite ispod sluzi samo za potrebe ove teme (ima inace nekih 30tak tabela a i ove dve imaju mnogo vise kolona) i mislim da mi prikazani dizajn ne odgovara a evo i zbog cega:

Kada pustim skript u tabelu pictures ce biti dodato oko 130.000 zapisa i taj broj svakim danom bi trebalo da se uvecava za nekih 100-300 redova.
Takodje je (mozda) bitno naglasiti da odredjena osoba ima svega 2-3 slike ali odredjene imaju 500+



Ono sto mene brine jeste kako ce ta tabela pictures da se ponasa za tolikim brojem redova ?
Ja sam razmisljao ali mi to deluje prilicno "glupo" da recimo limitiram broj zapisa u tabeli na nekih 100k i da imam identicne tabele samo sa drugim imenom (pictures_1, pictures_2) u koje bi se upisivalo sve dok se ne dodje to te neke limit cifre i tako redom.

Zanima me da li postoji neko prakticnije resenje pre svega i koji problemi mogu da mi se jave u buducnosti ako budem koristio neko od ova dva resenja koja sam gore izneo?
[ bogdan.kecman @ 09.08.2009. 18:15 ] @
Citat:
Mister_rap: 
Koristim InnoDB pa me zanima (izmedju ostalog) da li bi trebao da se prebacim na MyISAM zbog preformansi ?


samo ako su ti performanse prioritet ... myisam nije crash safe - sto ce reci, crash servera moze da dovede do korupcije tabele / gubitka poslednjih X transakcija, takodje myisam nije transactional tabela sto znaci da nikako ne mozes da budes siguran da imas konzistentnost podataka .. etc etc .. dakle ako ti je performansa bitnija od ove dve stavke - onda da, mozes da predjes na myisam ... ako na primer imas read only tabelu i jos ako je staticne sirine, myisam ti je super .. ali ako ces i da pises po toj tabeli, ne zaboravi da myisam ima samo table level locking....

Citat:

Dijargam koji vidite ispod sluzi samo za potrebe ove teme (ima inace nekih 30tak tabela a i ove dve imaju mnogo vise kolona) i mislim da mi prikazani dizajn ne odgovara a evo i zbog cega:


ne kapiram sta znaci "prikazani dizajn ne odgovara"

Citat:

Kada pustim skript u tabelu pictures ce biti dodato oko 130.000 zapisa i taj broj svakim danom bi trebalo da se uvecava za nekih 100-300 redova.
Takodje je (mozda) bitno naglasiti da odredjena osoba ima svega 2-3 slike ali odredjene imaju 500+

Ono sto mene brine jeste kako ce ta tabela pictures da se ponasa za tolikim brojem redova ?
Ja sam razmisljao ali mi to deluje prilicno "glupo" da recimo limitiram broj zapisa u tabeli na nekih 100k i da imam identicne tabele samo sa drugim imenom (pictures_1, pictures_2) u koje bi se upisivalo sve dok se ne dodje to te neke limit cifre i tako redom.

Zanima me da li postoji neko prakticnije resenje pre svega i koji problemi mogu da mi se jave u buducnosti ako budem koristio neko od ova dva resenja koja sam gore izneo?


nemas nikakav problem sa ovim konceptom ovako ... mnogo slogova nije problem za mysql (kao ni za vecinu modernih baza) .. razbijanje po tabelama nije dobro resenje... u slucaju da je tabela sa slikama "prevelika" range partitioning po person_id bi bio cool varijanta ali to je nesto sto uvek mozes kasnije da dodas (kada partitioning bude manje bagovit).

ako hoces da imas bolje performanse - nemoj da slike cuvas u blobu u pictures tabeli ... ako bas hoces da cuvas slike u bazi - napravi 1:1 tabelu sa pictures koja ima samo id i blob (ili blobove ako cuvas pregenerisane thumbnails) sa slikom ... dakle nemoj da turas blob direktno u pictures tabelu.
[ Mister_rap @ 09.08.2009. 19:38 ] @
Pozdrav,

Bogdane hvala na odgovoru, ovaj termin range partitioning mi je nov ali kapiram sta ovo zapravo radi :D

Slike naravno ne cuvam u bazi vec u toj pictures tabeli pamtim samo njihovo ime a fajlovi se skladise na posebnim fajl serverima.
[ bogdan.kecman @ 09.08.2009. 20:09 ] @
Citat:
Mister_rap:

Bogdane hvala na odgovoru, ovaj termin range partitioning mi je nov ali kapiram sta ovo zapravo radi :D


http://dev.mysql.com/doc/refman/5.1/en/partitioning.html
http://dev.mysql.com/tech-reso.../performance-partitioning.html

pogledaj ta dva linka ...

problem je sto je partitioning jos uvek nedovoljno istestiran ... nema dovoljno production instalacija i ima jos uvek par velikih poznatih bagova koji nisu popravljeni
[ tarla @ 10.08.2009. 02:39 ] @
Imam nekoliko tabela sa po 1 000 000 i više unosa, veličine 300 i više MB po tabeli i rade kulturno (nekoliko upita po sec). Tabele su bile MyISAM ali su prebačene na InnoDB upravo zbog "row level" zaključavanja
[ bogdan.kecman @ 10.08.2009. 04:51 ] @
dokle god tabeli pristupas preko primarnog kljuca (pk lookup) - miran si .... i innodb i myisam su tu vrlo brzi ...

da bi tabela ovog tipa bila "brza" person_id koji je u stvari kljuc po kom ces da radis pretragu, mora da bude deo primarnog kljuca.... no, cak i bez toga, kao obican ordered key to radi prilicno brzo.. tu je sada razlika u tome koliko je bitna brzina inserta u odnosu da brzinu select-a (select ce biti brzi ako je person_id deo PK ali ce zato insert biti sporiji i obrnuto
[ Mister_rap @ 14.08.2009. 16:17 ] @
Pozdrav,

Evo nakon sto sam odradio taj prvi insert, malo sam testirao i mogu reci da sam jako zadovoljan rezultatima.
Sama tabela nije nesto "teska" - 21 Megabajt (129.863 redova) i sve radi apsolutno zadovoljavajuce...
[ bogdan.kecman @ 14.08.2009. 16:32 ] @
Citat:

Evo nakon sto sam odradio taj prvi insert, malo sam testirao i mogu reci da sam jako zadovoljan rezultatima.


kakvog inserta? da li si merio razliku u brzini izmedju person_id u pk i van pk-a.?
[ Mister_rap @ 14.08.2009. 23:45 ] @
Pa izvrsio query koji je dodao validnih 129.863 zapisa u tu tabelu :)

Citat:

da li si merio razliku u brzini izmedju person_id u pk i van pk-a.


Ne, nisam.