7/23/2019 Mysql Optimizacija

1/4

Sadraj Upravljanje performansama je osnovni cilj

administratora beze podataka. Upravljanje performansama

baze podataka nije aktivnost koja se moe uraditi jednom za

stalno, ve je u pitanju proaktivan, kontinuiran i iterativan

proces koji traje koliko i eksplatacija baze podataka.

Upravljanje performansama MySQL baze podataka

podrazumeva mnogo kompromisa. Pronalaenje najboljih

kompromisa bio je prioritetni cilj autora.

Kljune rei Optimizacija baze podataka, Optimizacija

tabela, Optimizacija upita, Performanse baze podataka.

I. UVOD

RAENJEi optimizacija performansi je osnovni zadataksvakog administratora baze podataka. Skoro svako ko

je doao u kontakt sa raunarima iskusio je neke problemesa performansama. Upravljanje performansama moe sedefinisati i kao optimizacija resursa da bi se povealepropusne moi i smanjila konkurencija, istovremenoomoguavajui obradu najveeg mogueg optereenja.

Upravljanje performansama je iterativan proces, jer senakon primene parametara ponovo prati rad sistema,analizira ostvarena promena u odnosu na prethodno stanjei ponovo podeavaju parametri [1].

II. FAKTORI KOJI UTIU NA PERFORMANSE

Na performanse baze podataka utie vie faktora: Mogunost optimizacije Mnogi faktori

treba da budu optimizovani (kao to suformulacija SQL upita i parametri tabela iservera baze podataka), da bi optimizatorbaze podataka kreirao najoptimalnijeputanje do podataka.

Radno optereenje Radno optereenje jekombinacija trenutnih transakcija, batchposlova i ad hoc upita. Radno optereenjemoe drastino da fluktuira iz dana u dan, izasa u as, pa ak iz minuta u minut.Ponekad je optereenje predvidljivo (kao tosu velike obrade zarada, prihoda, rashoda iobaveza na kraju meseca ili vrlo slab pristupbazi podataka posle 19 asova, kada je

Blagodar Lovevi, Via tehnoloka kola u apcu, Srbija; (e-mail:vtssa@ptt.yu).

Danilo Obradovi, Fakultet tehnikih nauka u , Novom Sadu, Srbija;(e-mail: danilo1939@yahoo.com).

Krstan Bonjak, Elektrotehniki fakultet u Banja Luci, RepublikaSrpska; (e-mail: bosnjak@etfbl.net).

veina korisnika otila kuama), a ponekadvrlo nepredvidljivo (kao to su transakcioneobrade na zahtev i ad hoc upiti spoljnihkorisnika).

Propusna mo Propusna mo definiesveukupnu mogunost raunara da obradipodatke. Ona zavisi od brzine U/I operacija,brzine procesora, mogunosti paralelne

obrade i efikasnosti operativnog sistema iostalog sistemskog softvera.

Konkurencija Kada su zahtevi za odreeniresurs veliki, moe doi do konkurencije upristupu. Konkurencija je stanje u kome dveili vie komponenti koje ine optereenjesistema pokuavaju da pristupe jednomresursu. Kako konkurencija raste, takopropusna moopada.

Dinamiko radno okruenje karakterie brzo poveanjebaze podataka, stalni porast broja korisnika i poveavanjesloenosti i broja instaliranih aplikacija

III. OPIS ISTRAIVANJA

Autori su istraivali mogunosti optimizacije MySQLservera, upita i tabela da bi ostvarili proaktivno upravljanjeperformansama MySQL baze podataka. MySQL jenajznaajniji predstavnik proizvoda iz familije OpenSource za oblast baze podataka. Autori su istraivanjaobavili u preduzeu Link iz apca. Preduzee Link sebavi projektovanjem i izgradnjom informacionih sistemaza potrebe poslovnih partnera. Za potrebe HoldingaZorka abac, preduzee Link je projektovaloinformacioni sistem za praenje proizvodnje, prometa,finansija i odravanja. Poslovni sistem Holdinga Zorkaabac je relativno sloen; sastoji se od brojne proizvodne

opreme, maina, mehanikih i elektro ureaja, transportnihureaja...

Upravljanje performansama MySQL baze podatakapodrazumeva mnogo kompromisa. Pronalaenje najboljihkompromisa je bio prioritetan cilj autora.

IV. OPTIMIZACIJA MYSQL SERVERA

Performanse MySQL servera moemo poboljati akopreuzmemo izvorni kod i sami ga prevedemo pomouodgovarajueg prevodioca i opcija podeenih za korieniraunarski sistem.

Najvaniji parametri koje treba da podesimo jesu onikoji odreuju kako MySQL troi memoriju. Za svakiserver baza podataka vano je da ima to vie memorije,

Upravljanje performansama MySQL baze

podatakaBlagodar Lovevi, Danilo Obradovi, Krstan Bonjak

P

565

14. Telekomunikacioni forum TELFOR 2006 Srbija, Beograd, novembar 21.-23., 2006.

7/23/2019 Mysql Optimizacija

2/4

ali je vano i da se ta memorija pravilno raspodeljujeizmeu njegovih procesa.

MySQL odrava grupu internih bafera i ostava. Dvanajvanija parametra koja treba da podesimo suKey_buffer_size i Table_cache. Poto te bafere dele sve

niti koje rade na serveru, njihovo podeavanje ima velikiuticaj na performanse servera.

Key_buffer_size odreuje veliinu bafera u kojem seuvaju blokovi MyISAM indeksa. Kada aplikacija zatraiodreeni blok iz datoteke indeksa, on se uitava u tajbafer. Kad god se izvrava neki upit, ako se odgovarajuiblok indeksa nalazi u baferu, podaci se uitavaju iz njega.U suprotnom, blok indeksa mora da se uita iz datoteke nadisku u bafer za kljueve, to je sporije. Kada razmatramovrednost koju treba dodeliti parametru Key_buffer_size,treba uzeti u obzir: ukupnu koliinu memorije s kojomraspolaemo, da li se raunar koristi iskljuivo kaoMySQL server ili slui i za druge poslove. Autori su

merenjem performansi zakljuili da se na raunaru kojiradi iskljuivo kao MySQL server, parametruKey_buffer_sizedodeli vrednost u opsegu izmeu 30% i40% raspoloive RAM memorije.

Vrednost opcije Table_cacheodreuje maksimalan brojtabela koje mogu biti otvorene u isto vreme. KodMyISAM tabela, svaka tabela i svaki indeks su zasebnedatoteke u operativnom sistemu. Budui da je otvaranje izatvaranje datoteka spora operacija, te datoteke ostajuotvorene dok ne bude zahtevano zatvaranje, serversputen, ili dok ukupan broj otvorenih tabela ne premaivrednost parametra Table_cache. Poveavanje vrednostiparametraTable_cachekorisno je kada na serveru imamo

veliki broj tabela.Osim tih globalnih memorijskih bafera, pojedinimnitima se takoe dodeljuju blokobi memorije, kao to su ,na primer, bafer za sortiranje i bafer za itanje. U bafer zaitanje, ija se veliina odreuje parametromRead_buffer_size, smetaju se podaci iz tabele kada senjen sadraj ita sekvencijalnim redosledom (table scan).to se vie podataka iz tabele moe smestiti u bafer, to ebiti manji broj operacija itanja sa diska. Meutim, ako jevrednost tog parametra previsoka, grupa bafera za itanje,koje niti koriste, moe potriti previe memorije.Istraivanja su pokazala da veliina bafera za itanje ne bitrebalo da prelazi 20% raspoloive RAM memorije. Bafer

za sortiranje,

iju veli

inu odre

uje parametar Sort_buffer,koristi se pri izvravanju upita koji sadre odredbu Orderby. Ako sortiramo velike koliine podataka, treba poveatibafer za sortiranje, ali i za njega vai isto upozorenje kao iza bafer zaitanje.

InnoDB tabela ciklino popunjavaNdatoteka dnevnika,pri emu je N vrednost zadata opcijomInnoDB_log_files_in_group. Podrazumevana vrednost zaN je 2 i preporuuje se. Opcija InnoDB_log_file_sizedefinie veliinu datoteka dnevnika.

S obzirom da se u projektovanom informacionomsistemu obrauje dinamiko radno okruenje, autoripredlau da se kao server koristi raunarski sistem sa viediskova. Velike tabele i log fajlove InnoDB tabela treba

rasporediti na razliite diskove i praenjem njihovihperformansi ujednaiti optereenja.

Najnovija verzija MySQL-a podrava i replikaciju.Autori predlau da se povee vie MySQL servera tako dase zahtevi klijenata mogu preusmeriti na bilo koji od njih

[2]. Replikovanje moe znaajno da pobolja performansejer se izvravanje upita raspodeljuje na vie raunara.

V. OPTIMIZACIJA UPITA

MySQL omoguava da analiziramo upit da bismosaznali za koje se vreme izvri i kako se tano izvrava nadsadrajem baze podataka [3]. Najbolje je da se upit izvrivie puta i da zatim izraunamo proseno vreme njegovogtrajanja. Budui da trajanje jednog izvravanja upita zavisiod ukupnog optereenja sistema, rezultati samo jednogmerenja nemogu se uzeti kao validni.

Identifikovanje sporog upita vri se posmatranjemizvravanja upita, merenjem performansi upita i uvidom u

dnevnik sporih upita i dnevnik promena.U MySQL-u moemo meriti brzinu izraunavanja

vrednosti bilo kog izraza, pa i celog upita, pomouugraene funkcijeBenchmark().

Pomou dnevnika sporih upita moemo utvrditi koji seupiti presporo izvravaju. Beleenje sporih upita u dnevnikmoemo ukljuiti pomou opcije

Log_show_queries=ime_datotekekoja je sastavni deo datoteke opcija. Ako ukljuimo i

opciju Log_Long_Format, bie evidentirani i svi upiti priijem se izvravanju ne koristi nijedan indeks. To namukazuje emu treba da posvetimo najvie panje prioptimizaciji.

Zadavanjem vrednosti promenjivoj Long_query_timeodreujemo ta je za nas spot upit. Vrednost se zadaje ukonfiguracionoj datoteci ili pomou komande Set.Vrednost te promenjive izraava se u sekundama.

Dnevnik sporih upita moemo itati neposredno jer je toobina tekstualna datoteka. Jedno od tekuih ogranienjaMySQL-a jeste to da ne belei spore upite ije izvravanjetraje manje od sekunde.

Na sistemima koji obrauju relativno veliki brojjednostavnih upita, jedna sekunda traje veoma dugo.Autori smatraju da je u takvoj situaciji poeljno znatikojim upitima je potrebno vie od desetinke ili nekogdrugog dela sekunde. To je posebno bitno kada se

obrauju tabele koje sadre naloge proizvodnje, transportaili prodaje. Tada se generie vie upita za svaku ranijespomenutu tabelu. Da bi pratili i takve upite, autoripredlau promenu MySQL izvornog koda i beleenje upitau dnevnik sporih upita ije izvravanje traje vie oddesetinke sekunde.

MySQL poseduje ugraeni mehanizam optimizovanjaupita. Pomou komande Explain moemo saznati kakoMySQL tano izvrava upit da bismo zatim pokuali da gaoptimizujemo. Komanda Explain nalae MySQL-u daobjasni kako namerava da izvri upit.

Na osnovu procenjenog broja redova (koji prikazujekomanda Explain), MySQL utrvuje koji bi bio najbolji

redosled spajanja tabela. Ako smatramo da je njegova

566

7/23/2019 Mysql Optimizacija

3/4

procena pogrena, odredbom Straight Join izriitozadajemo redosled spajanja tabela. Merenjem performansiupita pre i posle te izmene, utvrdiemo da li timeaplikaciju poboljavamo ili pogoravamo.

Uzrok broj jedan loih performansi jeste upotreba tabela

kojima nije pridruen nijedan indeks ili nema indeksa zakolone koje pretraujemo. S druge strane, potrebno jeveliko vreme da bi se aurirao veliki broj indeksa svaki putkada se u tabelu upie novi red ili aurira postojei. Kadauitavamo podatke, indeksi su veoma korisni. Kadaupisujemo nove redove, odnosno auriramo neki podatakili briemo postojee redove, indeksi se auriraju toproduava obradu i poveava optereenje sistema.

Kada bira indeks, MySQL trai odgovarajui indeks kojiobuhvata manje od 10% redova tabele. Ako ne uspe dapronae indeks koji ispunjava te uslove, sekvencijalnopretrauje tabelu. S obzirom da se u projektovanominformacionom sistemu koriste tabele koje imaju po

nekoliko stotina hiljada redova, predodreenosekvencijalno pretraivanje nije prihvatljivo sa aspektaperformansi. Autori su vrili testiranje performansi kada sekoristi indeks koji obuhvata i vie procenata redova tabele.Pokazalo se da je za tabele koje sadre preko 700 hiljadaredova bolje koristiti indeks koji obuhvata i do 15%redova tabele. Takoe, pokazalo se da je za tabele kojesadre oko 400 hiljada redova povoljnije korienjeindeksa koji obuhvata 12% redova tabele. Autorima jejasno da stvaranje takvih indeksa troi procesorsko vreme,ali su takvi indeksi posebno korisni u upitima koji nemenjaju stanje tabela. Ako se potpun rezultat upita moedobiti iz podataka sadranih u indeksima, iz tabela se nee

uitati nijedan red.U radu [4] je pokazano da se Visual Age Generatormoe uspeno koristiti za kreiranje vienivovskih klijent-server aplikacija nad MySQL bazom podataka. Sistemirazvijeni u dvoslojnoj arhitekturi nezadovoljavajuepodravaju veliki broj korisnika, veliki obim transakcija inepredvidivo radno optereenje za Internet i Intranetaplikacije. Savremene aplikacije pomeraju veinu poslova,kao to su procesiranje, podatke i funkcije sa desktopraunara na aplikacione servere. Visual Age Generatorobezbeuje visoke performanse koje se postiu optimalnimiskorienjem svih segmenata informacionog sistema uzvertikalnu podelu poslova od servera do radne stanice. Iz

tog razloga autori predlau da se za razvoj aplikacija urazmatranom realnom sistemu koristi Visual AgeGenerator.

VI. OPTIMIZACIJA TABELA

Tokom upotrebe baze podataka, u datotekama u kojimase uvaju podaci raste broj praznina izmeu blokovapodataka na mestima gde su ranije bili izbrisani zapisi iliodakle su zapisi premeteni zato to su nakon auriranjapostali vei. Te praznine su uzrok slabije efikasnosti.Trebalo bi da povremeno upotrebimo komandu

Optimize tableime_tabele;koja je MySQL-ov ekvivalent komande za

defragmentaciju vrstog diska. Tako emo preurediti

podatke u datotekama, ponovo sortirati indekse i auriratistatistike podatke o tabeli.

Da bi smanjio broj spojeva koji se uspostavlja unajeim upitima treba razmotriti mogunostdenormalizacije tabela. Treba imati na umu da e

denormalizacija pored ubrzavanja najeih upita kaoposledicu imati i redudansu podataka, pa pri tome trebabiti veoma oprezan. Takoe treba razmotriti mogunostkompresije podataka da bi se smanjio broj U/I operacija.

A. Denormalizacija

Normalizovana baza podataka minimizira problemeintegriteta. Nezadovoljavajue performanse su jedinirazlog da se pristupi denormalizaciji. Svaka odluka odenormalizaciji mora biti dokumentovana, ukljuujui irazloge odluke i promene koje su izvrene u odnosu nanormalizovan logiki model.

Tabele za izvetavanje su idealne za

smetanje rezultata viestrukih spajanjatabela, meuzavisnih podupita ili ostalihsloenih SQL izraza. Tabele za izvetavanjesu pogodne za brzo kreiranje estokorienih izvetaja. Autori predlau da seformiraju tabele sa izvedenim podacima kojidirektno ukazuju na bilanse prometaproizvoda i usluga.

Horizontalna podela tabele na dve ili vietabela. U razmatranom realnom sistemuuoena je potreba horizontalne podele tabeleNarudbe na dve tabele: Velike_Narudbesa iznosima preko 100.000,00 dinara i

Male_Narudbe sa iznosima do 100.000,00dinara. Narudbama iji iznosi prelaze100.000,00 dinara time e se obezbeditibolje performanse i poseban tretman.

Vertikalna podela tabele odvaja samo nekekolone u nove tabele. Jedan skup kolona sesmeta u jednu tabelu, a drugi skup u drugutabelu. Primarni kljutabele se smeta u obetabele. Tabela sa matinim podacima oposlovnim partnerima sadri pored najeekorienih podataka (raun i naziv firme)mnogo drugih podataka kao to su ifradelatnosti, adresa, oblik svojine, vlasnik,direktor, osoba za kontakt, itd. Autoripredlau da se formiraju dve tabele:Poslovni_partner_I sa kolonama raun inaziv_firme i Poslovni_partner_II sa svimpodacima. U predloenom reenju nazivfirme se nalazi u obe tabele jer autorismatraju da e na taj nain obezbediti boljeperformanse.

Deljenje dugakih tekstualnih kolona moeda pobolja performanse. Opis artikla moebiti dugaak npr. 200 karaktera, ali mnogiartikli imaju opis od samo 20 karaktera aostali artikli se esto koriste sa skraenimopisom koji je takoe do 20 karaktera. Uovom sluaju moemo podeliti ovu tabelu na

567

7/23/2019 Mysql Optimizacija

4/4

dve, deljenjem kolone opisa na dve kolone.Jedna od njih e sadrati 20 karaktera(skraenog) opisa a u drugoj tabeli sa istimprimarnim kljuem kreirae se kolona za iriopis artikla.

Prethodno spojene tabele samo jednomspajanjem optereuju sistem (u fazi kreiranjaspoja). Nad unapred spojenim tabelama upitise izvravaju znatno efikasnije jer su tabeleve spojene i prilagoene zahtevu upita.Prethodno spojene tabele su korisne kodrelativno statikih podataka. Kod dinamikihiesto promenjivih tabela prethodno spojenetabele mogu i da pogoraju performanse.Sagledavajui sve aspekte realnog sistema,autori nisu predloili formiranje spojenihtabela.

B. Kompresija

Kompresija se moe koristiti za smanjenje veliine bazepodataka. Komprimovanjem podataka baza podatakazahteva manje prostora na disku. Mada se komprimovanjena prvi pogled ini korisno, trebalo bi ga primenjivatisamo za neke aplikacije, jer se komprimovane tabele mogusamo itati. Ako je potrebno da izmenimo strukturukomprimovane tabele, ili da auriramo podatke u njoj, ilida joj dodamo nove podatke, moramo da dekomprimujemocelu tabelu, unesemo odgovarajue izmene i zatim ponovokomprimujemo tabelu. MyISAM tabele mogu sekomprimovati primenom Hafmanovog koda i vieoptimizacija iji je cilj saimanje kolona, na primer,

konverzijom postoje

ih tipova podataka u manje, ikonverzijom sadraja kolona u nabrajanja.Pet slogova nekomprimovane tabele sa veliinom sloga

od 800 bajtova se moe smestiti u stranicu 4K.Pretpostavimo da je prosena vrednost kompresije oko30% (podatak dobijen tokom istraivanja). U tom sluaju,nekomprimovani slog od 800 bajtova e zauzeti samo 560bajtova nakon kompresije. Posle kompresije, sedam takvihslogovae se smestiti na stranicu od 4K. Zbog toga to U/Ioperacije rade na nivou stranica, jedna takva operacija eproitati vie podataka, to e optimizovati performansesekvencijanog itanja podataka i poveati verovatnouostajanja podataka u keu zato to se vie slogova nalazi nafizikoj stranici.

Kompresija nije reenje za svaku tabelu baze podataka.Za manje koliine podataka, moe se desiti da jekomprimovana datoteka vea od nekomprimovane. Uzroktome su dodatni podaci koji govore o strukturikomprimovanih podataka. Za male koliine podataka,veliina tih struktura moe biti vea od prostora koji sedobija kompresijom.

Autori predlau da se u razmatranom informacionomsistemu komprimuju podaci Stavki (rauna, partije, nalogaproizvodnje, narudbe, magacinske pozicije, itd) koji seodnose na prethodne mesece i nisu vie predmet aktivnogpraenja.

VII. ZAKLJUAK

Istraivanje je pokazalo da se uspeno upravljanjeperformansama moe postii samo proaktivnim planom.Mnogi problemi mogu se identifikovati i odrediti reenjaunapred.

Upravljanje performansama podrazumeva optimizacijuupita, tabela i servera MySQL baze podataka. Autoripredlau izmenu izvornog koda MySQL-a i optimizovanjeupita koji traju manje od jedne sekunde, kao i izmenuizvornog koda MySQL-a da bi se koristio indeks kojiobuhvata i do 15% redova velikih tabela. Autori predlauprimenu denormalizacije i kompresije podataka da bi se

postiglo proaktivno upravljanje performansama. Autoripredlau korienje Visual Age Generatora za stvaranjevienivovskih klijent-server aplikacija nad MySQL bazompodataka.

LITERATURA

[1] D. Simi, D. Starevi, Upravljanje performansama sloenihinformacionih sistema XI Konferencija INFO-TEH, str94-98,Donji Milanovac, 1996.

[2] B. Lovevi, D. Obradovi, K. Bonjak, Jedan pristupraspoloivosti MySQL baze podataka, Simpozijum INFO-TEH,Jahorina, 2006.

[3] B. Lovevi, K. Bonjak, D. Obradovi, Analiza kvaliteta OpenSource SUBP na osnovu mogunosti izvravanja sloenihupitaSimpozijum INFO-TEH, Jahorina, 2006.

[4] B. Lovevi, D. Obradovi, K. Bonjak, Korienje Visual AgeGeneratora za stvaranje vienivovske klijent- server aplikacije,Konferencija ETRAN, Beograd, 2006.

ABSTRACT

Performance management is primary objective foradministrators of data base. Performance management ofdata base is not an activity which could be donepermanently, but we have a case of proactivity, a continuosand iterative process which lasts as long as theexploatation of data base. Performance management ofMySQL data base asks for a lot of compromising. Thefondation of the best solutions was the autors priority aim.

PERFORMANCE MANAGEMENT OF MYSQL

DATA BASE

Blagodar Lovevi, Danilo Obradovi, Krstan Bonjak

568