Tabeli\/indeksi AM API-sse vajalikud muudatused, et toetada alternatiivseid MVCC rakendusi, k\u00e4sitletakse OrioleDB laienduse kontekstis, mis on loodud sisseehitatud PostgresSQL salvestusmehhanismi tuntud puuduste k\u00f5rvaldamiseks. Probleemiks on see, et OrioleDB t\u00e4ielikuks integreerimiseks PostgresSQL-iga on vajalikud muudatused PostgresSQL koodis, mis muudab projekti rakendamise keerulisemaks ja r\u00f5hutab vajadust current Table AM API moderniseerimise j\u00e4rele. <\/p>\n
Table AM API ei m\u00e4\u00e4rata otse MVCC rakendamise meetodit. Siiski, Table AM API ja Index AM API teevad j\u00e4rgmise eeldamise: iga TID (Tuple\/Row Identifier) kas indekseerib k\u00f5ikide indeksitega v\u00f5i mitte \u00fchtegi. Isegi kui Index AM-l on mitu viidet \u00fche TID-le (n\u00e4iteks GIN), peavad k\u00f5ik need viidatud vastama \u00fchele ja samale indekseeritud v\u00e4\u00e4rtusele.
![\"OrioleDB](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nSeda p\u00f5him\u00f5tet on kritiseeritud seoses kirjutamistegevuse arvu suurenemisega \u2014 kui \u00fche indekseeritud atribuudi uuendamiseks on vajalik iga indeksi uuendamine tabelis. T\u00e4ielike UNDO logi eeliste kasutamiseks v\u00f5i teise salvestusmeetodi arendamiseks ilma \"kirjutamise suurenemiseta\" (nt WARM meetod) on vajalik selle eeldus rikkuda.
![\"OrioleDB](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nTable AM, mis p\u00f5hineb UNDO-l, ei riku seda eeldust ning sarnaneb olemasolevale meetodile HOT (Heap-Only Tuples), v\u00e4lja arvatud see, et vanad stringiversioonid hoitakse UNDO logis ja need ei pea mahtuma samasse lehek\u00fclge. Kuid autorite arvates ei piisa sellest eelisest, et p\u00f5hjendada eraldi Table AM-i olemasolu. <\/p>\n
Praegused API praktilised piirangud: <\/p>\n
- \n
- Tabeli rea uuendamise ajal uuendatakse indekseid \"k\u00f5ik v\u00f5i mitte midagi\" p\u00f5him\u00f5tte j\u00e4rgi.\n
- API Index AM-l puudub v\u00f5imalus teatud korth\u00e4idete punktikustutamiseks. Praegu saab korth\u00e4tteindeksitest kustutada korth\u00e4idete massilisi koguseid, kasutades meetodeid ambulkdelete ja amvacuumcleanup. Katse teostada punktikustutamine l\u00e4bi selle API tooks kaasa madala efektiivsuse, kuna enamik praeguseid teostusi peab skaneerima kogu indeksi. Lisaks ei v\u00f5imalda API m\u00e4\u00e4rata, millised korth\u00e4tetest, mis viitavad samale TID-ile, tuleks kustutada. See saab kustutada ainult k\u00f5ik.\n
- Indeksid viitavad praegu tabeli ridadele plokknumbri (32 bitti) ja nihkenumbri (16 bitti) kaudu. Ainult 11 bitti nihkenumbrist v\u00f5ib TID tabelist ohutult indeksi juurdep\u00e4\u00e4su meetoditesse edastada. Samuti v\u00f5ivad alternatiivsetel MVCC teostustel olla vajalikud t\u00e4iendavad koormused (payload) koos TID-ga. N\u00e4iteks OrioleDB-s on vajalik \u00fcks v\u00f5i mitu bitti \"kustutamise m\u00e4rgistamise\" indeksite v\u00f5i t\u00e4ieliku n\u00e4htavusteabe rakendamiseks. <\/ul>\n
Kaks meetodit piirangute \u00fcletamiseks on ettepanekud: <\/p>\n
- \n
L\u00e4henemine 1: API Index AM pakub v\u00f5imalusi alternatiivseks MVCC teostuseks. <\/p>\n
Kuigi Table AM vastutab endiselt k\u00f5igi MVCC komponentide eest, pakub Index AM vajalikud v\u00f5imalused MVCC alternatiivse teostuse jaoks, nimelt: kasutajakoorma (payload) salvestamine koos TID-ga, punktkustutamise meetod ja isegi punktuuendamise meetod (kui TID-d indeksis ei saa muuta, siis kasutajakoormust saab). Lisaks on vajalik, et mitu indeksi tupikut viitaksid samale TID-le, seega tuleb indeksiskeemide skannimisel rakendatavaid API meetodeid ka uuendada. <\/p>\n
L\u00e4henemine 2: Indeksid, mis toetavad MVCC. <\/p>\n
Alternatiiv oleks lubada indekseid, mis toetavad MVCC-d. See t\u00e4hendab, et \"executor\" (v\u00f5i ehk Table AM) kutsub lihtsalt Index AM-is v\u00e4lja insert() ja delete() meetodeid, samal ajal kui Index AM pakub v\u00f5imalust skannimiseks MVCC arvestusega. See lihtsustaks oluliselt indeksi skannimist, kasutades ainult indekseid. Isegi kogu Table AM v\u00f5iks sellisel juhul muutuda vahekihiks, mis salvestab andmeid indeksis. <\/p>\n
Allole diagramm n\u00e4itab n\u00e4idet. Indeksi 2 v\u00e4\u00e4rtus uuendatakse tehinguga 11 v\u00e4\u00e4rtusest «A» v\u00e4\u00e4rtuseks «B». Seet\u00f5ttu on v\u00e4\u00e4rtus «A» t\u00e4histatud kui xmax == 11 ja v\u00e4\u00e4rtus «B» t\u00e4histatud kui xmin == 11. Seega saab indeksit 2 skaneerida ja saada ainult n\u00e4htavad tuplid vastavalt MVCC-le ilma hunniku (heap) kontrollideta. Indeksi 2 pr\u00fcgikogumine saab samuti toimuda ilma hunniku kasutamiseta.
![\"OrioleDB](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nKuna k\u00f5igi nende uuenduste rakendamine indeksite juurdep\u00e4\u00e4su API-sse on keeruline, on ebat\u00f5en\u00e4oline, et suudetakse k\u00f5ik indeksid \u00fcheaegselt t\u00e4iendada k\u00f5igi uute v\u00f5imalustega. Realistlikum oleks lubada \u00fche indeksi juurdep\u00e4\u00e4sumeetodi jaoks mitmeid teostusi. N\u00e4iteks, tavap\u00e4rase B-puuli k\u00f5rvale v\u00f5iks laiendus rakendada alternatiivset B-puud, mis toetab MVCC-d indeksi sees ja toetab muutujate identifikaatoreid, mille pikkus on mistahes.
![\"OrioleDB](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n