SVEUČILIŠTE JOSIPA JURJA STROSSMAYERA U OSIJEKU
ELEKTROTEHNIČKI FAKULTET
Sveučilišni preddiplomski studij računarstva
ANALIZA EFIKASNOSTI POHRANJIVANJA U
BAZAMA PODATAKA
Završni rad
Marin Relatić
Osijek, 2010
SADRŢAJ
1. UVOD ............................................................................................................................. 1
2. ARHITEKTURA MYSQL MEHANIZMA POHRANJIVANJA .................................. 2
2.1. Zaključavanje i istodobnost .................................................................................... 3
2.2. Transakcije ............................................................................................................. 4
2.3. Usporedba transakcijskih i netransakcijskih mehanizama pohranjivanja .............. 5
3. MYSQL MEHANIZMI POHRANJIVANJA ................................................................. 6
3.1. MyISAM mehanizam pohranjivanja ...................................................................... 7
3.2. InnoDB mehanizam pohranjivanja ........................................................................ 11
3.3. Ostali mehanizmi pohranjivanja ............................................................................ 14
4. OPIS I RJEŠENJE PROBLEMA .................................................................................... 17
5. POSTIGNUTI REZULTATI .......................................................................................... 19
6. ZAKLJUČAK ................................................................................................................. 20
Literatura ........................................................................................................................ 21
Saţetak ............................................................................................................................ 22
Ţivotopis ......................................................................................................................... 23
Prilozi.............................................................................................................................. 24
1
1. UVOD
Cilj ovog rada je upoznavanje koncepta mehanizma pohranjivanja u bazama podataka
(konkretno u MySQL-u), usporedba i opis prednosti i nedostataka pojedinih mehanizama
pohranjivanja te izvedba analize efikasnosti najčešće korištenih mehanizama. Potrebno je
usporediti konačne rezultate analize dva najznačajnija mehanizma pohranjivanja sa memory
mehanizmom pohranjivanja, koji zbog svojih svojstava predstavlja najbrţi mehanizam.
Odabir konkretnog mehanizma pohranjivanja omogućuje bolje performanse eliminiranjem
nepotrebnih opterećenja, te je stoga potrebno poznavati mogućnosti koje pojedini mehanizam
nudi kao i zahtjeve korisnika baze podataka.
Rad je podijeljen u četiri poglavlja. Prva dva poglavlju pruţaju teorijsku podlogu potrebnu za
shvaćanje principa mehanizma pohranjivanja i rješenje danog problema. U trećem poglavlju je
podrobnije predstavljen problem te detaljno opisani koraci u rješavanju. U posljednjem su
poglavlju prikazani i objašnjeni dobiveni rezultati.
2
2. ARHITEKTURA MYSQL MEHANIZMA POHRANJIVANJA
Mehanizam pohranjivanja (database engine ili storage engine) je inherentna komponenta
softvera koju upravljački sustav baza podataka, tj. DBMS (Database management system) koristi
za obavljanje CRUD (Create, Read, Update and Delete) operacija, tj. kreiranje, dohvaćanje,
izmjenu te brisanje podataka iz baze podataka. DBMS je skup programa koji kontroliraju
kreiranje, odrţavanje i korištenje baze podataka. Mehanizam pohranjivanja često se naziva i tip
tablice.
MySQL arhitektura uključivih mehanizama pohranjivanja omogućuje izabiranje specijalnog
mehanizma pohranjivanja za pojedinu aplikaciju bez potrebe za izmjenom koda same aplikacije.
MySQL arhitektura servera odvaja programera aplikacija i DBA od svih niţih detalja
implementacije na razini mehanizama pohranjivanja, pruţajući time konzistentan i jednostavan
model i API. Arhitektura uključivih mehanizama pohranjivanja pruţa standardan skup usluga
podrške i upravljanja koje su zajedničke svim inherentnim mehanizmima pohranjivanja. Sam
mehanizam pohranjivanja je ona komponenta servera baze podataka koja izvršava procese na
inherentnim podacima koji su sačuvani na fizičkoj razini servera. Ova učinkovita i modularna
arhitektura pruţa goleme prednosti za one koji ciljaju na specifične zahtjeve aplikacije, kao što
su skladištenje podataka ili transakcijsko procesiranje, dok omogućuje prednosti korištenja skupa
sučelja i usluga koji su nezavisni od bilo kojeg mehanizma pohranjivanja. Programer aplikacija i
DBA interaktira sa MySQL bazom podataka preko connector API-a i usluţnog sloja koji su
iznad sloja mehanizama pohranjivanja. Ukoliko izmjene aplikacije zahtijevaju promjenu
mehanizma pohranjivanja, ili da je potrebno dodati jedan ili više mehanizam pohranjivanja, nije
potrebno značajno programiranje ili izmjena procesa. MySQL arhitektura servera izolira
aplikacije od kompleksnosti mehanizama pohranjivanja pruţanjem konzistentnog i jednostavnog
API-a.
Mehanizam pohranjivanja je komponenta MySQL servera baze podataka koja je odgovorna
za ulazno/izlazne operacije u bazi podataka, kao i za omogućavanje i poboljšanje pojedinih
skupa mogućnosti koje pojadina aplikacija traţi. Velika prednost korištenja konkretnog
mehanizma pohranjivanja je bolja učinkovitost i perfomanse baze podataka jer se koriste samo
potrebne mogućnosti mehanizma pohranjivanja. U tablici 2.1. mogu se vidjeti osnovna svojstva
pojedinog mehanizma pohranjivanja.
3
Tab. 2.1. Usporedba različitih mehanizama pohranjivanja
Svojstvo MyISAM Memory BDB InnoDB
Transakcija ne ne da da
Razina
zaključavanja
tablica tablica Stranica (8 KB) redak
Spremanje odvojene
datoteke
direktno u
memoriju
datoteka po
tablici
tablični prostori
Razina
izoliranosti
nijedna nijedna izvršeno čitanje sve
2.1. Zaključavanje i istodobnost
Zaključavanje sluţi kako bi se spriječila pojava korumpiranih podataka, te omogućilo pristup
bazi podataka od više korisnika sa različitim zathjevima. Zaključavanje dijelimo na
zaključavanje od strane operacije čitanja, koje je zajedničko, te od strane operacije pisanja, koje
je ekskluzivno. Prema tome, više korisnika moţe čitati iz tablice istovremeno, dok samo jedan
korisnik istovremeno moţe aţurirati podatke ili brisati podatke iz tablice, pa i samu tablicu.
Zaključavanje i istodobnost su dva povezana pojma. Dobar sustav zaključavanja omogućuje
visoku istodobnost. Jedan način da se poveća istodobnost je povećanje zrnatosti zaključavanja.
Umjesto zaključavanja čitavih tablica, zaključava se samo dio koji sadrţi potrebne podatke koji
se koriste. Na ovaj način, dopušta se više izmjena nad tablicom istovremeno. Loša strana ovog
pristupa je smanjenje performansi. Stoga je potrebno pronaći ravnoteţu izmeĎu potrebnih
performansi i potrebne zrnatosti zaključavanja. U MySQL-u postoje tri tipa zaključavanja, na
nivou tablice, na nivou stranice i na nivou retka. Najjednostavnije zaključavanje, koje ujedno
najmanje opterećuje brzinu izvršavanja operacija, je zaključavanje na nivou tablice. Ovim
zaključavanjem se zaključava čitava tablica. Zaključavanje na nivou stranice zaključava dio
tablice zvan stranica. Zaključavanje na nivou retka pruţa najbolju zrnatost zaključavanja, ali
ujedno i najviše usporava izvršenje operacija.
InnoDB koristi napredniji oblik zaključavanja na nivou retka, kontrolu multi-verzijske
istodobnosti. Ovaj oblik omogućuje čitanje bez zaključavanja dok se istovremeno zaključavaju
potrebni podaci samo pri aţuriranju. Multi-verzijska istodobnost funkcionira na način da svaka
operacija nad tablicom vidi samo snimak podataka koji su postojali u trenutku započinjanja
operacije., nebitno koliko dugo operacija trajala. Kako bi se ovo omogućilo, svakom retku se
pridruţuju dodatne dvije vrijednosti. Ove vrijednosti govore kad je redak nastao i kad je izbrisan.
Prva vrijednost se naziva creation id, a drugi deletion id. MeĎutim, umjesto spremanja samog
4
vremena, baza podataka sprema broj verzije u trenutku pojedinog dogaĎaja. Verzija baze
podataka, ili verzija sustava, je broj koji se povećava svaki put kada započinje nova transakcija.
Zadaća servera je praćenje svih operacija i njima pridodanih brojeva verzije. Prilikom operacije
SELECT, server mora provjeriti tri kriterija. OdreĎeni redak mora imati creation id manji ili
jednak verziji baze podataka, čime se osigurava da je redak nastao prije početka operacije.
TakoĎer deletion id, ukoliko nije null vrijednost, mora biti veći od verzije baze podataka. Ovime
se osigurava da redak nije obrisan prije početka operacije. Da bi se osiguralo da redak nije dodan
ili mijenjan od operacije koja je još u tijeku, creation id ne smije biti u listi aktualnih operacija.
Prilikom operacije INSERT, verzija baze podataka postaje creation id zadanog retka, dok pri
operaciji DELETE verzija baze podataka postaje deletion id zadanog retka. Operacijom
UPDATE, server stvara novu kopiju retka koristeći verziju baze podataka kao novi creation id
zadanog retka, te kao stari deletion id. Rezultat kontrole multi-verzijske istodobnosti je da
operacije čitanja ne zaključavaju tablice, stranice niti retke, već jednostavno što je brţe moguće
pregledavaju samo one retke koje zadovoljavaju spomenute uvjete. Naravno, negativna
posljedica je korištenje nešto više memorije za spremanje dodatnih podataka za svaki pojedini
redak, kao i više posla prilikom obraĎivanja retka. U tablici 2.2. mogu se vidjeti svojstva
različitih tipova zaključavanja.
Tab. 2.2. Usporedba različitih tipova zaključavanja
Tip zaključavanja Istodobnost Opterećenje Mehanizam
pohranjivanja
Na nivou tablice Najniţe Najniţe MyISAM, Memory,
Merge
Na nivou stranice Srednje Srednje BDB
Multi-verzijsko Najviše Najviše InnoDB
2.2. Transakcije
Transkakcija je skup SQL procesa koji se tretiraju kao pojedinačna jedinica rada. Transakcija
je pokrenuta sa begin naredbom, i primijenjena sa coommit naredbom ili poništena sa rollback
naredbom. Same transakcije ne pruţaju dovoljnu sigurnost serveru baze podataka ukoliko server
ne zadovoljava četiri ACID svojstva. ACID predstavlja atomnost,konzistentnost, izoliranost i
trajnost, te se takve transakcije često nazivaju ACID transakcije. ACID transakcije dodatno
opterećuju memoriju i brzinu, te ukoliko nisu potrebne moguće ih je isključiti. Atomnost je
5
svojstvo transakcije da funkcionira kao pojedinačna neraskidiva jedinica rada. Kada je
transakcija atomna, ne postoji mogućnost djelomično odraĎene transakcije. Transakcija ili je
primijenjena ili je poništena. Konzistentnost je svojstvo koje osigurava da baza podataka slijedi
jednu konzistentnu naredbu za drugom, te ukoliko transakcija nije izvršena, nikakve promjene od
strane transakcije neće biti primijenjene u bazi podataka. Izoliranost je svojstvo koje omogućuje
da sve dok transakcija nije izvršena, rezultati transakcije budu nevidljivi ostalim transakcijama.
MeĎutim, da ne bi bilo prejednostavno pobrinuli su se 4 nivoa izoliranosti: neizvršeno čitanje,
izvršeno čitanje, ponavljano čitanje i serializacija. Ova 4 nivoa odreĎuju koje su promjene
vidljive ostalim transakcijama, a koje ne. Povećanjem razine izoliranosti sprečavaju se pojave
prljavih čitanja, tj. čitanje promjena neizvrsenih transakcija, neponavljanih redaka, tj. promjena
podataka izmeĎu naredba selektiranja i aţuriranja, te pojave fantomskih redaka. U tablici 2.3.
prikazana je usporedba različitih razina izoliranosti.
Tab. 2.3. Razine izoliranosti
Razina izoliranosti Vidljivi rezultati
neizvršenih
transakcija
Pojava
neponavljanih
redaka
Pojava fantomskih
redaka
Neizvršeno čitanje da da da
Izvršeno čitanje ne da da
Ponavljano čitanje ne ne da
Serializacija ne ne ne
Trajnost je svojstvo koje osigurava da su rezultati izvršene transakcije postojani. To znači da
podaci moraju biti spremljeni na način da prilikom pada sustava ne doĎe do gubitka podataka.
Naravno, ovo nema koristi u slučaju kvara na tvrdom disku servera baze podataka.
Kada god više transakcija dobiju pravo na zaključavanje, postoji opasnost potpunog zastoja.
Do zastoja dolazi kada dvije transakcije pokušavaju dobiti pravo na dva proturječna tipa
zaključavanja različitim redoslijedom. Kako ne bi došlo do ove pojave, koristi se više vrsta
detektiranja zastoja i vremenska ograničenja transakcija.
2.3. Usporedba transakcijskih i netransakcijskih mehanizama pohranjivanja
Transakcijski mehanizmi pohranjivanja su sigurniji. Čak i u slučaju zastoja MySQL-a ili
problema sa sklopovljem, moguće je spasiti podatke. TakoĎer sa transakcijskim mehanizmima
pohranjivanja moguće je korištenje rollback operacije radi poništavanja izmjena. U slučaju
6
neuspjeha aţuriranja, sve promjene se poništavaju. Transakcijski mehanizmi pohranjivanja
pruţaju bolju istodobnost za tablice na kojima se vrši mnogo aţuriranja i čitanja istovremeno.
MeĎutim, netransakcijski mehanizmi pohranjivanja su puno brţi, zahtijevaju manje prostora na
disku, te je potrebno manje memorije za izvršavanje aţuriranja.
7
3. MYSQL MEHANIZMI POHRANJIVANJA
3.1. MyISAM mehanizam pohranjivanja
MyISAM je standardni mehanizam pohranjivanja u MySQL-u. Nastao je na temelju starijeg
koda ISAM, te je proširen sa mnogim korisnim ekstenzijama. Ovaj mehanizam pohranjivanja sa
svojom jednostavnom strukturom, pruţa kompromis izmeĎu performansi i korisnih dodataka.
Svaka baza podataka je direktorij, sa svakom tablicom spremljenom u zaseban skup datoteka.
MyISAM tablice ne podrţavaju mogućnost transakcije, niti jako zrnast model zaključavanja, ali
imaju full-text indeksiranje, kompresiranje itd..
Svaka MyISAM tablica je spremljena na disk u tri datoteke. Imena datoteka imaju isto ime
kao i tablica ali se razlikuju po ekstenzijama koje označavaju o kojem tipu podatka se radi.
MySQL koristi .frm datoteku za spremanje definicije tablice. MeĎutim, ova datoteka nije dio
MyISAM engine-a već servera. Podatkovna datoteka ima ekstenziju .MYD (MYData), dok
datoteka .MYI (MYIndex) sadrţi indekse koji pripadaju tablici te pojedine statističke podatke za
tablicu. Na slici 3.1. prikazan je princip spremanja MyISAM tablice.
Sl. 2.1. Prikaz spremanja MyISAM tablice
mysqld
DATADIR
baza_podataka_1 baza_podataka_2
tablica_1 tablica_2 tablica_3
baza_podataka:3
DATADIR/Baza_podataka_2/tablica_2.frm
DATADIR/Baza_podataka_2/tablica_2.MYD
DATADIR/Baza_podataka_2/tablica_2.MYI
8
MyISAM tablice mogu biti sačinjene od dinamičnih ili statičnih redaka. Statični redci su redci
konstantne duljine, dok je kod dinamičnih redaka duljina promjenjiva. Ovisno o definiciji same
tablice, MySQL odlučuje koji tip redaka će koristiti. Maksimalni broj redaka koji MyISAM
tablica moţe sadrţavati ovisi prvenstveno o slobodnom prostoru na serveru te o maksimalnoj
veličini dokumenta koju odreĎeni operacijski sustav dopušta. MeĎutim zbog učinkovitosti,
MyISAM tablice sa redcima promjenjive veličine imaju zadanu maksimalnu veličinu od 4 GB.
Budući da je MyISAM jedan od najstarijih mehanizama pohranjivanja u MySQL-u, tijekom
vremena je razvijeno nekoliko korisnih mogućnosti radi zadovoljavanja potreba korisnika i
ispravljanja nedostataka. Automatsko popravljanje (automatic repair) omogućuje pregled i
popravak tablica. Ako je MySQL pokrenut sa myisam-recover opcijom, pri prvom otvaranju
MyISAM tablice, pregledava se tablica kako bi se provjerilo je li pri prijašnjem korištenju
ispravno zatvorena. Ako nije, a razlog je vjerojatno problem sa sklopovljem ili napajanjem,
MySQL skenira tablicu te pri pronalasku pogreške automatski popravlja tablicu. Nedostatak ove
opcije je naravno što se mora sačekati dok se tablica popravlja. MyISAM takoĎer pruţa
mogućnost ručnog pokretanja popravka preko naredbi CHECK TABLE i REPAIR TABLE. U
slučaju kada je server isključen, za pronalazak i ispravak pogrešaka se moţe koristiti myisamchk.
Zaključavanje se u MyISAM tablicama vrši na nivou tablica. Koristi se tri tipa zaključavanja.
Lokalno zaključavanje za čitanje se vrši od strane pretrage nad tablicama koje se samo čitaju.
Ovaj tip zaključavanje blokira tek aţuriranje tablice, kako bi se spriječila promjena podataka
prilikom pretrage tablice. Ostale pretrage mogu se nastaviti. Popunjavanje tablice, ukoliko se vrši
dodavanje podataka na kraj .myd datoteke, nije obuhvaćeno ovim tipom zaključavanja.
Zajedničko zaključavanje za čitanje blokira aţuriranje tablica, uključujući bilo kakvo
popunjavanje tablica. Najčešće se koristi u slučaju kada alat poput myisamcheck traţi direktan
pristup podacima u tablici. Ekskluzivno zaključavanje za pisanje se koristi od strane operacija
brisanja, aţuriranja te ponekad i popunjavanja. Svi ostali pristupi tablici, uključujući operacije
čitanja i pisanja, se blokiraju. Pod blokiranjem se podrazumijeva odgaĎanje pojedine operacije
dok se prvobitna ne izvrši.
Opcija DELAYED KEY WRITE omogućuje stvaranje tablica koje nemaju zapisane promjene
indeksa na disk. Kod ovih tablica promjene su sadrţane samo u unutarmemorijskom
meĎuspremniku ključa i puštene na disk kad su indeksirani blokovi isključeni iz meĎuspremnika
ključa ili kad su tablice zatvorene. Ova opcija znatno poboljšava performanse kod tablica koje se
često mjenjaju.
9
Sigurnosna kopija MyISAM tablica se kreira koristeći mysqldum ili mysqlhotcopy alat. U
slučaju pada sustava tablice sa redcima fiksne duljine jednostavnije je povratiti nego tablice sa
redcima promjenjive duljine. MeĎutim, prilikom pada sustava najčešće su samo indeksi
zahvaćeni, što se moţe rješiti jednostavnim i automatskim, iako ponekad dugotrajnim procesom.
U MyISAM tablicama, vrijednosti podataka su spremljene na način da se na prvo mjesto
stavlja donji byte. Ovime se postiţe neovisnost ureĎaja i operacijskog sustava. TakoĎer, ovakav
način spremanja podataka ne utječe znatno na brzinu pristupa podacima.
MyISAM koristi tri metode indeksiranja: b-stablo, r-stablo te fulltext. R-stabla se koriste za
indeksiranje geografskih (GIS) podataka, dok su fulltext indeksi specijalno usklaĎeni za MySQL
fulltext sustav pretrage. MyISAM tablica ima ograničenje od 1000 bajta po ključu, stoga indeks
zauzima svega nekoliko prvih bajtova u BLOB ili TEXT polju. MyISAM tablice omogućuju i
indeksiranje stupaca koje sadrţe NULL vrijednosti. Maksimalni broj indeksa po tablici je 64,
meĎutim to se moţe promijeniti do 128. Maksimalni broj stupaca po indeksu je 16. Pri sortiranju
redaka stablo indeksa je podijeljeno na način da gornji čvor sadrţi samo jedan ključ. Ovo
poboljšava iskorištenost prostora u stablu indeksa.
MyISAM koristi tri različita tipa pohranjivanja unutar osnovnog formata. Fiksno i dinamično
pohranjivanje odabire se automatski, ovisno o tipu stupca koji se koristi. Treći tip, kompresija,
obavlja se koristeći myisampack. Dekompresija tablica se vrši koristeći myisamchk naredbom
unpack.
Statični tip pohranjivanja je standardni format za MyISAM tablice. Koristi se kad tablice ne
sadrţe stupce promjenjive veličine, tj. varchar, varbinary, text ili blob tipove podataka. Svaki
redak je spremljen koristeći fiksni broj byteova, što za posljedicu ima izostanak problema
fragmentacije. Statični format je najjednostavniji i najsigurniji format. TakoĎer je i najbrţi, jer se
odreĎivanje pozicije odreĎenog retka vrši mnoţenjem fiksne duljine retka i rednog broja retka
što čini indekse manjima.
Dinamični tip pohranjivanja se koristi ukoliko tablica sadrţi stupce sa varchar, varbinary, text
ili blob tipom podataka. Svaki redak sadrţi zaglavlje u kojem se nalazi duljine retka. Iako ovaj
način znatno učinkovitije iskorištava memorijski prostor, prilikom brisanja pojedinog retka, ili
promjene veličine samog retka, pojavljuje se problem fragmentacije. U tom slučaju se koristi
myisamchk –r kako bi se defragmentirala tablica i poboljšale performanse. TakoĎer, korisno je
koristiti myisamchk –ei kako bi se dobilo pojedine statističke vrijednosti tablice.
10
Kompresirani tip retka moguće je samo čitati. Kompresirane tablice zauzimaju malo mjesta,
te su korisne kod sporih diskova, poput CD-ROM-a. Kreiraju se koristeći myisampack alat, dok
se dekompresiranje vrši koristeći myisamchk alat. Kompresirati se mogu i retci sa fiksnom
duljinom i sa promjenjivom duljinom. Maksimalni koeficijent kompresije iznosi 75%. Svaki
redak se kompresira pojedinačno, te se svaki stupac kompresira različito. Ovisno o
karakteristikama stupca razlikujemo nekoliko vrsta kompresiranja. Brojevi vrijednosti nula se
spremaju koristeći jedan bit. Ako je vrijednost cjelobrojnih stupaca manjeg ranga, stupac se
kompresira koristeći najmanji mogući tip cjelobrojnih podataka. Tako se tip bigint moţe
kompresirati kao tinyint ako su svi brojevi u rangu od -128 do 127. Ako stupac ima samo mali
skup mogućih vrijednosti, tip podatka se pretvara u enum. Dodatna dva tipa su kompresiranja su
sufiks i prefiks kompresiranje.
3.1.1. MyISAM merge mehanizam pohranjivanja
MyISAM merge tablica sama ne sadrţava podatke već se odnosi na skupinu identičnih
MyISAM podtablica koje se koriste kao jedna. Pod identičnim se misli da sve podtablice sadrţe
jednake informacije za stupce i indekse. Tako se ne mogu spojiti tablice u kojima su stupci
poredani različitim slijedom, nemaju jednak broj ili duţinu stupaca ili su indeksi različito
poredani. Budući da funkcionira kao union view, uvid u megre tablicu moţe se vršiti na jednoj ili
više podtablica. Unosi u tablice su takoĎer omogućeni. Merge tablice se najčešće koriste kod
analiziranja periodičnih podataka koji su spremljeni u više tablica. Spremanje takvih podataka u
jednu tablicu je nepraktično, uzimajući u obzir veličinu i rukovanje podacima.
Pri kreiranju merge tablice stvaraju se dvije datoteke na disku koja sadrţe jednako ime kao i
tablica. Datoteka sa ekstenzijom .frm sadrţi format tablice, dok .MRG datoteka sadrţi imena
podtablica. MyISAM podtablice ne moraju biti u istoj bazi podataka kao i merge tablica.
Suprotnost od merge tablica su particionirane tablice u kojima se dijelovi pojedine tablice
spremaju u odvojene datoteke.
11
3.2. InnoDB mehanizam pohranjivanja
InnoDB je jedan od najpopularnijih mehanizama pohranjivanja u MySQL-u. Najveća
prednost nad ostalim mehanizmima pohranjivanja je mogućnost ACID transakcije. ACID
(atomnost, konzistentnost, izoliranost, trajnost) predstavlja skup svojstava koja garantiraju da se
transakcije baza podataka odvijaju pouzdano.
InnoDB ima potpuno različitu arhitekturu od MyISAM-a, koja se temelji na konceptu
tabličnih prostora u koje se spremaju sve strukture, podaci i indeksi. Tablični prostor moţe
sadrţavati jednu ili više datoteka, čak i, iako ne često, neobraĎenu particiju diska. Korištenje
disk particije oteţava kreiranje sigurnosne kopije InnoDB tablica, i rezultira smanjenim
performansama. Svaki tablični prostor se sastoji od stranica standardne veličine od 16KB.
Stranice su grupirane u mjere od 1MB (64 uzastopnih stranica). „Datoteke“ unutar tabličnog
prostora zovu se segmenti. Dva segmenta su dodijeljena za svaki indeks u InnoDB. Budući da se
ne moţe odrediti gdje se unutar tabličnog prostora sprema tablica, pojavljuje se problem
fragmentacije. TakoĎer nasumično ubacivanje ili brisanje od strane sekundarnih indeksa moţe
dovesti do fragmentacije indeksa. Fragmentacija indeksa znači da fizički red stranica indeksa na
disku nije jednak poretku indeksa podataka na stranici, ili da ima puno neiskorištenih stranica u
64-straničnim blokovima koji su dodijeljeni indeksima. Jedan simptom fragmentacije je da je
tablici potrebno više prostora nego što bi trebalo. MeĎutim, točan iznos je teško odrediti. Svi
InnoDB podaci i indeksi su spremljeni u b-stabla, i njihov faktor popunjavanja varira izmeĎu
50% i 100%. Dodatna posljedica fragmentacije je da skeniranje tablice traje duţe nego što bi
trebalo. Kao alternativa tabličnim prostorima, i moguće rješenje fragmentacije, moguće je
spremiti InnoDB tablicu i njezine indekse u svojstvenu datoteku. Ova opcija se zove višestruki
tablični prostori, jer zapravo svaka novonastala tablica ima vlastiti tablični prostor. Višestruki
tablični prostori mogu biti korisni u slučaju potrebe spremanja tablica na različite diskove,
ubrzanja povrata podataka i slično.
InnoDB tablica razvrstava podatke na disku kako bi se optimizirala za najčešće upite na
temelju primarnih ključeva. Svaka InnoDB tablica ima indeks primarnog ključa koji se zove
klaster indeks. Zadaća ovog indeksa je organizacija podataka. Sa InnoDB mehanizmom
pohranjivanja svaka se aktivnost vrši unutar transakcije, tako da svaka naredba kreira vlastitu
transakciju.
ACID model InnoDB-a zahtjeva odreĎenu količinu I/O operacija, koje se mogu činiti
redudantnim, ali pomaţu u očuvanju pouzdanosti podataka. InnoDb optimizira rad baze podataka
12
i organizacije podataka na disku s ciljem minimiziranja potrebnih I/O operacija. Kad je moguće,
InnoDB koristi asinkrone I/O procese, kreiranjem odreĎenog broja niti za rukovanje I/O
operacijama, dok se ostalim procesima nad bazom podataka dopušta rad dok su I/O operacije u
tijeku.
U InnoDB transakcijskom modelu cilj je kombiniranje najboljih svojstava multi-verzijske
baze podataka sa tradicionalnim dvofaznim zaključavanjem. InnoDB vrši zaključavanje na razini
retka te izvodi upite kao nepromjenjivo čitanje bez mogućnosti zaključavanja. Informacije o
zaključavanju se spremaju sa iznimnom efikasnošću korištenja prostora, tako da eskalacija
zaključavanja nije potrebna. Ovo omogućava zaključavanje svakog retka od strane više korisnika
bez opterećivanja memorije. Ovisno o nivou izolacije, InnoDB ne zahtjeva nikakvo
zaključavanje za naredbu select. Za aţuriranje se koristi zaključavanje na razini redaka. Ovo
omogućava iznimno visoku razinu istodobnosti, meĎutim, zahtjeva tri puta više memorijskog
prostora nego što je to slučaj kod MyISAM mehanizma pohranjivanja, te veliki broj RAM
memorije za InnoDB meĎuspremnik. InnoDB koristi dva tipa zaključavanja. Zajedničko
zaključavanje dozvoljava transakciji čitanje retka. Izuzetno zaključavanje dozvoljava transakciji
aţuriranje ili brisanje retka. Ukoliko neka transakcija ima zajedničko zaključavanje na nekom
retku, druga transakcija ne mora nuţno biti stavljena na čekanje, kao što je to slučaj ukoliko prva
transakcija ima izuzetno zaključavanje na retku. InnoDB omogućava višestruko zrnasto
zaključavanje koje dopušta koegzistenciju zaključavanja na podacima i zaključavanja na cijeloj
tablici. Radi praktičnosti uveden je poseban tip zaključavanja, nazvan namjerno zaključavanje.
Ova vrsta zaključavanja sluţi za zaključavanje tablice.
InnoDB za indeksiranje koristi metodu b-stabla sa grupiranim primarnim ključem. Indeksi su
spremljeni u stranice koje su čvorovi stabla. Standardna veličina stranice za indeks je 16KB. Kad
je novi podatak ubačen, InnoDB pokušava ostaviti jednu šesnaestinu stranice slobodnu za
buduće umetanje ili aţuriranje indeksa.
3.2.1. Usporedba InnoDB i MyISAM mehanizma pohranjivanja
InnoDB se oporavlja od pada sustava ponavljajući operacije iz evidencije. MyISAM mora
potpuno skenirati ili rekreirati indekse ili tablice koji su bili aţurirani ali ne potpuno preneseni na
disk. InnoDB-ov pristup je fiksnog vremena, dok MyISAM-ovo vrijeme raste sa povećanjem
količine podataka u tablici. InnoDB sadrţi meĎuspremnik za spremanje podataka i indeska, dok
MyISAM sadrţi samo meĎuspremnik za indeske, dok se za podatke oslanja na operativni sustav.
InnoDB sprema podatke na disk poredane ovisno o primarnom ključu, dok MyISAM sprema
13
preteţno prema poretku dodavanja podataka u tablicu. Spremanje prema primarnom ključu moţe
biti vrlo korisno u vidu brzine ukoliko je ključ iazbran da dobro odgovara najčešćim
operacijama. Za razliku od MyISAM mehanizma pohranjivanja, InnoDB ne pruţa mogućnost
kompresiranja, meĎutim podrţava ACID transakcije. MyISAM koristi zaključavanje na razini
tablice za aţuriranje, dok InnoDB koristi zaključavanje na razini redaka. Za veće baze podataka
u kojima se često vrši aţuriranje zaključavanje na razini redaka je ključno jer zaključavanje na
razini tablice bitno smanjuje istodobnost. MeĎutim, u većini baza podataka u kojima se vrši
preteţno čitanje, te gdje stoga zaključavanje na razini redaka ne smanjuje bitno istodobnost,
dolazi do izraţaja veća brzina MyISAM mehanizma pohranjivanja. MyISAM za razliku od
InnoDB mehanizma pohranjivanja omogućuje full-text indeksiranje.
14
3.3. Ostali mehanizmi pohranjivanja
3.3.1. Archive
Archive mehanizam pohranjivanja koristi se za pohranjivanje velike količine podataka bez
indeksa (in a very small footprint). Prilikom kreiranja archive tablice, server stvara nekoliko
novih datoteka koje sve imaju ime jednako imenu tablice. Datoteka sa ekstenzijom .frm sadrţi
format tablice dok su podaci spremljeni u .ARZ datoteku. Prilikom operacija optimatizacije se
pojavljuje .ARN datoteka. Archive mehanizam pohranjivanja omogućava ubacivanje i
selektiranje podataka, ali ne i brisanje, zamjenu i aţuriranje. Omogućavanje archive mehanizma
pohranjivanja se vrši preko configure-a sa –with-archive-storage-engine opcijom.
3.3.2. BerkeleyDB
BerkeleyDB, ili BDB, mehanizam pohranjivanja razvijen je od strane Sleepycat Software, te
je od MySQL 5.1 verzije izbačen iz upotrebe. BerkleyDB je, osim InnoDB, jedini transakcijski
mehanizam pohranjivanja. Zaključavanje se vrši na nivou stranice, te stoga BDB mehanizam
pohranjivanja ima višu istodobnost od MyISAM mehanizma pohranjivanja. Prilikom kreiranja
tablica, BDB stvara dvije datoteke. Format tablice je spremljen u datoteci sa ekstenzijom .frm,
dok .db datoteka sadrţi podatke i indekse. BDB podrţava transakciju, kao i povrat na staro
poništavanjem transakcije.
3.3.3. Blackhole
Blackhole mehanizam pohranjivanja je dobio ime po tome što se prilikom pokušaja
ubacivanja podataka ponaša poput crne rupe. Naime, podaci se prihvaćaju ali se pritom odbacuju
i ne spremaju. Prilikom kreiranja nove blackhole tablice stvara se samo .frm datoteka koja sadrţi
format tablica. Blackhole mehanizam pohranjivanja omogućava korištenje svih vrsta indeksa.
Naravno, pritom se misli da je moguće uvrstiti deklaraciju indeksa u formatu tablice, jer se
ionako indeksi neće moći koristiti. Blackhole mehanizam pohranjivanja se koristi najčešće kao
filtar mehanizam ili repetitor. TakoĎer moţe se koristiti za verifikaciju sintakse dump datoteka,
te mjerenje opterećenja od strane binarnog evidentiranja.
15
3.3.4. CSV
CSV mehanizam pohranjivanja sprema podatke u tekstovne datoteke koristeći format pisanja
gdje su vrijednosti odvojeni zarezom. Prilikom kreiranja CSV tablice stvaraju se dvije datoteke.
Format tablice je spremljen u datoteci sa ekstenzijom .frm, dok se u .CSV datoteci spremaju
podaci iz tablice. Ukoliko nema podataka .CSV datoteka je prazna tekstovna datoteka. TakoĎer
se, prilikom stvaranja nove CSV tablice, kreira i odgovarajuća metafile datoteka koja sadrţi
stanje tablice kao i broj redaka koji postoje u tablici.
3.3.5. Example
Example mehanizam pohranjivanja je zamjenski mehanizam koji ne radi ništa. Njegova svrha
je da sluţi kao primjer u MySQL izvornom kodu kako bi se prikazalo kako početi pisati kod za
novi mehanizam pohranjivanja. Kao takav, sluţi samo programerima. Pri kreiranju example
tablice na disku se kreira datoteka sa ekstenzijom .frm koja sadrţi format tablice, te se nikakvi
podaci ne mogu spremati. Omogućavanje example mehanizma pohranjivanja se vrši naredbom
configure sa –with-example-storage-engine opcijom.
3.3.6. Federated
Federated mehanizam pohranjivanja omogućuje pristup podacima na lokalnom serveru sa
udaljenih MySQL baza podataka bez korištenja replikacije ili klastera. Tijekom korištenja
federated tablice, operacije na lokalnom serveru se automatski vrše na udaljenim tablicama.
Nikakvi podaci se ne spremaju na lokalnim tablicama. Tako se na lokalnom serveru nalazi samo
jedna datoteka sa ekstenzijom .frm koja sadrţi format tablice te konekcijski string koji pokazuje
na udaljenu tablicu, dok se na udaljenom serveru nalazi datoteka koja sadrţi format tablice kao i
sami podaci.Omogućavanje federated mehanizma pohranjivanja se vrši naredbom configure sa –
with-federated-storage-engine opcijom.
3.3.7. ISAM
ISAM (Indexed Sequential Access Method) je metoda indeksiranja podataka radi brzog
dohvaćanja. ISAM je razvio IBM (International Business Machines) za mainframe računala.
ISAM mehanizam pohranjivanja je prvobitni i jedini mehanizam pohranjivanja sve do izlaska
MySQL 3.23 verzije, kada je uvedena novija MyISAM verzija. ISAM omogućuje dva načina
pristupa redcima, sekvencijalno ili pomoću indeksa. Indeksi koji sadrţavaju pokazivače na retke,
16
omogućuju pristup pojedinom retku bez da se pretraţuje cijeli skup podataka. ISAM koristi
kompresirane ključeve fiksne duljine, te podrţava retke fiksne ili promjenjive duljine. Po tablici
je dopušteno korištenje maksimalno 16 indeksa, te 16 dijelova ključa po ključu. Najveća
maksimalna duljina ključa je 256 bajta. Za indeksiranje se koriste B-tree indeksi. Za razliku od
MyISAM mehanizma pohranjivanja, ISAM ne podrţava tablice veće od 4GB, kao niti merge
tablice.Svaka ISAM tablica je spremljena na disk u tri istoimene datoteke sa različitim
ekstenzijama. Datoteka sa ekstenzijom .frm sadrţi format tablice, dok .ISM datoteka sadrţi
indekse. Podaci su spremljeni u datoteci sa .ISD ekstenzijom.
3.3.8. Memory (HEAP)
Memory mehanizam pohranjivanja, poznat i pod imenom HEAP, stvara tablice čiji se
cjeloviti sadrţaj sprema direktno u memoriji. Naravno, ovime je ovaj način iznimno brz, ali
zahtjeva dostatnu količinu RAM-a. Iako je moguće kreirati privremenu tablicu, standardna
memory tablica je trajna te će se prilikom gašenja servera isprazniti, a ne obrisati u cijelosti.
Prilikom stvaranja memory tablice stvara se samo jedna datoteka na disku koja sadrţi format
tablice. Memory tablice podrţavaju hash i btree indeksiranje. TakoĎer koriste retke konstantne
duljine, te ne mogu sadrţavati text ili blob tipove stupaca.
3.3.9. NDB
MySQl Cluster je visoko uporabljiva i visoko redudantna verzija Mysql-a prilagoĎena okolini
distribuiranog računarstva. Kao mehanizam pohranjivanja koristi se NDB (Network Database)
koji omogućava rad više računala sa MySQL serverima i ostalim softverom u nakupini. Kada se
tablice spremaju pomoću NDB mehanizma pohranjivanja, tablice se, kao i podaci unutar tablice,
spremaju u podatkovne čvorove. Takvim tablicama moguće je direktno pristupiti sa svih drugih
MySQL servera (SQl čvorova) u nakupini. MeĎutim, MySQL server koji nije spojen u MySQL
nakupinu ne moţe koristiti NDB mehanizam pohranjivanja i ne moţe pristupiti podacima unutar
nakupine.
17
4. OPIS I RJEŠENJE PROBLEMA
Potrebno je kreirati jednake tablice koristeći MyISAM, InnoDB i memory mehanizme
pohranjivanja. Pod jednakim tablicama se podrazumijeva jednak broj redaka i stupaca, te jednaki
podaci unutar tablica. Nakon popunjavanja tablica sa podacima, potrebno je izvoditi različite
operacije nad tablicama, pritom prateći vrijeme koje je potrebno da se pojedine operacije izvrše.
Koristeći MySQL Query Browser kreirane su tri tipa tablica, MyISAM, InnoDB te memory.
Svaka tablica sadrţi četiri kolone, koje se popunjavaju nasumičnim vrijednostima. Popis naredbi
korištenih za kreiranje tablica nalazi se u prilogu 1.
Koristeći PHP, tablice su paralelno popunjavanje sa nasumičnim vrijednostima. Interval
mogućih vrijednosti je izmeĎu jedan i deset tisuća. Svaka tablica sadrţi jedan milijun redaka.
Korištene su tablice sa velikom količinom podataka kako bi se značajnije razlikovali dobiveni
rezultati. PHP kod popunjavanja tablica nalazi se u prilogu 2.
Nakon kreiranja i popunjavanja tablica izvršava se analiza efikasnosti pojedinog mehanizma
pohranjivanja. Ponovo koristeći MySQL Query Browser izvode se različite operacije nad
podacima unutar tablica. Kako bi se dobili precizniji rezultati, svaka operacije se izvodi deset
puta. MySQL Query Browser omogućuje uvid u vremena izvršavanja pojednih operacija. Pritom
su prikazane dvije vrijednosti. Prva vrijednost označava vrijeme potrebno da MySQL pošalje
serveru potrebne podatke, dok druga vrijednost označava vrijeme izvoĎenja same operacije.
Naredbe korištene u ovom koraku prikazane su u tablici 4.1. Cjeloviti kod nalazi se u prilogu 3.
Tab 4.1. Korištene naredbe za izvoĎenje pojedine operacije
Broj operacije Naredba
1. SELECT * FROM ime_tablice;
2. SELECT count(*) FROM ime_tablice;
3. SELECT COUNT(DISTINCT random_values1) FROM ime_tablice;
4. SELECT * FROM ime_tablice WHERE random_values1=random_values2 OR
random_values1=random_values3 OR random_values1=random_values4;
5. SELECT * FROM ime_tablice ORDER BY random_values1;
6. SELECT SUM(random_values1) FROM ime_tablice;
7. SELECT AVG(random_values1) FROM ime_tablice;
8. SELECT MIN(random_values1), MAX(random_values1) FROM ime_tablice;
9. SELECT MIN(random_values1),MAX(random_values1),
MIN(random_values2),MAX(random_values2), MIN(random_values3),
MAX(random_values3), MIN(random_values4), MAX(random_values4) FROM ime_tablice;
10. SELECT COUNT(*), COUNT(DISTINCT random_values2), AVG(random_values3),
AVG(random_values4) FROM ime_tablice;
18
Nakon izvoĎenja operacija izračunavaju se srednje vrijednosti izvoĎenja pojedinih operacija
nad svakom tablicom, te se rezultati usporeĎuju. U konačnici je potrebno izraziti rezultate
MyISAM i InnoDB mehanizama pohranjivanja u postotcima u odnosu na rezultate memory
mehanizma pohranjivanja kako bi se bolje izrazile razlike.
19
5. POSTIGNUTI REZULTATI
Postignuti rezultati su očekivani. Budući da se podaci spremaju unutar same memorije,
memory mehanizam pohranjivanja se pokazao najbrţi. Još uvijek iznimno brz, MyISAM
mehanizam pohranjivanja se pokazao za nijansu sporiji. Izuzetak je izvoĎenje prebrojavanja
redaka, gdje su rezultati identični. Ovo je rezultat činjenice da MyISAM, kao niti memory,
stvarno ne prebrojava retke poput InnoDB-a jer je broj redaka kod ovih mehanizama
pohranjivanja u svakom trenutku poznat. Postignuti rezultati prikazani su u tablici 5.1., dok se u
tablici 5.2. rezultati usporeĎuju sa rezultatima memory-a. Cjeloviti rezultati nalaze se u prilogu 4.
Tab 5.1. Vremena mjerenja
Redni broj operacije myisam innodb memory
1. 0,0016 0,0335 0,0014
2. 0,0004 1,0805 0,0004
3. 0,5710 1,5985 0,4322
4. 0,2941 1,4099 0,2119
5 0,9077 2,2902 0,6283
6. 0,2946 1,4246 0,2117
7. 0,2967 1,4035 0,2183
8. 0,2089 1,2110 0,1450
9. 0,4374 1,5907 0,3309
10. 0,9106 2,1400 0,7308
Tab. 5.2. Usporedba rezultata MyISAM i InnoDB mehanizma sa memory kao referentnom
točkom (rezultati su prikazani u postotcima u odnosu na memory mehanizam pohranjivanja)
Redni broj operacije myisam innodb
1. 114,29% 2392,86%
2. 100% 270125%
3. 132,12% 369,85%
4. 138,79% 665,36%
5 144,47% 364,51%
6. 139,16% 672,93%
7. 135,91% 642,92%
8. 144,07% 835,17%
9. 132,19% 480,72%
10. 124,60% 292,83%
20
6. ZAKLJUČAK
Rezultati analize pokazali su kako je MyISAM značajno brţi mehanizam pohranjivanja od
InnoDB. Posebno je naglašena veća brzina kod MyISAM mehanizma pohranjivanja u bazama
podataka gdje se često koristi selektiranje podataka, budući da se u tom području InnoDB
pokazao znatno inferiorniji. InnoDB mehanizam pohranjivanja sadrţi visoki integritet podataka
sa cijenom smanjenih performansi. MyISAM, bez takvih opterećenja, se moţe koristiti u
slučajevima gdje je naglasak na brzini, meĎutim sa cijenom gubitka podataka u slučaju pada
sustava. Stoga pitanje, „Koji je mehanizam pohranjivanja najbolji“ treba preformulirati u „Koji
je mehanizam pohranjivanja najprikladniji za…?“. Ovim radom se ne zaključuje kako je
MyISAM bolji mehanizam pohranjivanja od InnoDB, već isključivo da je brţi.
21
LITERATURA
A. Balter, SQL server 2005, Kompjutor biblioteka, Beograd, 2006
B. Hamilton, Programiranje SQL Server 2005, Dobar plan, Zagreb, 2006
V. Vaswani, PHP i MySQL, Mikro knjiga, Zagreb, 2005
R. Vujnović, SQL i relacijski model podataka, Znak, Zagreb, 1995
L. Welling, PHP i MySQL, Mikro knjiga, Beograd, 2004
Internet:
dev.mysql.com
www.devshed.com
www.innodb.com
22
SAŢETAK
Odabir konkretnog mehanizma pohranjivanja omogućuje bolje performanse eliminiranjem
nepotrebnih opterećenja, te je stoga potrebno poznavati mogućnosti koje pojedini mehanizam
nudi kao i zahtjeve korisnika baze podataka. Ovaj rad pruţa teorijsku podlogu potrebnu za
shvaćanje principa mehanizma pohranjivanja (konkretno u MySQL-u), te uvid u analizu
efikasnosti najčešće korištenih mehanizama. Rezultati analize pokazali su kako je MyISAM
značajno brţi mehanizam pohranjivanja od InnoDB, koji sadrţi visoki integritet podataka sa
cijenom smanjenih performansi. MyISAM, bez takvih opterećenja, se moţe koristiti u
slučajevima gdje je naglasak na brzini, meĎutim sa cijenom gubitka podataka u slučaju pada
sustava. Ovim radom se ne zaključuje kako je MyISAM bolji mehanizam pohranjivanja od
InnoDB, već isključivo da je brţi.
SUMARRY
Selecting a specific storage engine provides enhanced performance by eliminating
unnecessary overheads, and it is therefore required to be familiarized with the possibilities that
particular engine offers and database users requests. This paper provides a theoretical basis
necessary for understanding the principles of storage engine (specifically MySQL), and an
insight into the analysis of the efficiency of commonly used mechanisms. The analysis results
showed that the MyISAM storage engine is significantly faster than InnoDB, which has high
data integrity with a price of reduced performance. MyISAM, without such overheads, can be
used in cases where the emphasis is on speed, but with the cost of data loss in case of system
failure. This paper does not conclude that the MyISAM storage engine is better than InnoDB, but
only that it is faster.
23
ŢIVOTOPIS
RoĎen sam u Osijeku 06.01.1989. Prvih sedam razreda osnovnog obrazovanja završio sam u
osnovnoj školi „Mladost“ u Osijeku. 2001. godine preselio sam se sa obitelji u novosagraĎenu
kuću u Tenji, gdje i danas ţivim. Osmi razred pohaĎao sam u srednjoj školi „Tenja“. Od 2003.
godine do 2007. sam pohaĎao III. gimnaziju (prirodoslovnu-matematičku) u Osijeku. Tijekom
tog razdoblja sudjelovao sam u brojnim natjecanjima iz matematike, fizike i informatike, te na
završnom ACSL natjecanju u programiranju. 2007. godine upisao sam sveučilišni preddiplomski
studij računarstva na Elektrotehničkom fakultetu u Osijeku. 2009. godine dobio sam priznanje za
najboljeg studenta na godini na svom smjeru.
24
PRILOZI
Prilog 1
MySQL - Kreiranje tablica
CREATE TABLE table_myisam (random_values1 INT, random_values2 INT,
random_values3 INT, random_values4 INT) ENGINE = MYISAM;
CREATE TABLE table_innodb (random_values1 INT, random_values2 INT,
random_values3 INT, random_values4 INT) ENGINE = INNODB;
CREATE TABLE table_memory (random_values1 INT, random_values2 INT,
random_values3 INT, random_values4 INT) ENGINE = MEMORY;
Prilog 2
Php - popunjavanje tablica sa vrijednostima
<?
set_time_limit(0);
$user="root";
$password="";
$database="testing";
mysql_connect(localhost,$user,$password);
@mysql_select_db($database) or die( "Unable to select database");
for ($i=0;$i<1000000;$i++)
{
srand((double) microtime( )*1000000);
$r1=rand(1,10000);
$r2=rand(1,10000);
$r3=rand(1,10000);
$r4=rand(1,10000);
25
$query = "INSERT INTO table_myisam VALUES ($r1, $r2, $r3, $r4)";
mysql_query($query);
$query = "INSERT INTO table_innodb VALUES ($r1, $r2, $r3, $r4)";
mysql_query($query);
$query = "INSERT INTO table_memory VALUES ($r1, $r2, $r3, $r4)";
mysql_query($query);
}
mysql_close();
?>
Prilog 3
MySQL - Testiranje efikasnosti
1. operacija
SELECT * FROM t_myisam t;
SELECT * FROM t_innodb t;
SELECT * FROM table_memory t;
2. operacije
SELECT count(*) FROM t_myisam t;
SELECT count(*) FROM t_innodb t;
SELECT count(*) FROM table_memory t;
3. operacija
SELECT COUNT(DISTINCT random_values1) FROM table_myisam t;
SELECT COUNT(DISTINCT random_values1) FROM table_innodb t;
SELECT COUNT(DISTINCT random_values1) FROM table_memory t;
4. operacija
SELECT * FROM table_myisam t WHERE random_values1=random_values2 OR
random_values1=random_values3 OR random_values1=random_values4;
SELECT * FROM table_innodb t WHERE random_values1=random_values2 OR
random_values1=random_values3 OR random_values1=random_values4;
SELECT * FROM table_memory t WHERE random_values1=random_values2 OR
random_values1=random_values3 OR random_values1=random_values4;
26
5.operacija
SELECT * FROM table_myisam t ORDER BY random_values1;
SELECT * FROM table_innodb t ORDER BY random_values1;
SELECT * FROM table_memory t ORDER BY random_values1;
6. operacija
SELECT SUM(random_values1) FROM table_innodb t;
SELECT SUM(random_values1) FROM table_innodb t;
SELECT SUM(random_values1) FROM table_memory t;
7. operacija
SELECT AVG(random_values1) FROM table_myisam t;
SELECT AVG(random_values1) FROM table_innodb t;
SELECT AVG(random_values1) FROM table_memory t;
8. operacija
SELECT MIN(random_values1), MAX(random_values1) FROM table_myisam t;
SELECT MIN(random_values1), MAX(random_values1) FROM table_innodb t;
SELECT MIN(random_values1), MAX(random_values1) FROM table_memory t;
9. operacija
SELECT MIN(random_values1), MAX(random_values1),MIN(random_values2),
MAX(random_values2), MIN(random_values3), MAX(random_values3),
MIN(random_values4), MAX(random_values4) FROM table_myisam t;
SELECT MIN(random_values1), MAX(random_values1),MIN(random_values2),
MAX(random_values2), MIN(random_values3), MAX(random_values3),
MIN(random_values4), MAX(random_values4) FROM table_innodb t;
SELECT MIN(random_values1), MAX(random_values1),MIN(random_values2),
MAX(random_values2), MIN(random_values3), MAX(random_values3),
MIN(random_values4), MAX(random_values4) FROM table_memory t;
10. operacija
SELECT COUNT(*), COUNT(DISTINCT random_values2), AVG(random_values3),
AVG(random_values4) FROM table_myisam t;
SELECT COUNT(*), COUNT(DISTINCT random_values2), AVG(random_values3),
AVG(random_values4) FROM table_innodb t;
SELECT COUNT(*), COUNT(DISTINCT random_values2), AVG(random_values3),
AVG(random_values4) FROM table_memory t;
27
Prilog 4
Kompletne tablice rezultata
1. operacija
n myisam innodb memory
1. 0,0015 0,0231 0,0010
2. 0,0017 0,0140 0,0020
3. 0,0017 0,0222 0,0017
4. 0,0016 0,0198 0,0010
5. 0,0013 0,0245 0,0016
6. 0,0019 0,1566 0,0017
7. 0,0016 0,0178 0,0011
8. 0,0018 0,0230 0,0012
9. 0,0014 0,0185 0,0019
10. 0,0019 0,0150 0,0011
prosjek 0,0016 0,0335 0,0014
2. operacija
n myisam innodb memory
1. 0,0002 1,0565 0,0003
2. 0,0003 1,0268 0,0002
3. 0,0005 1,1838 0,0003
4. 0,0004 1,0576 0,0003
5. 0,0008 1,0415 0,0006
6. 0,0003 1,1263 0,0004
7. 0,0002 1,0811 0,0009
8. 0,0009 1,0821 0,0007
9. 0,0002 1,0624 0,0003
10. 0,0003 1,0868 0,0002
prosjek 0,0004 1,0805 0,0004
3. operacija
n myisam innodb memory
1. 0,5728 1,5161 0,4288
2. 0,5724 1,7860 0,4260
3. 0,5779 1,5760 0,4262
4. 0,5689 1,5470 0,4290
5. 0,5782 1,5958 0,4286
6. 0,5703 1,5229 0,4274
7. 0,5693 1,5701 0,4443
8. 0,5691 1,6314 0,4404
9. 0,5784 1,6166 0,4385
10. 0,5527 1,6233 0,4332
prosjek 0,5710 1,5985 0,4322
28
4. operacija
n myisam innodb memory
1. 0,2952 1,4301 0,2175
2. 0,2857 1,3254 0,2070
3. 0,2944 1,4598 0,2073
4. 0,2929 1,5596 0,2148
5. 0,2942 1,4561 0,2108
6. 0,2961 1,3345 0,2143
7. 0,2869 1,3541 0,2082
8. 0,2912 1,3947 0,2132
9. 0,3103 1,4410 0,2089
10. 0,2936 1,3438 0,2165
prosjek 0,2941 1,4099 0,2119
5. operacija
n myisam innodb memory
1. 0,9623 2,3066 0,6516
2. 0,9885 2,2692 0,6274
3. 0,8969 2,2354 0,6214
4. 0,9346 2,5914 0,6245
5. 0,8746 2,0520 0,6258
6. 0,8837 2,3311 0,6378
7. 0,8724 2,3138 0,5979
8. 0,8845 2,4874 0,6311
9. 0,8779 2,0662 0,6195
10. 0,9019 2,2486 0,6458
prosjek 0,9077 2,2902 0,6283
6. operacija
n myisam innodb memory
1. 0,2987 1,3395 0,2085
2. 0,2922 1,4101 0,2100
3. 0,2911 1,3500 0,2094
4. 0,2893 1,4782 0,2171
5. 0,2899 1,6409 0,2097
6. 0,2946 1,3754 0,2094
7. 0,2908 1,4087 0,2080
8. 0,3005 1,5158 0,2125
9. 0,2867 1,2842 0,2078
10. 0,3123 1,4429 0,2249
prosjek 0,2946 1,4246 0,2117
29
7. operacija
n myisam innodb memory
1. 0,2952 1,3789 0,2163
2. 0,2927 1,3831 0,2190
3. 0,2902 1,4303 0,2112
4. 0,3035 1,3567 0,2203
5. 0,2956 1,3760 0,2179
6. 0,2940 1,4008 0,2245
7. 0,2904 1,4391 0,2162
8. 0,2960 1,4728 0,2196
9. 0,3046 1,4150 0,2096
10. 0,3043 1,3825 0,2285
prosjek 0,2967 1,4035 0,2183
8. operacija
n myisam innodb memory
1. 0,2154 1,2134 0,1421
2. 0,2078 1,2080 0,1395
3. 0,2052 1,2477 0,1397
4. 0,2058 1,2538 0,1483
5. 0,2113 1,1976 0,1526
6. 0,2076 1,2077 0,1439
7. 0,2107 1,1685 0,1437
8. 0,2084 1,2256 0,1458
9. 0,2116 1,1617 0,1497
10. 0,2054 1,2259 0,1444
prosjek 0,2089 1,2110 0,1450
9. operacija
n myisam innodb memory
1. 0,4306 1,6444 0,3258
2. 0,4490 1,5474 0,3263
3. 0,4690 1,6380 0,3224
4. 0,4412 1,6034 0,3433
5. 0,4327 1,5553 0,3209
6. 0,4349 1,6649 0,3293
7. 0,4229 1,5308 0,3237
8. 0,4359 1,6171 0,3332
9. 0,4227 1,5598 0,3447
10. 0,4354 1,5463 0,3397
prosjek 0,4374 1,5907 0,3309
30
10. operacija
n myisam innodb memory
1. 0,9431 2,0952 0,7223
2. 0,9144 2,1420 0,7179
3. 0,9014 2,0147 0,7215
4. 0,9099 2,1661 0,7700
5. 0,8983 2,0677 0,7265
6. 0,9107 2,2203 0,7349
7. 0,9026 2,0877 0,7288
8. 0,9142 2,2209 0,7350
9. 0,8996 2,1289 0,7208
10. 0,9121 2,2561 0,7298
prosjek 0,9106 2,1400 0,7308