Zhvilluesit e OrioleDB analizuan gjendjen aktuale të API-t të nivelit të ulët, të përdorur për aksesin e zgjerimeve në tabela dhe indekse në PostgreSQL (Table/Index Access Method (AM) API), dhe propozuan mënyra për përmirësimin e tij. Që nga shfaqja e këtij API në PostgreSQL 12, zhvilluesit morën mundësinë të krijojnë mekanizma alternativë për ruajtjen e të dhënave. Megjithatë, pavarësisht nga ekzistenca e këtij API dhe kufizimeve të njohura të mekanizmit të ruajtjes të integruar, akoma nuk kanë lindur motorë të ruajtjes transaksionale plotë-funksionalë, të realizuar gjithmonë në formë zgjerimesh.
Funksionet më të kërkuara për motorët alternativë të tabelave PostgreSQL janë:
- Implementime alternative të MVCC, për shembull, ruajtjet të bazuara në ditarin UNDO.
- Tabela të organizuara në indeks, ku indeksi nuk është një shtesë e opcionale për tabelën që shpejton kërkesat, por përfaqëson strukturën kryesore të të dhënave, në të cilën ruhen të dhënat e tabelës.
Modifikimet, të nevojshme në API-në Table/Index AM për të mbështetur implementimet alternative të MVCC, shqyrtohen me referencë në zgjerimin OrioleDB, që është zhvilluar për të eliminuar të metat e njohura të mekanizmit të ruajtjes të integruar të PostgreSQL. Problemi është se për integrimin e plotë të OrioleDB me PostgreSQL kërkohen ndryshime në kodin e PostgreSQL, çka e komplikon zbatimin e projektit dhe thekson nevojën për modernizimin e aktualit API Table AM.
API Table AM nuk imponon drejtpërdrejt mënyrën e implementimit të MVCC. Megjithatë, API Table AM dhe API Index AM bëjnë këtë supozim: çdo TID (Tuple/row Identifier) është ose indeksohet nga të gjitha indekset, ose nuk indeksohet fare. Madje edhe nëse Index AM ka disa referenca për një TID (p.sh., GIN), të gjitha këto referenca duhet të korrespondohen me një vlerë të indeksuar të njëjtë.
Ky parim Ă«shtĂ« kritikuar pĂ«r rritjen e numrit tĂ« operacioneve tĂ« shkrimit («write amplification») â nĂ«se azhurnohet njĂ« atribut i indeksuar, Ă«shtĂ« e nevojshme tĂ« azhurnohet çdo indekse nĂ« tabelĂ«. NĂ«se Ă«shtĂ« e nevojshme tĂ« shfrytĂ«zohen plotĂ«sisht pĂ«rfitimet e ditarit UNDO ose tĂ« ndĂ«rtohet njĂ« metodĂ« tjetĂ«r ruajtjeje pa «pĂ«rforcim tĂ« shkrimit» (p.sh., metoda WARM), Ă«shtĂ« e nevojshme tĂ« shkelet ky supozim.
Table AM i bazuar në UNDO, që nuk do të shkelë këtë supozim, i ngjan metodës ekzistuese HOT (Heap-Only Tuples), përveç që versionet e vjetra të rreshtave ruhen në ditarin UNDO dhe nuk duhet të ngjiten në të njëjtën faqe. Por, sipas autorëve, këtij avantazhi i mungon e drejta për të justifikuar ekzistencën e një Table AM të veçantë.
Kufizimet praktike të API-t aktual:
- Gjatë azhurnimit të rreshtit të tabelës, indekset azhurnohen sipas parimit «të gjitha ose asgjë».
- Mungesa në API-në Index AM të mundësisë për fshirjen e pikave të caktuara të caktueseve. Tani është e mundur të fshihen rreshtat nga indekset në mënyrë masive përmes metodave ambulkdelete dhe amvacuumcleanup. Përpjekja për të realizuar fshirjen e pikave të caktuara përmes këtij API do të sillte efikasitet të ulët, pasi shumica e implementimeve aktuale duhet të skanojnë të gjithë indeksin. Përveç kësaj, API nuk lejon të specifikohet se cilat nga caktuese të lidhur me të njëjtin TID duhet të fshihen. Ai mund të fshijë vetëm të gjithë.
- Indekset tani i referohen rreshtave të tabelës sipas numrit të bllokut (32 bit) dhe numrit të offsetit (16 bit). Dhe vetëm 11 bit të numrit të offsetit mund të kalohen sigurtësisht nga TID i tabelës në të gjitha metodat e aksesit të indeksit. Në të njëjtën kohë, implementimet alternative të MVCC mund të kenë nevojë për të ruajtur ngarkesë shtesë (payload) së bashku me TID. Për shembull, në OrioleDB kërkohen një ose disa bit për të realizuar indekset «delete-marking» apo informacionin e plotë për dukshmërinë.
Janë propozuar dy mënyra për të kapërcyer kufizimet në praktikë:
Qasja 1: API Index AM ofron mundësi për implementimin alternativ të MVCC.
NdĂ«rsa Table AM vazhdon tĂ« pĂ«rgjigjet pĂ«r tĂ« gjithĂ« komponentĂ«t e MVCC, Index AM ofron mundĂ«sitĂ« e nevojshme pĂ«r implementimin alternativ tĂ« MVCC, pikĂ«risht: ruajtjen e ngarkesĂ«s sĂ« pĂ«rdoruesit (payload) sĂ« bashku me TID, metodĂ«n e fshirjes sĂ« pikave dhe madje metodĂ«n e azhornimit tĂ« pikave (nĂ«se TID nĂ« indeks nuk mund tĂ« ndryshohet, ngarkesa e pĂ«rdoruesit â mund tĂ« ndryshohet). PĂ«r mĂ« tepĂ«r, pasi Ă«shtĂ« e nevojshme tĂ« lejohet qĂ« disa caktuese tĂ« indekseve tĂ« referohen nĂ« tĂ« njĂ«jtin TID, metodat e API-t qĂ« pĂ«rdoren gjatĂ« skanimit tĂ« indeksit gjithashtu kanĂ« nevojĂ« pĂ«r pĂ«rditĂ«sim.
Qasja 2: Indekset që mbështesin MVCC.
Një alternativë do të ishte të lejohej indekset që mbështesin MVCC. Pra, «executor» (ose ndoshta Table AM) thjesht thërret metodat insert() dhe delete() në Index AM, ndërsa Index AM ofron mundësinë e skanimit duke marrë parasysh MVCC. Kjo do të thjeshtonte në mënyrë të konsiderueshme skanimin duke përdorur vetëm indekset (index-only). Edhe i gjithë Table AM në këtë rast mund të bëhej një shtresë ndërmjetëse, e cila ruan të dhënat në indeks.
Në diagramin më poshtë është një shembull. Vlera e indeksit 2 përditësohet nga transaksioni 11 nga vlera «A» në vlerën «B». Prandaj, vlera «A» shënohet si xmax == 11, ndërsa vlera «B» shënohet si xmin == 11. Kështu mund të skanohet indeksi 2 dhe të merrni vetëm tuple të dukshme sipas MVCC pa kontrolle në heap. Pastrimi i mbeturinave në indeksin 2 gjithashtu mund të bëhet pa përdorimin e heap.
Me implementimin e të gjitha risive të përmendura në API-në e metodave të indeksit për qasje, është shumë e pamundur që të përfundojnë të gjitha indiket për mbështetje të gjitha mundësive të reja njëherësh. Më realiste është të lejohet disa realizime për një metodë të vetme qasjeje në indeks. Për shembull, në përveç të B-tree standarde, zgjerimi do të ishte në gjendje të implementonte një B-tree alternativ me mbështetje për MVCC brenda indeksit dhe mbështetje për identifikatorë regjistrimesh në gjatësi të rastësishme.
Prandaj, propozohet rishikimi jo vetëm i API Table AM, por edhe i API Index AM, i cili ka shërbyer besnikërisht komunitetit PostgreSQL për shumë vjet. Më tepër, propozohet ndarja e Index AM në një shtresë logjike dhe një shtresë implementimi. Kjo arkitekturë e ripensuar do të lejojë PostgreSQL të mbështesë modele të ndryshme ruajtjeje.
Burimi: opennet.ru
