Nakala ya mazungumzo ya Bruce Momjian ya 2020 "Kufungua Kidhibiti cha Kufuli cha Postgres".
(Kumbuka: Maswali yote ya SQL kutoka kwa slaidi yanaweza kupatikana kutoka kwa kiungo hiki: )
Habari! Ni vizuri kuwa hapa Urusi tena. Samahani sikuweza kuja mwaka jana, lakini mwaka huu mimi na Ivan tuna mipango mikubwa. Natumai kuwa hapa mara nyingi zaidi. Ninapenda kuja Urusi. Nitatembelea Tyumen, Tver. Nimefurahi sana kwamba nitaweza kutembelea miji hii.
Jina langu ni Bruce Momjian. Ninafanya kazi katika EnterpriseDB na nimekuwa nikifanya kazi na Postgres kwa zaidi ya miaka 23. Ninaishi Philadelphia, Marekani. Ninasafiri takriban siku 90 kwa mwaka. Na mimi huhudhuria takriban mikutano 40. Yangu , ambayo ina slaidi ambazo nitakuonyesha sasa. Kwa hiyo, baada ya mkutano unaweza kuzipakua kutoka kwenye tovuti yangu ya kibinafsi. Pia ina takriban maonyesho 30. Pia kuna video na idadi kubwa ya maingizo ya blogu, zaidi ya 500. Hii ni rasilimali yenye taarifa nzuri. Na ikiwa una nia ya nyenzo hii, basi ninakualika uitumie.
Nilikuwa mwalimu, profesa kabla sijaanza kufanya kazi na Postgres. Na ninafurahi sana kwamba sasa nitaweza kukuambia kile nitakachokuambia. Hii ni moja ya maonyesho yangu ya kuvutia zaidi. Na wasilisho hili lina slaidi 110. Tutaanza kuzungumza na mambo rahisi, na mwishowe ripoti itakuwa ngumu zaidi na zaidi, na itakuwa ngumu sana.
Haya ni mazungumzo yasiyofurahisha. Kuzuia sio somo maarufu zaidi. Tunataka hii ipotee mahali fulani. Ni kama kwenda kwa daktari wa meno.
- Kufunga ni tatizo kwa watu wengi wanaofanya kazi katika hifadhidata na wana michakato mingi inayoendeshwa kwa wakati mmoja. Wanahitaji kuzuia. Hiyo ni, leo nitakupa maarifa ya msingi juu ya kuzuia.
- Vitambulisho vya muamala. Hii ni sehemu ya kuchosha ya uwasilishaji, lakini zinahitaji kueleweka.
- Ifuatayo tutazungumzia kuhusu aina za kuzuia. Hii ni sehemu ya mitambo.
- Na hapa chini tutatoa mifano kadhaa ya kuzuia. Na itakuwa ngumu sana kuelewa.
Wacha tuzungumze juu ya kuzuia.
Istilahi zetu ni ngumu sana. Je! ni wangapi kati yenu mnajua kifungu hiki kinatoka wapi? Watu wawili. Hii ni kutoka kwa mchezo unaoitwa Colossal Cave Adventure. Ilikuwa ni mchezo wa kompyuta unaotegemea maandishi katika miaka ya 80, nadhani. Huko ilibidi uingie kwenye pango, kwenye labyrinth, na maandishi yakabadilika, lakini yaliyomo yalikuwa takriban sawa kila wakati. Ndivyo ninavyokumbuka mchezo huu.
Na hapa tunaona jina la kufuli zilizotujia kutoka Oracle. Tunazitumia.
Hapa tunaona maneno ambayo yananichanganya. Kwa mfano, SHIRIKI USASISHAJI EXXLUSIVE. Inayofuata SHIRIKI MBICHI EXXLUSIVE. Kuwa waaminifu, majina haya si wazi sana. Tutajaribu kuzingatia kwa undani zaidi. Baadhi yana neno "kushiriki", ambalo linamaanisha kutengana. Baadhi yana neno "pekee". Baadhi yana maneno haya yote mawili. Ningependa kuanza na jinsi kufuli hizi zinavyofanya kazi.
Na neno "ufikiaji" pia ni muhimu sana. Na maneno "safu" ni kamba. Hiyo ni, usambazaji wa ufikiaji, usambazaji wa safu.
Suala jingine ambalo linahitaji kueleweka katika Postgres, ambalo kwa bahati mbaya sitaweza kulizungumzia katika mazungumzo yangu, ni MVCC. Nina uwasilishaji tofauti juu ya mada hii kwenye wavuti yangu. Na ikiwa unafikiri wasilisho hili ni gumu, MVCC labda ndiyo gumu zaidi kwangu. Na ikiwa una nia, unaweza kuitazama kwenye tovuti. Unaweza kutazama video.
Jambo lingine tunalohitaji kuelewa ni vitambulisho vya muamala. Shughuli nyingi haziwezi kufanya kazi bila vitambulisho vya kipekee. Na hapa tunayo maelezo ya shughuli ni nini. Postgres ina mifumo miwili ya kuhesabu shughuli. Najua hili sio suluhisho zuri sana.
Pia kumbuka kuwa slaidi zitakuwa ngumu sana kuelewa, kwa hivyo kile kilichoangaziwa kwa nyekundu ndicho unahitaji kulipa kipaumbele.
Hebu tuone. Nambari ya muamala imeangaziwa kwa rangi nyekundu. Chaguo la kukokotoa la SELECT pg_back linaonyeshwa hapa. Hurejesha muamala wangu na kitambulisho cha muamala.
Jambo moja zaidi, ikiwa unapenda wasilisho hili na unataka kuliendesha kwenye hifadhidata yako, basi unaweza kwenda kwenye kiungo hiki kwa rangi ya pinki na kupakua SQL kwa wasilisho hili. Na unaweza kuiendesha katika PSQL yako na wasilisho lote litakuwa kwenye skrini yako mara moja. Haitakuwa na maua, lakini angalau tunaweza kuiona.
Katika kesi hii tunaona kitambulisho cha muamala. Hii ndio nambari tuliyompa. Na kuna aina nyingine ya kitambulisho cha muamala katika Postgres, kinachoitwa kitambulisho cha muamala pepe
Na lazima tuelewe hili. Hii ni muhimu sana, vinginevyo hatutaweza kuelewa kufunga kwenye Postgres.
Kitambulisho cha muamala pepe ni kitambulisho cha muamala ambacho hakina thamani zinazoendelea. Kwa mfano, ikiwa nitaendesha amri ya SELECT, basi uwezekano mkubwa sitabadilisha hifadhidata, sitafunga chochote. Kwa hivyo tunapoendesha CHAGUO rahisi, hatupi muamala huo kitambulisho endelevu. Tunampa tu kitambulisho pepe hapo.
Na hii inaboresha utendakazi wa Postgres, inaboresha uwezo wa kusafisha, kwa hivyo kitambulisho cha muamala pepe huwa na nambari mbili. Nambari ya kwanza kabla ya kufyeka ni kitambulisho cha nyuma. Na upande wa kulia tunaona counter tu.
Kwa hivyo, nikiendesha ombi, inasema kwamba kitambulisho cha nyuma ni 2.
Na ikiwa ninaendesha mfululizo wa shughuli kama hizo, basi tunaona kwamba counter inaongezeka kila wakati ninapoendesha swala. Kwa mfano, ninapoendesha swala 2/10, 2/11, 2/12, nk.
Kumbuka kwamba kuna safu mbili hapa. Upande wa kushoto tunaona kitambulisho cha muamala pepe - 2/12. Na upande wa kulia tuna kitambulisho cha kudumu cha muamala. Na uwanja huu ni tupu. Na shughuli hii haibadilishi hifadhidata. Kwa hivyo siipei kitambulisho cha kudumu cha muamala.
Mara tu ninapoendesha amri ya uchanganuzi ((CHAMBUA)), swala sawa hunipa kitambulisho cha kudumu cha muamala. Tazama jinsi hii imebadilika kwetu. Sikuwa na kitambulisho hiki hapo awali, lakini sasa ninacho.
Kwa hivyo hapa kuna ombi lingine, shughuli nyingine. Nambari ya muamala pepe ni 2/13. Na nikiomba kitambulisho cha muamala endelevu, basi nitakapoendesha hoja, nitakipata.
Kwa hiyo, mara moja zaidi. Tuna kitambulisho cha muamala pepe na kitambulisho cha muamala endelevu. Elewa tu hatua hii kuelewa tabia ya Postgres.
Tunaendelea kwenye sehemu ya tatu. Hapa tutapitia kwa urahisi aina tofauti za kufuli kwenye Postgres. Haipendezi sana. Sehemu ya mwisho itakuwa ya kuvutia zaidi. Lakini tunapaswa kuzingatia mambo ya msingi, kwa sababu vinginevyo hatuwezi kuelewa nini kitatokea baadaye.
Tutapitia sehemu hii, tutaangalia kila aina ya kufuli. Nami nitakuonyesha mifano ya jinsi zilivyosakinishwa, jinsi zinavyofanya kazi, nitakuonyesha baadhi ya maswali ambayo unaweza kutumia kuona jinsi kufunga kunafanya kazi katika Postgres.
Ili kuunda swali na kuona kinachoendelea katika Postgres, tunahitaji kutoa hoja katika mwonekano wa mfumo. Katika kesi hii, pg_lock imeangaziwa kwa rangi nyekundu. Pg_lock ni jedwali la mfumo ambalo hutuambia ni kufuli gani zinazotumika kwa sasa katika Postgres.
Walakini, ni ngumu sana kwangu kukuonyesha pg_lock peke yake kwa sababu ni ngumu sana. Kwa hivyo niliunda mwonekano unaoonyesha pg_locks. Na pia inanifanyia kazi fulani ambayo huniruhusu kuelewa vyema. Hiyo ni, haijumuishi kufuli zangu, kikao changu mwenyewe, nk. Ni SQL ya kawaida tu na hukuruhusu kukuonyesha vyema kinachoendelea.
Shida nyingine ni kwamba maoni haya ni pana sana, kwa hivyo lazima nitengeneze ya pili - lockview2.
Na inanionyesha safu zaidi kutoka kwa jedwali. Na nyingine inayonionyesha safu wima zingine. Hii ni ngumu sana, kwa hivyo nilijaribu kuiwasilisha kwa urahisi iwezekanavyo.
Kwa hivyo tuliunda meza inayoitwa Lockdemo. Na tuliunda mstari mmoja hapo. Hii ndio jedwali letu la mfano. Na tutakuwa tukiunda sehemu ili tu kukuonyesha mifano ya kufuli.
Kwa hivyo, safu moja, safu moja. Aina ya kwanza ya kufuli inaitwa ACCESS SHARE. Hiki ndicho kizuizi kidogo zaidi. Hii ina maana kwamba kivitendo haipingani na kufuli nyingine.
Na ikiwa tunataka kufafanua kwa uwazi kufuli, tunaendesha amri ya "meza ya kufuli". Na bila shaka itazuia, yaani, katika hali ya KUPATIKANA NA KUSHIRIKI, tunazindua jedwali la kufuli. Na ikiwa nitaendesha PSQL nyuma, basi ninaanza kikao cha pili kutoka kwa kikao changu cha kwanza kwa njia hii. Yaani nitafanya nini hapa? Ninaenda kwenye kikao kingine na kukiambia "nionyeshe mwonekano wa kufuli wa ombi hili." Na hapa nina AccessShareLock kwenye jedwali hili. Hili ndilo hasa nililoomba. Na anasema kuwa kizuizi kimepewa. Rahisi sana.
Zaidi ya hayo, ikiwa tunatazama safu ya pili, basi hakuna kitu huko. Wao ni tupu.
Na ikiwa nitaendesha amri ya "CHAGUA", basi hii ndiyo njia dhahiri (ya wazi) ya kuomba AccessShareLock. Kwa hivyo mimi huachilia meza yangu na kuendesha swala na swala inarudisha safu nyingi. Na katika moja ya mistari tunaona AccessShareLock. Kwa hivyo, SELECT huita AccessShareLock kwenye meza. Na haipingani na chochote kwa sababu ni kufuli ya kiwango cha chini.
Je, ikiwa nitaendesha CHAGUA na kuwa na jedwali tatu tofauti? Hapo awali nilikuwa nikiendesha jedwali moja tu, sasa ninaendesha tatu: pg_class, pg_namespace na pg_attribute.
Na sasa ninapoangalia hoja, naona AccessShareLocks 9 katika jedwali tatu. Kwa nini? Jedwali tatu zimeangaziwa kwa rangi ya samawati: pg_attribute, pg_class, pg_namespace. Lakini pia unaweza kuona kwamba faharisi zote ambazo zimefafanuliwa kupitia majedwali haya pia zina AccessShareLock.
Na hii ni kufuli ambayo kwa kweli haina mgongano na wengine. Na yote inayofanya ni kutuzuia tu kuweka upya jedwali tunapoichagua. Inaleta maana. Hiyo ni, ikiwa tunachagua meza, inatoweka wakati huo, basi hii ni makosa, hivyo AccessShare ni kufuli ya kiwango cha chini ambayo inatuambia "usidondoshe jedwali hili ninapofanya kazi". Kimsingi, hiyo ndiyo yote anafanya.
KUSHIRIKI KWA SAFU - Kufuli hii ni tofauti kidogo.
Hebu tuchukue mfano. CHAGUA ROW SHIRE mbinu ya kufunga kila safu kivyake. Kwa njia hii hakuna mtu anayeweza kuzifuta au kuzibadilisha tunapozitazama.
Kwa hivyo SHARE LOCK inafanya nini? Tunaona kwamba kitambulisho cha muamala ni 681 cha SELECT. Na hii inavutia. Nini kilitokea hapa? Mara ya kwanza tunaona nambari iko kwenye uwanja wa "Funga". Tunachukua kitambulisho cha muamala na inasema inakizuia katika hali ya kipekee. Inachofanya tu ni kusema nina safu ambayo imefungwa kitaalam mahali fulani kwenye jedwali. Lakini hasemi ni wapi hasa. Tutaangalia hili kwa undani zaidi baadaye kidogo.
Hapa tunasema kwamba kufuli hutumiwa na sisi.
Kwa hivyo, kufuli ya kipekee inasema wazi kuwa ni ya kipekee. Na pia ikiwa utafuta safu kwenye jedwali hili, basi hii ndio kitakachotokea, kama unavyoona.
SHIRIKI KIPEKEE ni kufuli refu.
Hii ndio amri ya (CHAMBUA) ya uchanganuzi ambayo itatumika.
SHIRIKI LOCK - unaweza kufunga kwa uwazi katika hali ya kushiriki.
Unaweza pia kuunda index ya kipekee. Na hapo unaweza kuona SHARE LOCK, ambayo ni sehemu yao. Na inafunga meza na kuweka LOCK YA SHARE juu yake.
Kwa chaguomsingi, SHIRIKI LOCK kwenye jedwali inamaanisha kuwa watu wengine wanaweza kusoma jedwali, lakini hakuna anayeweza kulirekebisha. Na hii ndio hasa hufanyika unapounda faharisi ya kipekee.
Ikiwa nitaunda faharisi ya kipekee kwa wakati mmoja, basi nitakuwa na aina tofauti ya kufunga kwa sababu, kama unavyokumbuka, kutumia faharisi wakati huo huo hupunguza hitaji la kufunga. Na ikiwa ninatumia lock ya kawaida, index ya kawaida, basi nitazuia kuandika kwa index ya meza wakati inaundwa. Ikiwa ninatumia faharisi kwa wakati mmoja, basi ninahitaji kutumia aina tofauti ya kufunga.
SHIRIKI SAFU KIPEKEE - tena inaweza kuwekwa wazi (kwa uwazi).
Au tunaweza kuunda sheria, yaani, kuchukua kesi maalum ambayo itatumika.
Kufunga KIPEKEE kunamaanisha kuwa hakuna mtu mwingine anayeweza kubadilisha jedwali.
Hapa tunaona aina tofauti za kufuli.
ACCESS EXCLUSIVE, kwa mfano, ni amri ya kuzuia. Kwa mfano, ikiwa unafanya CLUSTER table, basi hii itamaanisha kwamba hakuna mtu atakayeweza kuandika huko. Na hufunga si tu meza yenyewe, lakini pia indexes.
Huu ni ukurasa wa pili wa uzuiaji wa ACCESS EXCLUSIVE, ambapo tunaona ni nini hasa inazuia kwenye jedwali. Inafunga safu za meza za kibinafsi, ambayo inavutia sana.
Hiyo ndiyo habari yote ya msingi ambayo nilitaka kutoa. Tulizungumza kuhusu kufuli, kuhusu vitambulisho vya miamala, tulizungumza kuhusu vitambulisho vya miamala pepe, kuhusu vitambulisho vya kudumu vya miamala.
Na sasa tutapitia mifano ya kuzuia. Hii ni sehemu ya kuvutia zaidi. Tutaangalia kesi za kuvutia sana. Na lengo langu katika wasilisho hili ni kukupa ufahamu bora wa kile Postgres anafanya hasa inapojaribu kuzuia mambo fulani. Nadhani yeye ni mzuri sana katika kuzuia sehemu.
Hebu tuangalie baadhi ya mifano maalum.
Tutaanza na meza na safu moja kwenye jedwali. Ninapoingiza kitu nina ExclusiveLock, Kitambulisho cha Muamala na ExclusiveLock iliyoonyeshwa kwenye jedwali.
Nini kitatokea ikiwa nitaingiza safu mbili zaidi? Na sasa meza yetu ina safu tatu. Na niliingiza safu moja na nikapata hii kama pato. Na ikiwa nitaingiza safu mbili zaidi, ni nini cha kushangaza kuhusu hilo? Kuna jambo la kushangaza hapa kwa sababu nimeongeza safu tatu kwenye jedwali hili, lakini bado nina safu mbili kwenye jedwali la kufuli. Na hii kimsingi ndio tabia ya kimsingi ya Postgres.
Watu wengi wanafikiri kwamba ikiwa katika hifadhidata utafunga safu 100, basi utahitaji kuunda maingizo 100 ya kufuli. Ikiwa nitazuia safu 1 mara moja, basi nitahitaji maswali 000 kama haya. Na ikiwa ninahitaji milioni au bilioni kuzuia. Lakini tukifanya hivi, haitafanya kazi vizuri sana. Ikiwa umetumia mfumo unaounda maingizo ya kuzuia kwa kila safu ya mtu binafsi, basi unaweza kuona kwamba hii ni ngumu. Kwa sababu unahitaji kufafanua mara moja jedwali la kufuli ambalo linaweza kufurika, lakini Postgres haifanyi hivyo.
Na lililo muhimu sana kuhusu slaidi hii ni kwamba inaonyesha wazi kwamba kuna mfumo mwingine unaofanya kazi ndani ya MVCC ambao hufunga safu mlalo mahususi. Kwa hivyo unapofunga mabilioni ya safu mlalo, Postgres haiundi amri bilioni tofauti za kufunga. Na hii ina athari nzuri sana kwenye tija.
Vipi kuhusu sasisho? Ninasasisha safu mlalo sasa, na unaweza kuona kuwa imefanya shughuli mbili tofauti mara moja. Ilifunga meza kwa wakati mmoja, lakini pia ilifunga index. Na alihitaji kufunga fahirisi kwa sababu kuna vizuizi vya kipekee kwenye jedwali hili. Na tunataka kuhakikisha kuwa hakuna mtu anayeibadilisha, kwa hivyo tunaizuia.
Nini kitatokea ikiwa ninataka kusasisha safu mlalo mbili? Na tunaona kwamba anafanya vivyo hivyo. Tunafanya sasisho mara mbili, lakini idadi sawa ya mistari ya kufuli.
Ikiwa unashangaa jinsi Postgres hufanya hivi, utahitaji kusikiliza mazungumzo yangu kwenye MVCC ili kujifunza jinsi Postgres huweka alama kwa ndani mistari hii ambayo inabadilika. Na Postgres ina njia ambayo hufanya hivi, lakini haifanyi katika kiwango cha kufunga meza, hufanya kwa kiwango cha chini na bora zaidi.
Je, ikiwa ninataka kufuta kitu? Ikiwa nitafuta, kwa mfano, safu moja na bado nina pembejeo zangu mbili za kuzuia, na hata nikitaka kuzifuta zote, bado zipo.
Na, kwa mfano, nataka kuingiza mistari 1, na kisha kufuta au kuongeza mistari 000, kisha mistari hiyo ya kibinafsi ambayo ninaongeza au kubadilisha, haijarekodiwa hapa. Zimeandikwa kwa kiwango cha chini ndani ya safu yenyewe. Na wakati wa hotuba ya MVCC nilizungumza juu ya hili kwa undani. Lakini ni muhimu sana unapochanganua kufuli ili kuhakikisha kuwa unafunga katika kiwango cha jedwali na huoni jinsi safu mlalo mahususi zinavyorekodiwa hapa.
Vipi kuhusu kuzuia waziwazi?
Nikibofya onyesha upya, nina safu mlalo mbili zilizofungwa. Na ikiwa nitawachagua wote na bonyeza "sasisha kila mahali," basi bado nina rekodi mbili za kuzuia.
Hatuundi rekodi tofauti kwa kila safu mlalo mahususi. Kwa sababu basi tija inapungua, kunaweza kuwa na mengi sana. Na huenda tukajikuta katika hali isiyopendeza.
Na jambo lile lile, ikiwa tutashiriki, tunaweza kuifanya mara 30.
Tunarejesha meza yetu, kufuta kila kitu, kisha ingiza safu moja tena.
Tabia nyingine ambayo unaona kwenye Postgres ambayo inajulikana sana na tabia inayotakikana ni kwamba unaweza kusasisha au kuchagua. Na unaweza kufanya hivyo kwa wakati mmoja. Na kuchagua haizuii sasisho na kitu kimoja katika mwelekeo tofauti. Tunamwambia msomaji asimzuie mwandishi, na mwandishi hakumzuia msomaji.
Nitakuonyesha mfano wa hili. Nitafanya uchaguzi sasa. Kisha tutafanya INSERT. Na kisha unaweza kuona - 694. Unaweza kuona kitambulisho cha shughuli iliyofanya uingizaji huu. Na hivyo ndivyo inavyofanya kazi.
Na nikiangalia kitambulisho changu cha nyuma sasa, sasa ni 695.
Na ninaweza kuona 695 ikitokea kwenye meza yangu.
Na ikiwa nitasasisha hapa kama hii, basi ninapata kesi tofauti. Katika kesi hii, 695 ni lock ya kipekee, na sasisho lina tabia sawa, lakini hakuna mgogoro kati yao, ambayo ni ya kawaida kabisa.
Na unaweza kuona kwamba juu ni ShareLock, na chini ni ExclusiveLock. Na shughuli zote mbili zilifanyika.
Na unahitaji kusikiliza mazungumzo yangu huko MVCC ili kuelewa jinsi hii inavyotokea. Lakini hiki ni kielelezo ambacho unaweza kuifanya kwa wakati mmoja, yaani fanya CHAGUA na USASISHAJI kwa wakati mmoja.
Wacha tuweke upya na tufanye operesheni moja zaidi.
Ukijaribu kutekeleza sasisho mbili kwa wakati mmoja kwenye safu moja, itazuiwa. Na kumbuka, nilisema kwamba msomaji hamzuii mwandishi, na mwandishi hamzuii msomaji, lakini mwandishi mmoja huzuia mwandishi mwingine. Hiyo ni, hatuwezi kuwa na watu wawili kusasisha safu mlalo moja kwa wakati mmoja. Unapaswa kusubiri hadi mmoja wao amalize.
Na ili kuelezea hili, nitaangalia jedwali la Lockdemo. Na tutaangalia safu moja. Kwa muamala 698.
Tumesasisha hii hadi 2. 699 ni sasisho la kwanza. Na ilifanikiwa au iko katika shughuli inayosubiri na inasubiri sisi kuthibitisha au kughairi.
Lakini angalia kitu kingine - 2/51 ni shughuli yetu ya kwanza, kikao chetu cha kwanza. 3/112 ni ombi la pili lililotoka juu ambalo lilibadilisha thamani hiyo hadi 3. Na ikiwa unaona, ya juu ilijifunga yenyewe, ambayo ni 699. Lakini 3/112 haikutoa kufuli. Safu ya Lock_mode inasema inachosubiri. Inatarajia 699. Na ukiangalia 699 ilipo, ni ya juu zaidi. Na kikao cha kwanza kilifanya nini? Aliunda kufuli ya kipekee kwenye kitambulisho chake cha muamala. Hivi ndivyo Postgres hufanya hivyo. Inazuia kitambulisho chake cha muamala. Na ikiwa unataka kusubiri mtu kuthibitisha au kufuta, basi unahitaji kusubiri wakati kuna shughuli inayosubiri. Na ndiyo sababu tunaweza kuona mstari wa ajabu.
Hebu tuangalie tena. Upande wa kushoto tunaona kitambulisho chetu cha kuchakata. Katika safu ya pili tunaona kitambulisho chetu cha muamala, na katika safu ya tatu tunaona lock_type. Hii ina maana gani? Kimsingi inachosema ni kwamba inazuia kitambulisho cha muamala. Lakini kumbuka kuwa safu zote chini zinasema uhusiano. Na hivyo una aina mbili za kufuli kwenye meza. Kuna kufuli ya uhusiano. Na kisha kuna kuzuia transactionid, ambapo wewe kuzuia juu yako mwenyewe, ambayo ni hasa kile kinachotokea kwenye safu ya kwanza au chini kabisa, ambapo transactionid ni, ambapo sisi kusubiri kwa 699 kumaliza kazi yake.
Nitaona kitakachotokea hapa. Na hapa mambo mawili hutokea kwa wakati mmoja. Unaangalia kufuli ya kitambulisho cha muamala katika safu mlalo ya kwanza inayojifunga yenyewe. Na anajizuia ili kuwafanya watu wasubiri.
Ukiangalia mstari wa 6, ni kiingilio sawa na cha kwanza. Na kwa hivyo shughuli 699 imezuiwa. 700 pia ni kujifungia. Na kisha katika safu ya chini utaona kwamba tunangojea 699 kumaliza kazi yake.
Na katika lock_type, tuple unaona nambari.
Unaweza kuona ni 0/10. Na hii ni nambari ya ukurasa, na pia kukabiliana na safu hii maalum.
Na unaona inakuwa 0/11 tunaposasisha.
Lakini kwa kweli ni 0/10, kwa sababu kuna kusubiri kwa operesheni hii. Tunayo fursa ya kuona kwamba huu ni mfululizo ambao ninasubiri kuthibitisha.
Mara tu tumeithibitisha na kushinikiza ahadi, na sasisho likikamilika, hii ndio tunapata tena. Transaction 700 ndio kufuli pekee, haingojei mtu mwingine yeyote kwa sababu ilijitolea. Inasubiri tu shughuli ikamilike. Mara 699 inapoisha, hatungojei chochote tena. Na sasa shughuli 700 inasema kwamba kila kitu ni sawa, kwamba ina kufuli zote zinazohitajika kwenye meza zote zinazoruhusiwa.
Na kufanya jambo hili lote kuwa ngumu zaidi, tunaunda mtazamo mwingine, ambao wakati huu utatupatia uongozi. Sitarajii uelewe ombi hili. Lakini hii itatupa mtazamo wazi zaidi wa kile kinachoendelea.
Huu ni mtazamo unaorudiwa ambao pia una sehemu nyingine. Na kisha huleta kila kitu pamoja tena. Hebu tumia hii.
Nini ikiwa tutafanya sasisho tatu kwa wakati mmoja na kusema kwamba safu sasa ni tatu. Na tutabadilisha 3 hadi 4.
Na hapa tunaona 4. Na kitambulisho cha shughuli 702.
Na kisha nitabadilisha 4 hadi 5. Na 5 hadi 6, na 6 hadi 7. Na nitapanga safu ya watu ambao watakuwa wakingojea muamala huu mmoja kumalizika.
Na kila kitu kinakuwa wazi. Safu ya kwanza ni ipi? Hii ni 702. Hiki ndicho kitambulisho cha muamala ambacho kiliweka thamani hii awali. Ni nini kimeandikwa kwenye safu yangu ya Umepewa? Nina alama f. Haya ni masasisho yangu ambayo (5, 6, 7) hayawezi kuidhinishwa kwa sababu tunasubiri ID 702 ya muamala imalizike. Hapo tuna uzuiaji wa kitambulisho cha muamala. Na hii husababisha kufuli 5 za kitambulisho cha muamala.
Na ukiangalia 704, saa 705, hakuna kitu kilichoandikwa huko bado, kwa sababu hawajui kinachoendelea bado. Wanaandika tu kwamba hawajui kinachoendelea. Na watalala tu kwa sababu wanangojea mtu amalize na kuamshwa wakati kuna fursa ya kubadilisha safu.
Hivi ndivyo inavyoonekana. Ni wazi kwamba wote wanasubiri mstari wa 12.
Hivi ndivyo tulivyoona hapa. Hii hapa 0/12.
Kwa hivyo mara tu muamala wa kwanza utakapoidhinishwa, unaweza kuona hapa jinsi uongozi unavyofanya kazi. Na sasa kila kitu kinakuwa wazi. Wote huwa safi. Na kwa kweli bado wanasubiri.
Hiki ndicho kinachoendelea. 702 ahadi. Na sasa 703 inapata kufuli kwa safu hii, na kisha 704 inaanza kungojea 703 kujitolea. Na 705 inangojea hii pia. Na haya yote yakikamilika, wanajisafisha. Na ningependa kusema kwamba kila mtu anajipanga. Na hii ni sawa na hali katika msongamano wa magari wakati kila mtu anasubiri gari la kwanza. Gari la kwanza linasimama na kila mtu anajipanga kwenye mstari mrefu. Kisha inasonga, basi gari linalofuata linaweza kusonga mbele na kupata kizuizi chake, nk.
Na ikiwa hii haikuonekana kuwa ngumu vya kutosha kwako, basi sasa tutazungumza nawe juu ya kufuli. Sijui ni yupi kati yenu amekutana nazo. Hili ni shida ya kawaida katika mifumo ya hifadhidata. Lakini mikwamo ni pale kikao kimoja kinaposubiri kikao kingine kufanya jambo fulani. Na kwa wakati huu kikao kingine kinasubiri kikao cha kwanza kufanya kitu.
Na, kwa mfano, ikiwa Ivan anasema: "Nipe kitu," na nasema: "Hapana, nitakupa tu ikiwa utanipa kitu kingine." Na anasema, "Hapana, sitakupa ikiwa hutanipa." Na tunaishia katika hali ya msuguano. Nina hakika kuwa Ivan hatafanya hivi, lakini unaelewa maana kwamba tuna watu wawili ambao wanataka kupata kitu na hawako tayari kukitoa hadi mtu mwingine awape kile wanachotaka. Na hakuna suluhisho.
Na kimsingi, hifadhidata yako inahitaji kugundua hii. Na kisha unahitaji kufuta au kufunga moja ya vikao, kwa sababu vinginevyo watabaki huko milele. Na tunaiona kwenye hifadhidata, tunaiona katika mifumo ya uendeshaji. Na katika maeneo yote ambapo tuna taratibu sambamba, hii inaweza kutokea.
Na sasa tutafunga vifunga viwili. Tutaweka 50 na 80. Katika safu ya kwanza, nitasasisha kutoka 50 hadi 50. Nitapata nambari ya muamala 710.
Na kisha nitabadilisha 80 hadi 81, na 50 hadi 51.
Na hii ndivyo itakavyoonekana. Na hivyo 710 ina safu imefungwa, na 711 inasubiri uthibitisho. Tuliona hili tuliposasisha. 710 ndiye mmiliki wa safu yetu. Na 711 inasubiri 710 kukamilisha shughuli hiyo.
Na hata inasema ni safu gani mikwaruzo hutokea. Na hapa ndipo inapoanza kuwa ya ajabu.
Sasa tunasasisha 80 hadi 80.
Na hapa ndipo mikwamo inaanza. 710 inasubiri jibu kutoka 711, na 711 inasubiri 710. Na hii haitaisha vizuri. Na hakuna njia ya kutoka kwa hili. Na watatarajia jibu kutoka kwa kila mmoja.
Na itaanza tu kuchelewesha kila kitu. Na hatutaki hilo.
Na Postgres ina njia za kugundua hii inapotokea. Na hii inapotokea, unapata kosa hili. Na kutoka kwa hili ni wazi kwamba mchakato huo na vile unasubiri SHARE LOCK kutoka kwa mchakato mwingine, yaani, ambao umezuiwa na mchakato wa 711. Na mchakato huo ulikuwa unangoja KUFUNGWA KWA HISA kutolewa kwenye kitambulisho cha muamala fulani na kuzuiwa na utaratibu fulani. Kwa hiyo, kuna hali ya msuguano hapa.
Je, kuna vikwazo vya njia tatu? Inawezekana? Ndiyo.
Tunaingiza nambari hizi kwenye meza. Tunabadilisha 40 hadi 40, tunafanya kuzuia.
Tunabadilisha 60 hadi 61, 80 hadi 81.
Na kisha tunabadilisha 80 na kisha boom!
Na 714 sasa inangojea 715. Ya 716 inangojea ya 715. Na hakuna kitu kinachoweza kufanywa juu yake.
Hakuna tena watu wawili hapa, tayari kuna watu watatu hapa. Ninataka kitu kutoka kwako, huyu anataka kitu kutoka kwa mtu wa tatu, na mtu wa tatu anataka kitu kutoka kwangu. Na tunaishia katika kusubiri kwa njia tatu kwa sababu sote tunasubiri mtu mwingine amalize anachohitaji kufanya.
Na Postgres anajua ni safu gani hii hufanyika. Na kwa hivyo itakupa ujumbe ufuatao, ambao unaonyesha kuwa una shida ambapo pembejeo tatu zinazuia kila mmoja. Na hakuna vikwazo hapa. Hii inaweza kuwa kesi ambapo maingizo 20 yanazuia kila mmoja.
Tatizo linalofuata linaweza kutatuliwa.
Ikiwa kufuli maalum inayoweza kutatuliwa.
Na tunarudi 719. Pato lake ni la kawaida kabisa.
Na unaweza kubofya ili kufanya muamala kutoka kwa mfululizo.
Na unagundua kuwa sasa una aina tofauti ya kufuli ya SA - inamaanisha kuwa inaweza kutatuliwa.
Na kwa hivyo tuna aina mpya ya kufuli inayoitwa SARIadLock, ambayo ni kufuli ya mfululizo na hukuruhusu kuingiza mfululizo.
Na pia unaweza kuingiza faharisi za kipekee.
Katika jedwali hili tuna faharisi za kipekee.
Kwa hivyo nikiweka nambari 2 hapa, kwa hivyo nina 2. Lakini juu kabisa, ninaweka 2 nyingine. Na unaweza kuona kwamba 721 ina kufuli ya kipekee. Lakini sasa 722 inasubiri 721 ikamilishe operesheni yake kwa sababu haiwezi kuingiza 2 hadi ijue nini kitatokea kwa 721.
Na kama tutafanya subtransaction.
Hapa tunayo 723.
Na ikiwa tutahifadhi uhakika na kisha kuisasisha, basi tunapata kitambulisho kipya cha muamala. Huu ni mtindo mwingine wa tabia unayohitaji kufahamu. Tukirudisha hii, basi kitambulisho cha muamala kitatoweka. 724 majani. Lakini sasa tuna 725.
Kwa hivyo ninajaribu kufanya nini hapa? Ninajaribu kukuonyesha mifano ya kufuli zisizo za kawaida ambazo unaweza kupata: iwe ni kufuli zinazoweza kuunganishwa au SAVEPOINT, hizi ni aina tofauti za kufuli ambazo zitaonekana kwenye jedwali la kufuli.
Huu ni uundaji wa kufuli za wazi (wazi), ambazo zina pg_advisory_lock.
Na unaona kuwa aina ya kuzuia imeorodheshwa kama ushauri. Na hapa inasema "ushauri" katika nyekundu. Na unaweza kuzuia wakati huo huo kama hii na pg_advisory_unlock.
Na kwa kumalizia, ningependa kukuonyesha jambo moja zaidi la kusisimua akili. Nitaunda mtazamo mwingine. Lakini nitajiunga na jedwali la pg_locks na jedwali la pg_stat_activity. Na kwa nini ninataka kufanya hivi? Kwa sababu hii itaniruhusu kutazama na kuona vikao vyote vya sasa na kuona ni aina gani ya kufuli wanangojea. Na hii inavutia sana tunapoweka pamoja meza ya kufuli na jedwali la hoja.
Na hapa tunaunda pg_stat_view.
Na tunasasisha safu moja kwa moja. Na hapa tunaona 724. Na kisha tunasasisha safu yetu hadi tatu. Na unaona nini hapa sasa? Haya ni maombi, yaani, unaona orodha nzima ya maombi ambayo yameorodheshwa kwenye safu wima ya kushoto. Na kisha upande wa kulia unaweza kuona vizuizi na kile wanachounda. Na inaweza kuwa wazi zaidi kwako ili usilazimike kurudi kwenye kila kikao kila wakati na kuona ikiwa unahitaji kujiunga nacho au la. Wanafanya hivyo kwa ajili yetu.
Kipengele kingine ambacho ni muhimu sana ni pg_blocking_pids. Pengine hujawahi kusikia habari zake. Anafanya nini? Inaturuhusu kusema kwamba kwa kipindi hiki 11740 ni vitambulisho gani maalum vya mchakato inangojea. Na unaweza kuona kwamba 11740 inasubiri 724. Na 724 iko juu sana. Na 11306 ni kitambulisho chako cha mchakato. Kwa kweli, chaguo hili la kukokotoa linapitia jedwali lako la kufuli. Na najua ni ngumu kidogo, lakini unaweza kuelewa. Kimsingi chaguo hili la kukokotoa linapitia jedwali hili la kufuli na kujaribu kutafuta mahali ambapo kitambulisho hiki cha mchakato kimepewa kufuli ambacho kinasubiri. Na pia inajaribu kujua ni kitambulisho gani cha mchakato mchakato ambao unangojea kufuli unayo. Kwa hivyo unaweza kuendesha kazi hii pg_blocking_pids.
Na hii inaweza kuwa na manufaa sana. Tuliongeza hii tu katika toleo la 9.6, kwa hivyo kipengele hiki kina umri wa miaka 5 tu, lakini ni muhimu sana. Na hiyo inatumika kwa ombi la pili. Inaonyesha kile tunachohitaji kuona.
Hili ndilo nilitaka kuzungumza nawe. Na kama nilivyotarajia, tulitumia wakati wetu wote kwa sababu kulikuwa na slaidi nyingi. Na slaidi zinapatikana kwa kupakuliwa. Ningependa kukushukuru kwa kuwa hapa. Nina hakika utafurahia mkutano uliosalia, asante sana!
Maswali:
Kwa mfano, ikiwa ninajaribu kusasisha safu, na kikao cha pili kinajaribu kufuta jedwali zima. Kwa kadiri ninavyoelewa, kunapaswa kuwa na kitu kama kufuli ya kukusudia. Kuna kitu kama hicho huko Postgres?
Turudi mwanzo kabisa. Unaweza kukumbuka kuwa unapofanya chochote, kwa mfano unapofanya CHAGUA, tunatoa AccessShareLock. Na hii inazuia meza isiangushwe. Kwa hivyo ikiwa wewe, kwa mfano, unataka kusasisha safu katika jedwali au kufuta safu, basi mtu hawezi kufuta jedwali zima kwa wakati mmoja kwa sababu unashikilia AccessShareLock hii juu ya jedwali zima na juu ya safu. Na mara tu ukimaliza, wanaweza kuifuta. Lakini wakati unabadilisha kitu moja kwa moja hapo, hawataweza kukifanya.
Hebu tufanye tena. Wacha tuendelee kwenye mfano wa kufuta. Na unaona jinsi kuna kufuli ya kipekee kwenye safu mlalo juu ya jedwali zima.
Hii itaonekana kama kufuli pekee, sivyo?
Ndiyo, inaonekana kama hivyo. Ninaelewa unachozungumza. Unasema kwamba nikifanya CHAGUA basi nina ShareExclusive kisha niifanye Row Exclusive, hiyo inakuwa shida? Lakini cha kushangaza, hii haileti shida. Hii inaonekana kama kuongeza kiwango cha kufuli, lakini kimsingi nina kufuli ambayo inazuia kufutwa. Na sasa, ninapofanya kufuli hii kuwa na nguvu zaidi, bado inazuia kufutwa. Kwa hivyo sio kama ninapanda. Hiyo ni, ilizuia isitokee wakati ilikuwa katika kiwango cha chini pia, kwa hivyo ninapoongeza kiwango chake bado inazuia meza kufutwa.
Ninaelewa unachozungumza. Hakuna kesi ya kuongeza kufuli hapa, ambapo unajaribu kutoa kufuli moja ili kutambulisha yenye nguvu zaidi. Hapa inaongeza tu uzuiaji huu kote, kwa hivyo haisababishi mzozo wowote. Lakini ni swali zuri. Asante sana kwa kuuliza hili!
Je, tunahitaji kufanya nini ili kuepuka hali ya msuguano wakati tuna vipindi vingi, idadi kubwa ya watumiaji?
Postgres hutambua moja kwa moja hali za msuguano. Na itafuta moja kwa moja moja ya vipindi. Njia pekee ya kuzuia kuzuia wafu ni kuzuia watu kwa mpangilio sawa. Kwa hivyo unapoangalia ombi lako, mara nyingi sababu ya mikwamo ... Wacha tufikirie kuwa nataka kuzuia vitu viwili tofauti. Programu moja hufunga jedwali la 1, na programu nyingine hufunga 2, na kisha jedwali 1. Na njia rahisi zaidi ya kuepuka kufuli ni kuangalia programu yako na kujaribu kuhakikisha kuwa kufunga kunatokea kwa mpangilio sawa katika programu zote. Na hii kawaida huondoa 80% ya shida, kwa sababu kila aina ya watu huandika maombi haya. Na ikiwa utawazuia kwa mpangilio sawa, basi hutakutana na hali ya msuguano.
Asante sana kwa utendaji wako! Ulizungumza juu ya utupu kamili na, ikiwa ninaelewa kwa usahihi, utupu kamili hupotosha mpangilio wa rekodi katika hifadhi tofauti, kwa hivyo huweka rekodi za sasa bila kubadilika. Kwa nini utupu kamili huchukua ufikiaji wa kipekee wa kufuli na kwa nini unakinzana na shughuli za uandishi?
Hilo ni swali zuri. Sababu ni kwamba utupu kamili huchukua meza. Na kimsingi tunaunda toleo jipya la jedwali. Na meza itakuwa mpya. Inageuka hii itakuwa toleo jipya kabisa la meza. Na shida ni kwamba tunapofanya hivi, hatutaki watu wasome kwa sababu tunahitaji waone meza mpya. Na kwa hivyo hii inaunganisha kwa swali lililopita. Ikiwa tungeweza kusoma kwa wakati mmoja, hatungeweza kuisogeza na kuwaelekeza watu kwenye jedwali jipya. Tungehitaji kungoja kila mtu amalize kusoma jedwali hili, na kwa hivyo ni hali ya kipekee ya kufuli.
Tunasema tu kwamba tunafunga tangu mwanzo kwa sababu tunajua kwamba mwisho kabisa tutahitaji kufuli ya kipekee ili kuhamisha kila mtu kwenye nakala mpya. Kwa hivyo tunaweza kusuluhisha hii. Na tunaifanya kwa njia hii kwa kuorodhesha kwa wakati mmoja. Lakini hii ni ngumu zaidi kufanya. Na hii inahusiana sana na swali lako la awali kuhusu kufuli pekee.
Inawezekana kuongeza muda wa kufunga kwa Postgres? Katika Oracle, naweza, kwa mfano, kuandika "chagua kusasisha" na subiri sekunde 50 kabla ya kusasisha. Ilikuwa nzuri kwa maombi. Lakini katika Postgres, ninahitaji kuifanya mara moja na nisingojee kabisa, au subiri hadi muda fulani.
Ndiyo, unaweza kuchagua kuisha kwa kufuli zako, kwenye kufuli zako. Unaweza pia kutoa amri ya hakuna njia, ambayo ... ikiwa huwezi kupata kufuli mara moja. Kwa hivyo, ama kuisha kwa muda au kitu kingine ambacho kitakuruhusu kufanya hivi. Hili halifanyiki katika kiwango cha kisintaksia. Hii inafanywa kama kutofautisha kwenye seva. Wakati mwingine hii haiwezi kutumika.
Je, unaweza kufungua slaidi ya 75?
Ndiyo.
Na swali langu ni hili lifuatalo. Kwa nini michakato yote miwili ya sasisho inatarajia 703?
Na hili ni swali kubwa. Sielewi, kwa njia, kwa nini Postgres hufanya hivi. Lakini 703 ilipoundwa, ilitarajiwa 702. Na 704 na 705 zilipojitokeza, inaonekana kama hawajui wanachotarajia kwa sababu bado hakuna kitu. Na Postgres hufanya hivyo kwa njia hii: wakati huwezi kupata lock, inaandika "Ni nini maana ya kusindika wewe?", Kwa sababu tayari unasubiri mtu. Kwa hivyo tutaiacha tu ining'inie hewani, haitaisasisha hata kidogo. Lakini nini kilitokea hapa? Mara tu 702 ilipokamilisha mchakato na 703 ikapokea kufuli yake, mfumo ulirudi nyuma. Na akasema kwamba sasa tuna watu wawili ambao wanangojea. Na kisha tuzisasishe pamoja. Na tuonyeshe kwamba wote wawili wanatarajia.
Sijui kwanini Postgres hufanya hivi. Lakini kuna shida inaitwa fβ¦. Inaonekana kwangu kuwa hii sio neno kwa Kirusi. Huu ndio wakati kila mtu anangojea ngome moja, hata ikiwa kuna mamlaka 20 ambayo yanangojea ngome hiyo. Na ghafla wote huamka kwa wakati mmoja. Na kila mtu anaanza kujaribu kujibu. Lakini mfumo hufanya hivyo kwamba kila mtu anasubiri 703. Kwa sababu wote wanasubiri, na mara moja tutawapanga wote. Na ikiwa ombi lingine jipya litaonekana ambalo lilitolewa baada ya hili, kwa mfano, 707, basi kutakuwa na utupu tena.
Na inaonekana kwangu kwamba hii imefanywa ili tuweze kusema kwamba katika hatua hii 702 inasubiri 703, na wale wote wanaokuja baada ya hayo hawatakuwa na kiingilio chochote katika uwanja huu. Lakini mara tu mhudumu wa kwanza akiondoka, wale wote ambao walikuwa wakingojea wakati huo kabla ya sasisho wanapokea ishara sawa. Na kwa hivyo nadhani hii inafanywa ili tuweze kushughulikia kwa utaratibu ili waagizwe vizuri.
Siku zote nilitazama hili kama jambo la kushangaza. Kwa sababu hapa, kwa mfano, hatuwaorodheshi kabisa. Lakini inaonekana kwangu kwamba kila wakati tunapotoa kufuli mpya, tunaangalia wale wote ambao wako katika mchakato wa kusubiri. Kisha tunawapanga wote. Na kisha mpya yoyote inayoingia inaingia tu kwenye foleni mtu anayefuata anapomaliza kuchakatwa. Swali zuri sana. Asante sana kwa swali lako!
Inaonekana kwangu kuwa ni mantiki zaidi wakati 705 inatarajia 704.
Lakini tatizo hapa ni lifuatalo. Kitaalam, unaweza kuamka moja au nyingine. Na hivyo tutaamka moja au nyingine. Lakini nini kinatokea kwenye mfumo? Unaweza kuona jinsi 703 juu kabisa amezuia kitambulisho chake cha muamala. Hivi ndivyo Postgres inavyofanya kazi. Na 703 imefungwa na kitambulisho chake cha shughuli, hivyo ikiwa mtu anataka kusubiri, basi atasubiri 703. Na, kwa asili, 703 inakamilisha. Na tu baada ya kukamilika kwake moja ya michakato inaamsha. Na hatujui ni nini hasa mchakato huu utakuwa. Kisha tunasindika kila kitu hatua kwa hatua. Lakini haijulikani ni mchakato gani unaamshwa kwanza, kwa sababu inaweza kuwa yoyote ya michakato hii. Kwa kweli, tulikuwa na kipanga ratiba ambacho kilisema sasa tunaweza kuamsha yoyote ya michakato hii. Tunachagua moja tu bila mpangilio. Kwa hivyo zote mbili zinahitaji kuzingatiwa kwa sababu tunaweza kuamsha yoyote kati yao.
Na shida ni kwamba tuna CP-infinity. Na kwa hivyo, kuna uwezekano mkubwa kwamba tunaweza kuamka baadaye. Na ikiwa, kwa mfano, tutaamsha baadaye, tutamngojea yule aliyepokea kizuizi, kwa hivyo hatuwezi kuamua ni nani hasa ataamshwa kwanza. Tunaunda hali kama hiyo, na mfumo utawaamsha kwa mpangilio wa nasibu.
Kuna . Angalia, wao pia ni ya kuvutia na muhimu. Mada, bila shaka, ni ngumu sana. Asante sana, Bruce!
Chanzo: mapenzi.com