A Unix fejlesztői az 1970-es években egy jól használható adattárolási módot találtak ki: az adatokat folytonosan kell elhelyezni a merevlemezen,
az így kialakított fájlokat pedig fa szerkezetben kell tárolni. Ez a megoldás az akkori igényeket maximálisan kielégített, ugyanis elég egyszerű
és rugalmas volt a feladatok elvégzéséhez: akkoriban a programok jellemzően az egész fájlt beolvasták a memóriába, majd a számítások elvégzését
követően visszaírták a teljes fájlt a merevlemezre. Ez a koncepció kiválóan működött a szekvenciális állományokra, amelyek kizárólag ASCII
karaktereket tartalmaztak.
Másrészről azonban felmerült az igény relációs adatbázisokban tárolt adatok mentésére. A nagy mennyiségű, összetett struktúrájú adat felhalmozásakor
fontos tényezővé vált a tárolókapacitás optimális kihasználása és az adatelérés idejének minimalizálása. Ehhez csupán azt az "egyszerű"
kérdést kellett jól megválaszolni, hogy hogyan képezzük le az adatbázist a merevlemezre, azaz az adatbázis mely eleme feleljen meg egy fájlnak?
Ha túl nagy egységet választunk a leképezéshez (pl. az egész adatbázist vagy 1 táblát), akkor előfordulhat, hogy a fájl belső szerkezete lesz túl
bonyolult ahhoz, hogy az adatokat hatékonyan tároljuk vagy elérjük. Ha azonban túl kicsi egységet választunk: mondjuk minden rekordot vagy minden
mezőt önálló fájlban tárolunk, akkor "szétforgácsoljuk" az adatokat, ami megint csak az adatelérés rovására megy. Bár a különböző fájlrendszerek
javítottak valamelyest az elérési sebességen és a tárterület optimális kihasználásán, a Unix fájlrendszerei két problémára nem adtak megoldást: sosem
vált lehetővé a tranzakció-kezelés, illetve sosem volt igazán jó a tárolási mód nagy mennyiségű elemi adat esetén.
A modern adatbázisokban ezért a Unix fájlszervezéshez az alkalmazási rétegbe épült be az az intelligencia, amely a nagy mennyiségű elemi adat hatékony
kezelését lehetővé tette.
Adattárolás a memóriában
A Pliant készítői a kezdetektől fogva amellett érveltek, hogy a gyakorta szükséges adatokat az adatbázis-kezelő tartsa a könnyen elérhető operatív tárban.
Az egyszerű ellenérvre, mely szerint a növekvő adatbázis nem fog beleférni a memóriába, a tervezők azt az egyszerű választ adták, hogy ez nem feltétlenül baj,
ugyanis a memória elfogyasztását követően a rendszer működhet tovább helyesen, csak gyengébb teljesítménnyel. Aki szeretné kihasználni azt a kényelmet, hogy
az adatokat a merevlemez helyett a memóriában kezelje, kénytelen számolni azzal a hatékonyságcsökkenéssel, ami a memória teljes kihasználása esetén lép fel.
Természetesen nem kell megvárni a memória felhasználását, hiszen a sok gigányi adat között nyilván akadnak olyan adatok, amelyek az adott számításokhoz
nem szükségesem és később a lemezről újra betölthetőek.
- A számos nyelvből jól ismert explicit allokáció jelenthet megoldást, de a többszörös hivatkozások esetén ez járhat duplikálással is.
- A Python nyelvben használt hivatkozás számláló lényege, hogy a memóriában lévő adatelemekhez egy-egy számlálót tartunk nyilván, amely megmondja, hogy hány helyről hivatkoznak az adott adatra. Amennyiben a számláló értéke 0-ra csökken, az adatelem törölhető, az általa foglalt hely pedig felszabadítható, hiszen az adat nincs használatban. Ez a módszer bár első ránézésre rokonszenves lehet, valójában nem hatékony. A számlálók nem csak újabb helyet vesznek el a memóriából, de aktualizálásuk folyamatos munkát igényel, ami állandóan számítási kapacitást von el. Ráadásul a körkörösen hivatkozott adatok felismerése és a hivatkozások feloldása igazán bonyolult adatszerkezetek esetében nem kivitelezhető.
- A garbage collection, amely a memória túlzott kihasználása esetén lép életbe az éppen nem hivatkozott adatokat távolítja el. Persze ez esetben nem könnyű eldönteni, hogy mely adatokra nincs hivatkozás, hiszen erre vonatkozólag semmilyen előzetes információ nem áll rendelkezésre. Annak ellenére, hogy ez alacsony szintű programozást igényel, a módszer használatos napjaink magas szintű programozási nyelveiben, mint pl. a Java. Fontos, hogy a módszer csak akkor hatékony, ha a garbage collection csak ritkán fut le.
Tárolási modell
Ahogy az előbb is láthattuk, a Pliant adattárolásának kulcsa, hogy minden adatot objektumként tárol a globális gyorsítótárban felépített fa hierarchiában.
A merevlemezre írt adatok pedig csak a változások naplózásaként funkcionálnak. A módszer hátránya, hogy meg kell oldani a merevlemezen lévő adatok egyedi
azonosítását, majd mindezt le kell tudni képezni a memóriára. Az adatok egyedi azonosítása a memóriacímzés használatával adott, bár az alkalmazás újraindításával
a memóriacímek átrendeződhetnek. Nem árt tudni, hogy a Pliant ezen problémák leküzdésére számos technikát alkalmaz, melyek akár verziónként is eltérőek
lehetnek.
Egy adatbázishoz hasonló nyitott rendszerben a fájlnaplózás nem csak azt teszi lehetővé, hogy tudjuk ki és mikor fért hozzá egy adathoz, hanem azt is, hogy
ha egy hozzáférés illetéktelen kezekbe kerülne, mely időpontra kell visszaállítani az adatokat. A naplózás emellett egyszerűsíti távoli adatbázisszerverek
szinkronizációját is, hiszen elegendő csupán a naplófájlt továbbítani, majd a szükséges műveleteket elvégezni.
Pliant adatbázis modell
A Pliant adatbázis modellje az imént részletezet tárolási modellen alapszik. Ennek megfelelően egy Pliant adatbázis-motor is faszerkezetben tárolja az
adatokat. A hagyományos adatbázis modellel szemben, mely szerint az adatbázis táblákból, a táblák rekordokból, a rekord pedig mezőkből áll és a táblák között 1-1
és 1-n kapcsolatok definiálhatók, a Pliant modellje az egészet a faszerkezet oldaláról közelíti meg: míg a hagyományos relációs adatbázis egy kapcsolatok
mentén felépített bonyolult gráf, addig a Pliant azt erőlteti, hogy a gráf felső szintjei legyenek egyszerűek. Sőt, a felső szinteken elhelyezett fa
szerkezet nagy hatékonysággal gyorsítja az adatelérést, az összetett adatszerkezetek pedig lehetnek a fa csúcsain lévő gráfok (beágyazott táblák).
Mindkét rendszernek megvannak a maga előnyei:
Mivel a relációs adatbázis kapcsolatai egyedi kulcsok egyenlőségén alapszanak, a modern adatbázis motorok indexek segítségével gyorsítják az adatelérést. A különféle
indexek az n-n kapcsolatok feloldásakor keletkező kapcsolótáblák esetében kifejezetten hatékonyak tudnak lenni. Összegezve tehát a relációs adatbázis-kezelők
ráálltak arra, hogy igazán bonyolult adatbázis kapcsolatokat leírva is hatékonyan működjenek.
Másrészt azonban a gyakorlatban legtöbb adatbázisnak van valamiféle "gerince", így a relációk sem olyan szövevényesek. Ezekben az esetekben a bonyolult
indexelési eljárások közel sem lehetnek olyan hatékonyak, mint a Pliant modellje, amely a fő adatokat faként tárolja, ezzel biztosítva a gyors elérést. Ezáltal
a memóriába be nem került adatok elérése is egy merevlemezről történő olvasással elérhetőek, nem kell bonyolult hierarchiákat követni a lassú elérésű diszken.
A Pliant megközelítése tehát hasonlít a progamnyelvi adattárolási modellre, hiszen a faszerkezet itt is egyfajta gyorsítótárban, az operatív tárban helyezkedik
el, ezzel minimalizálva a lassan elérhető háttértár (jelen esetben a merevlemez) szerepét.
Míg az adatbázis-kezelők többsége az SQL-t, azaz egy deklaratív programnyelvet használ az adatbázis-interakciók megfogalmazásához, addig a Pliant procedurális alapokon
oldja meg ezt a problémát. Hogy miért? A tervezők válasza rendkívül frappáns: először is a logikai programnyelveken a legtöbb programozónak közel sincs akkora
tapasztalata, mint a procedurális nyelveken. Sőt, utóbbi esetben a közlendőnk sokkal absztraktabban megfogalmazható, mint mondjuk SQL-ben.