db4o vs Hibernate/MySQL

Az elmúlt években egyre erősebben lehetett érezni azt, hogy a webes alkalmazások perzisztenciájának megoldására a relációs adatbázis kezelők egyre kevésbé alkalmasak.
Az RDBMS-ek sajnos nem nyújtják a legjobb megoldást ha elosztott rendszerről van szó és nagy mennyiségű adatokat kell tárolni. Ennek kiküszöbölésére jöttek létre például az elosztott cache-ek és a nem relációs elveken alapuló adatbázisok. Ezek modern megnevezése a NoSQL (http://en.wikipedia.org/wiki/NoSQL).

Habár a skálázhatóság fontos szempont, engem mégsem ez vezérelt mikor elkezdtem alternatív perzisztencia megoldást keresni webes alkalmazásokhoz. Az én fő szempontom az volt, hogy Java-ban könnyen kezelhető adatbázist találjak.
Igazából elegem lett abból, hogy az adataim modellezését kétszer kell megcsinálnom, a Java domain modellt és a relációs adatbázis sémát. Ezekhez a teendőkhöz még hozzátársul a két modell közötti megfeleltetés konfigurálása. Ez a többszörös munka több hibalehetőséget hoz magával, amit rendes teszteléssel lehet csak kideríteni.

Rátaláltam a NeoDatisra, amely egy objektum adatbázis Java-hoz és .Net-hez, nagyon kellemes API-t ad. A NeoDatis a teljesítményét a db4o-hoz méri, így úgy tűnt érdemes megnéznem azt is. Nem csalódtam benne, mert az API-ja szinte ugyanaz, de sokkal kiforrottabb.

Ez a poszt eredetileg a NeoDatis, db4o és Hibernate/MySQL adatbáziskezelő teljesítményének összehasonlításaként indult, de a NeoDatis még nem alkalmas production rendszerbe (habár a teljesítményre nem panaszkodhat, de hajlamos a hibára). A megmaradt két versenyzőt a PolePosition (http://www.polepos.org) nevű java adatbázis benchmark programmal hasonlítottam össze. Sajnos ennek a tesztprogramnak a fejlesztése 2005-ben megállt, viszont open source jellegéből adódóan letölthettem és kisebb módosításokkal és lib frissítésekkel működésre bírható volt.

A tesztkörnyezet paraméterei:
OS: Ubuntu 9.10 32 bit
CPU: Intel Atom 330 @ 1.6 GHz
Memória: 4 GB DDR2
db4o verzió: 7.12.132.14217
MySQL verzió: 5.1.30really5.0.75-0ubuntu10.2 (Ubuntu repo-ból)
Hibernate verzió: 3.3.2.GA

Az eredményekhez kattints ide.

A teszteredményekhez még annyit el kell árulnom, hogy az db4o embedded módban futott, így nem csak az ORM folyamatot, hanem a hálózati kommunikációt is megspórólta. Az embedded mód mellett létezik kliens/szerver mód is, de ez most nincs terítéken.

A PolePosition tesztben a teszt-eseteket Forma 1-es pályák neveivel látták el. Mindegyik pálya különböző típusú terhelést jelent, viszont elmondható, hogy a legtöbb követi az írás, lekérdezés/adatmódosítás, törlés ciklust. A pályákról részletesebben:

- Bahrain: egyszerű POJO objektumok kezelésének a tesztje. Az adatok lementése után a lekérdezéseken van a hangsúly. Indexelt és nem indexelt attribútumok alapján keres.
- Barcelona: 5 mélységű osztályhierarchiának objektumainak tárolását teszteli.
- Imola: objektum lekérdezése id (belső) alapján
- Melbourne: megint sima POJO-kat ír, a visszaolvasás ebben az esetben az összes elmentett adatra vonatkozik (select * from akarmi).
- Sepang: különböző mélységű objektum hierarchiák írását, olvasását és törlését teszteli

A db4o egészen jól teljesített. Sebességben felveszi a versenyt a Hibernate/MySQL párossal. Tudom, hogy a grafikonokon a db4o jobban teljesít a write, update, delete műveleteknél, de ezt úgy teszi, hogy hálózati forgalmat egyáltalán nem bonyolít. Ezért inkább egyenlőnek tekintem az állást ezekben a műveletekben. A db4o előnye a hierarchiák kezelésében jön ki, mind az osztály-hierarchia mind az objektum-hierarchia lekérdezésében jobban teljesít, mint a MySQL.
A MySQL is volt első ebben a tesztben, méghozzá a nem indexelt attribútumok alapján való lekérdezésben és a frissen lekérdezett adatok újbóli olvasásában (az utóbbit valószínűleg a Hibernate 1st level cachenek köszönheti).

A tesztjeim alapján és a db4o dokumentáció olvasgatása alapján bárkinek azt ajánlhatom, hogy érdemes kipróbálni és alternatív megoldásként tekinteni rá.

K.B.