SVEUILITE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE VARADIN

Ante Toli

OBJEKTNA BAZA PODATAKA (ZODB)

SEMINARSKI RAD IZ KOLEGIJA BAZE PODATAKA 1

Varadin, 2012.

SVEUILITE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE VARADIN

Ante Toli, 38203/09-R Preddiplomski studij

OBJEKTNA BAZA PODATAKA (ZODB)

SEMINARSKI RAD IZ KOLEGIJA BAZE PODATAKA 1

Mentor:
Prof. dr. sc. Mirko Malekovi

Doc.dr.sc. Markus Schatten

Varadin, travanj 2012.

Sadraj

Contents
1. UVOD ....................................................................................................................................................................... 2 2.ZODB KAO NOSQL BAZA PODATAKA............................................................................................................ 3 3.OSOBINE ZODB ..................................................................................................................................................... 4 4.INSTALACIJA I KONFIGURACIJA ................................................................................................................... 1 5.PREZISTENTNE KLASE ...................................................................................................................................... 2 6.TRANSAKCIJE ....................................................................................................................................................... 3 7.VERZIJE .................................................................................................................................................................. 5 8.ZAKLJUAK .......................................................................................................................................................... 6 9.LITERATURA ......................................................................................................................................................... 7

1. Uvod

Zope Object Database (ZODB) je objektno-orijentirana baza podataka za uvanje objekata napisanih u programskom jeziku Python. Ideja autora je bila da se omogui uvanje Python objekata koji mogu biti meusobno razliiti i sadrati reference jedni na druge u bazi podataka u kojoj nijedna informacija o objektu nee biti izgubljena, to bi svakako bio sluaj sa koritenjem relaciskih baza podataka. Pored toga, upotreba relaciskih baza smanjuje slobodu programera u pisanju objektno-orijentiranog koda. ZODB ne uva podatke u tabelama, ve uva Python objekte u neizmjenjenom obliku, pa je tako programski kod koji na bilo koji nain pristupa ovoj bazi podataka daleko jednostavniji i laki za razumjevanje nego da je koriten Python u kombinaciji sa nekim upitnim jezikom za izvravanje upita nad relaciskih bazom podataka (npr. SQL-om). Ovime je prevladan jaz izmeu programa i baze podataka, odnosno eliminirana je potreba za pisanjem bilo kakvog meukoda ili pravljenjem mapiranja. Dont squeeze your objects into tables: store them in an object database (ne gurajte svoje objekte u tabele: uvajte ih u objektnoj bazi podataka) je i dalje moto ovog projekta koji se neprekidno razvija i unapreuje.

2.ZODB kao NoSQL baza podataka

Termin NoSQL se u posljednje vrrijeme koristi kao klasifikacija novu generaciju baza podataka sa zajednikom osobinom da ne koriste relacisku paradigmu. Iako ne postoji tona definicija, esto se podrazumjeva da ove baze podataka imaju jo i neke od sljedeih osobina: distribuiranost, open-source, mogunost replikacije i eventualna konzistentnost. Ovaj pokret je nastao rane 2009. godine sa ciljem kreiranja modernih baza podataka prilagoenih radu na web-u, i nastavlja se ubrzano razvijati. ZODB je postojao jo mnogo prije osnivanja ovog pokreta (kraj devedesetih), to je sluaj i sa mnogim drugim NoSQL bazama podataka. Njihova zajednika osobina je da su ne-relaciske, pa se ZODB moe svrstati u grupu NoSQL baza. Pored toga, ZODB je i open-source, ali nije distribuiran sistem niti omoguava jednostavnu replikaciju.

3.Osobine ZODB
ZODB je ukljuen u Zope (Z Object Publishing Environment, gde slovo Z u nazivu nema neko posebno znaenje), koji je svojevrsni framework za razvoj web aplikacija zasnovan na Python-u. ZODB se moe instalirati i koristiti i nezavisno od Zope-a, ali se razvojni procesi ova dva projekta meusobno prepliu, pa se tako nove verzije oba projekta izbacuju nasumino1. Zope omoguava i znatno lake koritenje ZODB-a, jer programer u tom sluaju ne mora da brine o konceptima kao to su transakcija, konekcija sa bazom podataka, fiziko uvanje podataka na disku i ostali unutarnji elementi komunikacije aplikacije sa bazom podataka,koji su prikazani na slici 1. ZODB ima punu podrku za transakcije i ispunjava sve ACID uslove (atominost, konzistentnost, izoliranost i trajnost)2. Programer ne mora da brine o sigurnosti pristupa podacima za svoju aplikaciju, jer sustav to radi automatski. Konflikti izmeu transakcija se takoe rijeavaju automatski, i to tako da su podaci u svakom trenutku konzistentni. ZODB od verzije 3.4 ima podrku za Multi Version Concurrency Control, koja uklanja konflikte kod itanja, jer je svakoj aplikaciji siguran pristup objektu u onom obliku u kojem je on bio na poetku transakcije.Naravno, to ne znai da su u potpunosti uklonjeni konflikti kod pisanja, ali to moe rijeiti koritenjem struktura podataka koje podravaju uklanjanje konflikata, kao to su binarna stabla u biblioteci BTrees. Transakcije podravaju i savepoint-e (esto se ovaj sustav naziva sustavom podtransakcija), koji daju mogunost fine kontrole greaka i smanjenje zauzea radne memorije koritenjem garbage collector-a u toku same transakcije. ZODB uva svaku transakciju u bazi podataka, pa je tako mogue za svaki objekat vidjeti povijest promjena, odnosno stanje tog objekta prije i poslje svake od izvrenih transakcija. Undo opcija je prisutna, ali nije preporuljiva za koritenje nad indeksiranim objektima ako je katalog odvojen od baze, jer ukoliko je neka kasnija transakcija promjenila indeks, undo e samo vratiti stanje objekta u bazi na neko prethodno, dok e indeks ostati nepromenjen, odnosno baza i katalog nee biti sinhronizovani. Ipak, u nekim sluajevima je potpuno sigurno koristiti undo opciju.3

1 2

http://searchsoa.techtarget.com/definition/Zope http://www.oracle.com/technetwork/articles/dsl/prez-transactions-lobs-089563.html 3 http://autopoiesis.foi.hr/wiki.php?name=Baze+Podataka+-+FOI&parent=NULL&page=oobp

Slika 1:Komunikacija aplikacije sa ZODB bazom podataka Izvor:http://plone.org/events/regional/nola05/collateral/Chris%20McDonoughZODB%20Tips%20and%20Tricks.pdf

ZODB ima potpunu podrku za Blobs (Binary large objects, binarni veliki objekti). Ovaj tip podataka se ne uva i obrauje kao ostali Python objekti, jer ne samo da zbog prirode Blobs-a nema potrebe za tim, ve bi u tom sluaju dolo do znaajnog poveanja baze podataka, a samim tim i do pada performansi. Zbog toga se za ovaj tip podataka koristi poseban prostor za pohranu na disku, ime je omogueno jednostavno upravljanje fajlovima i od po vie stotina megabajta, uz ouvanje performansi. Prilikom svakog itanja nekog objekata iz baze, ZODB ga smjetata u cache koji je u radnoj memoriji. Na taj nain svaki sljedei pristup objektu oduzima znatno manje vremena i resursa. Naravno, objekti kojima dugo nije pristupano se briu iz cacha kako bi se oslobodila memorija za nove objekte, i to sve potpuno transparentno za korisnika. Veliina cache se moe runo podesiti, tako da raunala sa dosta memorije mogu u potpunosti iskoristiti ovu mogunost za dodatno poboljanje performansi. Preporuka je da cache bude to vei, ali da pri

tom ne zauzme toliko memorije da operaciski sustav bude prinuen da koristi virtuelnu memoriju. Bitno je imati u vidu i to da ne postoji jedinstveni cache, ve se za svaku konekciju kreira poseban. Podeavanje cache je, pored optimizacije programskog koda, najznaajniji nain za izvlaenje boljih performansi iz aplikacije, pa mu se esto posveuje dosta vremena. ZODB uva sve verzije objekata u bazi, to znai da se nakon veeg broja izmena nad objektima baza moe viestruko uveati, to za posledicu ima loije performanse kao i nepotrebno zauzimanje prostora na disku. Za brisanje starijih verzija objekata koristi se procedura poznata kao pakovanje (packing), koja je dovoljno fleksibilna da osigura, na primer, brisanje samo onih objekata koji su stariji od nekoliko dana, dok se novije verzije i dalje uvaju u bazi. ZODB ima vie naina za uvanje podataka na disku. Najbolji i ujedno najee koriten, je FileStorage, kod koga se svi objekti, kao i njihove starije verzije, uvaju u jednom velikom fajlu sa ekstenzijom .fs, koji je u sutini transakripciski log. DirectoryStorage uva svaku verziju objekta u posebnom fajlu. Prednost u odnosu na FileStorage je ta to nakon nestandardnog iskljuivanja sustava ne mora se ponovo kreirati indeks fajl. I pored toga, DirectoryStorage ima malo korisnika. Od ostalih naina imamo PGStorage, koji je relativno nov pa se za sada rijetko koristi u ozbiljnijim aplikacijama, dok se BDBStorage, OracleStorage i APE vie gotovo uope ne koriste. Znaajno je to da ZODB omoguuje prikljuivanje podataka iz drugih baza na aplikaciju bez potrebe za modificiranjem izvornog koda, pa se objekti mogu uvati na razliitim medijima i u razliitim formatima4. Global Interpreter Lock ograniava Python na koritenje samo jednog procesora. Meutim Zope Enterprise Objects (ZEO) omoguava da vie Zope servera koristi istu bazu podataka pokretanjem jednog Zope klijenta za svaki procesor.

http://www.zodb.org/documentation/articles/ZODB1.html

4.Instalacija i konfiguracija
The Python Package Index (PyPI) je repozitorijum softvera za Python koji sadri veliki broj paketa za preuzimanje. PyPI je najbolje koristiti u kombinaciji sa Python skriptom easy_install, koja omoguava Python programerima da jednostavno preuzimaju i instaliraju pakete sa PyPI mree, pri tom vodei rauna o meuzavisnostima i verzijama. Paketi koji se mogu instalirati pomou easy_install skripte imaju ekstenziju .egg, i nazivaju se Python eggs. ZODB je konceptualno prilino jednostavan. Python klase moraju biti podklase klase Persistent kako bi bilo mogue koristiti ih u kombinaciji sa ZODB bazom. Instance ovih klasa se uzimaju sa diska kada su potrebne aplikaciji, i ostaju u radnoj memoriji. ZODB hvata sve modifikacije nad objektima, tako da se na primer nakon izvravanja naredbe obj.size = 1 modificirani objekat obiljeava kao prljav (dirty). Na zahtjev se prljavi objekti zapisuju ponovo na disk. Ovo predstavlja potvrivanje transakcije. Transakcije mogu biti i ponitene, to rezultira odbacivanjem svih izmjena i vraanjem prljavog objekta u stanje u kojem je bio prije poetka transakcije. ZODB posjeduje tri glavna interfejsa: klase Storage, DB, i Connection. DB i Connection sueljem imaju po jednu implementaciju, dok postoji vie klasa koje implementiraju sueljem Storage. Storage klase su na najniem nivou, i reguliraju uvanje i uzimanje objekata sa diska ili nekog drugog memorijskog medija. Postoji vie tipova Storage klasa, kao to su FileStorage, koja koristi klasine fajlove na disku, i bsddb3Storage, koja koristi BerkeleyDB bazu podataka. Programerima je omogueno da piu i vlastite Storage klase ukoliko to vie odgovara njihovim aplikacijama. Tako je mogue uvati objekte i u relaciskoj bazi podataka ili Metakit fajlu. Uz ZODB dolaze i dva primera Storage klasa, DemoStorage i MappingStorage, koje je mogue koristiti kao modele za pisanje potpuno novih klasa. DB klasa se nalazi iznad Storage klase, i posreduje u interakciji vie konekcija. Za svaki proces se kreira posebna instanca klase DB. Connection klasa je zaduena je za uzimanje objekata i njihovo uvanje na disku. Program sa vie niti (multithreaded) bi trebalo da kreira posebnu instancu klase Connection za svaku nit. Na taj nain razliite niti mogu da modificiraju objekte i da uvaju te izmjene u bazi potpuno nezavisno jedna od druge.

5.Prezistentne klase
Pretvaranje Python klase u perzistentnu klasu je jednostavno. Dovoljno je da ona bude potklasa klase Persistent, kao to je prikazano u sledeem primeru: import ZODB
from Persistence import Persistent class User(Persistent):

pass Klasa Persistent je klasa tipa ExtensionClass. Kao posledica toga, ona nije kompatibilna sa novim klasama i tipovima iz Python-a verzije 2.2 i novijih.

Radi jednostavnosti, u sljedeim primjerima klasa User e sadrati samo nekoliko atributa. U realnoj situaciji veina klasa bi vjerovatno sadravala i brojne metode, ali to nikako ne utijee na ZODB i nain na koji se postupa sa klasama, odnosno objektima. ZODB omoguuje nasljeivanje perzistentnosti. Poevi od (root) objekata, svi atributi tih objekata su takoe perzistentni, bez obzira da li su oni nekog standardnog Python tipa, ili su instance drugih klasa. Ne postoji metod za eksplicitno uvanje objekata u ZODB bazi podataka. Dovoljno je dodjeliti ih kao vrijednost atributa objektu koji se ve nalazi u bazi podataka. Ovakav lanac objekata mora se zavravati korijenskim objektom. U sledeem primjeru bit e kreirana baza korisnika koja omoguava uzimanje podataka iz objekta klase User pomou njegovog ID-a. Najpre uzimamo korijenski objekat koristei metod root() iz instance klase Connection. Korijenski objekat se ponaa kao Python rijenik, pa je mogue jednostavno mu dodavati parove klju/vrednost. Takoe, bie koriten i objekat klase OOBTree koji e sadrati sve objekte klase User (BTree je deo Zope sistema): dbroot = conn.root() if not dbroot.has_key(userdb):
from BTrees.OOBTree import OOBTree dbroot[userdb] = OOBTree()

userdb = dbroot[userdb] Ubacivanje novog korisnika je jednostavno. Kreira se objekat klase User, unesu se eljeni podaci u objekat, a zatim se objekat ubacuje u BTree instancu i potvruje transakcija:
newuser = User()

newuser.id = js

newuser.first_name = John ; newuser.last_name = Smith userdb[newuser.id] =newuser get_transaction().commit()

Koritenjem ZODB paketa, funkcija get_transaction() se pridodaje postojeim, ugraenim Python funkcijama. Funkcija get_transaction() vraa objekat klase Transaction, koji sadri commit() i abort(). Naredba commit() zapisuje sve modificirane objekte na disk, inei izmjene na taj nain stalnim, dok naredba abort() ponitava sve izmjene i vraa objekte u prethodno sauvano stanje.

6.Transakcije
Aplikacija komunicira sa transakcijama preko transakciskog menadera, koji je zaduen za postavljanje granica transakcija, to znai da ih on kreira i prati transakciju koja se trenutno izvrava. Podrazumjevani transakciski menader svakoj niti dodeljuje posebnu transakciju. Iako postoji mogunost za razvoj novih transakciskih menadera. Menader podataka posreduje u komunikaciji izmeu transakciskog menadera i mehanizma za uvanje podataka na disku. Da bi bio dio transakcije, menader podataka mora da joj se prikljui. Jednoj transakciji se moe prikljuiti vie menadera podataka, to znai da programer na primjer moe da operacije upisivanja podataka u ZODB i relacisku bazu podataka posmatra kao dio iste transakcije. Transakciski menader e se pobrinuti da ili oba upisivanja budu uspjena, ili se oba upisivanja ponite5. U okviru jedne transakcije mogue je kreirati i podtransakcije. Svaka podtransakcija se moe nezavisno potvrditi ili ponititi, iako potvrivanje podtransakcije nije konano sve dok se ne potvrdi i glavna transakcija. Osnovna uloga podtransakcija je smanjenje zauzea memorije tokom izvravanja transakcija u kojima sudjeluje jako veliki broj objekata. Programer moe u svojoj aplikaciji da odredi interval, odnosno broj objekata koji sudjeluju u transakciji, nakon kojeg e izvriti potvrivanje podtransakcije, to e sprijeiti da se cache napuni ogromnom koliinom podataka. Potvrivanje i ponitavanje podtransakcije se poziva slino kao i kod

http://old.zope.org/Members/mcdonc/HowTos/transaction

regularne transakcije, s tim to se odgovarajuim metodima predaje parametar 1:

get_transaction().commit(1) get_transaction().abort(1)

Nova podtransakcija automatski zapoinje nakon potvrivanja ili ponitavanja prethodne transakcije. Za ponitavanje transakcije koristi se naredba DB.undo(id), gde je id idektifikator transakcije. Ukoliko transakcija ne moe biti ponitena, bie podignut ZODB.POSException.UndoError izuzetak. Ovo se najee dogaa u sluaju da su objekti ukljueni u tu transakciju bili modificirani nekom kasnijom transakcijom. Nakon ponitavanja transakcije potrebno je pozvati naredbu commit() kako bi ponitavanje bilo zapisano u bazi. Ovde postoji i jedan problem, a to je da nit koja je izvrila ponitavanje ne vidi promjene nad objektima dok ne pozove naredbu Connection.sync(), ili izvri neku drugu transakciju. Postoje sluajevi kada je zbog nekog problema neophodno ponitavanje transakcije koja je u toku, ali izvravanje odreenog dijela programa mora se nastaviti bez obzira na rezultat transakcije. Na primjer, u web aplikaciji moe biti potrebno da se sva polja nekog formulara validiraju iako ve neko od prvih nije prolo validaciju, kako bi korisnik mogao da vidi sve mogue greke nakon svog zahteva. U ovakvim situacijama programer moe da obiljei problematinu transakciju kao doomed (osuena na propast). Ovakva transakcija se ponaa kao bilo koja regularna transakcija, ali u sluaju njenog potvrivanja bie prijavljena greka to e prouzrokovati njeno ponitavanje.

7.Verzije
Kao to je mogue da vie podtransakcija bude sadrano u jednoj regularnoj transakciji, tako je mogue smjestit vie regularnih transakcija u jednu dugu transakciju, koja se u ZODB terminologiji naziva verzija. Unutar verzije moe biti kreiran veliki broj transakcija koje se izvravaju ili ponitavaju, ali promjene unutar jedne verzije nee biti vidljive drugim konekcijama na istu bazu podataka. Verzije ne podravaju svi mehanizmi uvanja podataka, ali se to moe provjeriti pozivom naredbe supportsVersions() instance klase DB, koji vraa true ako podrava, a false u suprotnom. Verzija moe biti izabrana prilikom kreiranja instance klase Connection koristei naredbu DB.open([version]). Argument version je string koji predstavlja ime verzije: vers_conn = db.open(version=Working version) Transakcije dalje mogu biti potvrivane i ponitavane koristei konekciju sa verzijom. Konekcije kod kojih nije eksplicitno navedeno ime verzije, ili je navedeno drugo ime verzije, nee videti promjene unutar verzije sa nazivom Working version. I verzije se mogu potvrditi, odnosno ponititi, kako bi promjene unutar njih bile vidljive ostalim klijentima, odnosno ponitene. To se izvrava korienjem naredbom DB.commitVersion(), odnosno DB.abortVersion().

8.Zakljuak
ZODB je sustav koji je prisutan ve dugi niz godina, i koji je puno napredovao od svojih poetaka i postao veoma kvalitetan i pouzdan proizvod. Nema sumnje da e nove verzije donijeti jo brojnija poboljanja. Za jedan ovakav sustav koji je jednostavan za upotrebu, robustan, a pored svega i slobodan, oekivalo bi se da ima vei broj korisnika meu programerima. Problem je slian kao i kod ostalih nerelaciskih baza podataka: veliki broj programera je prosto naviknut na relaciske baze, koje su i najee koriste, pa ih ponekad upotrebljavaju i u situacijama kada su objektne baze prirodnije i efikasnije rijeenje. Drugi problem je vezanost ZODB sustava za programski jezik Python, to takoe odvraa veliki broj programera koji koriste neke druge programske jezike.

9.Literatura
http://wiki.zope.org/ZODB/guide/contents.html http://zodb.readthedocs.org/en/latest/ http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html http://en.wikipedia.org/wiki/Object_database http://pypi.python.org/pypi/ZODB3/3.10.3 http://docs.zope.org/zope2/zope2book/ZopeArchitecture.html http://searchsoa.techtarget.com/definition/Zope http://autopoiesis.foi.hr/wiki.php?name=Baze+Podataka+-+FOI&parent=NULL&page=oobp http://poincare.matf.bg.ac.rs/~smalkov//files/dobp.r373.2011/public/seminarski%20radovi/sem. Objektna%20baza%20podataka%20ZODB%20-%20Marko%20Stankovic.pdf http://www.coactivate.org/projects/topp-engineering/blog/2009/03/20/to-zodb-or-not-to-zodb