OrioleDB arendajad pakuvad alternatiivsete PostgreSQL-i mootorite API täiustamist

OrioleDB arendajad analüüsisid PostgreSQL-i tabelitele ja indeksitele juurdepääsetavate laienduste jaoks kasutatava madala taseme API praegust olekut ja soovitasid selle täiustamiseks. Alates sellise API kasutuselevõtust PostgreSQL 12-s on arendajad suutnud luua alternatiivseid andmesalvestusmehhanisme. Siiski, hoolimata selle API olemasolust ja sisseehitatud salvestusmootori teadaolevatest piirangutest, pole ikka veel täielikult funktsionaalseid tehingusalvestusmootoreid, mida oleks rakendatud ainult laiendustena.

Alternatiivsete PostgreSQL-i tabelimootorite kõige populaarsemad funktsioonid on:

• Alternatiivsed MVCC-rakendused, näiteks UNDO logipõhised poed.
• Indeksiga organiseeritud tabelid, kus indeks ei ole tabeli valikuline lisand, mis kiirendab päringuid, vaid on esmane andmestruktuur, kuhu tabeli andmed salvestatakse.

Alternatiivsete MVCC rakenduste toetamiseks vajalikke muudatusi Table/Index AM API-s käsitletakse OrioleDB laienduse poole, mis oli mõeldud sisseehitatud PostgreSQL-i salvestusmootori teadaolevate puuduste kõrvaldamiseks. Probleem on selles, et OrioleDB täielik integreerimine PostgreSQL-iga nõuab muudatusi PostgreSQL-koodis, mis raskendab projekti rakendamist ja tõstab esile vajaduse moderniseerida praegust Table AM ​​​​API-d.

Tabel AM ​​API ei määra otseselt, kuidas MVCC-d tuleks rakendada. Tabeli AM ​​API ja Index AM API eeldavad aga järgmist: iga TID (korteeži/rea identifikaator) on kas kõigi indeksite poolt indekseeritud või üldse mitte indekseeritud. Isegi kui indeksil AM on mitu viidet ühele TID-le (nt GIN), peavad kõik need viited olema seotud sama indekseeritud väärtusega.

Seda põhimõtet on kritiseeritud kirjutamisoperatsioonide arvu suurendamise ("kirjutusvõimenduse") pärast – ühe indekseeritud atribuudi uuendamisel tuleb uuendada iga indeksit tabelis. Kui soovite UNDO logi täielikult ära kasutada või luua mõne muu salvestusmeetodi ilma "kirjutusvõimenduseta" (näiteks meetod WARM), peate selle eelduse murdma.

UNDO-põhine tabel AM, mis seda eeldust ei riku, meenutab olemasolevat HOT (Heap-Only Tuples) meetodit, välja arvatud see, et vanad reaversioonid salvestatakse UNDO logi ja need ei pea samale lehele mahtuma. Kuid autorite sõnul ei piisa sellest eelisest eraldi tabeli AM olemasolu õigustamiseks.

Olemasoleva API praktilised piirangud:

• Tabelirea värskendamisel värskendatakse indekseid põhimõttel "kõik või mitte midagi".
• Index AM API-l puudub võimalus konkreetseid kortereid valikuliselt kustutada. Praegu on võimalik indeksitest kortereid hulgi kustutada, kasutades meetodit ambulkdelete ja amvacuumcleanup. Kui proovite selle API kaudu punktkustutusi rakendada, väheneb tõhusus, kuna enamik praeguseid rakendusi peavad skannima kogu indeksi. Lisaks ei võimalda API teil määrata, millised samale TID-le viitavad korteežid tuleks kustutada. Ta saab ainult need kõik kustutada.
• Praegu viitavad indeksid tabeli ridadele ploki numbri (32 bitti) ja nihkenumbri (16 bitti) järgi. Ja ainult 11 bitti nihkearvust saab ohutult edastada tabelist TID kõigile indeksi juurdepääsumeetoditele. Alternatiivsed MVCC-rakendused võivad siiski vajada täiendavat kasulikku koormust koos TID-ga. Näiteks nõuab OrioleDB üht või mitut bitti, et rakendada "kustutamismärgistuse" indekseid või täielikku nähtavuse teavet.

Praktikas pakutakse välja kaks võimalust piirangute ületamiseks:

1. lähenemisviis: Index AM API pakub võimalusi MVCC alternatiivseks rakendamiseks.

Kuigi tabel AM vastutab jätkuvalt kõigi MVCC komponentide eest, pakub Index AM vajalikke võimalusi MVCC alternatiivseks juurutamiseks, nimelt: kasutaja kasuliku koormuse salvestamine koos TID-ga, punktide kustutamise meetod ja isegi punkti värskendamise meetod (kui indeksi TID-d ei saa muuta, saab kasutaja kasulikku koormust). Lisaks, kuna samale TID-le tuleb lubada viidata mitmel indeksikorpusel, tuleb uuendada ka indeksi skaneerimisel kasutatavaid API meetodeid.

2. lähenemisviis: MVCC-teadlikud indeksid.

Alternatiiviks oleks MVCC-d toetavate indeksite lubamine. See tähendab, et "täitur" (või võib-olla tabel AM) kutsub lihtsalt Index AM-i meetodeid insert() ja delete(), samas kui Index AM pakub MVCC-teadlikke skannimisvõimalusi. See muudaks ainult registripõhise skannimise palju lihtsamaks. Isegi kogu AM-tabel võib muutuda vahekihiks, mis salvestab andmeid indeksis.

Allolev diagramm näitab näidet. Indeksi 2 väärtust värskendatakse tehinguga 11 väärtuselt "A" väärtusele "B". Seetõttu on väärtus "A" tähistatud kui xmax == 11 ja väärtus "B" on tähistatud kui xmin == 11. Nii saab indeksit 2 skannida ja ilma kuhjade kontrollimiseta saab MVCC-ga kooskõlas ilma vaadata ainult nähtavaid kortereid. Indeks 2 prügivedu saab teostada ka ilma hunnikut kasutamata.



Kõigi ülaltoodud uuendustega indeksi juurdepääsumeetodite API-s on ebatõenäoline, et kõiki indekseid saab üheaegselt värskendada, et toetada kõiki uusi funktsioone. Reaalsem on lubada ühe indeksi juurdepääsumeetodi jaoks mitut rakendust. Näiteks saab laiendus lisaks tavalisele B-puule rakendada alternatiivset B-puud, millel on indeksi sees MVCC tugi ja suvalise pikkusega kirjeidentifikaatorite tugi.



Seega tehakse ettepanek vaadata üle mitte ainult Table AM ​​​​API, vaid ka Index AM API, mis on PostgreSQL-i kogukonda aastaid hästi teenindanud. Lisaks tehakse ettepanek jagada indeks AM loogiliseks kihiks ja rakenduskihiks. See ümberkujundatud arhitektuur võimaldab PostgreSQL-il toetada mitut salvestusmudelit.

Allikas: opennet.ru