OrioleDB forritarar greindu núverandi ástand lágstigs API sem notað er fyrir viðbætur til að fá aðgang að töflum og vísitölum í PostgreSQL (Table/Index Access Method (AM) API) og bentu á leiðir til að bæta það. Frá því að slíkt API var kynnt í PostgreSQL 12 hafa verktaki getað búið til aðrar gagnageymsluaðferðir. Hins vegar, þrátt fyrir tilvist þessa API og þekktar takmarkanir á innbyggðu geymsluvélinni, eru enn engar fullkomlega virkar viðskiptageymsluvélar útfærðar eingöngu sem framlengingar.
Vinsælustu eiginleikar annarra PostgreSQL borðvéla eru:
- Aðrar MVCC útfærslur, svo sem UNDO log-undirstaða verslanir.
- Vísitöluskipulagðar töflur, þar sem vísitalan er ekki valfrjáls viðbót við töfluna sem flýtir fyrir fyrirspurnum heldur er hún aðalgagnaskipulagið sem gögn töflunnar eru geymd í.
Breytingarnar sem þarf á Table/Index AM API til að styðja aðrar MVCC útfærslur eru ræddar með auga í átt að OrioleDB viðbótinni, sem var hönnuð til að taka á þekktum göllum innbyggðu PostgreSQL geymsluvélarinnar. Vandamálið er að full samþætting OrioleDB við PostgreSQL krefst breytinga á PostgreSQL kóðanum, sem flækir framkvæmd verkefnisins og undirstrikar þörfina á að nútímavæða núverandi Table AM API.
Tafla AM API ræður ekki beint hvernig MVCC ætti að innleiða. Hins vegar, Tafla AM API og Index AM API gera eftirfarandi forsendur: hvert TID (Tuple/row Identifier) er annað hvort verðtryggt með öllum vísitölum eða alls ekki verðtryggt. Jafnvel þótt Index AM sé með margar tilvísanir í eitt TID (t.d. GIN), verða allar þessar tilvísanir að varpa til sama verðtryggða gildisins.
Þessi meginregla hefur verið gagnrýnd fyrir að fjölga skrifaðgerðum ("write amplification") - ef einn verðtryggður eiginleiki er uppfærður þarf að uppfæra hverja vísitölu í töflunni. Ef þú vilt nýta þér UNDO-skrána til fulls, eða byggja aðra geymsluaðferð án "skrifamögnunar" (eins og WARM-aðferðin), þarftu að brjóta þessa forsendu.
UNDO-undirstaða tafla AM sem mun ekki brjóta í bága við þessa forsendu líkist núverandi HOT (Heap-Only Tuples) aðferð, nema að gamlar raðaútgáfur eru geymdar í UNDO-skránni og þurfa ekki að passa á sömu síðu. En samkvæmt höfundum nægir þessi kostur ekki til að réttlæta tilvist sérstakrar töflu AM.
Hagnýtar takmarkanir núverandi API:
- Þegar töflulína er uppfærð eru vísitölur uppfærðar á grundvelli allt-eða-ekkers.
- Index AM API skortir getu til að eyða sértækum túllum. Eins og er er hægt að eyða túllum úr vísitölum í lausu með því að nota ambulkdelete og amvacuumcleanup aðferðirnar. Að reyna að innleiða blettaeyðingu í gegnum þetta API myndi leiða til lítillar skilvirkni, þar sem flestar núverandi útfærslur verða að skanna alla vísitöluna. Að auki leyfir API þér ekki að tilgreina hvaða tuples sem vísa til sama TID ætti að eyða. Hann getur bara eytt þeim öllum.
- Vísitölur vísa nú til töflulína eftir blokkanúmeri (32 bita) og mótnúmeri (16 bita). Og aðeins 11 bita af offsetnúmerinu er hægt að senda á öruggan hátt frá TID töflunni til allra vísitöluaðgangsaðferða. Aðrar MVCC útfærslur gætu hins vegar þurft að geyma viðbótarhleðslu ásamt TID. Til dæmis, OrioleDB krefst einn eða fleiri bita til að innleiða "eyða-merkja" vísitölur eða fullar upplýsingar um sýnileika.
Lagðar eru til tvær leiðir til að sigrast á takmörkunum í framkvæmd:
Aðferð 1: Index AM API býður upp á valkosti fyrir aðra útfærslu á MVCC.
Þó að Tafla AM haldi áfram að bera ábyrgð á öllum íhlutum MVCC, þá veitir Index AM nauðsynlegan möguleika fyrir aðra útfærslu á MVCC, nefnilega: að geyma notandahleðslu ásamt TID, punktaeyðingaraðferð og jafnvel punktauppfærsluaðferð (ef ekki er hægt að breyta TID í vísitölunni getur notandahlaðinn það). Þar að auki, þar sem leyfa þarf mörgum vísitölutöflum að vísa til sama TID, þarf einnig að uppfæra API aðferðirnar sem notaðar eru við vísitöluskannanir.
Aðferð 2: MVCC-meðvitaðar vísitölur.
Annar valkostur væri að leyfa vísitölur sem styðja MVCC. Það er, „framkvæmdarstjórinn“ (eða kannski Table AM) kallar einfaldlega insert() og delete() aðferðirnar á Index AM, á meðan Index AM veitir MVCC-meðvitaða skannamöguleika. Þetta myndi gera vísitöluskönnun mun auðveldari. Jafnvel öll taflan AM gæti þá orðið millilag sem geymir gögn í vísitölu.
Myndin hér að neðan sýnir dæmi. Gildi vísitölu 2 er uppfært með færslu 11 úr gildi "A" í gildi "B". Þess vegna er gildi "A" merkt sem xmax == 11, og gildi "B" er merkt sem xmin == 11. Þannig er hægt að skanna vísitölu 2 og aðeins hægt að ná í sýnilega tuple í samræmi við MVCC án haugathugunar. Index 2 sorphirðu er einnig hægt að framkvæma án þess að nota hauginn.
Með öllum ofangreindum nýjungum í vísitöluaðgangsaðferðum API, er ólíklegt að hægt sé að uppfæra allar vísitölur samtímis til að styðja alla nýju eiginleikana. Það er raunhæfara að leyfa margar útfærslur fyrir eina vísitöluaðgangsaðferð. Til dæmis, auk venjulegs B-trés, mun framlengingin geta innleitt annað B-tré með MVCC stuðningi inni í vísitölunni og stuðningi við handahófskenndar færsluauðkenni.
Þannig er lagt til að endurskoða ekki aðeins Table AM API, heldur einnig Index AM API, sem hefur þjónað PostgreSQL samfélaginu vel í mörg ár. Ennfremur er lagt til að skipta Index AM í rökrétt lag og útfærslulag. Þessi endurmyndaða arkitektúr mun leyfa PostgreSQL að styðja mörg geymslulíkön.
Heimild: opennet.ru
