Utvecklarna av OrioleDB har föreslagit förbättringar av API:n för alternativa PostgreSQL-motorer.

Utvecklarna av OrioleDB har analyserat det aktuella tillståndet för det lågnivå-API som används för att ge tillgång till utökningar av tabeller och index i PostgreSQL (Table/Index Access Method (AM) API) och föreslagit sätt att förbättra det. Sedan detta API introducerades i PostgreSQL 12 har utvecklarna haft möjlighet att skapa alternativa datalagringsmekanismer. Trots detta har det inte blivit några fullt fungerande transaktionella lagringsmotorer, som uteslutande implementeras som utökningar.

De mest efterfrågade funktionerna för alternativa tabellmotorer i PostgreSQL är:

• Alternativa implementeringar av MVCC, till exempel lagring baserad på UNDO-loggar.
• Indexorganiserade tabeller där index inte är ett valfritt tillägg till tabellen, vilket påskyndar frågorna, utan fungerar som den primära datalagringsstrukturen där tabellens data lagras.

De förändringar som krävs i API Table/Index AM för att stödja alternativa implementeringar av MVCC övervägs med hänsyn till OrioleDB-utvidgningen, som utvecklats för att åtgärda kända brister i den inbyggda lagringsmekanismen i PostgreSQL. Problemet är att fullständig integration av OrioleDB med PostgreSQL kräver ändringar i PostgreSQL-koden, vilket komplicerar projektets genomförande och understryker behovet av att modernisera det nuvarande API:et för Table AM.

API Table AM påtvingar inte direkt hur MVCC ska implementeras. Ändå gör API Table AM och API Index AM följande antagande: varje TID (Tuple/row Identifier) antingen indexeras av alla index eller inte indexeras alls. Även om Index AM har flera referenser till en TID (till exempel GIN), måste alla dessa referenser överensstämma med samma indexerade värde.

Detta princip har kritiserats för att öka antalet skrivoperationer ('write amplification') — om en indexerad attribut uppdateras, måste varje index i tabellen uppdateras. Om man helt vill utnyttja fördelarna med UNDO-loggen eller bygga en annan lagringsmetod utan 'förstärkning av skrivningar' (till exempel WARM-metoden), krävs det att detta antagande bryts.

Tabell AM, baserad på UNDO, kommer inte att bryta mot denna förutsättning och liknar den befintliga metoden HOT (Heap-Only Tuples), förutom att gamla versioner av rader sparas i UNDO-loggen och inte behöver få plats på samma sida. Men enligt författarna är denna fördel inte tillräcklig för att rättfärdiga existensen av en separat Table AM.

Praktiska begränsningar med det befintliga API:et:

• Vid uppdatering av tabellrader uppdateras indexen enligt principen 'allt eller inget'.
• Avsaknad av API Index AM för möjligheten att punktligt ta bort specifika tuples. För närvarande kan tuples tas bort från index massivt med metoderna ambulkdelete och amvacuumcleanup. Att försöka implementera punktvis borttagning genom detta API skulle leda till låg effektivitet, eftersom de flesta nuvarande implementationer måste skanna hela indexet. Dessutom tillåter API:et inte att ange vilka av de tuples som refererar till samma TID som ska tas bort. Det kan endast ta bort dem alla.
• Index hänvisar för närvarande till tabellrader genom blocknummer (32 bitar) och förskjutningsnummer (16 bitar). Endast 11 bitar av förskjutningsnumret kan säkert överföras från TID till alla indexåtkomstmetoder. Dessutom kan alternativa MVCC-implementationer behöva lagra en extra nyttolast tillsammans med TID. Till exempel kräver OrioleDB en eller flera bitar för att implementera 'delete-marking'-index eller fullständig synlighetinformation.

Två sätt har föreslagits för att övervinna begränsningarna i praktiken:

Tillvägagångssätt 1: API Index AM tillhandahåller möjligheter för alternativ MVCC-implementering.

Medan Table AM fortsätter att ansvara för alla komponenter av MVCC, erbjuder Index AM de nödvändiga funktionerna för alternativ MVCC-implementering, nämligen: lagring av användarnytolasten tillsammans med TID, metod för punktvis borttagning och till och med metod för punktvis uppdatering (om TID i indexet inte kan ändras, kan användarnytolasten ändras). Dessutom, eftersom flera tuples kan referera till samma TID, behöver de API-metoder som används vid indexskanning också uppdateras.

Tillvägagångssätt 2: Index som stödjer MVCC.

Ett alternativ skulle vara att tillåta index som stöder MVCC. Det vill säga att "executor" (eller eventuellt Table AM) helt enkelt anropar metoder som insert() och delete() i Index AM, medan Index AM erbjuder möjlighet att skanna med hänsyn till MVCC. Detta skulle avsevärt förenkla scanning med endast index (index-only). Till och med hela Table AM skulle i så fall kunna bli ett mellanlager som lagrar data i indexet.

I diagrammet nedan visas ett exempel. Indexvärdet 2 uppdateras av transaktion 11 från värdet "A" till värdet "B". Därför markeras värdet "A" som xmax == 11, och värdet "B" markeras som xmin == 11. Således kan index 2 skannas och endast synliga tuples erhållas i enlighet med MVCC utan kontroller av heapen. Skräputvinning av index 2 kan också utföras utan användning av heapen.



Vid implementeringen av alla de nämnda nyheterna i API:et för indexmetoder är det osannolikt att det går att samtidigt revidera alla index för att stödja alla nya funktioner. Det är mer realistiskt att tillåta flera implementationer för en indexmetod. Till exempel, utöver den vanliga B-tree, kan utvidgningen implementera en alternativ B-tree med stöd för MVCC inuti indexet och stöd för postidentifierare av godtycklig längd.



Således föreslås det att inte bara revidera API:et för Table AM, utan också API:et för Index AM, som har tjänat PostgreSQL-gemenskapen troget under många år. Dessutom föreslås det att dela upp Index AM i ett logiskt lager och ett implementationslager. Denna omdefinierade arkitektur kommer att möjliggöra för PostgreSQL att stödja olika lagringsmodeller.

Källa: opennet.ru