Masu haɓaka OrioleDB sun bincika halin yanzu na ƙananan matakin API da aka yi amfani da su don kari don samun damar tebur da fihirisa a cikin PostgreSQL (Table/Index Access Method (AM) API) kuma sun ba da shawarar hanyoyin inganta shi. Tun da aka gabatar da irin wannan API a cikin PostgreSQL 12, masu haɓakawa sun sami damar ƙirƙirar madadin hanyoyin adana bayanai. Duk da haka, duk da kasancewar wannan API da sanannen gazawar ginanniyar ingin ajiya, har yanzu babu cikakken injunan ajiya na ma'amala da aka aiwatar kawai azaman kari.
Shahararrun fasalulluka don madadin injunan tebur na PostgreSQL sune:
- Madadin aiwatar da MVCC, kamar shagunan da ke tushen UNDO.
- Teburan da aka tsara, inda fihirisa ba ƙari ba ne na zaɓi ga tebur wanda ke hanzarta tambayoyin, amma shine tsarin bayanan farko wanda aka adana bayanan tebur a ciki.
Canje-canjen da ake buƙata a cikin Table/Index AM API don tallafawa madadin aiwatar da MVCC ana tattaunawa tare da ido zuwa tsawo na OrioleDB, wanda aka tsara don magance sanannun gazawar injin ajiya na PostgreSQL. Matsalar ita ce cikakkiyar haɗin kai na OrioleDB tare da PostgreSQL yana buƙatar canje-canje zuwa lambar PostgreSQL, wanda ke dagula aiwatar da aikin kuma yana nuna buƙatar sabunta tebur AM API na yanzu.
Teburin AM API bai bayyana kai tsaye yadda ya kamata a aiwatar da MVCC ba. Koyaya, Teburin AM API da Index AM API suna yin zato mai zuwa: kowane TID (Tuple/Jay Identifier) ko dai ana lissafta shi da duk maƙasudi ko kuma ba a lissafta shi kwata-kwata. Ko da Index AM yana da nassoshi da yawa zuwa TID ɗaya (misali GIN), duk waɗannan nassoshi dole ne su taswira zuwa ƙima ɗaya.
An soki wannan ƙa'idar don ƙara yawan ayyukan rubuce-rubuce ("ƙarfin rubutu") - idan an sabunta sifa guda ɗaya, kowane fihirisar da ke cikin tebur dole ne a sabunta shi. Idan kuna son ci gaba da amfani da log ɗin UNDO, ko gina wata hanyar ajiya ba tare da “rubutu ƙarawa” (kamar hanyar WARM), kuna buƙatar karya wannan zato.
Tebur na tushen UNDO wanda ba zai keta wannan zato yayi kama da hanyar HOT (Heap-Only Tuples), sai dai an adana tsoffin juzu'an jeri a cikin log ɗin UNDO kuma ba dole ba ne su dace a shafi ɗaya. Amma, bisa ga mawallafa, wannan fa'idar bai isa ba don tabbatar da kasancewar wani Table AM dabam.
Iyakoki na aiki na API ɗin da ke akwai:
- Lokacin da aka sabunta layin tebur, ana sabunta fihirisa akan komai-ko-komai.
- API ɗin Index AM ba ta da ikon share takamaiman tuples. A halin yanzu yana yiwuwa a share tuples daga fihirisa a cikin girma ta amfani da hanyoyin ambulkdelete da amvacuumcleanup. Ƙoƙarin aiwatar da gogewar tabo ta wannan API ɗin zai haifar da ƙarancin inganci, tunda yawancin aiwatarwa na yanzu dole ne su bincika dukkan fihirisar. Bugu da ƙari, API ɗin ba ya ƙyale ka ka ƙididdige waɗanne tuples da ke magana TID iri ɗaya ya kamata a share su. Yana iya share su duka.
- Fihirisa a halin yanzu suna nunin layuka na tebur ta lambar toshe (32 ragowa) da lambar kashewa (bits 16). Kuma kawai rago 11 na lambar kashewa za a iya wuce su cikin aminci daga TID tebur zuwa duk hanyoyin samun index. Madadin aiwatar da MVCC na iya, duk da haka, yana buƙatar adana ƙarin kayan aiki tare da TID. Misali, OrioleDB yana buƙatar guda ɗaya ko fiye don aiwatar da fihirisar "share-alama" ko cikakken bayanin gani.
Hanyoyi biyu don shawo kan gazawar a aikace an gabatar da su:
Hanyar 1: API ɗin Index AM yana ba da zaɓuɓɓuka don madadin aiwatar da MVCC.
Yayin da Table AM ta ci gaba da alhakin duk abubuwan da ke cikin MVCC, Index AM yana ba da damar da ake bukata don madadin aiwatar da MVCC, wato: adana nauyin mai amfani tare da TID, hanyar share ma'ana, har ma da hanyar sabunta ma'ana (idan TID a cikin index ba za a iya canza ba, mai amfani zai iya). Bugu da kari, tunda ana buƙatar ba da izinin tuples da yawa don yin nunin TID iri ɗaya, hanyoyin API ɗin da aka yi amfani da su yayin binciken fihirisa suma suna buƙatar sabunta su.
Hanyar 2: Ma'anar MVCC-sane.
Madadin zai kasance don ba da izinin firikwensin da ke goyan bayan MVCC. Wato, "executor" (ko watakila Table AM) kawai ya kira hanyoyin saka () da share() akan Index AM, yayin da Index AM ya ba da damar yin amfani da MVCC-aware. Wannan zai sa binciken fihirisa-kawai ya fi sauƙi. Ko da duka Table AM na iya zama matsakaicin Layer adana bayanai a cikin fihirisa.
Hoton da ke ƙasa yana nuna misali. Ana sabunta ƙimar fihirisar 2 ta hanyar ciniki 11 daga ƙimar "A" zuwa ƙimar "B". Saboda haka, ana yiwa kimar "A" alamar xmax == 11, kuma ana yiwa kimar "B" alama a matsayin xmin == 11. Ta wannan hanyar, za a iya duba index 2 kuma za a iya dawo da tuples da ake iya gani kawai bisa ga MVCC ba tare da tantancewa ba. Hakanan ana iya yin tarin datti 2 ba tare da amfani da tulin ba.
Tare da duk sabbin abubuwan da ke sama a cikin hanyoyin samun index API, yana da wuya a sami damar sabunta duk fihirisa lokaci guda don tallafawa duk sabbin abubuwan. Yana da mafi haƙiƙa don ƙyale aiwatarwa da yawa don hanyar samun damar fihirisa guda. Misali, ban da itacen B na yau da kullun, tsawo zai iya aiwatar da madadin bishiyar B tare da tallafin MVCC a cikin fihirisa da goyan bayan masu gano rikodin rikodi na sabani.
Don haka, an ba da shawara don sake fasalin ba kawai Table AM API ba, har ma da Index AM API, wanda ya yi hidima ga al'ummar PostgreSQL da kyau shekaru da yawa. Bugu da ƙari, an ba da shawarar raba Index AM cikin ma'auni mai ma'ana da ƙirar aiwatarwa. Wannan gine-ginen da aka sake fasalin zai ba da damar PostgreSQL don tallafawa nau'ikan ajiya da yawa.
source: budenet.ru
