of 32 /32
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

ANALIZA EFIKASNOSTI POHRANJIVANJA U BAZAMA PODATAKA · 2010. 10. 28. · naredbom. Same transakcije ne pruţaju dovoljnu sigurnost serveru baze podataka ukoliko server ne zadovoljava

  • Author
    others

  • View
    2

  • Download
    0

Embed Size (px)

Text of 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

  • 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