Particionisanje podataka

Pre nekog sitnog vremena jedna firma me zamolila da im malo protrkeljam sistem da vidim sta bi moglo da se ubrza posto imaju veliku bazu, zahtev za velikim brojem upita (uglavnom read) ali im sve to vrlo traljavo radi. Po iskustvu pretpostavio sam neke osnovne greske u postavci sistema (los server, lose iskonfigurisan mysql, ugasen ili lose podesen query cache etc) ali kada sam stigao na teren – sve moje pretpostavke su bile pogresne. MySQL je bio vrlo optimalno konfigurisan, server je zmija (8 jezgara, 15000RPM diskovi u raidu, mnogo rama…)… sumnja je naravno odma pala na lose upite. Pogledavsi upite, ni tu nije bilo sta mnogo da se „ubrza“ … neke sitnice smo ubrzali par stotina puta no to nije mnogo uticalo na ukupnu sporost celog sistema, te sam se usresredio na samu strukturu i kvalitet podataka.

Baza ima stotinjak tabela od kojih su vecma sve poprilicno male po horizontali – sto generalno govori da je baza prilicno dobro normalizovana. Atributske tabelice su reda velicine par stotina do par hiljada slogova sto nije puno, ali „glavna“ velika tabela, iako dobro normalizovana, ima oko 250 miliona slogova. Upiti koji se izvrsavaju nad tom tabelom i mnoze sa atributskim tabelama zahtevaju prolazak kroz veliki broj slogova i ma koliko indexi bili korisni ako imate agregatnu funkciju nad 10000 slogova, to prosto znaci da morate da prodjete kroz 10000 slogova, procitate svaki, uzmete vrednost, ubacite je u agregatnu funkciju … tu indexi na zalost ne pomazu mnogo …  Posle malo dublje analize zakljucio sam da bi bilo realno da se ta glavna tabela particionise po jednom delu primarnog kljuca. Ako pogledamo kako radi partitioning na mysql-u zakljucicemo da je svaka operacija nad vise particija „mnogo“ sporija nego u slucaju da nema particija ali sam ja ovaj put resio da batalim „opste brojke“ i izmerim sam u realnom sistemu kakva je razlika. Operacije koje idu nad CELOM tabelom (znaci SVIM particijama) su radile oko 2.5% sporije nego na neparticionisanim podacima – dakle prilicno zadovoljavajuci rezultat ako se pokaze da se upiti nad jednom particijom izvrsavaju brze (posebno sto tih upita ima znacajno vise). Podaci nad jednom particijom su radili oko 40 PUTA brze :). I ne samo da je brzina izvrsavanja svakog upita veca, tokom izvrsavanja upita stres nad samim serverom je mnogostruko manji (i do 200 puta manji IO, 30tak puta manji user cpu usage …)

Grafikoni koje vidite pokazuju CPU USAGE i AVERAGE LOAD na serveru u nekom vremenskom periodu. Pretpostavite trenutak kada smo ukljucili particionisanje podataka :)

MySQL podrzava partitioning od verzije 5.1. U osnovi, MySQL partitioning radi tako da vasu tabelu podeli u male tabele (svaka particija fizicki na disku postane zasebna tabela) i kada optimizer prepozna da moze upit da izvrsi nad samo jednom particijom, operaciju vrsi nad tom jednom „tabelicom“, ako upit mora da izvrsava nad vise tabela, onda se odredjuje da li moze da sekvencijalno koristi jednu pa drugu pa … ili mora da pravi „join“ izmedju particija. U slucaju da se pravi join tada je pristup particionisanim podaci nesto sporiji nego kada oni nisu particionisani. U slucaju upisa i slicno podatak se upisuje u „odgovarajucu tabelu“. Ono sto je kod particionisanja vrlo zgodno je to sto mozete

• Obrisati podatke iz particije (recimo da particionisete podatke po godini, brisanje svih podataka iz jedne godine se u ovom slucaju svodi na brisanje jednog fajla sa diska)
• Popraviti jednu particiju (u slucaju korupcije, repair se vrsi nad samo jednim segmentom tabele, ne nad celom tabelom)
• U slucaju da su vam particije tipa myisam, svaka particija moze da bude na svom disku i to posebno data posebno index sto vam daje mogucnost da rasprostrete tabelu na mnogo diskova povecavajuci time max IO koji masina moze da da

Ako resite da probate mysql paritioning, obavezno procitajte i deo o limitima istog.