OrioleDB arendajad pakuvad välja parandusi PostgreSQL alternatiivsete mootorite API-le.

OrioleDB arendajad analüüsisid PostgreSQL-is tabelite ja indeksite laienduste juurdepääsu jaoks kasutatava madala taseme API praegust seisundit (Table/Index Access Method (AM) API) ja pakkusid välja selle täiustamise võimalusi. Alates PostgreSQL 12 tutvustamisest on arendajatel olnud võimalus luua alternatiivseid andmesalvestusmehhanisme. Siiski, hoolimata selle API olemasolust ja sissetuleva salvestusmehhanismi tuntud piirangutest, ei ole siiani täieliku funktsionaalsusega tehingute salvestusmootoreid, mis oleksid rakendatud ainult laiendustena.

PostgreSQL alternatiivsete tabelimootorite jaoks on kõige nõudlikumad funktsioonid:

• MVCC alternatiivsed teostused, näiteks UNDO žurnali põhised salvestused.
• Indeksiga korraldatud tabelid, kus indeks ei ole tabeli täiendav funktsioon, mis kiirendab päringute täitmist, vaid kujutab endast peamist andmestruktuuri, kus tabeli andmeid säilitada.

API Table/Index AM-i jaoks vajalikud muudatused MVCC alternatiivsete rakenduste toetamiseks arutatakse OrioleDB laienduse kontekstis, mis on välja töötatud PostgreSQL-i sisseehitatud salvestusmehhanismi tuntud puuduste kõrvaldamiseks. Probleem seisneb selles, et OrioleDB täielik integratsioon PostgreSQL-iga nõuab muudatusi PostgreSQL-i koodis, mis muudab projekti rakendamise keeruliseks ja rõhutab vajadust praeguse API Table AM-i moderniseerimise järele.

API Table AM ei sea MVCC rakenduse üleloomulikke nõudmisi. Siiski, API Table AM ja API Index AM eeldavad järgmist: iga TID (Tuple/row Identifier) on kas indekseeritud kõigi indeksite poolt või üldse mitte indekseeritud. Isegi kui Index AM-l on mitmeid viiteid ühe TID-iga (näiteks GIN), peavad kõik need viited vastama ühele ja samale indekseeritud väärtusele.

Seda põhimõtet kritiseeriti, kuna see suurendab kirjutamisoperatsioonide arvu („write amplification“) — kui uuendatakse ühte indekseeritud atribuuti, tuleb iga tabeli indeks uuendada. Kui soovitakse täielikult kasutada UNDO logi eeliseid või luua mõni muu salvestusmeetod ilma „kirjutamise suurenemiseta“ (nt WARM meetod), tuleb seda eeldust rikkuda.

UNDO-l põhinev Table AM, mis ei rikuks seda eeldust, meenutab olemasolevat HOT (Heap-Only Tuples) meetodit, välja arvatud see, et vanad ridade versioonid salvestatakse UNDO logis ja ei pea mahtuma samasse lehte. Kuid autorite arvates ei ole see eelis piisav, et õigustada eraldi Table AM olemasolu.

Praeguste API praktilised piirangud:

• Tabeli ridade uuendamise ajal uuendatakse indekseid „kõik või mitte midagi“ põhimõtte järgi.
• API Index AM-is puudub võimalus eemaldada kindlaid ridasid. Praegu saab ridu massiliselt eemaldada indikaatoritest meetodite ambulkdelete ja amvacuumcleanup kaudu. Katse rakendada punktide eemaldamist läbi selle API tooks kaasa madala efektiivsuse, kuna enamik praegustest rakendustest peavad kogu indikaatori skaneerima. Lisaks ei võimalda API määrata, millised rida, mis viitavad samale TID-le, tuleks eemaldada. See suudab eemaldada ainult kõik.
• Indeksid viitavad praegu tabelite ridadele ploki numbri (32 bitti) ja nihke numbri (16 bitti) kaudu. Ainult 11 bitti nihke numbrist saab turvaliselt edastada TID tabelist kõigisse indeksi juurdepääsumeetoditesse. Sellega seoses võivad alternatiivsed MVCC rakendused vajada täiendava laadimise (payload) salvestamist koos TID-ga. Näiteks OrioleDB nõuab indeksi „delete-marking” rakendamiseks ühe või mitme bit’i säilitamist või täielikku nähtavuse teavet.

Pakkuda on kaks võimalust, kuidas piirangutest üle saada:

Lähenemine 1: API Index AM pakub võimalusi alternatiivse MVCC rakendamise jaoks.

Kuigi Table AM vastutab kõigi MVCC komponentide eest, pakub Index AM vajalikku tuge alternatiivse MVCC rakenduse jaoks, nimelt: kasutaja kasuliku koormuse (payload) salvestamine koos TID-ga, punktide kustutamise meetod ja isegi punktide uuendamise meetod (kui TID indeksis ei saa muudetud, siis kasutaja kasulik koormus – saab). Lisaks, kuna on vajalik lubada mitmetel indeksikorteritel viidata samale TID-le, vajavad indeksiskannimise ajal kasutatavad API meetodid samuti uuendamist.

Lähtekoht 2: MVCC-d toetavad indeksid.

Alternatiiv oleks lubada MVCC-d toetavad indeksid. St «executor» (või võimalikult Table AM) kutsub lihtsalt Index AM-is välja insert() ja delete() meetodid, samas kui Index AM võimaldab skaneerimist, arvestades MVCC-d. See lihtsustaks oluliselt skaneerimist, kasutades ainult indekseid (index-only). Isegi kogu Table AM võiks sellisel juhul olla vahekiht, mis salvestab andmeid indeksis.

Allpooli näidatakse allolevas diagrammis. Indeksi väärtus 2 uuendatakse tehinguga 11 väärtuselt "A" väärtusele "B". Seetõttu on väärtus "A" märgitud kui xmax == 11 ja väärtus "B" kui xmin == 11. Nii saab indeksi 2 skaneerimist teostada ja saada ainult nähtavaid tuple'e vastavalt MVCC-le, ilma kuhja (heap) kontrollideta. Indeksi 2 prügikogu võib samuti toimuda ilma kuhi kasutamiseta.



Kõigi eespool toodud uuendustega indeksimeetodite API-s on vähetõenäoline, et kõik indeksid suudetakse samal ajal täiustada, et toetada kõiki uusi funktsioone. Realistlikum on lubada mitmeid rakendusi ühe indeksi meetodi jaoks. Näiteks võiks lisaks tavalisele B-puule laiendus rakendada alternatiivset B-puud, millel on oma indeksis MVCC tugi ja muutuva pikkusega kirje identifikaatorite tugi.



Seega soovitatakse läbi vaadata mitte ainult API Table AM, vaid ka API Index AM, mis on aastate jooksul hästi teeninud PostgreSQL kogukonda. Veelgi enam, soovitatakse jagada Index AM loogiliseks kihiks ja rakenduskihiks. See ümbermõeldud arhitektuur võimaldab PostgreSQL-l toetada erinevaid salvestusmudeleid.

Allikas: opennet.ru