Mi az ImmuDB és mi az előnye? Technikai és gyakorlati áttekintés (1. rész)

Az AWS bejelentette, hogy a Quantum Ledger Database (QLDB) szolgáltatást 2025 júliusában megszüntetik, így a felhasználóknak alternatívát kell keresniük. A javasolt PostgreSQL-alapú megoldások nem valódi QLDB alternatívának tekinthetők, mivel nem nyújt kellő alacsony szintű megmásíthatatlanságot, szemben az immutable adatbázisokkal (Immutable Databases), amelyek garantálják az adatintegritás biztosítását, és megbízható blokklánc alternatívát jelenthetnek. A QLDB felhasználóinak három nyílt forráskódú alternatívát ajánlanak: ImmuDB, TerminusDB és Dolt. Ebben a cikkben áttekintjük, hogy mi az ImmuDB, milyen esetekben érdemes használni, és milyen alternatívák állnak rendelkezésre.

Mi az ImmuDB és miben különbözik a klasszikus adatbázisoktól?

Az ImmuDB egy nyílt forráskódú adatbázis, amely a tárolt adatok megmásíthatatlanságának garantálásával emelkedik ki a többi adatbázis megvalósítás közül. Bár egyes meglévő adatbázisok rendelkeznek azokkal a kiegészítő eszközökkel, amik lehetővé teszik az adatok változásának nyomon követését, a Codenotary csapata a problémát alapvetően más szemlélettel közelítette meg. A céljuk egy olyan adatbázis létrehozása volt, amely alapjaiban biztosítja a megmásíthatatlanságot.

A Codenotary hivatalos publikációja szerint a rendszer megalkotásának fő motivációját a kiberbiztonság és az adatintegritás kérdésköre jelentette. Ennek kapcsán felmerül a kérdés: mit is jelent pontosan a megmásíthatatlanság, és hogyan hogyan valósul ez meg a gyakorlatban?. Valójában ez a megfogalmazás ennél árnyaltabb, és a “tamper-proof”, ami tisztább képet fest az adatok helyességének biztosításáról. Az adatok teljes megmásíthatatlansága és törölhetetlensége helyett az ImmuDB minden módosítást nyomon követ ami történt, és ennek a helyességét egy úgynevezett Merkle-fával biztosítja.

A Merkle-fák olyan bináris fák, amiknek a levelei valamilyen értékhalmaznak a hash-elt értékei, belső csúcsai pedig a közvetlen leszármazottak hash-elt értékeinek hash-elései. Lényegében tehát a levéltől gyökérig tartó hash láncolatot takar. Amennyiben ez a hash függvény kriptográfiailag biztonságos, azaz a jósolhatósága “nehéz”, akkor a Merkle fa bármely elemének módosítása nem lehetséges észrevétlenül a hash függvény ismerete nélkül, hiszen a gyökérig vezető úton a szülő hash értékek már nem lennének konzisztensek a levél-beli elemmel. 

Az ImmuDB esetében ez azt jelenti, hogy bármilyen módosítás esetén - ha például hozzáadjuk az új értéket, mint levél a fához -. a gyökér hash értéke csakis akkor lesz valid, ha minden korábbi érték is változatlanul jelen van a fában. Ha illetéktelen módon megpróbálunk értéket módosítani, akkor a hash függvény ismeretének hiányában ezt a fát nem lehet naprakész és verifikált módon kezelni, beleértve a levelek törlését.

A kiberbiztonság területén gyakran hivatkoznak egy elsőre ellentmondásosnak tűnő érvre: a nyílt forráskódú megoldások sok esetben biztonságosabbak, hiszen nem csupán az ártó céllal érkező személyek látnak bele a működésbe, hanem azok is, akiknek érdekük fűződik a rendszer biztonságának megőrzéséhez és fejlesztéséhez. A Codenotary csapata is ezt a megközelítést választotta: a Go nyelvben írt ImmuDB bárki számára elérhető nyílt forráskódú projektként, az Apache 2.0 licenc alatt a GitHub-on.

Az ImmuDB alkalmazási területei

Az ImmuDB elsődleges célja az adatbázisban tárolt adatok hitelessége, és az integritásának védelme. Hasonló célokra használják a Blockchain-alapú adatbázisokat is, amelyek szintén lehetővé teszik az adatok változásának nyomon követését. A két technológia azonban több szempontból is egymás inverzének tekinthető. A Blockchain-alapú adatbázist olyan területeken érdemes alkalmazni, ahol az üzleti logikában résztvevő felek nem bíznak egymásban, és kis komplexitású adatstruktúra decentralizált konszenzusára van szükség. Ezzel szemben az ImmuDB által is képviselt filozófia egy centralizált, megmásíthatatlan relációs adatbázis sémát követ.

Más, “mezei” adatbázisok esetében minden ilyen funkció nem az adatbázis sajátosságai révén, hanem az azt kiegészítő egyéb eszközökkel és kiegészítőkkel valósul meg. Ezek adott esetben megkerülhetők, így sebezhetővé válik az adatok védelme. 

“Locks keep honest people honest.”

Mikor érdemes az ImmuDB-t választani?

Az ImmuDB használata elsősorban olyan esetekben javasolt, ahol az adatintegritás, a változások nyomon követhetősége, az adatbiztonság és az audit naplózás lehetősége elsődleges szempont, a blokkláncnál nagyobb hatékonyságot szeretnénk elérni, ám nélkülözni tudjuk a technológia elosztott architektúrájából fakadó előnyöket. Az ImmuDB weboldala szerint több ismert vállalat is alkalmazza már a rendszert különféle formában. Emiatt az ImmuDB releváns választás lehet QLDB migráció esetén is, amikor olyan alternatívát keresünk, amely képes biztosítani a megváltoztathatatlanságot és a kriptográfiai hitelesítést.

Fiatal kora, és az ebből fakadó nehézségek (kompatibilitás, dokumentáció hiánya) ellenére az ImmuDB vonzó lehet olyan startupok számára is, amelyek olyan infrastruktúra köré építenék alkalmazásukat, ahol alapvető a megmásíthatatlanság. Ez esetben az ImmuDB gyors és relatív könnyen fejleszthetősége jelentős előnyt nyújthat a startup fejlődésének korai szakaszában.

Az ImmuDB használata különböző programnyelveken

Az ImmuDB alapvetően kulcs-érték párokkal dolgozó adatbázis, ami eltér a széles körben elterjedt relációs megoldásoktól. A kulcs-érték pár adatbázis lényege, hogy minden tárolt adat egy egyedi kulccsal érhető el. Ez azonban nem akadályozta meg a fejlesztőket abban, hogy egy SQL absztrakciót emeljenek a rendszer fölé, aminek segítségével az ImmuDB relációs adatbázisként is emulálható. Bár ez a felhasználása egyelőre limitált más, régebb óta fejlesztett relációs adatbázisokhoz képest, az alapvető funkcionalitásokat ellátja a saját megmásíthatatlansági feltételei mellett is.

Mivel az ImmuDB a Go nyelvben íródott, elsőrendű támogatása ehhez van. Emellett több más nyelvhez is vannak szintén nyílt forráskódú projektek, mint például a Python, Java, .Net és NodeJs. Ezek között vannak eltérések, mivel nem minden megvalósítás ekvivalens egymással, így a nyelv kiválasztásakor különös figyelmet érdemes fordítani a hozzá tartozó dokumentációra.

Cikkünk következő részében az ImmuDB megoldást egy Python Django projekt példáján keresztül vizsgáljuk meg részletesebben.