14.

Telekomunikacioni forum TELFOR 2006

Srbija, Beograd, novembar 21.-23., 2006.

Upravljanje performansama MySQL baze

podataka
Blagodar Lovevi, Danilo Obradovi, Krstan Bonjak

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

i optimizacija performansi je osnovni zadatak

svakog administratora baze podataka. Skoro svako ko
je doao u kontakt sa raunarima iskusio je neke probleme
sa performansama. Upravljanje performansama moe se
definisati i kao optimizacija resursa da bi se poveale
propusne moi i smanjila konkurencija, istovremeno
omoguavajui obradu najveeg mogueg optereenja.
Upravljanje performansama je iterativan proces, jer se
nakon primene parametara ponovo prati rad sistema,
analizira ostvarena promena u odnosu na prethodno stanje
i ponovo podeavaju parametri [1].
RAENJE

II. FAKTORI KOJI UTIU NA PERFORMANSE

Na performanse baze podataka utie vie faktora:
Mogunost optimizacije Mnogi faktori
treba da budu optimizovani (kao to su
formulacija SQL upita i parametri tabela i
servera baze podataka), da bi optimizator
baze podataka kreirao najoptimalnije
putanje do podataka.
Radno optereenje Radno optereenje je
kombinacija trenutnih transakcija, batch
poslova i ad hoc upita. Radno optereenje
moe drastino da fluktuira iz dana u dan, iz
asa u as, pa ak iz minuta u minut.
Ponekad je optereenje predvidljivo (kao to
su velike obrade zarada, prihoda, rashoda i
obaveza na kraju meseca ili vrlo slab pristup
bazi 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, Republika
Srpska; (e-mail: bosnjak@etfbl.net).

veina korisnika otila kuama), a ponekad

vrlo nepredvidljivo (kao to su transakcione
obrade na zahtev i ad hoc upiti spoljnih
korisnika).
Propusna mo Propusna mo definie
sveukupnu mogunost raunara da obradi
podatke. Ona zavisi od brzine U/I operacija,
brzine procesora, mogunosti paralelne
obrade i efikasnosti operativnog sistema i
ostalog sistemskog softvera.
Konkurencija Kada su zahtevi za odreeni
resurs veliki, moe doi do konkurencije u
pristupu. Konkurencija je stanje u kome dve
ili vie komponenti koje ine optereenje
sistema pokuavaju da pristupe jednom
resursu. Kako konkurencija raste, tako
propusna mo opada.
Dinamiko radno okruenje karakterie brzo poveanje
baze podataka, stalni porast broja korisnika i poveavanje
sloenosti i broja instaliranih aplikacija
III. OPIS ISTRAIVANJA
Autori su istraivali mogunosti optimizacije MySQL
servera, upita i tabela da bi ostvarili proaktivno upravljanje
performansama MySQL baze podataka. MySQL je
najznaajniji predstavnik proizvoda iz familije Open
Source za oblast baze podataka. Autori su istraivanja
obavili u preduzeu Link iz apca. Preduzee Link se
bavi projektovanjem i izgradnjom informacionih sistema
za potrebe poslovnih partnera. Za potrebe Holdinga
Zorka abac, preduzee Link je projektovalo
informacioni sistem za praenje proizvodnje, prometa,
finansija i odravanja. Poslovni sistem Holdinga Zorka
abac je relativno sloen; sastoji se od brojne proizvodne
opreme, maina, mehanikih i elektro ureaja, transportnih
ureaja...
Upravljanje performansama MySQL baze podataka
podrazumeva mnogo kompromisa. Pronalaenje najboljih
kompromisa je bio prioritetan cilj autora.
IV. OPTIMIZACIJA MYSQL SERVERA
Performanse MySQL servera moemo poboljati ako
preuzmemo izvorni kod i sami ga prevedemo pomou
odgovarajueg prevodioca i opcija podeenih za korieni
raunarski sistem.
Najvaniji parametri koje treba da podesimo jesu oni
koji odreuju kako MySQL troi memoriju. Za svaki
server baza podataka vano je da ima to vie memorije,

565

ali je vano i da se ta memorija pravilno raspodeljuje

izmeu njegovih procesa.
MySQL odrava grupu internih bafera i ostava. Dva
najvanija parametra koja treba da podesimo su
Key_buffer_size i Table_cache. Poto te bafere dele sve
niti koje rade na serveru, njihovo podeavanje ima veliki
uticaj na performanse servera.
Key_buffer_size odreuje veliinu bafera u kojem se
uvaju blokovi MyISAM indeksa. Kada aplikacija zatrai
odreeni blok iz datoteke indeksa, on se uitava u taj
bafer. Kad god se izvrava neki upit, ako se odgovarajui
blok indeksa nalazi u baferu, podaci se uitavaju iz njega.
U suprotnom, blok indeksa mora da se uita iz datoteke na
disku u bafer za kljueve, to je sporije. Kada razmatramo
vrednost koju treba dodeliti parametru Key_buffer_size,
treba uzeti u obzir: ukupnu koliinu memorije s kojom
raspolaemo, da li se raunar koristi iskljuivo kao
MySQL server ili slui i za druge poslove. Autori su
merenjem performansi zakljuili da se na raunaru koji
radi iskljuivo kao MySQL server, parametru
Key_buffer_size dodeli vrednost u opsegu izmeu 30% i
40% raspoloive RAM memorije.
Vrednost opcije Table_cache odreuje maksimalan broj
tabela koje mogu biti otvorene u isto vreme. Kod
MyISAM tabela, svaka tabela i svaki indeks su zasebne
datoteke u operativnom sistemu. Budui da je otvaranje i
zatvaranje datoteka spora operacija, te datoteke ostaju
otvorene dok ne bude zahtevano zatvaranje, server
sputen, ili dok ukupan broj otvorenih tabela ne premai
vrednost parametra Table_cache. Poveavanje vrednosti
parametra Table_cache korisno je kada na serveru imamo
veliki broj tabela.
Osim tih globalnih memorijskih bafera, pojedinim
nitima se takoe dodeljuju blokobi memorije, kao to su ,
na primer, bafer za sortiranje i bafer za itanje. U bafer za
itanje, ija se veliina odreuje parametrom
Read_buffer_size, smetaju se podaci iz tabele kada se
njen sadraj ita sekvencijalnim redosledom (table scan).
to se vie podataka iz tabele moe smestiti u bafer, to e
biti manji broj operacija itanja sa diska. Meutim, ako je
vrednost tog parametra previsoka, grupa bafera za itanje,
koje niti koriste, moe potriti previe memorije.
Istraivanja su pokazala da veliina bafera za itanje ne bi
trebalo da prelazi 20% raspoloive RAM memorije. Bafer
za sortiranje, iju veliinu odreuje parametar Sort_buffer,
koristi se pri izvravanju upita koji sadre odredbu Order
by. Ako sortiramo velike koliine podataka, treba poveati
bafer za sortiranje, ali i za njega vai isto upozorenje kao i
za bafer za itanje.
InnoDB tabela ciklino popunjava N datoteka dnevnika,
pri
emu
je
N
vrednost
zadata
opcijom
InnoDB_log_files_in_group. Podrazumevana vrednost za
N je 2 i preporuuje se. Opcija InnoDB_log_file_size
definie veliinu datoteka dnevnika.
S obzirom da se u projektovanom informacionom
sistemu obrauje dinamiko radno okruenje, autori
predlau da se kao server koristi raunarski sistem sa vie
diskova. Velike tabele i log fajlove InnoDB tabela treba

rasporediti na razliite diskove i praenjem njihovih

performansi ujednaiti optereenja.
Najnovija verzija MySQL-a podrava i replikaciju.
Autori predlau da se povee vie MySQL servera tako da
se zahtevi klijenata mogu preusmeriti na bilo koji od njih
[2]. Replikovanje moe znaajno da pobolja performanse
jer se izvravanje upita raspodeljuje na vie raunara.
V. OPTIMIZACIJA UPITA
MySQL omoguava da analiziramo upit da bismo
saznali za koje se vreme izvri i kako se tano izvrava nad
sadrajem baze podataka [3]. Najbolje je da se upit izvri
vie puta i da zatim izraunamo proseno vreme njegovog
trajanja. Budui da trajanje jednog izvravanja upita zavisi
od ukupnog optereenja sistema, rezultati samo jednog
merenja nemogu se uzeti kao validni.
Identifikovanje sporog upita vri se posmatranjem
izvravanja 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, pomou
ugraene funkcije Benchmark().
Pomou dnevnika sporih upita moemo utvrditi koji se
upiti presporo izvravaju. Beleenje sporih upita u dnevnik
moemo ukljuiti pomou opcije
Log_show_queries=ime_datoteke
koja je sastavni deo datoteke opcija. Ako ukljuimo i
opciju Log_Long_Format, bie evidentirani i svi upiti pri
ijem se izvravanju ne koristi nijedan indeks. To nam
ukazuje emu treba da posvetimo najvie panje pri
optimizaciji.
Zadavanjem vrednosti promenjivoj Long_query_time
odreujemo ta je za nas spot upit. Vrednost se zadaje u
konfiguracionoj datoteci ili pomou komande Set.
Vrednost te promenjive izraava se u sekundama.
Dnevnik sporih upita moemo itati neposredno jer je to
obina tekstualna datoteka. Jedno od tekuih ogranienja
MySQL-a jeste to da ne belei spore upite ije izvravanje
traje manje od sekunde.
Na sistemima koji obrauju relativno veliki broj
jednostavnih upita, jedna sekunda traje veoma dugo.
Autori smatraju da je u takvoj situaciji poeljno znati
kojim upitima je potrebno vie od desetinke ili nekog
drugog dela sekunde. To je posebno bitno kada se
obrauju tabele koje sadre naloge proizvodnje, transporta
ili prodaje. Tada se generie vie upita za svaku ranije
spomenutu tabelu. Da bi pratili i takve upite, autori
predlau promenu MySQL izvornog koda i beleenje upita
u dnevnik sporih upita ije izvravanje traje vie od
desetinke sekunde.
MySQL poseduje ugraeni mehanizam optimizovanja
upita. Pomou komande Explain moemo saznati kako
MySQL tano izvrava upit da bismo zatim pokuali da ga
optimizujemo. Komanda Explain nalae MySQL-u da
objasni kako namerava da izvri upit.
Na osnovu procenjenog broja redova (koji prikazuje
komanda Explain), MySQL utrvuje koji bi bio najbolji
redosled spajanja tabela. Ako smatramo da je njegova

566

procena pogrena, odredbom Straight Join izriito

zadajemo redosled spajanja tabela. Merenjem performansi
upita pre i posle te izmene, utvrdiemo da li time
aplikaciju poboljavamo ili pogoravamo.
Uzrok broj jedan loih performansi jeste upotreba tabela
kojima nije pridruen nijedan indeks ili nema indeksa za
kolone koje pretraujemo. S druge strane, potrebno je
veliko vreme da bi se aurirao veliki broj indeksa svaki put
kada se u tabelu upie novi red ili aurira postojei. Kada
uitavamo podatke, indeksi su veoma korisni. Kada
upisujemo nove redove, odnosno auriramo neki podatak
ili briemo postojee redove, indeksi se auriraju to
produava obradu i poveava optereenje sistema.
Kada bira indeks, MySQL trai odgovarajui indeks koji
obuhvata manje od 10% redova tabele. Ako ne uspe da
pronae indeks koji ispunjava te uslove, sekvencijalno
pretrauje tabelu. S obzirom da se u projektovanom
informacionom sistemu koriste tabele koje imaju po
nekoliko
stotina
hiljada
redova,
predodreeno
sekvencijalno pretraivanje nije prihvatljivo sa aspekta
performansi. Autori su vrili testiranje performansi kada se
koristi indeks koji obuhvata i vie procenata redova tabele.
Pokazalo se da je za tabele koje sadre preko 700 hiljada
redova bolje koristiti indeks koji obuhvata i do 15%
redova tabele. Takoe, pokazalo se da je za tabele koje
sadre oko 400 hiljada redova povoljnije korienje
indeksa koji obuhvata 12% redova tabele. Autorima je
jasno da stvaranje takvih indeksa troi procesorsko vreme,
ali su takvi indeksi posebno korisni u upitima koji ne
menjaju stanje tabela. Ako se potpun rezultat upita moe
dobiti iz podataka sadranih u indeksima, iz tabela se nee
uitati nijedan red.
U radu [4] je pokazano da se Visual Age Generator
moe uspeno koristiti za kreiranje vienivovskih klijentserver aplikacija nad MySQL bazom podataka. Sistemi
razvijeni u dvoslojnoj arhitekturi nezadovoljavajue
podravaju veliki broj korisnika, veliki obim transakcija i
nepredvidivo radno optereenje za Internet i Intranet
aplikacije. Savremene aplikacije pomeraju veinu poslova,
kao to su procesiranje, podatke i funkcije sa desktop
raunara na aplikacione servere. Visual Age Generator
obezbeuje visoke performanse koje se postiu optimalnim
iskorienjem svih segmenata informacionog sistema uz
vertikalnu podelu poslova od servera do radne stanice. Iz
tog razloga autori predlau da se za razvoj aplikacija u
razmatranom realnom sistemu koristi Visual Age
Generator.
VI. OPTIMIZACIJA TABELA
Tokom upotrebe baze podataka, u datotekama u kojima
se uvaju podaci raste broj praznina izmeu blokova
podataka na mestima gde su ranije bili izbrisani zapisi ili
odakle su zapisi premeteni zato to su nakon auriranja
postali vei. Te praznine su uzrok slabije efikasnosti.
Trebalo bi da povremeno upotrebimo komandu
Optimize table ime_tabele;
koja je MySQL-ov ekvivalent komande za
defragmentaciju vrstog diska. Tako emo preurediti

podatke u datotekama, ponovo sortirati indekse i aurirati

statistike podatke o tabeli.
Da bi smanjio broj spojeva koji se uspostavlja u
najeim
upitima
treba
razmotriti
mogunost
denormalizacije tabela. Treba imati na umu da e
denormalizacija pored ubrzavanja najeih upita kao
posledicu imati i redudansu podataka, pa pri tome treba
biti veoma oprezan. Takoe treba razmotriti mogunost
kompresije podataka da bi se smanjio broj U/I operacija.
A. Denormalizacija
Normalizovana baza podataka minimizira probleme
integriteta. Nezadovoljavajue performanse su jedini
razlog da se pristupi denormalizaciji. Svaka odluka o
denormalizaciji mora biti dokumentovana, ukljuujui i
razloge odluke i promene koje su izvrene u odnosu na
normalizovan logiki model.
Tabele za izvetavanje su idealne za
smetanje rezultata viestrukih spajanja
tabela, meuzavisnih podupita ili ostalih
sloenih SQL izraza. Tabele za izvetavanje
su pogodne za brzo kreiranje esto
korienih izvetaja. Autori predlau da se
formiraju tabele sa izvedenim podacima koji
direktno ukazuju na bilanse prometa
proizvoda i usluga.
Horizontalna podela tabele na dve ili vie
tabela. U razmatranom realnom sistemu
uoena je potreba horizontalne podele tabele
Narudbe na dve tabele: Velike_Narudbe
sa iznosima preko 100.000,00 dinara i
Male_Narudbe sa iznosima do 100.000,00
dinara. Narudbama iji iznosi prelaze
100.000,00 dinara time e se obezbediti
bolje performanse i poseban tretman.
Vertikalna podela tabele odvaja samo neke
kolone u nove tabele. Jedan skup kolona se
smeta u jednu tabelu, a drugi skup u drugu
tabelu. Primarni klju tabele se smeta u obe
tabele. Tabela sa matinim podacima o
poslovnim partnerima sadri pored najee
korienih podataka (raun i naziv firme)
mnogo drugih podataka kao to su ifra
delatnosti, adresa, oblik svojine, vlasnik,
direktor, osoba za kontakt, itd. Autori
predlau da se formiraju dve tabele:
Poslovni_partner_I sa kolonama raun i
naziv_firme i Poslovni_partner_II sa svim
podacima. U predloenom reenju naziv
firme se nalazi u obe tabele jer autori
smatraju da e na taj nain obezbediti bolje
performanse.
Deljenje dugakih tekstualnih kolona moe
da pobolja performanse. Opis artikla moe
biti dugaak npr. 200 karaktera, ali mnogi
artikli imaju opis od samo 20 karaktera a
ostali artikli se esto koriste sa skraenim
opisom koji je takoe do 20 karaktera. U
ovom sluaju moemo podeliti ovu tabelu na

567

dve, deljenjem kolone opisa na dve kolone.

Jedna od njih e sadrati 20 karaktera
(skraenog) opisa a u drugoj tabeli sa istim
primarnim kljuem kreirae se kolona za iri
opis artikla.
Prethodno spojene tabele samo jednom
spajanjem optereuju sistem (u fazi kreiranja
spoja). Nad unapred spojenim tabelama upiti
se izvravaju znatno efikasnije jer su tabele
ve spojene i prilagoene zahtevu upita.
Prethodno spojene tabele su korisne kod
relativno statikih podataka. Kod dinamikih
i esto promenjivih tabela prethodno spojene
tabele mogu i da pogoraju performanse.
Sagledavajui sve aspekte realnog sistema,
autori nisu predloili formiranje spojenih
tabela.

B. Kompresija
Kompresija se moe koristiti za smanjenje veliine baze
podataka. Komprimovanjem podataka baza podataka
zahteva manje prostora na disku. Mada se komprimovanje
na prvi pogled ini korisno, trebalo bi ga primenjivati
samo za neke aplikacije, jer se komprimovane tabele mogu
samo itati. Ako je potrebno da izmenimo strukturu
komprimovane tabele, ili da auriramo podatke u njoj, ili
da joj dodamo nove podatke, moramo da dekomprimujemo
celu tabelu, unesemo odgovarajue izmene i zatim ponovo
komprimujemo tabelu. MyISAM tabele mogu se
komprimovati primenom Hafmanovog koda i vie
optimizacija iji je cilj saimanje kolona, na primer,
konverzijom postojeih tipova podataka u manje, i
konverzijom 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 oko
30% (podatak dobijen tokom istraivanja). U tom sluaju,
nekomprimovani slog od 800 bajtova e zauzeti samo 560
bajtova nakon kompresije. Posle kompresije, sedam takvih
slogova e se smestiti na stranicu od 4K. Zbog toga to U/I
operacije rade na nivou stranica, jedna takva operacija e
proitati vie podataka, to e optimizovati performanse
sekvencijanog itanja podataka i poveati verovatnou
ostajanja podataka u keu zato to se vie slogova nalazi na
fizikoj stranici.
Kompresija nije reenje za svaku tabelu baze podataka.
Za manje koliine podataka, moe se desiti da je
komprimovana datoteka vea od nekomprimovane. Uzrok
tome su dodatni podaci koji govore o strukturi
komprimovanih podataka. Za male koliine podataka,
veliina tih struktura moe biti vea od prostora koji se
dobija kompresijom.

Autori predlau da se u razmatranom informacionom

sistemu komprimuju podaci Stavki (rauna, partije, naloga
proizvodnje, narudbe, magacinske pozicije, itd) koji se
odnose na prethodne mesece i nisu vie predmet aktivnog
praenja.
VII. ZAKLJUAK
Istraivanje je pokazalo da se uspeno upravljanje
performansama moe postii samo proaktivnim planom.
Mnogi problemi mogu se identifikovati i odrediti reenja
unapred.
Upravljanje performansama podrazumeva optimizaciju
upita, tabela i servera MySQL baze podataka. Autori
predlau izmenu izvornog koda MySQL-a i optimizovanje
upita koji traju manje od jedne sekunde, kao i izmenu
izvornog koda MySQL-a da bi se koristio indeks koji
obuhvata i do 15% redova velikih tabela. Autori predlau
primenu denormalizacije i kompresije podataka da bi se
postiglo proaktivno upravljanje performansama. Autori
predlau korienje Visual Age Generatora za stvaranje
vienivovskih klijent-server aplikacija nad MySQL bazom
podataka.
LITERATURA
[1]

[2]

[3]

[4]

D. Simi, D. Starevi, Upravljanje performansama sloenih

informacionih sistema XI Konferencija INFO-TEH, str94-98,
Donji Milanovac, 1996.
B. Lovevi, D. Obradovi, K. Bonjak, Jedan pristup
raspoloivosti MySQL baze podataka, Simpozijum INFO-TEH,
Jahorina, 2006.
B. Lovevi, K. Bonjak, D. Obradovi, Analiza kvaliteta Open
Source SUBP na osnovu mogunosti izvravanja sloenih
upitaSimpozijum INFO-TEH, Jahorina, 2006.
B. Lovevi, D. Obradovi, K. Bonjak, Korienje Visual Age
Generatora za stvaranje vienivovske klijent- server aplikacije,
Konferencija ETRAN, Beograd, 2006.

ABSTRACT
Performance management is primary objective for
administrators of data base. Performance management of
data base is not an activity which could be done
permanently, but we have a case of proactivity, a continuos
and iterative process which lasts as long as the
exploatation of data base. Performance management of
MySQL data base asks for a lot of compromising. The
fondation of the best solutions was the autors priority aim.

568

PERFORMANCE MANAGEMENT OF MYSQL

DATA BASE
Blagodar Lovevi, Danilo Obradovi, Krstan Bonjak