Spremembe, potrebne v API-ju Table\/Index AM za podporo alternativnim implementacijam MVCC, se obravnavajo ob upo\u0161tevanju raz\u0161iritve OrioleDB, razvite za odpravo znanih pomanjkljivosti vgrajenega mehanizma shranjevanja PostgreSQL. Te\u017eava je, da so za popolno integracijo OrioleDB s PostgreSQL potrebne spremembe v kodi PostgreSQL, kar ote\u017euje izvedbo projekta in poudarja potrebo po modernizaciji trenutnega API-ja Table AM. <\/p>\n
API Table AM ne narekuje neposredno na\u010dina izvedbe MVCC. Kljub temu API Table AM in API Index AM delita to domnevo: vsak TID (Tuple\/row Identifier) je bodisi indeksiran z vsemi indeksi bodisi sploh ni indeksiran. Tudi \u010de ima Index AM ve\u010d referenc na en TID (na primer, GIN), morajo vse te reference ustrezati istemu indeksiranemu vrednosti.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nTa na\u010dela so kritizirali zaradi pove\u010danja \u0161tevila zapisov (\u00bbwrite amplification\u00ab) \u2014 \u010de se posodobi en indeksiran atribut, je potrebno posodobiti vsak indeks v tabeli. Da bi v celoti izkoristili prednosti UNDO dnevnika ali razvili drugo metodo shranjevanja brez \u00bbpove\u010danega zapisa\u00ab (na primer metodo WARM), je treba to domnevo kr\u0161iti.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nTabela AM, zasnovana na UNDO, ki ne bo kr\u0161ila te predpostavke, spominja na obstoje\u010do metodo HOT (Heap-Only Tuples), s to razliko, da stare razli\u010dice vrstic ostajajo v UNDO logu in ne smejo biti shranjene na isti strani. Vendar pa avtorji menijo, da ta prednost ni dovolj, da bi upravi\u010dila obstoj lo\u010denega Table AM. <\/p>\n
Prakti\u010dne omejitve obstoje\u010dega API-ja: <\/p>\n
- \n
- Med posodobitvijo vrstice tabele se indeksi posodabljajo po na\u010delu \u00bbvse ali ni\u010d\u00ab.\n
- Pomanjkanje v API-ju Index AM mo\u017enosti to\u010dkovnega brisanja dolo\u010denih tupljev. Trenutno je mogo\u010de bri\u0161eti tuplje iz indeksov masovno s pomo\u010djo metod ambulkdelete in amvacuumcleanup. Poskus implementacije to\u010dkovnega brisanja prek tega API-ja bi privedel do nizke u\u010dinkovitosti, saj bi ve\u010dina trenutnih implementacij morala skenirati celoten indeks. Poleg tega API ne omogo\u010da dolo\u010danja, kateri od tupljev, ki se nana\u0161ajo na isti TID, naj se izbri\u0161ejo. Lahko izbri\u0161e le vse.\n
- Indeksi trenutno sklicujejo na vrstice tabele po \u0161tevilu bloka (32 bitov) in \u0161tevilu premika (16 bitov). In le 11 bitov \u0161tevilke premika lahko varno prenesemo iz TID tabele v vse metode dostopa do indeksa. Pri tem lahko alternativne implementacije MVCC zahtevajo shranjevanje dodatne uporabne obremenitve (payload) skupaj s TID. Na primer, v OrioleDB je potrebno enega ali ve\u010d bitov za izvedbo indeksov \u00bbdelete-marking\u00ab ali popolne informacije o vidnosti. <\/ul>\n
Predlagana sta dva na\u010dina za premagovanje omejitev v praksi: <\/p>\n
- \n
Pristop 1: API Index AM zagotavlja mo\u017enosti za alternativno implementacijo MVCC. <\/p>\n
Medtem ko Table AM \u0161e naprej odgovarja za vse komponente MVCC, Index AM zagotavlja potrebne funkcionalnosti za alternativno implementacijo MVCC, in sicer: shranjevanje uporabne obremenitve (payload) skupaj s TID, metoda to\u010dkovnega brisanja in celo metoda to\u010dkovnega posodabljanja (\u010de TID v indeksu ne more biti spremenjen, uporabna obremenitev \u2013 lahko). Poleg tega, ker je potrebno dovoljiti ve\u010dim tupljem indeksa, da se sklicujejo na isti TID, zahtevajo tudi API metode, uporabljene pri skeniranju indeksa, posodobitev. <\/p>\n
Pristop 2: Indeksi, ki podpirajo MVCC. <\/p>\n
Alternativa bi bila dovoliti indeksom, da podpirajo MVCC. To pomeni, da \u00bbexecutor\u00ab (ali morda Table AM) preprosto pokli\u010de metode insert() in delete() v Index AM, medtem ko Index AM omogo\u010da skeniranje ob upo\u0161tevanju MVCC. To bi znatno poenostavilo skeniranje z uporabo samo indeksov (index-only). Tudi celoten Table AM bi v tem primeru lahko postal vmesni sloj, ki shranjuje podatke v indeksu. <\/p>\n
Na spodnjem diagramu je prikazan primer. Vrednost indeksa 2 se posodobi s transakcijo 11 z vrednosti «A» na vrednost «B». Zato je vrednost «A» ozna\u010dena kot xmax == 11, vrednost «B» pa kot xmin == 11. Tako lahko skeniramo indeks 2 in pridobimo le vidne nize v skladu z MVCC brez preverjanja kupov (heap). Tudi zbiranje smeti indeksa 2 se lahko izvede brez uporabe kupa.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nPrilikom implementacije svih navedenih inovacija u API indeksnih metoda pristupa, malo je verovatno da \u0107e biti mogu\u0107e istovremeno doraditi sve indekse za podr\u0161ku svim novim mogu\u0107nostima. Realisti\u010dnije je dozvoliti nekoliko implementacija za jednu indeksnu metodu pristupa. Na primer, pored uobi\u010dajenog B-treeda, pro\u0161irenje bi moglo implementirati alternativni B-tree sa podr\u0161kom za MVCC unutar indeksa i podr\u0161kom za identifikatore zapisa proizvoljne du\u017eine.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n