analiza efikasnosti pohranjivanja u bazama podataka · 2010. 10. 28. · naredbom. same transakcije...

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)";


$query = "INSERT INTO table_memory VALUES ($r1, $r2, $r3, $r4)";


}

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


SELECT * FROM table_innodb t WHERE random_values1=random_values2 OR


SELECT * FROM table_memory t WHERE random_values1=random_values2 OR


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;



MIN(random_values4), MAX(random_values4) FROM table_innodb t;



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;


AVG(random_values4) FROM table_innodb t;


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


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


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


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


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


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


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


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


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


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

analiza efikasnosti pohranjivanja u bazama podataka · 2010. 10. 28. · naredbom. same transakcije...

Documents