SVEUILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

ZAVRNI RAD br. 2467

NoSql sustavi za upravljanje bazama podataka

Ljudevit Habjanec

Zagreb, lipanj 2012.

Abstract In this paper, we examine what new features are available in NoSql database systems in comparison with traditional relational database systems. MongoDB is chosen for in depth analysis of its features: horizontal scaling, consistency mechanism, durability guaranty, availability and query support. Also, benchmarks for MongoDB and MySQL database systems are presented, showing comparisons in terms of speed for reading, writing and executing queries on a two node distributed system.

Sadraj 1. 2. Uvod .......................................................................................................... 6 Specifinosti NoSql baza podataka ........................................................... 7 2.1. 2.2. 2.3. 2.4. Performanse ....................................................................................... 8 Dostupnost podataka .......................................................................... 9 CAP teorem ........................................................................................ 9 Vrste NoSql baza podataka .............................................................. 10 Key-value ................................................................................... 11 Column-oriented......................................................................... 11 Graph ......................................................................................... 12 Document oriented ..................................................................... 13

2.4.1. 2.4.2. 2.4.3. 2.4.4. 3.

MongoDB ................................................................................................ 14 3.1. 3.2. 3.3. 3.4. 3.5. Specifinosti...................................................................................... 14 Primjena ........................................................................................... 15 Nedostaci i ogranienja .................................................................... 15 Struktura podataka ........................................................................... 17 Dohvat podataka............................................................................... 18 Skupovi heterogenih entiteta ...................................................... 19 N-N veze .................................................................................... 20 MapReduce funkcije ................................................................... 22 Usporedba SQL jezika i rada s MongoDB JSON upitima ........... 23

3.5.1. 3.5.2. 3.5.3. 3.5.4. 3.6. 3.7. 3.8.

Atomarnost operacija ........................................................................ 26 Replikacija ........................................................................................ 27 Podjela na odlomke .......................................................................... 30 Komponente sustava s podjelom na odlomke ............................ 30

3.8.1.

ii

4.

Usporedba performansi MySql i MongoDB SUBP-a na primjeru ogledne

aplikacije............................................................................................................... 32 4.1. 4.2. 4.3. 4.4. 4.5. 5. 6. Struktura podataka ogledne aplikacije .............................................. 32 Konfiguracija MySql posluitelja ....................................................... 33 Konfiguracija MongoDB posluitelja ................................................. 33 Testiranje .......................................................................................... 33 Rezultati testiranja ............................................................................ 34

Zakljuak ................................................................................................. 38 Literatura ................................................................................................. 39

iii

Popis oznaka i kratica SUBP engl sustav za upravljanje bazama podataka engleski

iv

Popis slika Slika 1. Horizontalna i vertikalna skalabilnost..................................................... 7 Slika 2. Usporedba NoSql i tradicionalnih relacijskih SUBP-ova ........................ 8 Slika 3. Poveanje performansi tradicionalnog SUBP-a uz predpohranjivanje .. 9 Slika 4. CAP teorem i neki NoSql SUBP-ovi s odgovarajuim svojstvima ........ 10 Slika 5. Column oriented BigTable baza podataka........................................... 12 Slika 6. Poznanstva u Graph bazi podataka .................................................... 13 Slika 7. Relacijska shema Osobe-Nekretine .................................................... 18 Slika 8. Prebrojavanje pojavljivanja mjeseci MapReduce funkcijama .............. 22 Slika 9. Proces nakon kvara nadreenog posluitelja kod replikacije nadreenipodreeni ............................................................................................................. 28 Slika 10. Proces oporavka kvara nadreenog kod skupa replika ..................... 29 Slika 11. Komponente MongoDB sustava s podjelom na odlomke .................. 31 Slika 12. Struktura podataka ogledne aplikacije ............................................... 32 Slika 13. Usporedba trajanja unosa korisnika i avatara .................................... 34 Slika 14. Usporedba simulacije borbi za razliitu koliinu korisnika ................. 35 Slika 15. Usporedba trajanja operacija dohvata statistike korisnika, avatara i borbi ..................................................................................................................... 36 Popis tablica Tabela 1. Primjer MongoDB dokumenta .......................................................... 17

Uvod

1. Uvod
Razvoj poslovnih aplikacija, web aplikacija i socijalnih mrea nezamisliv je bez upotrebe SUBP-ova (sustava za upravljanje bazama podataka). SUBP-ovi omoguuju razvoj aplikacija koje zahtijevaju spremanje, dohvat, zatitu integriteta i kontrolu istodobnog pristupa podacima. Trenutno najzastupljeniji SUBP-ovi zasnovani su na relacijskom modelu i koriste SQL jezik, te se najee koriste kada je potreban rad vie korisnika uz ouvanje integriteta podataka. Od 1960-ih, kada su se poeli razvijati sustavi temeljeni na relacijskom modelu, pa do danas, pojavljivali su se sustavi s razliitim pristupima poput objektno orijentiranih i XML baza podataka. Takvi pristupi nisu zamijenili relacijski model te su uglavnom integrirani u postojee SUBP-ove ili se koriste u vrlo uskim i specijaliziranim primjenama. Posljednjih nekoliko godina sve veom zastupljenosti web aplikacija i socijalnih mrea pojavila se potreba za brzim razvojem aplikacija za velik broj korisnika. Postojei relacijski SUBP-ovi pokazali su se kompliciranim u takvim sluajevima kada je bilo potrebno podravati brzo rastui broj korisnika i brz razvoj aplikacija. Kao rjeenje navedenih problema pojavljuju se NoSql baze podataka koje donose jednostavniju skalabilnost u usporedbi s tradicionalnim relacijskim SUBPovima na velikom broju posluitelja, te razvoj usmjeren na specifine primjene poput socijalnih mrea i programskih rjeenja u oblacima (engl. cloud computinga). Zajednika obiljeja novonastalih baza podataka su to nisu relacijske i to nude mogunosti rada s razliitim vrstama podataka poput dokumenata i grafova, pa se i prema tome nazivaju NoSql ne samo SQL (eng. not only SQL i eng. not relational) baze podataka.

Specifinosti NoSql baza podataka

2. Specifinosti NoSql baza podataka

Najistaknutija prednost NoSql baza podataka je prilagoenost za horizontalnu skalabilnost. Poveane potrebe za resursima mogu se zadovoljiti poveanjem performansi posluitelja na kojem se nalazi SUBP i to je najjednostavniji nain jer ne zahtijeva nikakve promjene u SUBP-u i aplikaciji. To se naziva vertikalna skalabilnost i ona ima svoj limit koji je odreen maksimalnim performansama koje jedan posluitelj moe postii. Drugi nain je dodavanje jo posluitelja na koje se raspodjeljuje posao i to se naziva horizontalna skalabilnost. Na taj nain mogu se zadovoljiti poveane potrebe za resursima dodavanjem dodatnih posluitelja (engl. scaling out), te kasnije eventualno njihovim odstranjivanjem ako nestaje potreba za njima.

Vertikalna skalabilnost Horizontalna skalabilnost

SUBP posluitelj

Slika 1. Horizontalna i vertikalna skalabilnost Kako bi se omoguila jednostavnija horizontalna skalabilnost (u odnosu na tradicionalne relacijske
1

SUBP-ove)

NoSql

baze

podataka

uglavnom

ne

zadovoljavaju ACID

uvjete. Iako se to ini kao ozbiljan problem, upravo to

omoguuje najvanije prednosti NoSql baza podataka: brzina i odaziv kod rada i izvanredna skalabilnost. Zadovoljavanje ACID uvjeta poveava kompleksnost SUBP-a. U odreenim primjenama ta svojstva su manje vana od brzine i

ACID - atomarnost, konzistencija, izolacija i izdrljivost

7

Specifinosti NoSql baza podataka

skalabilnosti. Kada su ACID svojstva prijeko potrebna, NoSql baza podataka nije prikladan izbor, te je zato potrebno poznavati svojstva relacijskih i NoSql baza podataka kako bi se mogao napraviti dobar odabir SUBP-ova kod razvoja aplikacija.

Mogudnosti NoSql baza podataka

Mogudnosti tradicionalnih relacijskih baza podataka

Problem

Slika 2. Usporedba NoSql i tradicionalnih relacijskih SUBP-ova

2.1. Performanse
Kod tradicionalnih relacijskih SUBP-ova gdje postoji potreba za brzim odazivom kod zapisivanja i itanja podataka esto se koristi zasebni sustav za predpohranjivanje (engl. caching). Podaci se uz pomo sustava za

predpohranjivanje prvo pohranjuju u radnu memoriju, a tek onda u bazu podataka (najpoznatiji takav mehanizam je Memcached). Predpohranjivanje se moe ugraditi u aplikaciju i u tom sluaju ubrzavaju se samo itanja dok se zapisivanja i dalje moraju obraditi u SUBP-u to bitno smanjuje performanse u primjenama gdje je odnos zapisivanja i itanja podjednak. Kod nekih NoSql SUBP-ova poput MongoDB-a, predpohranjivanje ugraeno je u samu bazu podataka koja se, ako je to mogue, cijela smjeta u radnu memoriju i time poveava performanse.

Specifinosti NoSql baza podataka

Aplikacijski posluitelji

Memchached posluitelji

SUBP posluitelj

Slika 3. Poveanje performansi tradicionalnog SUBP-a uz predpohranjivanje

2.2. Dostupnost podataka

NoSql baze podataka omoguuju replikaciju podataka na vie posluitelja2 s ciljem poveanja njihove dostupnosti. Ispadom jednog posluitelja (ili vie, ovisno o konfiguraciji i koliini posluitelja) SUBP i dalje moe ispravno funkcionirati, bez prekida u radu i bez gubitka podataka.

2.3. CAP teorem

CAP teorem (poznat i kao Brewerov teorem) nastao 2000. godine govori kako je nemogue zadovoljiti sva tri poeljna svojstva u distribuiranim sustavima: dostupnost (engl. availability), konzistenciju (engl. consistency) i toleranciju na ispad dijela sustava (engl. partition tolerance) Kod razvoja SUBP-a, mogu se odabrati samo dva od navedena tri svojstava distribuiranih sustava: Konzistentnost sve akcije nad podacima, uspjene ili ne, ostavljaju bazu podataka u konzistentnome stanju

podaci imaju barem jednu dodatnu kopiju na fiziki odvojenom posluitelju

9

Specifinosti NoSql baza podataka

Dostupnost svaki klijent moe uvijek itati i zapisivati Partition tolerance sustav moe dalje funkcionirati, bez obzira to dijelovi sustava ne mogu meusobno komunicirati
Availability Dostupnost

A
MySQL (i ostali tradicionalni SUBP-i) Hypergraph Neo4J Mogude odabrati samo 2 svojstva CouchDB Cassandra Riak

C
Consistency Konzistencija

P
MongoDB Hbase Redis
Partition tolerance Tolerancija na ispad dijela sustava

Slika 4. CAP teorem i neki NoSql SUBP-ovi s odgovarajuim svojstvima

Tradicionalni relacijski SUBP-ovi koncentriraju se na CA - konzistentnost

dostupnost. Time se poveava sloenost kod raspodjele sustava na vie vorova. NoSql SUBP-ovi, za razliku od tradicionalnih SUBP-ova, koncentriraju se na PA ili PC rtvuje se konzistentnost ili dostupnost dok tolerancija na podijeljenost uvijek ostaje kao bi se zadrala jednostavna skalabilnost.

2.4. Vrste NoSql baza podataka

Iako ne postoji jedinstvena definicija to je tono obuhvaeno pojmom NoSql, on obuhvaa baze podataka koje uglavnom imaju navedena obiljeja: ne relacijske su podravaju jednostavno horizontalno skaliranje i replikaciju

10

Specifinosti NoSql baza podataka

podravaju skup BASE obiljeja3, za razliku od ACID-a kod tradicionalnih relacijskih SUBP-ova

otvorenog su koda

BASE svojstva NoSql SUBP-ova oznaavaju da su podaci: konzistentni u konanici, ali ne moe se garantirati da e oni biti konzistentni odmah po unosu u bazu podataka (engl. eventual consistency) promjenjivi, s obzirom da se mogu promijeniti i bez vanjskih utjecaja kako bi se zadovoljila konzistentnost (engl. soft state) dostupni ak i u sluajevima kada neki od vorova nisu dostupni (engl. basically available) Kako nepodravanje SQL jezika nije jedina bitna razlika u usporedbi s tradicionalnim relacijskim SUBP-ima, NoSql pojam se objanjava i kao engl. not only SQL ne samo SQL. U sljedeih nekoliko poglavlja objanjene su vrste SUBP-ova koji se svrstavaju pod pojam NoSql.

2.4.1. Key-value
Key-Value (parovi klju-vrijednost) je najjednostavniji oblik baze podataka. Prednosti Key-Value baza podataka su vrlo brzo zapisivanje i itanje bez obzira na koliinu podataka i bez utjecaja na skalabilnost. Nedostatak su vrlo ograniene mogunosti pretrage i analize podataka. Ovakav oblik baze podataka uglavnom se koristi za predpohranjivanje velike koliine podataka.

2.4.2. Column-oriented
Column-oriented (tabelarne) baze podataka su zapravo key-value baze podataka koje za pronalazak podataka koriste skup kljueva (npr. redak, stupac). Na taj nain grupiraju povezane podatke u jedan redak (to automatski podrazumijeva da podaci kad se spreme na disk budu fiziki homogeni). Nije potrebno unaprijed odrediti koliko se stupaca nalazi u retku i podaci se pretrauju po kljuu koji jednoznano odreuje redak.

engl. Basically Available, Soft state, Eventual consistency

11

Specifinosti NoSql baza podataka

Primjer jedne takve tabelarne baze podataka je BigTable koju koristi Google u veini svojih servisa, npr. za: indeksiranje Web-a, Google Earth, Google Analytics i Google Docs. BigTable je razvijen s ciljem da podrava skaliranje iznimno velike koliine (vie petabajta) strukturiranih podataka preko vie tisua posluitelja [5]. Svakom podatku pristupa se preko: kljua koji odreuje redak, kljua koji odreuje stupac i vremenske oznake. Vremenska oznaka slui za uvanje vie inaica istog podatka kroz odreeno vremensko razdoblje. Slika 5. prikazuje jedan redak BigTablea, u kojem se nalaze podaci prikupljeni s Web stranice www.cnn.com (klju retka), a razliiti strukturni dijelovi stranice su kljuevi stupaca. Podaci mogu imati vie inaica, npr. podaci u "contents:" stupcu imaju 3 inaice: t3, t5 i t6.

Slika 5. Column oriented BigTable baza podataka

2.4.3. Graph
Graph baze podataka temeljene su na teoriji grafova te koriste vorove (s atributima) i veze izmeu vorova. Ne koriste indekse jer svaki vor ima veze na susjedne vorove. Npr. na slici 6. koja prikazuje osobe i njihove odnose, u sluaju da elimo pronai prijatelje "Osobe 1", slijedit emo sve veze "prijatelj" koje direktno pokazuju na njezine prijatelje, bez upotrebe indeksa koji bi sadravali sve veze svih osoba. Prikladne su za koritenje u socijalnim mreama gdje se ljudi povezuju vezama (npr. poznanstva ili prijateljstva) ili geografskih lokacija s vezama koje predstavljaju udaljenosti. Neo4J je najpoznatija takva baza podataka, dok npr. Twitter koristi FlockDB izgraenu na MySQL tehnologiji.

12

Specifinosti NoSql baza podataka

Osoba 1 Grad: Zagreb Spol: M

POZNAJE Osoba 2 Grad: Oroslavje Spol: M Osoba 3 Grad: New York Spol:

POZNAJE PRIJATELJ Osoba 5 Grad: D. Stubica Spol: M

POZNAJE PRIJATELJ Osoba 4 Grad: Zapreid Spol: POZNAJE Osoba 5 Grad: Osijek Spol: M POZNAJE

Slika 6. Poznanstva u Graph bazi podataka

2.4.4. Document oriented

Najee koriteni tip NoSql baze podataka su baze podataka temeljene na dokumentima (engl. Document oriented). Svaki podatak je jedan dokument ija struktura nije unaprijed odreena, to znai da razliiti dokumenti mogu imati razliita obiljeja. Svaki dokument ima jedinstveni klju koji se koristi za pretragu i izmjenu dokumenata. S obzirom da nije potrebno unaprijed odrediti shemu, podaci se spremaju onako kako se i s njima radi u aplikacijama, tj. nije ih potrebno normalizirati. Ovakav pristup olakava razvoj aplikacija gdje unaprijed nije poznato s kakvim e se sve podacima raditi i gdje je potrebno spremati vie razliitih tipova podataka unutar jedne grupe. Najpoznatije baze podataka temeljene na dokumentima su CouchDB i MongoDB. MongoDB je zbog lakoe koritenja i pristupane dokumentacije odabran kao primjer baze podataka ije e se mogunosti detaljnije obraditi u ovome radu.

13

MongoDB

3. MongoDB
MongoDB je NoSql baza temeljena na dokumentima iji je razvoj zapoeo 2007. godine u tvrtci 10gen. Verzija 1.4 izdana sredinom 2011. godine je prva verzija koja se smatra dovoljno stabilnom za koritenje u komercijalne svrhe. Izvorni kod dostupan je pod GNU licencom.

3.1. Specifinosti
- Svaki dokument sprema se kao jedan BSON objekt. BSON je binarni oblik JSON objekta. JSON je format zapisivanja podataka u obliku JavaScript sintakse koji je razvijen s ciljem da se lako ita, lako parsira i da mu struktura zauzima minimum podatkovnog prostora. Primjer jednog takvog dokumenta je Osoba s atributima ImePrezime i Godina: Osoba = { ImePrezime: Pero Peri, Godina: 1987 }; - Jezik za pretraivanje po vrijednostima atributa ili njihovim rasponima (engl. range queries) i pretraivanje uporabom regularnih izraza. Mogue je i pisanje korisnikih upita koji se sastoje od funkcija pisanih u JavaScript jeziku koje se izvravaju na posluitelju. - Nad svakim atributom moe se izgraditi indeks za bre pretraivanje - Podrka za nadreeni-podreeni (engl. master-slave) replikaciju. Nadreeni moe pisati i itati, dok podreeni ima samo mogunost itanja. Ispadanjem nadreenog posluitelja odabire se novi nadreeni bez prekida rada baze podataka i dostupnosti podataka. - Horizontalno skaliranje odabirom kljua na temelju kojeg se podaci raspodjeljuju na nekoliko odlomaka (engl. shard) (svaki odlomak se sastoji od nadreenog-podreenog posluitelja) - Spremanje binarnih podataka (slika, arhiva i sl.) unutar baze podataka, takoer koristei skaliranje i otpornost na ispadanje vorova - Automatsko ograniavanje koliine podataka moe se definirati maksimalan broj dokumenata. Kada se dosegne definirani maksimum, najstariji podaci se

14

MongoDB

poinju brisati unosom novih, to je posebno korisno kod obrade velike koliine podataka koji brzo zastarijevaju - Ugraena podrka za rad s geoprostornim podacima npr. pretraga dokumenata koji se nalaze unutar odreenog broja kilometara od zadane GPS lokacije. - Mogunost Fire & forget principa zapisivanja podataka unos i izmjena podataka moe se zatraiti od SUPB-a bez ekanja odgovora. Ukoliko se akcija ne uspije izvriti, klijentska aplikacija ne dobiva nikakav odgovor. Prednost ovakvog principa je brzina jer klijentska aplikacija moe odmah nastaviti s radom nakon izdavanje naredbe SUBP-u.

3.2. Primjena
Svoju primjenu MongoDB baza podataka s obzirom na svoje specifinosti nalazi u: - Zapisivanje dnevnika rada aplikacija (engl. Application Data Logs) - Sustavi za upravljanje sadrajem (engl. CMS content management systems), s obzirom da nije potrebno unaprijed odrediti shemu podataka pojedine zbirke dokumenata. - Online raunalne igre kod kojih je potreban velik broj zapisivanja i itanja velikog broja korisnika, a koji ne smiju utjecati na brzinu izvoenja - Svoju primjenu nalazi i kod brzog razvoja aplikacija jer nije potrebno unaprijed odreivati shemu baze podataka to olakava uvoenje novih atributa i vrsta dokumenata tijekom razvoja aplikacija - Openito kod mobilnih aplikacija zbog upravljanja geoprostornim podacima

3.3. Nedostaci i ogranienja

Zbog specifinosti MongoDB baze podataka i podranih BASE obiljeja, ona nije prikladna za upotrebu u slijedeim primjenama:
15

MongoDB

Rad s financijskim, raunovodstvenim podacima i bankarskim transakcijama kod kojih je bitno nekoliko akcija izvriti kao jednu atomarnu akciju.

Analiza velike koliine nepromjenjivih podataka ili skladita podataka. Za takve primjene pogodniji su relacijski SUBP-ovi koji mogu pretraivati i analizirati podatke SQL jezikom

Kod rada s podacima kod kojih je potrebno spajati vie zbirki u jedan rezultat, s obzirom da MongoDB nema ekvivalent SQL JOIN naredbe

Kod rada s podacima gdje se trebaju generirati slijedne oznake poput rednih brojeva i sl. U ovakvim sluajevima potrebno je koristiti pomone tabele za efikasno dohvaanje sljedeeg rednog broja.

Dodatni nedostatak MongoDB-a je to je on tek kratko vrijeme dostupan na tritu u usporedbi s tradicionalnim relacijskim SUBP-ovima, te ima manje dokumentacije i manje osoba s iskustvom rada s MongoDB-om.

16

MongoDB

3.4. Struktura podataka

Osnovna jedinica podataka su JSON-dokumenti koji se spremaju u zbirke (engl. collections). U usporedbi s relacijskim bazama podataka, dokumenti predstavljaju zapise, tj. n-torke (engl. records), a zbirke su relacije. U relacijskim bazama podataka svi zapisi iste relacije imaju isti broj atributa, no kod dokumenata u MongoDB-u svaki dokument moe imati svoja polja nevezana uz strukturu zbirke u kojoj se nalazi. Npr., svaka osoba ne mora imati unaprijed predodreene informacije o roenju, to bi kod relacijske baze podataka zahtijevalo dodavanje novog atributa u shemu relacije kad god bi se pojavio novi atribut. Tablica 1. Primjer MongoDB dokumenta
Tablica relacijske baze podataka
ID 1 2 Ime Pero Hrvoje Prezime Peri Horvat God. roenja 1967 1955 Ana Majka Mjesto roenja Zagreb

MongoDB dokument
{ "_id": ObjectID("4efa8d2b7d284dad101e4bc9"), "Ime" : "Pero", "Prezime : "Peri", "God roenja" : 1967, "Mjesto roenja": "Zagreb" }, { "_id" : ObjectID("4efa8d2b7d284dad101e4bc7"), "Ime" : "Hrvoje", "Prezime" : "Horvat", "God roenja" : 1955, "Majka" : "Ana"

Atribut "_id" je obavezan, automatski ga dodaje MongoDB kao klju koji jednoznano odreuje svaki dokument unutar kompletne baze podataka. Mogue je koristiti i dodatni vlastiti klju (npr. OIB kod osoba) nad kojim se izgradi jedinstveni indeks (engl. unique index).
17

DODATAK B

3.5. Dohvat podataka

U relacijskim bazama podataka podaci su spremljeni u normaliziranom obliku, npr. imamo osobe kojima pridruujemo nekretnine koje posjeduju:
Osobe PK OIB Ime Prezime PK Nekretnine ID VlasnikOIB Adresa

Slika 7. Relacijska shema Osobe-Nekretine Kako bismo spojili ove dvije relacije i dobili popis nekretnina s pripadajuim vlasnicima, potreban je sljedei SQL upit:
SELECT osobe.*, nekretnine.Adresa FROM osobe LEFT JOIN nekretnine ON nekretnine.VlasnikOIB = osobe.OIB Rezultat: OIB 21312312312 Ime Pero Prezime Peri Adresa Mokrice 100

MongoDB ne podrava spajanje u upitima, pa se koriste alternativna rjeenja: a) dvije zbirke, u jednu spremiti Osobe, a u drugu Nekretnine koja se povezuje s osobom preko "_id" kljua ili OIB-a, to je slino kao kod relacijske baze podataka, ali "spajanje" podataka je potrebno izvesti u aplikacijskom sloju:

Pseudo kod:
za svaku nekretninu { vlasnik:=osobe.find( { OIB: nekretnina.VlasnikOIB } ) }

18

DODATAK B

b) unutar dokumenta Osoba, spremiti pod-dokument Nekretnina, bez potrebe za jo jednom zbirkom (treba imati na umu ogranienje od 16Mb koliko maksimalno moe iznositi veliina jednog dokumenta)
{ "_id" : ObjectID("4efa8d2b7d284dad101e4bc9"), "OIB" : "21312312312", "Ime" : "Pero", "Prezime : "Peri", "Nekretnine" : { "Adresa" : "Mokrice 100", } }

3.5.1. Skupovi heterogenih entiteta

Ako elimo u relacijsku bazu podataka spremiti geometrijske oblike i njihove fizike veliine, moemo to uiniti tako da zajednika svojstva stavimo u jednu relaciju (Oblik), a ostala svojstva spremamo u zasebnu relaciju (Oblik-svojstvo).
Relacijska baza podataka
Tip PK ID NazivTip PK FK1 Oblik ID IDTip Povrina Oblik svojstvo PK,FK1 PK,FK2 IDOblik IDSvojstvo Iznos
Oblik svojstvo IDTipa 100 povrina 3.14 IDOblik 1 Svojstvo IDTipa 100 Naziv Krug ID 500 Naziv svojstvo polumjer IDSvojstvo 500 Iznos 1

Svojstvo PK ID NazivSvojstvo

Oblik ID 1 Tip ID 1

Isti problem daleko je jednostavnije i prirodnije rijeiti u MongoDB-u, gdje e se takoer spremati tip geometrijskih oblika, no nije unaprijed potrebno predvidjeti shemu za sve tipove geometrijskih oblika.
19

DODATAK B

MongoDB
Krug PK ID Promjer Povrina PK Kvadrat ID Promjer Povrina Pravokutnik PK ID Stranica A Stranica B Povrina

Geometrijski oblici
{ "_id" : ObjectID("4efa8d2b7d284dad101e4bc9"), "tip" : "krug", "povrina" : 3.14, "promjer" : 1, }, { "_id" : ObjectID("1efa8d2b7d284dad101egg44"), "tip" : "kvadrat", "povrina" : 1, "stranica" : 1, },

itd.

3.5.2. N-N veze

N-N (engl. many to many) veze ili odnosi se uglavnom u relacijskim bazama podataka izvode koristei tri relacije, npr. kod povezivanja proizvoda i kategorija (svaki proizvod moe biti u N kategorija, a svaka kategorija ima N proizvoda) koristimo treu relaciju ProizvodKategorija u kojoj spremamo klju proizvoda i klju kategorije:

20

DODATAK B

Relacijska baza podataka

Proizvod PK ID Naziv

ProizvodKategorija PK PK FK1,FK2 IDProizvod IDKategorija ID

Kategorija PK ID Naziv

U MongoDB-u moemo koristiti samo dvije zbirke, Proizvodi i Kategorije, povezujui ih tako da unutar svakog proizvoda spremamo sve kljueve kategorija u koje spada odabrani proizvod.
MongoDB
proizvodi: { _id: ObjectID("1efa8d2b7d284dad101egg44"), naziv: "MongoDB knjiga", kategorije: [ ObjectID("1232138d2284dad101ee3a5a7a"), ObjectID("030c00d2284dad101eec7cc5c4 ") ] } kategorije: { _id : ObjectID("1232138d2284dad101ee3a5a7a"); naziv: "Baze podataka" }, { _id : ObjectID("030c00d2284dad101eec7cc5c4 "); naziv: "NoSQL baze podataka" }

21

DODATAK B

3.5.3. MapReduce funkcije

MapReduce je programski model koji se upotrebljava za obradu velikih koliina podataka kod raspodijeljenih sustava (engl. distributed systems). Model je dobio ime po funkcijama koje se uglavnom upotrebljavaju u funkcijskim jezicima, iako se one razlikuju od MapReduce funkcija koje se upotrebljavaju u MongoDB-u i drugim NoSql SUBP-ima. Transformacija podataka odvija se u dva koraka: Map itanje podataka, njihovo filtriranje i grupiranje u parove kljuvrijednost. Map funkcija se kod rada s vie vorova moe izvravati na svakom voru zasebno. Reduce obrada udruenih klju-vrijednost podataka iz Map funkcije (svih vorova) i generiranje izlaza u obliku parova klju-vrijednost Slika 8. prikazuje prebrojavanje pojavljivanja imena mjeseci koji se nalaze raspodijeljeni na tri vora. Funkcija Map izvrava se na svakom voru te generira parove (npr. "sijeanj, 1") za rijei koje je proitala. Nakon to su proitani podaci na svim vorovima, podaci se grupiraju u parove gdje je rije klju, a vrijednost zbroj pojavljivanja iz svih Map funkcija.

Filter

Ulaz
SIJEANJ, VELJAA, SVIBANJ

Map
SIJEANJ, 1 VELJAA, 1 SVIBANJ, 1

Reduce

Finalize

Rezultat

SIJEANJ VELJAA OUJAK, TRAVANJ, SVIBANJ SIJEANJ PROSINAC VELJAA PROSINAC LIPAN.

SIJEANJ [1,1] VELJAA [1,1] SIJEANJ,2 VELJAA, 2 SVIBANJ, 1 PROSINAC, 2 LIPANJ, 1 SVIBANJ [1] PROSINAC [1,1] LIPANJ [1] SIJEANJ,2 VELJAA, 2 SVIBANJ, 1 PROSINAC, 2 LIPANJ, 1

SIJEANJ, PROSINAC

SIJEANJ, 1 PROSINAC, 1

VELJAA, PROSINAC, LIPANJ

VELJAA, 1 PROSINAC, 1 LIPANJ, 1

Slika 8. Prebrojavanje pojavljivanja mjeseci MapReduce funkcijama

22

DODATAK B

3.5.4. Usporedba SQL jezika i rada s MongoDB JSON upitima

Kod jednostavnih operacija, poput pretraivanja, unosa i brisanja SQL upiti vrlo se lako preslikavaju u MongoDB JSON upite:
SQL upit
CREATE table..

MongoDB JSON upit

Stvaranje novih zbirki nije potrebno eksplicitno izvravati; stvaraju se automatski dodavanjem prvog dokumenta u nepostojeu zbirku Svaki dokument mogue je izmijeniti bez izmjene sheme db.osobe.insert( { ime:"Pero", prezime: "Peri" } );

ALTER TABLE..

INSERT INTO OSOBE ("Pero", "Peri")

SELECT * FROM osobe SELECT * FROM osobe WHERE god>33 AND god<=40

db.osobe.find(); db.osobe.find( { {"god"} : {$gt : 33, $lte : 40 } } );

SELECT * FROM osobe WHERE rbr=1 OR god=50

db.osobe.find( { $or : [ {rbr : 1}, { god : 50} ] } );

UPDATE osobe SET ime = "Kreo" WHERE ime="Pero"

db.osobe.update( { ime : "Pero" }, {$set : { ime : "Kreo" } } );

DELETE FROM osobe WHERE ime = "Kreo"

db.osobe.remove( { ime : "Kreo" } );

SQL upiti s grupiranjem podataka poput prebrojavanja, sumiranja i sl. preslikavaju se u agregacijske funkcije u JSON upitima:

23

DODATAK B

SQL upit
SELECT COUNT(*) FROM osobe

MongoDB JSON upit

db.osobe.aggregate ( { $group : { _id : null, count : { $sum : 1 }} } );

SELECT SUM(iznos) FROM racun

db.racuni.aggregate ( { $group : { id:null, total: {$sum: "$iznos"}} } );

Kompliciraniji SQL upiti preslikavaju se u MapReduce funkcije u JSON upitima. Prvi korak u sastavljanju MapReduce funkcije je napisati Map funkciju. Map funkcija se izvrava nad svakim dokumentom iz zbirke i s njome se odreuju kljuevi za grupiranje i prikupljanje podataka koji se kasnije koriste za izraun podataka. Slijedei primjer prikazuje funkciju koja grupira iznose po mjesecu i godini, priprema broj i iznos rauna. Map funkcija
map = function() { var mjesecIgodina = this.datum.getMonth() + this.datum.getYear(); var broj=0, zbroj=0; emit (mjesecIgodina, {broj=1, iznos=this.iznos } ); }

24

DODATAK B

Slijedei korak je napisati Reduce funkciju koja vri izraun grupiranih podataka, u ovom primjeru, ukupni iznos i broj rauna u mjesecu. Reduce funkcija
reduce = function(key, values) { var result { broj : 0, iznos : 0 }; values.forEach(function(value) { result.broj += value.broj; result.iznos += value.iznos; }); }

Ako je potrebno dodatno izraunati neke vrijednosti samo jednom za pojedine grupe, npr. u ovome primjeru prosjek iznosa rauna, potrebno je napisati i Finalize funkciju. Finalize funkcija
function prosjekFinalize(key, value) { if (value.broj > 0) value.prosjek = value.iznos / value.broj; return value; }

Na kraju je jo potrebno izvriti MapReduce funkciju nad eljenim podacima, u ovome primjeru samo za poslovnicu br. 1.: Map/reduce funkcija s filterom
filter = { poslovnica = 1 }; db.racuni.mapReduce(map, reduce, {query : filter, finalize: prosjekFinalize});

25

DODATAK B

Slijedei primjer prikazuje SQL upit i ekvivalentni primjer MapReduce funkcije u MongoDB-u. Npr. za pojedinog studenta izraunati koliko je ispita pisao i koja je prosjena ocjena svakog studenta:
SQL upit
SELECT COUNT(*) AS broj_ispita, AVG(ocjena) AS prosjecna_ocj

MongoDB JSON map/reduce funkcija

db.ispiti.group({ key : { studentOIB : true }, initial: { broj_ispita : 0, prosj_ocj : 0 }, reduce: function (doc, aggregator)

FROM ispiti

{ aggregator.broj_ispita+=1;

GROUP BY studentOIB }

aggregator.sum_ocjena += doc.ocjena;

finalize: function(doc) { doc.prosj_ocj = doc.sum_ocjena / doc.broj_ispita; } });

3.6. Atomarnost operacija

Za razliku od relacijskih sustava podataka koji podravaju transakcije odnosno omoguuju da se obave sve ili niti jedna operacija, takvo to ne postoji u MongoDB-u. Atomarnost operacija garantira se samo kod rada s jednim dokumentom. Npr., koritenjem operatora $set, $unset, $inc, $push, $pushAll kojima se moe izmijeniti postojei dokument. Drugi nain je koritenjem "update if current" metode koja prvo dohvaa dokument, mijenja se lokalna kopija, te se nakon toga izmijenjeni dokument vraa MongoDB-u, a on se uspjeno sprema samo ukoliko je dokument u zbirci ostao u meuvremenu nepromijenjen. Sljedei primjer prikazuje primjenu ove metode kod izmjene stanja artikla na skladitu.
26

DODATAK B

MongoDB JSON upit

privremeni = db.stanjeArtikla.findOne( { sifra : "123" } ); staraKolicina = privremeni.kolicina; privremeni.kolicina += 1; db.stanjeArtikala.update({ sifra : "123", kolicina : staraKolicina }, privremeni); // Provjerava je li izmjena podataka uspjela, vraa pogreku ako je privremeni podatak u meuvremenu promijenjen db.$cmd.findOne( {getlasterror: 1} );

// Ukoliko je izmjena uspjeno izvrena, posljednji upit davat e ovakav rezultat: {"err" : , "updatedExisting" : true , "n" : 1 , "ok" : 1} // Alternativno, ukoliko je neki od operatora pogodan za izmjenu atributa, mogue je koristiti findAndModify koji navedenu metodu integrira unutar jednog upita: db.stanjeArtikala.update({sifra : "123"}, {$inc: {{ kolicina : 1 } }}) // Ovdje koristimo operator $inc koji pribraja/oduzima broj u argumentu (u ovome sluaju pribraja 1)

Jedan od alternativnih naina je upotreba dodatnog atributa za praenje verzija. Kod svake izmjene dokumenta atribut verzija se poveava za jedan. Nakon lokalne izmjene dokumenta, kod upita za njegovu izmjenu u zbirci, uz jedinstveni klju koji odreuje dokument dodaje se i parametar verzija koji osigurava da se dokument u meuvremenu nije promijenio (verzija bi se poveala za broj izmjena obavljenih u vremenu proteklom od dohvata lokalnog dokumenta).

3.7. Replikacija
Replikacija je stvaranje kopija baza podataka na dva ili vie posluitelja kako bi se poveala pouzdanost pristupanja i otpornost sustava na pogreke. Ako doe do kvara na jednom posluitelju, drugi posluitelj na koji su se replicirali podaci moe preuzeti ulogu prvog posluitelja i rad s bazom podataka se nastavlja bez pogreke. MongoDB omoguuje dvije vrste replikacija: nadreeni-podreeni (engl. masterslave) i skupovi replika (engl. replica sets) replikaciju. Nadreeni-podreeni replikacija je uobiajeni nain replikacije podataka podran u veini tradicionalnih relacijskih SUBP-ova, gdje jedan posluitelj prima zahtjeve za itanje i zapisivanje
27

DODATAK B

podataka (nadreeni), te se ti podaci tada repliciraju na sve podreene posluitelje koji se mogu koristiti za itanje podataka. U sluaju kvara nadreenog posluitelja, rad se moe nastaviti sa samo jednim od podreenih posluitelja. Da bi se vratio nadreeni posluitelj, on se mora prvo uskladiti s podacima privremenog podreenog posluitelja kako bi mogao nastaviti s radom kao nadreeni posluitelj.
Stanje prije kvara nadreenog Stanje poslije kvara nadreenog

Nadreeni
Podreeni 1

Nadreeni
Podreeni 3

Podreeni 1

Podreeni 2

Podreeni 3

Podreeni 2 privremeni nadreeni

Slika 9. Proces nakon kvara nadreenog posluitelja kod replikacije nadreenipodreeni Replikacija skupovima, za razliku od nadreeni-podreeni replikacije, unaprijed ne odreuje koji je posluitelj nadreeni. Ukoliko doe do kvara na nadreenom posluitelju, jedan od preostalih spremnih podreenih posluitelja unutar istog skupa replika automatski preuzima ulogu nadreenog posluitelja. Kada se posluitelj koji je bio u kvaru natrag vraa u skup replika, prvo se pokuava sinkronizirati s ostalim posluiteljima kako bi uskladio podatke i tada on radi kao jedan od podreenih posluitelja u skupu replika dok uloga nadreenog ostaje onome koju ju je preuzeo tijekom kvara.

28

DODATAK B
Stanje prije kvara nadreenog Stanje nakon kvara nadreenog

Nadreeni

Nadreeni (u procesu oporavka)

Novi nadreeni Replika Replika Replika Replika Replika

Stanje nakon oporavka

Replika

Novi nadreeni Replika Replika

Slika 10. Proces oporavka kvara nadreenog kod skupa replika Dodatna prednost replikacije je i poveanje performansi sustava koji imaju velik broj zahtjeva za itanjem iz baze podataka. Tada se itanja mogu raspodijeliti na sve podreene posluitelje, no to je mogue samo u sluaju kada konzistentnost podataka nije bitna s obzirom da podaci na podreenim posluiteljima ne moraju biti jednaki podacima na nadreenom posluitelju. Podaci izmeu nadreenog posluitelja i ostalih podreenih posluitelja mogu kasniti ako je replikacija asinkrona, tj. nadreeni posluitelj ne eka na potvrdu podreenih posluitelja da
29

DODATAK B

su se podaci zaista zapisali na njih. Zbog pada performansi kod sinkrone replikacije, uglavnom se koristi asinkrona replikacija.

3.8. Podjela na odlomke

Kada jedan posluitelj ne moe vie obraivati zahtjeve za itanjem i zapisivanjem jedno od rjeenja je dodati jo jedan posluitelj koji automatski preuzima dio podataka, a samim time i obraivanje zahtjeva nad tim podacima. Taj postupak naziva se podjela na odlomke (engl. sharding). Podjela na odlomke se moe izvesti na razini klijentske aplikacije ili unutar SUBP-a. Obino se podjela na odlomke na razini klijentske aplikacije izvodi kad SUBP nema te mogunosti. Tada je potrebno imati tabele u kojima se zapisuje koji se podaci nalaze na kojem posluitelju. Svakih zahtjev za podacima mora prvo pristupiti takvoj tabeli, pronai na kojem se posluitelju nalaze podaci i tek tada proslijediti upit tom posluitelju. Ovakvim pristupom dolazi se do problema kada se jedan ili vie odlomka preoptereti jer se razmjetanje podataka na novo dodane odlomke mora obaviti na razini aplikacije ili runo. Podjela na odlomke je podrana u MongoDB-u i za njihovo koritenje nisu potrebne nikakve prilagodbe unutar klijentske aplikacije. Razmjetanja podataka i njihova migracija izmeu odlomaka rijeeni su na razini MongoDB SUBP-a.

3.8.1. Komponente sustava s podjelom na odlomke

MongoDB SUBP koji omoguuje podjelu na odlomke sastoji se od nekoliko komponenti: Odlomak (engl. shard) jedan odlomak moe biti jedan posluitelj ili to moe biti set replika koji se sastoji od vie posluitelja. Mongos usmjeriva na njega se spaja klijentska aplikacija, njemu upuuje zahtjeve za itanjem i zapisivanjem isto kao to to i ini kada radi direktno samo s jednim posluiteljem bez podjele na odlomke. Moe ih biti i vie, npr. svaki aplikacijski posluitelj ima svoj Mongos usmjeriva. Konfiguracijski posluitelj na njima se nalaze podaci o fizikim lokacijama podataka, tj. na kojim se tono posluiteljima (ili skupovima replika) nalaze podskupovi kompletne baze podataka
30

DODATAK B

Odlomak 1 (dio skupa replika)

Odlomak 1 (dio skupa replika)

Konfiguracijski posluitelj Mongos usmjeriva

Konfiguracijski posluitelj

Aplikacijski posluitelj

Slika 11. Komponente MongoDB sustava s podjelom na odlomke Podaci se na odlomke dijele prema kljuu koji se zadaje SUBP-u. Vrlo je bitno odabrati pogodan klju kako bi se podaci mogli dijeliti jer ukoliko klju ne nudi dovoljnu rasprenost podaci e se grupirati u prevelike grupe koje se nee moi seliti izmeu posluitelja. Npr. dobar klju bi se sastojao od 2 podatka: OIB i _id. OIB omoguuje da se svi podaci jednog korisnika nalaze na im manje razliitih odlomaka, to je pogodno kod itanja jer se upit prosljeuje manjem broju odlomaka. "_id" osigurava da se podaci dijele ako koliina podataka jednog korisnika prelazi veliinu odlomka.

31

DODATAK B

4. Usporedba performansi MySql i MongoDB SUBP-a na primjeru ogledne aplikacije

U svrhu prikaza razlika performansi MySql i MongoDB SUBP-a razvijena je ogledna aplikacija u Java 7 programskom jeziku koja u nekoliko koraka SUBPovima zadaje zahtjeve za: 1) slijednim zapisivanjem podataka u jednu relaciju 2) isprepletenim zapisivanjem i itanjem iz vie razliitih relacija/zbirki 3) dohvat, grupiranje i izraun podataka po zadanim kljuevima S obzirom da se MySql i NoSql SUBP-ovi tehniki i konceptualno razlikuju, aplikacija je napisana tako da iskoritava specifinosti svakog SUBP-a kako bi rezultati testiranja bili usporedivi.

4.1. Struktura podataka ogledne aplikacije

Korisnik PK ID Ime BrojPoraza BrojPobjeda

Borba Avatar PK FK1 ID IDKorisnika Ime BrojPobjeda BrojPoraza FK1 FK2 FK3 FK4 IDKorisnik1 IDKorisnik2 IDAvatar1 IDAvatar2 Bodova1 Bodova2 Pobjednik Gubitnik PK ID

Slika 12. Struktura podataka ogledne aplikacije Ogledna aplikacija se sastoji od Korisnika, odreenog broja Avatara koje svaki korisnik posjeduje i Borbi, koje su rezultat borbe dva Avatara. Struktura aplikacije zamiljena je tako da bude slina strukturi igara na Internetu kod kojih postoji velik
32

DODATAK B

broj korisnika i velik broj akcija koje ti korisnici mogu istovremeno generirati (posebice kod igara povezanim s socijalnim mreama [7]). Slika 12 prikazuje strukturu podataka koja nije idealna, jer se pojavljuju redundantni podaci: broj poraza i pobjeda kod korisnika i avatara, te IDKorisnik kod borbi. Rezultat je to optimizacije da se postigne vea brzina dohvata podataka jer nee biti potrebe za spajanjima.

4.2. Konfiguracija MySql posluitelja

U svrhu testiranja koriten je MySql Cluster Edition u inaici 7.2.6 na operativnom sustavu Windows XP s 1 gigabajt radne memorije. Konfiguracija SUBP-a sastoji se od dva vora istih tehnikih karakteristika. SUBP je podeen da koristi raspodjelu odlomaka izmeu dva vora, koristei automatski odabir kljua za raspodjelu. Klijentska aplikacija nalazila se na jednom od ta dva vora.

4.3. Konfiguracija MongoDB posluitelja

Za testiranje koriten je MongoDB u inaici 2.0.5 na istim vorovima kao i MySql SUBP. MongoDB je takoer konfiguriran da koristi raspodjelu odlomaka izmeu 2 vora, ali tek nakon to koliina podataka na jednom voru dosegne 5 megabajta.

4.4. Testiranje
Testiranje se odvijalo tako da se na jednom voru pokretala aplikacija u dvije dretve i mjerilo vrijeme: stvaranja odreenog broja korisnika s sluajno generiranim imenima i odreenog broja avatara (takoer s sluajnom generiranim imenima) pridruenih tim korisnicima sluajnog odabir dva avatara bilo koja dva korisnika i simulacija borbe, te spremanje rezultata te borbe u zasebnu relaciju Borbe, uz istodobnu izmjenu broj pobjeda i poraza kod korisnika. Simulacija borbe sastoji se od generiranja sluajnih brojeva kako bi se troilo im manje vremena i utjecalo na ishod testa. dohvaanje statistike:
33

DODATAK B

o korisnik s najvie pobjeda o sortirani popis korisnika s najboljim omjerom pobjeda i poraza o sortirani popis avatara s najboljim omjerom pobjeda i poraza ukupno vrijeme svih navedenih operacija obje dretve

Broj korisnika, broj avatara po korisniku i broj borbi parametri su koji su se poveavali s svakim testiranjem kako bi se dobile razlike u performansama ovisne o koliini podataka.

4.5. Rezultati testiranja

Prvi dio testa sastoji se od slijednog zapisivanje generiranog odreenog broja korisnika i avatara za te korisnike. Imena su im sluajno generirana. Broj avatara po korisniku za sve testove je pet, to znai da je ukupan broj unosa u bazu podataka jednak: brojUnosa = brojKorisnika + brojKorisnika*5

Slika 13. Usporedba trajanja unosa korisnika i avatara MongoDB je u prosjeku 52% bri u svakoj iteraciji od MySql-a. Razlog tome je to MongoDB ne zapisuje sve podatke odmah na tvrdi disk posluitelja, ve se podaci prvo spremaju u radnu memoriju, klijent odmah dobiva potvrdu o tome da su podaci spremljeni, dok oni zapravo ekaju u redu za zapisivanje.
34

DODATAK B

Drugi dio testa sastoji se od simuliranja borbi izmeu sluajno odabranih avatara. Nakon simulacije borbe sprema se rezultat i osvjeavaju brojai pobjeda i poraza kod korisnika i avatara.

Slika 14. Usporedba simulacije borbi za razliitu koliinu korisnika Nakon 10000 korisnika MongoDB se znatno usporio. Do toga je dolo zbog nedostatka radne memorije na testnim raunalima. MongoDB smjeta kompletnu bazu podataka u radnu memoriju i kada ona naraste preko koliine dostupne radne memorije poinje stranienje radne memorije na tvrdi disk (engl. memory paging). Performanse u tom sluaju padaju za dva puta u usporedbi s oekivanim performansama. Trei dio testa sastoji se od dohvata i analiziranja podataka o korisnicima, avatarima i borbama.

35

DODATAK B

Slika 15. Usporedba trajanja operacija dohvata statistike korisnika, avatara i borbi Kod MongoDB-a te operacije izvedene su MapReduce i Finalize funkcijama, a kod MySqla standardnim SQL naredbama. MySql je u ovim operacijama daleko bri ve i na manjem broju zapisa, a ta razlika u brzini jo se vie naglaava porastom koliine podataka i njihovim dijeljenjem na odlomke na vie posluitelja. Programski kod koriten za dobivanje navedenih rezultata nalazi se u sljedeoj tabeli:
Dohvat korisnika sortiranih po odnosu pobjeda/poraz upotrebom Map, Reduce i Finalize funkcija Map funkcija
function() { emit(this.ime, { pobjeda : this.brojPobjeda, poraza : this.brojPoraza}); }

Reduce funkcija
function(ime, values ) { var n = { pobjeda:0, poraza:0 }; for ( var i = 0; i < values.length; i ++ ) { n.pobjeda += values[i].pobjeda; n.poraza += values[i].poraza; } return n; } 36

DODATAK B

Finalize funkcija
function(ime, value) { value.wl = value.pobjeda / value.poraza; return value; }

Poziv Map, Reduce i Finalize funkcija u Java programskom kodu

/* * Poziv Map i Reduce funkcija, * rezultat se sprema u privremenu zbirku temp */ MapReduceCommand cmd = new MapReduceCommand( getDB().getCollection("korisnici"), mapFunc, reduceFunc, "temp", MapReduceCommand.OutputType.REPLACE, null ); /* * Poziv Finalize funkcije */ cmd.setFinalize(finalizeFunc); /* * Sortiranje po polju "WL" (odnos pobjeda/poraza) */ DBObject sortWLDESC = new BasicDBObject(); sortWLDESC.put("value.wl", -1); /* * Dohvat kursora s kojim se kree po dobivenim rezultatima */ DBCursor c = getDB().getCollection("korisnici"). mapReduce(cmd).getOutputCollection().find().sort(sortWLDESC);

Ekvivalentni SQL upit SELECT ime, broj_pobjeda / broj_poraza FROM korisnici WHERE broj_poraza != 0 ORDER BY 2 Poziv SQL upita u Java programskom kodu
Connection conn = ConnectionPool.getConnection(); /* * Izvravanje SQL upita */ PreparedStatement stmtRead = conn.prepareStatement(SQLUpit); /* * Dohvat kursora s kojim se kree po dobivenim rezultatima */ ResultSet result = stmtRead.executeQuery();

37

DODATAK B

5. Zakljuak
NoSQL SUBP-ovi donose mnoge prednosti i inovacije u usporedbi s tradicionalnim relacijskim SUBP-ovima na podruju horizontalne skalabilnosti, replikacije podataka i rada s podacima bez unaprijed odreene sheme. Iako su prednosti znaajne, one ipak donose i nedostatke: skup ACID obiljeja koji je prisutan kod tradicionalnih relacijskih SUBP-ova i neophodan u mnogim primjenama, zamijenjen je BASE skupom obiljeja. Za kvalitetan odabir izmeu NoSQL SUBP-a i tradicionalnog relacijskog SUBP-a potrebno je dobro poznavati razlike ACID i BASE svojstava i kako one utjeu na rad s podacima. Kod odabira treba razmotriti i injenicu da veina NoSQL SUBP-ova postoji tek nekoliko godina u usporedbi s tradicionalnim relacijskim SUBP-ovima koji postoje ve nekoliko desetljea i koji su dokazali svoju stabilnost i kvalitetu. Nesumnjivo je da NoSql SUBP-ovi nisu prolazan trend i da e svoju primjenu nai u mnogim raspodijeljenim sustavima i programskim rjeenjima u oblacima. Dodajmo na kraju kako se ne radi nuno o izboru jedne ili druge tehnologije: relacijske baze podataka i NoSQL baze podataka se u sloenijim sustavim mogu kombinirati (nadopunjavati) kako bi se ostvarila optimalna rjeenja za pojedine zadae odnosno dijelove sustava.

38

DODATAK B

6. Literatura
1. Peschka, Jeremiah: Top 5 Reasons to use NoSql, http://facility9.com/2010/09/five-reasons-touse-nosql/, 22.4.2012. 2. Ruflin, Nicolas: Storing and Analyzing Social Data, Master thesis, University of Basel, pp. 1-48, 2010. 3. Kyle Banker, MongoDB in Action , Manning Publications Co, New York, 2012. 4. Couchbase: Data Management for Social and Online Games, 2012. 5. Strauch, Christof: NoSQL Databases, Hochschule der Medien, Stuttgart, 2011. 6. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach,Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber: Bigtable: A Distributed Storage System for Structured Dana, OSDI, Seattle, WA, 2006. 7. Inside Social Games, Top 25 Facebook Games of March 2012, http://www.insidesocialgames.com/2012/03/01/top-25-facebook-games-of-march-2012, 30.5.2012

39