OrioleDB arendajad on pakkunud parandusi API-le alternatiivsete PostgreSQL mootorite jaoks.

OrioleDB arendajad analüüsisid PostgresSQL-i tabelite ja indeksite laienduste madaltaseme API hetkeolukorda (Table/Index Access Method (AM) API) ning pakkusid välja selle täiustamise võimalusi. Alates PostgresSQL 12 käivitamisest on sellise API olemasolu võimaldanud arendajatel luua alternatiivseid andmesalvestusmehhanisme. Kuid hoolimata sellest API-st ja tuntud piirangutest sisseehitatud andmesalvestusmehhanismis, ei ole siiani täielikult funktsionaalseid tehingupõhiseid salvestusmootoreid, mis oleksid loodud ainult laiendustena.

PostgreSQL-i alternatiivsete tabelimootorite kõige nõutavamad funktsioonid on:

• Alternatiivsed MVCC-ide rakendused, nagu näiteks UNDO logide põhised salvestused.
• Indeksiga organiseeritud tabelid, kus indeks ei ole tabelile vabatahtlik lisa, mis kiirendab päringuid, vaid kujutab endast peamist andmestruktuuri, milles hoitakse tabeli andmeid.

Tabeli/indeksi AM API-sse vajalikud muudatused, et toetada alternatiivseid MVCC rakendusi, käsitletakse OrioleDB laienduse kontekstis, mis on loodud sisseehitatud PostgresSQL salvestusmehhanismi tuntud puuduste kõrvaldamiseks. Probleemiks on see, et OrioleDB täielikuks integreerimiseks PostgresSQL-iga on vajalikud muudatused PostgresSQL koodis, mis muudab projekti rakendamise keerulisemaks ja rõhutab vajadust current Table AM API moderniseerimise järele.

Table AM API ei määrata otse MVCC rakendamise meetodit. Siiski, Table AM API ja Index AM API teevad järgmise eeldamise: iga TID (Tuple/Row Identifier) kas indekseerib kõikide indeksitega või mitte ühtegi. Isegi kui Index AM-l on mitu viidet ühe TID-le (näiteks GIN), peavad kõik need viidatud vastama ühele ja samale indekseeritud väärtusele.

Seda põhimõtet on kritiseeritud kirjutamise tegevuste arvu suurenemise tõttu („write amplification“) — kui uuendatakse ühte indekseeritud atribuut, tuleb igat indeksit tabelis uuendada. Kui on vajalik täielikult ära kasutada UNDO logi eeliseid või ehitada mõni muu salvestusmeetod, mis ei põhjusta kirjutamise tugevdamist (näiteks WARM meetod), tuleb seda eeldust rikkuda.

Table AM, mis põhineb UNDO-l, ei riku seda eeldust ning sarnaneb olemasolevale meetodile HOT (Heap-Only Tuples), välja arvatud see, et vanad stringiversioonid hoitakse UNDO logis ja need ei pea mahtuma samasse lehekülge. Kuid autorite arvates ei piisa sellest eelisest, et põhjendada eraldi Table AM-i olemasolu.

Praegused API praktilised piirangud:

• Rea värskendamise ajal uuendatakse tabeli indeksid põhimõttel "kõik või mitte midagi".
• API Index AM-l puudub võimalus teatud korthäidete punktikustutamiseks. Praegu saab korthätteindeksitest kustutada korthäidete massilisi koguseid, kasutades meetodeid ambulkdelete ja amvacuumcleanup. Katse teostada punktikustutamine läbi selle API tooks kaasa madala efektiivsuse, kuna enamik praeguseid teostusi peab skaneerima kogu indeksi. Lisaks ei võimalda API määrata, millised korthätetest, mis viitavad samale TID-ile, tuleks kustutada. See saab kustutada ainult kõik.
• Indeksid viitavad praegu tabeli ridadele ploki numbri (32 bitti) ja nihke numbri (16 bitti) kaudu. Ainult 11 bitti nihke numbrist võib TID-st ohutult indeksi juurdepääsu meetoditesse edastada. Samuti võivad MVCC alternatiivsete teostuste jaoks olla vajalikud täiendavate kasuliku koormuse (payload) säilitamine koos TID-ga. Näiteks OrioleDB-s on vaja ühte või mitut bitti, et rakendada „delete-marking“ indekseid või täielikku nähtavuse teavet.

Kaks meetodit piirangute ületamiseks on ettepanekud:

Lähenemine 1: API Index AM pakub võimalusi alternatiivseks MVCC teostuseks.

Kuigi Table AM vastutab kõigi MVCC komponentide eest, pakub Index AM vajalikud võimalused alternatiivse MVCC teostuse jaoks, nimelt: kasutaja kasuliku koormuse (payload) säilitamine koos TID-ga, punktikustutamise meetod ja isegi punktivärskenduse meetod (kui indeksi TID-d ei saa muuta, võib kasutaja kasulik koormus muutuda). Lisaks on vajalik, et mitu indeksi korthäidjat viitaksid samale TID-le, seetõttu peavad indeksi skaneerimise ajal kasutatavad API meetodid samuti uuendamist.

Lähenemine 2: Indeksid, mis toetavad MVCC.

Alternatiiv oleks lubada MVCC toetavaid indekseid. See tähendab, et «executor» (või võib-olla Table AM) kutsub lihtsalt Index AM-is välja insert() ja delete() meetodid, samal ajal kui Index AM pakub võimalust skannimiseks MVCC arvestamisega. See lihtsustaks skannimist kasutades ainult indekseid (index-only) märkimisväärselt. Isegi kogu Table AM võiks sellisel juhul saada vahekihiks, mis talletab andmeid indeksis.

Alloleval joonisel on näide. Indeksi 2 väärtus värskendatakse tehinguga 11 väärtusest «A» väärtuseks «B». Seetõttu on väärtus «A» märgitud xmax == 11 ja väärtus «B» on märgitud xmin == 11. Nii saab skannida indeksit 2 ja saada ainult MVCC kohaseid nähtavaid tuple’ite ilma kuhja (heap) kontrollimata. Indeksi 2 prügikogu (garbage collection) saate samuti läbi viia ilma kuhjata.



Kuna kõigi nende uuenduste rakendamine indeksite juurdepääsu API-sse on keeruline, on ebatõenäoline, et suudetakse kõik indeksid üheaegselt täiendada kõigi uute võimalustega. Realistlikum oleks lubada ühe indeksi juurdepääsumeetodi jaoks mitmeid teostusi. Näiteks, tavapärase B-puuli kõrvale võiks laiendus rakendada alternatiivset B-puud, mis toetab MVCC-d indeksi sees ja toetab muutujate identifikaatoreid, mille pikkus on mistahes.



Seega on soovitatav üle vaadata mitte ainult Table AM API, vaid ka Index AM API, mis on olnud PostgreSQL kogukonna teenistuses aastaid. Veelgi enam, soovitatakse jagada Index AM loogiliseks kihiks ja rakenduse kihiks. See ümberkehastatud arhitektuur võimaldab PostgreSQL-l toetada erinevaid salvestusmudeleid.

Allikas: opennet.ru