Az OrioleDB fejlesztői elemezték a PostgreSQL-ben a táblákhoz és indexekhez való hozzáférést biztosító alacsony szintű API jelenlegi helyzetét (Table/Index Access Method (AM) API), és javaslatokat tettek a fejlesztésére. A PostgreSQL 12-es verziójában megjelenő API óta a fejlesztők alternatív adatbázistárolási mechanizmusokat hozhattak létre. Azonban, a meglévő API és az ismert beépített tárolási mechanizmus korlátai ellenére, még mindig nem jelentek meg teljes mértékben funkcionális tranzakciós tárolómotorok, amelyek kizárólag bővítmények formájában valósultak meg.
A PostgreSQL alternatív táblamotoraihoz leginkább keresett funkciók:
- Alternatív MVCC megvalósítások, például UNDO naplóalapú tárolók.
- Indexált táblák, ahol az index nem egy opcionális kiegészítés a táblához, amely felgyorsítja a lekérdezéseket, hanem az alapvető adatstruktúra, amelyben a táblázat adatai tárolódnak.
A Table/Index AM API-ban végrehajtandó változtatásokat az OrioleDB kiterjesztés szemszögéből vizsgálják, amelyet a PostgreSQL beépített tárolási mechanizmusának ismert hiányosságainak kiküszöbölésére fejlesztettek ki. A probléma az, hogy az OrioleDB teljes integrációjához a PostgreSQL kódjában módosításokat kell végezni, ami bonyolítja a projekt bevezetését, és hangsúlyozza a jelenlegi Table AM API korszerűsítésének szükségességét.
A Table AM API nem kényszerít közvetlenül MVCC megvalósítási módot. Mégis, a Table AM és Index AM API az alábbi feltevést teszi: minden TID (Tuple/row Identifier) vagy minden index által indexálva van, vagy egyáltalán nem indexálva. Még ha az Index AM több hivatkozást is tartalmaz egy TID-re (például GIN), akkor az összes hivatkozásnak ugyanarra az indexált értékre kell vonatkoznia.
Ezt az elvet a „write amplification” (írási fokozódás) miatt kritizálták – ha egy indexelt attribútum frissítése történik, akkor minden indexet frissíteni kell a táblában. Ha a legteljesebb mértékben ki szeretnénk használni az UNDO naplót, vagy egy másik tárolási módszert szeretnénk kiépíteni „írás fokozódás” nélkül (például WARM módszer), akkor ezt a feltevést meg kell szegni.
Az UNDO-ra alapozott Table AM, amely nem sérti ezt a feltételezést, hasonlít a meglévő HOT (Heap-Only Tuples) módszerhez, kivéve, hogy a régi sorverziók az UNDO naplóban tárolódnak, és nem kell, hogy ugyanabban az oldalon legyenek. Az írók véleménye szerint azonban ez az előny nem elegendő ahhoz, hogy indokolja a külön Table AM létezését.
A meglévő API gyakorlati korlátai:
- A táblázat sorának frissítésekor az indexek a 'mindent vagy semmit' elv szerint frissülnek.
- Az API Index AM nem nyújt lehetőséget bizonyos tuple-ök pontszerű törlésére. Jelenleg tömegesen lehet törölni a tuple-öket az indexekből az ambulkdelete és az amvacuumcleanup módszerek segítségével. A pontszerű törlés megvalósítása ezen az API-n keresztül alacsony hatékonysághoz vezetne, mivel a jelenlegi implementációk többsége az egész indexet át kell, hogy szkennelje. Ezenkívül az API nem teszi lehetővé, hogy megadjuk, mely tuple-öket kell törölni, amelyek ugyanarra TID-re hivatkoznak. Csak az összeset törölheti.
- Az indexek jelenleg a táblázat soraira blokkazonosító (32 bites) és eltolási szám (16 bites) segítségével hivatkoznak. Csak 11 bit eltolás száma adható át biztonságosan a táblázat TID-jéből az index hozzáférési módszerekhez. Ezenkívül az alternatív MVCC implementációknak további hasznos teher (payload) tárolása lehet szükséges a TID mellett. Például az OrioleDB esetében egy vagy több bit szükséges a 'törlés-megjelölés' indexek megvalósításához vagy a láthatóság teljes információjának tárolásához.
Két módot javasoltak a korlátok gyakorlati túllépésére:
1. megközelítés: Az API Index AM lehetőségeket biztosít az alternatív MVCC megvalósítására.
Míg a Table AM továbbra is felelős a MVCC összes komponenséért, az Index AM a szükséges lehetőségeket biztosít az alternatív MVCC megvalósításához, nevezetesen: a felhasználói hasznos teher (payload) tárolása a TID-vel együtt, a pontszerű törlési módszer és akár a pontszerű frissítési módszer (ha a TID az indexben nem módosítható, a felhasználói hasznos teher módosítható). Ezenkívül, mivel lehetővé kell tenni, hogy több indextuple hivatkozzon ugyanarra a TID-re, az index szkennelésekor alkalmazott API módszereknek is frissítésre van szükségük.
2. megközelítés: MVCC-t támogató indexek.
A megoldás az lenne, hogy engedélyezzük az MVCC-t támogató indexeket. Tehát az „executor” (vagy talán a Table AM) egyszerűen hívja az insert() és delete() metódusokat az Index AM-ben, míg az Index AM biztosítja az MVCC figyelembevételével történő szkennelés lehetőségét. Ez jelentősen megkönnyítené a csak indexekkel történő szkennelést (index-only). Még az egész Table AM is közbülső réteggé válhatna, amely az indexben tárolja az adatokat.
Az alábbi diagram egy példát mutat be. A 2-es index értékét a 11-es tranzakció frissíti az "A" értékről "B" értékre. Ezért az "A" értéket xmax == 11-ként, míg a "B" értéket xmin == 11-ként jelölhetjük. Így a 2-es indexet átvizsgálva csak az MVCC szerint látható tuple-öket kaphatunk anélkül, hogy a heap ellenőrzése szükséges lenne. A 2-es index szemétgyűjtése szintén elvégezhető a heap használata nélkül.
A fent említett újítások implementálásánál az indexelési metódusok API-jában valószínűtlen, hogy egyszerre sikerülne az összes indexet módosítani az új funkciók támogatására. Realistább lenne, ha több megvalósítás is engedélyezve lenne egy indexelési metódus számára. Például a hagyományos B-fa mellett a kiterjesztés megvalósíthat egy alternatív B-fát, amely támogatja az MVCC-t az indexen belül, és kezeli az önkényes hosszúságú rekordazonosítókat.
Így javasolt a Table AM API mellett az Index AM API felülvizsgálata is, amely évek óta megbízhatóan szolgálja a PostgreSQL közösséget. Továbbá javasolt az Index AM-et logikai rétegre és végrehajtási rétegre bontani. Ez az újragondolt architektúra lehetővé teszi a PostgreSQL számára, hogy különböző tárolási modelleket támogasson.
Forrás: opennet.ru
