Ndryshimet e nevojshme n\u00eb API-n\u00eb Table\/Index AM p\u00ebr t\u00eb mb\u00ebshtetur realizimet alternative t\u00eb MVCC shqyrtohen me v\u00ebmendje n\u00eb zgjerimin OrioleDB, t\u00eb zhvilluar p\u00ebr t\u00eb eliminuar t\u00eb metat e njohura t\u00eb mekanizmit t\u00eb ruajtjes t\u00eb integruar n\u00eb PostgreSQL. Problemi \u00ebsht\u00eb se p\u00ebr integrimin e plot\u00eb t\u00eb OrioleDB me PostgreSQL k\u00ebrkohen modifikime n\u00eb kodin e PostgreSQL, gj\u00eb q\u00eb e v\u00ebshtir\u00ebson zbatimin e projektit dhe thekson nevoj\u00ebn p\u00ebr modernizimin e API-t aktual t\u00eb Table AM. <\/p>\n
API Table AM nuk e imponon drejtp\u00ebrdrejt m\u00ebnyr\u00ebn e realizimit t\u00eb MVCC. Megjithat\u00eb, API Table AM dhe API Index AM b\u00ebjn\u00eb k\u00ebt\u00eb supozim: \u00e7do TID (Tuple\/Rreshti Identifikues) ose indeksohet nga t\u00eb gjitha indekset, ose nuk indeksohet fare. Edhe n\u00ebse Index AM ka disa referenca n\u00eb nj\u00eb TID (p.sh., GIN), t\u00eb gjitha k\u00ebto referenca duhet t\u00eb p\u00ebrputhen me t\u00eb nj\u00ebjtin vler\u00eb t\u00eb indeksuar.
![\"Zhvilluesit](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nKy princip \u00ebsht\u00eb kritikuar p\u00ebr rritjen e numrit t\u00eb operacioneve t\u00eb shkruar (\"write amplification\") \u2014 n\u00ebse nj\u00eb atribut i indeksuar p\u00ebrdit\u00ebsohet, \u00ebsht\u00eb e nevojshme t\u00eb p\u00ebrdit\u00ebsohet \u00e7do indeks n\u00eb tabel\u00eb. Kur \u00ebsht\u00eb e nevojshme t\u00eb shfryt\u00ebzohen n\u00eb maksimum avantajet e regjistrit UNDO ose t\u00eb nd\u00ebrtohet nj\u00eb metod\u00eb tjet\u00ebr ruajtjeje pa \"p\u00ebrforcimin e shkrimit\" (p\u00ebr shembull, metoda WARM), \u00ebsht\u00eb e nevojshme t\u00eb thyhet ky supozim.
![\"Zhvilluesit](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nTabela AM e cila bazohet n\u00eb UNDO, e cila nuk do t\u00eb d\u00ebmtoj\u00eb k\u00ebt\u00eb supozim, i ngjan metod\u00ebs ekzistuese HOT (Heap-Only Tuples), p\u00ebrve\u00e7 faktit se versionet e vjetra t\u00eb rreshtave ruhen n\u00eb regjistrin UNDO dhe nuk duhet t\u00eb p\u00ebrshtaten n\u00eb t\u00eb nj\u00ebjt\u00ebn faqe. Por, sipas autor\u00ebve, ky avantazh nuk \u00ebsht\u00eb i mjaftuesh\u00ebm p\u00ebr t\u00eb justifikuar ekzistenc\u00ebn e nj\u00eb Table AM t\u00eb ve\u00e7ant\u00eb. <\/p>\n
Kufizimet praktike t\u00eb API ekzistues: <\/p>\n
- \n
- Gjat\u00eb azhurnimit t\u00eb rreshtave t\u00eb tabel\u00ebs, indekset azhurnohen sipas parimit 't\u00eb gjitha ose asgj\u00eb'.\n
- Mungesa n\u00eb API t\u00eb Index AM e mund\u00ebsis\u00eb p\u00ebr fshirjen e pik\u00ebs s\u00eb caktuar t\u00eb caktuarve. Aktualisht, caktuesit mund t\u00eb fshihen nga indekset masivisht n\u00ebp\u00ebrmjet metodave ambulkdelete dhe amvacuumcleanup. P\u00ebrpjekja p\u00ebr t\u00eb realizuar fshirjen e pik\u00ebs s\u00eb caktuar p\u00ebrmes k\u00ebtij API do t\u00eb \u00e7onte n\u00eb efektivitet t\u00eb ul\u00ebt, pasi shumica e implementimeve aktuale duhet t\u00eb skanojn\u00eb t\u00eb gjith\u00eb indeksin. P\u00ebr m\u00eb tep\u00ebr, API nuk lejon t\u00eb specifikohet se cil\u00ebt prej caktuesve q\u00eb referohen n\u00eb t\u00eb nj\u00ebjtin TID duhet t\u00eb fshihen. Ai mund t\u00eb fshij\u00eb vet\u00ebm t\u00eb gjith\u00eb ata.\n
- Indekset aktualisht referohen n\u00eb rreshtat e tabel\u00ebs sipas numrit t\u00eb bllokut (32 bit) dhe numrit t\u00eb ofsetit (16 bit). Dhe vet\u00ebm 11 bit t\u00eb numrit t\u00eb ofsetit mund t\u00eb transmetohen me siguri nga TID i tabel\u00ebs n\u00eb t\u00eb gjitha metodat e qasjes n\u00eb indeks. N\u00eb k\u00ebt\u00eb rast, implementimet alternative t\u00eb MVCC mund t\u00eb k\u00ebrkojn\u00eb t\u00eb ruajn\u00eb nj\u00eb ngarkes\u00eb shtes\u00eb (payload) s\u00eb bashku me TID. P\u00ebr shembull, n\u00eb OrioleDB k\u00ebrkohet nj\u00eb ose disa bit p\u00ebr t\u00eb implementuar indekset 'delete-marking' ose informacion t\u00eb plot\u00eb mbi dukshm\u00ebrin\u00eb. <\/ul>\n
Jan\u00eb propozuar dy m\u00ebnyra p\u00ebr t\u00eb kap\u00ebrcyer kufizimet n\u00eb praktik\u00eb: <\/p>\n
- \n
Qasja 1: API Index AM ofron mund\u00ebsi p\u00ebr implementimin alternativ t\u00eb MVCC. <\/p>\n
Nd\u00ebrsa Table AM vazhdon t\u00eb p\u00ebrgjigjet p\u00ebr t\u00eb gjith\u00eb komponent\u00ebt e MVCC, Index AM ofron mund\u00ebsit\u00eb e nevojshme p\u00ebr implementimin alternativ t\u00eb MVCC, p\u00ebrkat\u00ebsisht: ruajtjen e ngarkes\u00ebs p\u00ebrdoruese (payload) s\u00eb bashku me TID, metoda e fshirjes s\u00eb pik\u00ebs dhe madje metoda e azhurnimit t\u00eb pik\u00ebs (n\u00ebse TID n\u00eb indeks nuk mund t\u00eb ndryshohet, ngarka p\u00ebrdoruese \u2013 mund). P\u00ebrve\u00e7 k\u00ebsaj, pasi \u00ebsht\u00eb e nevojshme t\u00eb lejohet q\u00eb disa caktues t\u00eb indeksit t\u00eb referohen n\u00eb t\u00eb nj\u00ebjtin TID, metodat API q\u00eb p\u00ebrdoren gjat\u00eb skanimit t\u00eb indeksit gjithashtu kan\u00eb nevoj\u00eb p\u00ebr azhurnim. <\/p>\n
Qasja 2: Indekset q\u00eb mb\u00ebshtesin MVCC. <\/p>\n
Nj\u00eb alternativ\u00eb do t\u00eb ishte t\u00eb lejojm\u00eb indekset q\u00eb mb\u00ebshtesin MVCC. K\u00ebshtu, 'executor' (ose ndoshta Table AM) thjesht th\u00ebrret metodat insert() dhe delete() n\u00eb Index AM, nd\u00ebrkoh\u00eb q\u00eb Index AM ofron mund\u00ebsin\u00eb p\u00ebr skanim duke marr\u00eb parasysh MVCC. Kjo do ta thjeshtonte ndjesh\u00ebm skanimin duke p\u00ebrdorur vet\u00ebm indekset (index-only). Edhe e gjith\u00eb Table AM n\u00eb k\u00ebt\u00eb rast mund t\u00eb b\u00ebhet nj\u00eb shtres\u00eb nd\u00ebrmjet\u00ebse q\u00eb ruan t\u00eb dh\u00ebnat n\u00eb indeks. <\/p>\n
N\u00eb diagramin m\u00eb posht\u00eb \u00ebsht\u00eb nj\u00eb shembull. Vlera e indeksit 2 p\u00ebrdit\u00ebsohet nga transaksioni 11 nga vlera 'A' n\u00eb vler\u00ebn 'B'. Prandaj, vlera 'A' sh\u00ebnohet si xmax == 11, nd\u00ebrsa vlera 'B' sh\u00ebnohet si xmin == 11. K\u00ebshtu, mund t\u00eb skanohet indeksi 2 dhe t\u00eb merret vet\u00ebm tuple q\u00eb jan\u00eb t\u00eb dukshme n\u00eb p\u00ebrputhje me MVCC pa verifikime t\u00eb heap-it. Kreatorja e plehrave p\u00ebr indeksi 2 gjithashtu mund t\u00eb kryhet pa p\u00ebrdorimin e heap-it.
![\"Zhvilluesit](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nMe implementimin e t\u00eb gjitha novacioneve t\u00eb renditura n\u00eb API-n\u00eb e metodave t\u00eb aksesit p\u00ebr indekset, \u00ebsht\u00eb e pamundur q\u00eb t\u00eb p\u00ebrfundojn\u00eb t\u00eb gjitha indekset p\u00ebr t\u00eb mb\u00ebshtetur t\u00eb gjitha karakteristikat e reja m\u00eb nj\u00ebher\u00eb. M\u00eb realist \u00ebsht\u00eb t\u00eb lejohet disa realizime p\u00ebr nj\u00eb metod\u00eb t\u00eb vetme aksesimi t\u00eb indeksit. P\u00ebr shembull, s\u00eb bashku me B-tree-n\u00eb e zakonshme, zgjatja do t\u00eb jet\u00eb n\u00eb gjendje t\u00eb implementoj\u00eb nj\u00eb B-tree alternativ me mb\u00ebshtetje p\u00ebr MVCC brenda indeksit dhe mb\u00ebshtetje p\u00ebr identifikuesit e sh\u00ebnimeve me gjat\u00ebsi t\u00eb rastit.
![\"Zhvilluesit](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n