OrioleDB-udviklere analyserede den aktuelle tilstand af lavniveau-API'en, der bruges til udvidelser til at få adgang til tabeller og indekser i PostgreSQL (Table/Index Access Method (AM) API) og foreslog måder at forbedre det på. Siden introduktionen af en sådan API i PostgreSQL 12 har udviklere været i stand til at skabe alternative datalagringsmekanismer. Men på trods af eksistensen af denne API og de kendte begrænsninger af den indbyggede storage-motor, er der stadig ingen fuldt funktionelle transaktions-lagringsmotorer implementeret udelukkende som udvidelser.
De mest populære funktioner til alternative PostgreSQL-bordmotorer er:
- Alternative MVCC implementeringer, såsom UNDO log-baserede butikker.
- Indeksorganiserede tabeller, hvor indekset ikke er en valgfri tilføjelse til tabellen, der fremskynder forespørgsler, men er den primære datastruktur, hvori tabellens data er gemt.
Ændringerne, der er nødvendige i Table/Index AM API for at understøtte alternative MVCC-implementeringer, diskuteres med et øje mod OrioleDB-udvidelsen, som er designet til at løse kendte mangler ved den indbyggede PostgreSQL-lagringsmotor. Problemet er, at fuld integration af OrioleDB med PostgreSQL kræver ændringer af PostgreSQL-koden, hvilket komplicerer implementeringen af projektet og fremhæver behovet for at modernisere den nuværende Table AM API.
Table AM API dikterer ikke direkte, hvordan MVCC skal implementeres. Tabel AM-API og Index AM API gør dog følgende antagelse: hver TID (Tuple/row Identifier) er enten indekseret af alle indekser eller slet ikke indekseret. Selvom Index AM har flere referencer til et enkelt TID (f.eks. GIN), skal alle disse referencer tilknyttes den samme indekserede værdi.
Dette princip er blevet kritiseret for at øge antallet af skriveoperationer ("write amplification") - hvis en indekseret attribut opdateres, skal hvert indeks i tabellen opdateres. Hvis du vil drage fuld fordel af UNDO-loggen eller bygge en anden lagringsmetode uden "skriveforstærkning" (såsom WARM-metoden), skal du bryde denne antagelse.
En UNDO-baseret tabel AM, der ikke vil overtræde denne antagelse, ligner den eksisterende HOT (Heap-Only Tuples) metode, bortset fra at gamle rækkeversioner er gemt i UNDO-loggen og ikke behøver at passe på samme side. Men ifølge forfatterne er denne fordel ikke nok til at retfærdiggøre eksistensen af en separat tabel AM.
Praktiske begrænsninger af den eksisterende API:
- Når en tabelrække opdateres, opdateres indekser på alt-eller-intet-basis.
- Index AM API mangler muligheden for selektivt at slette specifikke tupler. Det er i øjeblikket muligt at slette tuples fra indekser i bulk ved hjælp af ambulkdelete- og amvacuumcleanup-metoderne. At forsøge at implementere spotsletninger gennem denne API ville resultere i lav effektivitet, da de fleste nuværende implementeringer skal scanne hele indekset. Derudover tillader API'en dig ikke at angive, hvilke tuples, der refererer til det samme TID, der skal slettes. Han kan kun slette dem alle.
- Indekser henviser i øjeblikket til tabelrækker efter bloknummer (32 bit) og offsetnummer (16 bit). Og kun 11 bits af offsetnummeret kan sikkert overføres fra tabellen TID til alle indeksadgangsmetoder. Alternative MVCC-implementeringer kan dog være nødvendigt at lagre yderligere nyttelast sammen med TID. For eksempel kræver OrioleDB en eller flere bits for at implementere "delete-marking"-indekser eller fuld synlighedsinformation.
Der foreslås to måder at overvinde begrænsningerne i praksis:
Fremgangsmåde 1: Index AM API giver muligheder for en alternativ implementering af MVCC.
Mens Tabel AM fortsat er ansvarlig for alle komponenterne i MVCC, giver Index AM de nødvendige muligheder for en alternativ implementering af MVCC, nemlig: lagring af en brugernyttelast sammen med TID'et, en punktsletningsmetode og endda en punktopdateringsmetode (hvis TID'et i indekset ikke kan ændres, kan brugerens nyttelast). Da flere indekstupler skal have lov til at referere til det samme TID, skal de API-metoder, der bruges under indeksscanninger, også opdateres.
Fremgangsmåde 2: MVCC-bevidste indekser.
Et alternativ ville være at tillade indekser, der understøtter MVCC. Det vil sige, at "executor" (eller måske Tabel AM) blot kalder metoderne insert() og delete() på Index AM, mens Index AM giver MVCC-bevidste scanningsmuligheder. Dette ville gøre scanning kun med indeks meget nemmere. Selv hele Table AM kan så blive et mellemlag, der lagrer data i et indeks.
Diagrammet nedenfor viser et eksempel. Værdien af indeks 2 opdateres af transaktion 11 fra værdi "A" til værdi "B". Derfor er værdi "A" markeret som xmax == 11, og værdi "B" er markeret som xmin == 11. På denne måde kan indeks 2 scannes, og kun synlige tupler kan hentes i overensstemmelse med MVCC uden heap checks. Indeks 2 affaldsopsamling kan også udføres uden brug af dyngen.
Med alle de ovennævnte innovationer i indeksadgangsmetodes API er det usandsynligt, at alle indekser vil kunne opdateres samtidigt for at understøtte alle de nye funktioner. Det er mere realistisk at tillade flere implementeringer for en enkelt indeksadgangsmetode. For eksempel vil udvidelsen ud over det almindelige B-træ være i stand til at implementere et alternativt B-træ med MVCC-understøttelse inde i indekset og understøttelse af arbitrær-længde-postidentifikatorer.
Det foreslås således at revidere ikke kun Table AM API, men også Index AM API, som har tjent PostgreSQL-fællesskabet godt i mange år. Desuden foreslås det at opdele Index AM i et logisk lag og et implementeringslag. Denne fornyede arkitektur vil tillade PostgreSQL at understøtte flere lagermodeller.
Kilde: opennet.ru
