Postgres- ဖောင်းပွခြင်း၊ pg_repack နှင့် ရွှေ့ဆိုင်းကန့်သတ်ချက်များ

ဇယားများနှင့် အညွှန်းများပေါ်တွင် ဖောင်းပွခြင်း၏အကျိုးသက်ရောက်မှုကို ကျယ်ကျယ်ပြန့်ပြန့်သိရှိပြီး Postgres တွင်သာမကဘဲ ရှိနေပါသည်။ VACUUM FULL သို့မဟုတ် CLUSTER ကဲ့သို့ ၎င်းကို ဘောက်စ်ပြင်ပတွင် ကိုင်တွယ်ဖြေရှင်းရန် နည်းလမ်းများ ရှိသည်၊ သို့သော် ၎င်းတို့သည် လည်ပတ်နေစဉ်အတွင်း စားပွဲများကို သော့ခတ်ထားသောကြောင့် အမြဲတမ်း အသုံးမပြုနိုင်ပါ။

ဆောင်းပါးတွင် ဖောင်းပွမှုဖြစ်ပွားပုံ၊ ၎င်းကို သင်မည်ကဲ့သို့ တိုက်ဖျက်နိုင်သနည်း၊ ရွှေ့ဆိုင်းထားသော ကန့်သတ်ချုပ်ချယ်မှုများနှင့် pg_repack တိုးချဲ့မှုကို အသုံးပြုခြင်းအတွက် ၎င်းတို့ယူဆောင်လာသည့် ပြဿနာများအကြောင်း သီအိုရီအနည်းငယ်ပါရှိသည်။

ဒီဆောင်းပါးကို အခြေခံပြီး ရေးထားတာပါ။ ငါ့စကား PgConf.Russia 2020 တွင်

ဝမ်းချုပ်ခြင်း ဘာကြောင့်ဖြစ်တာလဲ။

Postgres သည် ဗားရှင်းပေါင်းစုံ မော်ဒယ်ကို အခြေခံသည် (MVCC) ၎င်း၏ အနှစ်သာရမှာ ဇယားရှိ အတန်းတစ်ခုစီတွင် ဗားရှင်းများစွာရှိနိုင်ပြီး ငွေပေးငွေယူများသည် ဤဗားရှင်းများထဲမှ တစ်ခုထက် မပိုဘဲ တူညီနေမည်မဟုတ်ပေ။ ၎င်းသည် ငွေပေးငွေယူများစွာကို တစ်ပြိုင်နက် လုပ်ဆောင်နိုင်စေပြီး တစ်ခုနှင့်တစ်ခု ထိခိုက်မှု မရှိသလောက်ဖြစ်သည်။

ရှင်းပါတယ်၊ ဒီဗားရှင်းအားလုံးကို သိမ်းဆည်းထားဖို့ လိုပါတယ်။ Postgres သည် စာမျက်နှာတစ်ခုပြီးတစ်ခု မှတ်ဉာဏ်ဖြင့် အလုပ်လုပ်ပြီး စာမျက်နှာတစ်ခုသည် ဒစ်ခ်မှ သို့မဟုတ် စာဖြင့်ဖတ်နိုင်သည့် အနည်းဆုံးဒေတာပမာဏဖြစ်သည်။ ဒီလိုဖြစ်သွားတာကို နားလည်ဖို့ ဥပမာလေးတစ်ခုကို ကြည့်ရအောင်။

ကျွန်ုပ်တို့တွင် မှတ်တမ်းများစွာထည့်ထားသော ဇယားတစ်ခုရှိသည် ဆိုကြပါစို့။ ဇယားကို သိမ်းဆည်းထားသည့် ဖိုင်၏ ပထမစာမျက်နှာတွင် ဒေတာအသစ် ပေါ်လာသည်။ ၎င်းတို့သည် ကတိပြုပြီးနောက် အခြားငွေပေးငွေယူများအတွက် ရရှိနိုင်သော တိုက်ရိုက်ဗားရှင်းအတန်းများဖြစ်သည် (ရိုးရိုးရှင်းရှင်းအတွက်၊ သီးခြားခွဲထုတ်မှုအဆင့်သည် Read Committed ဟု ကျွန်ုပ်တို့ ယူဆပါမည်)။

ထို့နောက် ထည့်သွင်းမှုများထဲမှ တစ်ခုကို အပ်ဒိတ်လုပ်ကာ ဗားရှင်းဟောင်းကို မသက်ဆိုင်တော့ကြောင်း အမှတ်အသားပြုပါသည်။

တစ်ဆင့်ပြီးတစ်ဆင့်၊ အတန်းဗားရှင်းများကို အဆင့်မြှင့်တင်ခြင်းနှင့် ဖျက်ခြင်း၊ ဒေတာတစ်ဝက်ခန့်သည် "အမှိုက်" ဖြစ်သည့် စာမျက်နှာတစ်ခုဖြင့် အဆုံးသတ်ခဲ့သည်။ ဤဒေတာကို မည်သည့်ငွေကြေးလွှဲပြောင်းမှုတွင်မျှ မမြင်နိုင်ပါ။

Postgres တွင် ယန္တရားတစ်ခုရှိသည်။ အနုပညာအသုံးမပြုတော့သော ဗားရှင်းများကို ရှင်းထုတ်ပြီး ဒေတာအသစ်အတွက် နေရာပေးသည်။ သို့သော် ၎င်းကို ပြင်းပြင်းထန်ထန် မပြင်ဆင်ရသေးပါက သို့မဟုတ် အခြားဇယားများတွင် အလုပ်များနေပါက၊ "အမှိုက်ဒေတာ" ကျန်ရှိနေပြီး ဒေတာအသစ်အတွက် နောက်ထပ်စာမျက်နှာများကို အသုံးပြုရမည်ဖြစ်သည်။

ထို့ကြောင့် ကျွန်ုပ်တို့၏ဥပမာတွင်၊ တစ်ချိန်ချိန်တွင် ဇယားတွင် စာမျက်နှာလေးမျက်နှာပါလိမ့်မည်၊ သို့သော် ၎င်းတွင် တစ်ဝက်သာသော တိုက်ရိုက်ဒေတာပါရှိသည်။ ရလဒ်အနေဖြင့်၊ ဇယားကိုဝင်ရောက်သောအခါ၊ ကျွန်ုပ်တို့သည် လိုအပ်သည်ထက်ပို၍ အချက်အလက်များစွာကို ဖတ်ပါမည်။

ယခု VACUUM သည် မသက်ဆိုင်သောအတန်းဗားရှင်းအားလုံးကို ဖျက်လိုက်လျှင်ပင်၊ အခြေအနေ သိသိသာသာ ကောင်းမွန်လာမည်မဟုတ်ပါ။ အတန်းသစ်အတွက် စာမျက်နှာများ သို့မဟုတ် စာမျက်နှာတစ်ခုလုံးတွင် နေရာလွတ်ရှိမည်ဖြစ်သော်လည်း လိုအပ်သည်ထက်ပို၍ ဒေတာကို ကျွန်ုပ်တို့ ဆက်လက်ဖတ်ရှုနေပါမည်။
စကားမစပ်၊ ဖိုင်၏အဆုံးတွင် လုံးဝဗလာဖြစ်နေသည် (ကျွန်ုပ်တို့၏ဥပမာရှိ ဒုတိယစာမျက်နှာ) ဖြစ်ပါက VACUUM သည် ၎င်းကိုချုံ့နိုင်မည်ဖြစ်သည်။ ယခုမူ သူမသည် အလယ်တွင်ရှိနေပြီဖြစ်သောကြောင့် သူမအတွက် ဘာမှလုပ်မပေးနိုင်ပါ။

ထိုကဲ့သို့ ဗလာ သို့မဟုတ် အလွန်ကျဲသော စာမျက်နှာအရေအတွက် ကြီးမားလာသောအခါ၊ bloat ဟုခေါ်သော၊ ၎င်းသည် စွမ်းဆောင်ရည်ကို စတင်သက်ရောက်ပါသည်။

အထက်ဖော်ပြပါအရာအားလုံးသည် ဇယားများတွင် ဖောင်းပွမှုဖြစ်ပေါ်ခြင်း၏ စက်ပြင်ဖြစ်သည်။ အညွှန်းကိန်းများတွင် ဤနည်းအတိုင်းပင် ဖြစ်တတ်ပါသည်။

ငါ့မှာ ဖောင်းနေသလား

သင့်တွင် ဝမ်းချုပ်ခြင်းရှိမရှိ ဆုံးဖြတ်ရန် နည်းလမ်းများစွာရှိပါသည်။ ပထမအကြံဥာဏ်မှာ ဇယားများရှိ အတန်းအရေအတွက်၊ တိုက်ရိုက်ထုတ်လွှင့်သည့် အတန်းအရေအတွက်စသည်ဖြင့် အနီးစပ်ဆုံးအချက်အလက်များပါရှိသော ပြည်တွင်း Postgres စာရင်းအင်းများကို အသုံးပြုရန်ဖြစ်သည်။ အင်တာနက်ပေါ်တွင် အသင့်လုပ်ထားသော script အများအပြားကို သင်ရှာတွေ့နိုင်ပါသည်။ အခြေခံအဖြစ်ယူတယ်။ ဇာတ်ညွှန်း Toast နှင့် bloat btree အညွှန်းများနှင့်အတူ bloat table များကိုအကဲဖြတ်နိုင်သည့် PostgreSQL ကျွမ်းကျင်သူများမှ။ ကျွန်ုပ်တို့၏အတွေ့အကြုံအရ၊ ၎င်း၏အမှားသည် 10-20% ဖြစ်သည်။

နောက်တနည်းကတော့ Extension ကိုသုံးဖို့ပါ။ pgstattuple၎င်းသည် စာမျက်နှာများအတွင်း ကြည့်ရှုနိုင်ပြီး ခန့်မှန်းခြေနှင့် အတိအကျ ဖောင်းပွမှုတန်ဖိုး နှစ်ခုစလုံးကို ရရှိနိုင်သည်။ သို့သော် ဒုတိယကိစ္စတွင်၊ သင်သည် ဇယားတစ်ခုလုံးကို စကင်န်ဖတ်ရမည်ဖြစ်သည်။

ကျွန်ုပ်တို့သည် 20% အထိ လက်ခံနိုင်သော သေးငယ်သော bloat တန်ဖိုးကို သုံးသပ်ပါသည်။ ၎င်းကို fillfactor ၏ analogue အဖြစ် ယူဆနိုင်သည်။ ဇယား и အညွှန်းကိန်းများ. 50% နှင့်အထက်တွင်၊ စွမ်းဆောင်ရည်ပြဿနာများစတင်နိုင်သည်။

ဝမ်းချုပ်ခြင်းကို တိုက်ဖျက်နည်းများ

Postgres သည် ဘောက်ထဲက ဝမ်းပျက်ခြင်းကို ကိုင်တွယ်ဖြေရှင်းရန် နည်းလမ်းများစွာရှိသော်လည်း ၎င်းတို့သည် လူတိုင်းအတွက် အမြဲတမ်း မသင့်လျော်ပါ။

ဖောင်းခြင်းမဖြစ်ပေါ်စေရန် AUTOVACUUM ကို စီစဉ်သတ်မှတ်ပါ။. သို့မဟုတ် ပို၍တိကျစွာ၊ ၎င်းကို သင့်လက်ခံနိုင်သော အဆင့်တွင် ထားရှိရန်။ ၎င်းသည် "ကပ္ပတိန်၏" အကြံဉာဏ်နှင့်တူပုံရသည်၊ သို့သော်လက်တွေ့တွင်၎င်းသည်အောင်မြင်ရန်အမြဲတမ်းမလွယ်ကူပါ။ ဥပမာအားဖြင့်၊ သင့်တွင် ဒေတာအစီအစဉ်ကို ပုံမှန်ပြောင်းလဲမှုများဖြင့် တက်ကြွစွာ ဖွံ့ဖြိုးတိုးတက်မှုရှိသည်၊ သို့မဟုတ် အချို့သောဒေတာရွှေ့ပြောင်းမှုမျိုး လုပ်ဆောင်နေပါသည်။ ရလဒ်အနေဖြင့်၊ သင်၏ load profile သည် မကြာခဏ ပြောင်းလဲနိုင်ပြီး ပုံမှန်အားဖြင့် ဇယားတစ်ခုမှ တစ်ခုသို့ ကွဲပြားလိမ့်မည်။ ဆိုလိုသည်မှာ သင်သည် အနည်းငယ် ရှေ့သို့ အဆက်မပြတ် လုပ်ဆောင်ပြီး ဇယားတစ်ခုစီ၏ ပြောင်းလဲနေသော ပရိုဖိုင်သို့ AUTOVACUUM ကို ချိန်ညှိရန် လိုအပ်သည်။ ဒါပေမယ့် ဒီလိုလုပ်ရတာ မလွယ်ဘူးဆိုတာ သိသာပါတယ်။

AUTOVACUUM သည် ဇယားများကို လိုက်မမီနိုင်ရသည့် အကြောင်းရင်းမှာ ထိုငွေပေးငွေယူများအတွက် ရရှိနိုင်သော ဒေတာများကို ရှင်းထုတ်ခြင်းမှ ဟန့်တားသော ကာလရှည်ကြာ ငွေပေးငွေယူမှုများ ရှိနေသောကြောင့် ဖြစ်သည်။ ဤနေရာတွင် အကြံပြုချက်မှာလည်း သိသာထင်ရှားသည် - “dangling” အရောင်းအ၀ယ်များကို ဖယ်ရှားပြီး တက်ကြွသော အရောင်းအ၀ယ်ပြုလုပ်သည့်အချိန်ကို လျှော့ချပါ။ သို့သော် သင့်လျှောက်လွှာတွင် load သည် OLAP နှင့် OLTP တို့၏ ပေါင်းစပ်တစ်ခုဖြစ်ပါက၊ သင်သည် တပြိုင်နက်တွင် မကြာခဏ အပ်ဒိတ်များနှင့် တိုတောင်းသော စုံစမ်းမေးမြန်းမှုများအပြင် ရေရှည်လုပ်ဆောင်မှုများ အများအပြားရှိသည် - ဥပမာ၊ အစီရင်ခံစာတစ်ခုကို တည်ဆောက်ခြင်း။ ထိုသို့သောအခြေအနေမျိုးတွင်၊ ၎င်းတို့တစ်ခုစီကို ပိုမိုကောင်းမွန်စွာချိန်ညှိနိုင်စေမည့် မတူညီသောအခြေများတစ်လျှောက် ဝန်ကိုဖြန့်ကြက်ရန် စဉ်းစားသင့်သည်။

အခြားဥပမာ- ပရိုဖိုင်သည် တစ်သားတည်းဖြစ်နေလျှင်ပင်၊ သို့သော် ဒေတာဘေ့စ်သည် အလွန်မြင့်မားသောဝန်အောက်တွင် ရှိနေသည်၊ ထို့နောက် အပြင်းထန်ဆုံးသော AUTOVACUUM သည်ပင် ထိန်းမနိုင်ဖြစ်ပြီး ဖောင်းကားလာမည်ဖြစ်သည်။ အတိုင်းအတာ (ဒေါင်လိုက် သို့မဟုတ် အလျားလိုက်) သည် တစ်ခုတည်းသော ဖြေရှင်းချက်ဖြစ်သည်။

AUTOVACUUM ကို တပ်ဆင်ထားသည့် အခြေအနေတွင် ဘာလုပ်ရမည်နည်း။

အဖွဲ့ ဖုန်စုပ်စက် အပြည့် ဇယားများနှင့် အညွှန်းကိန်းများ၏ အကြောင်းအရာများကို ပြန်လည်တည်ဆောက်ပြီး ၎င်းတို့တွင် သက်ဆိုင်ရာ အချက်အလက်များကိုသာ ချန်ထားသည်။ ဖောင်းပွမှုကို ဖယ်ရှားရန်၊ ၎င်းသည် ပြီးပြည့်စုံစွာ လုပ်ဆောင်နိုင်သော်လည်း ၎င်း၏လုပ်ဆောင်မှုအတွင်း စားပွဲပေါ်ရှိ သီးသန့်သော့ခလောက်တစ်ခု (AccessExclusiveLock) ကို ဖမ်းယူထားပြီး ဤဇယားရှိ စုံစမ်းမေးမြန်းမှုများကိုပင် လုပ်ဆောင်ခွင့်မပြုဘဲ ရွေးချယ်ထားသည်။ အကယ်၍ သင်သည် သင်၏ ဝန်ဆောင်မှု သို့မဟုတ် ၎င်း၏ အစိတ်အပိုင်းကို အချိန်အတန်ကြာ ရပ်တန့်ရန် တတ်နိုင်လျှင် (ဒေတာဘေ့စ်နှင့် သင်၏ ဟာ့ဒ်ဝဲ၏ အရွယ်အစားပေါ် မူတည်၍ မိနစ် ဆယ်ဂဏန်းမှ နာရီများစွာအထိ)၊ ထို့နောက် ဤရွေးချယ်မှုသည် အကောင်းဆုံးဖြစ်သည်။ ဝမ်းနည်းပါသည်၊ ကျွန်ုပ်တို့တွင် VACUUM FULL ကို စီစဉ်ထိန်းသိမ်းထားစဉ်အတွင်း လုပ်ဆောင်ရန် အချိန်မရှိသောကြောင့် ဤနည်းလမ်းသည် ကျွန်ုပ်တို့အတွက် မသင့်လျော်ပါ။

အဖွဲ့ တန်းခွဲ VACUUM FULL ကဲ့သို့ပင် ဇယားများ၏ အကြောင်းအရာများကို ပြန်လည်တည်ဆောက်ပေးသည်၊ သို့သော် ဒေတာကို ဒစ်ခ်ပေါ်တွင် ရုပ်ပိုင်းဆိုင်ရာ စီစဥ်ထားမည့် အညွှန်းတစ်ခုကို သတ်မှတ်ခွင့်ပြုသည် (သို့သော် နောင်တွင် အတန်းအသစ်အတွက် အာမခံချက်မရှိပါ)။ အချို့သောအခြေအနေများတွင်၊ ဤအရာသည် မှတ်တမ်းများစွာကို အညွှန်းဖြင့်ဖတ်ခြင်းနှင့်အတူ queries အများအပြားအတွက် ကောင်းမွန်သင့်လျော်မှုတစ်ခုဖြစ်သည်။ command ၏အားနည်းချက်သည် VACUUM FULL နှင့်အတူတူပင်ဖြစ်သည် - လည်ပတ်နေစဉ်အတွင်းဇယားကိုသော့ခတ်သည်။

အဖွဲ့ REINDEX ယခင်နှစ်ခုနှင့် ဆင်တူသော်လည်း ဇယား၏ တိကျသောအညွှန်း သို့မဟုတ် အညွှန်းအားလုံးကို ပြန်လည်တည်ဆောက်သည်။ လော့ခ်များသည် အနည်းငယ် အားနည်းသည်- စားပွဲပေါ်ရှိ ShareLock (ပြုပြင်မွမ်းမံမှုများကို တားဆီးထားသော်လည်း ရွေးချယ်မှုကို ခွင့်ပြုသည်) နှင့် အညွှန်းတွင် AccessExclusiveLock ပြန်လည်တည်ဆောက်ခြင်း (ဤအညွှန်းကို အသုံးပြု၍ မေးမြန်းမှုများကို ပိတ်ဆို့သည်)။ သို့သော် Postgres ၏ 12th ဗားရှင်းတွင် parameter တစ်ခုပေါ်လာသည်။ ပြိုင်တူတစ်ပြိုင်တည်း ထပ်လောင်းခြင်း၊ ပြုပြင်မွမ်းမံခြင်း သို့မဟုတ် မှတ်တမ်းများကို ဖျက်ခြင်းတို့ကို ပိတ်ဆို့ခြင်းမရှိဘဲ အညွှန်းကို ပြန်လည်တည်ဆောက်နိုင်စေပါသည်။

Postgres ၏ အစောပိုင်းဗားရှင်းများတွင်၊ သင်သည် REINDEX ကို တစ်ပြိုင်နက် အသုံးပြုခြင်းနှင့် အလားတူ ရလဒ်ကို ရရှိနိုင်သည်။ Index ကို တပြိုင်နက် ဖန်တီးပါ။. ၎င်းသည် သင့်အား တင်းကျပ်သောသော့ခတ်မှုမရှိဘဲ အညွှန်းတစ်ခုဖန်တီးနိုင်သည် (ShareUpdateExclusiveLock၊ အပြိုင်မေးမြန်းချက်များကိုအနှောင့်အယှက်မပေးသော)၊ ထို့နောက် အညွှန်းဟောင်းကိုအသစ်တစ်ခုဖြင့်အစားထိုးပြီး အညွှန်းအဟောင်းကိုဖျက်ပါ။ ၎င်းသည် သင့်လျှောက်လွှာကို မနှောင့်ယှက်ဘဲ index bloat ကို ဖယ်ရှားနိုင်စေပါသည်။ အညွှန်းများကိုပြန်လည်တည်ဆောက်သည့်အခါ disk subsystem တွင်နောက်ထပ် load တစ်ခုရှိလာမည်ကိုထည့်သွင်းစဉ်းစားရန်အရေးကြီးသည်။

ထို့ကြောင့်၊ အညွှန်းကိန်းများအတွက် "ပျံဝဲခြင်း" ကိုဖယ်ရှားရန်နည်းလမ်းများရှိပါက၊ ဇယားများအတွက်မရှိပါ။ ဤနေရာတွင် အမျိုးမျိုးသော ပြင်ပ extension များ ပါဝင်လာသည်- pg_repack (ယခင် pg_reorg)၊ pgcompact, pgcompactable နှင့်အခြားသူများ။ ဤဆောင်းပါးတွင်၊ ကျွန်ုပ်သည် ၎င်းတို့ကို မနှိုင်းယှဉ်ဘဲ အချို့သောပြုပြင်မွမ်းမံပြီးနောက် ကျွန်ုပ်တို့ကိုယ်တိုင်အသုံးပြုသည့် pg_repack အကြောင်းကိုသာ ပြောဆိုပါမည်။

pg_repack ဘယ်လိုအလုပ်လုပ်သလဲ။

ကျွန်ုပ်တို့တွင် အညွှန်းများ၊ ကန့်သတ်ချက်များ၊ ကံမကောင်းစွာဖြင့် ဖောင်းပွသော လုံးလုံးလျားလျား စားပွဲတစ်လုံးရှိသည် ဆိုကြပါစို့။ pg_repack ၏ ပထမအဆင့်မှာ ၎င်းလုပ်ဆောင်နေချိန်တွင် ပြောင်းလဲမှုများအားလုံးကို သိမ်းဆည်းရန်အတွက် မှတ်တမ်းဇယားတစ်ခု ဖန်တီးရန်ဖြစ်သည်။ ထည့်သွင်းမှု၊ အပ်ဒိတ်နှင့် ဖျက်မှုတိုင်းအတွက် ဤပြောင်းလဲမှုများကို အစပျိုးမှုမှ ထပ်တူပွားစေမည်ဖြစ်သည်။ ထို့နောက် ဒေတာထည့်သွင်းခြင်းလုပ်ငန်းစဉ်ကို နှေးကွေးစေရန်အတွက် အညွှန်းများနှင့် ကန့်သတ်ချက်များမပါဘဲ ဇယားတစ်ခုကို ဖန်တီးပါသည်။

ထို့နောက်၊ pg_repack သည် ဇယားဟောင်းမှ ဒေတာများကို ဇယားအသစ်သို့ လွှဲပြောင်းပေးကာ၊ မသက်ဆိုင်သော အတန်းအားလုံးကို အလိုအလျောက် စစ်ထုတ်ကာ ဇယားအသစ်အတွက် အညွှန်းများကို ဖန်တီးပေးသည်။ ဤလုပ်ဆောင်မှုများအားလုံးကို လုပ်ဆောင်နေစဉ်အတွင်း အပြောင်းအလဲများသည် မှတ်တမ်းဇယားတွင် စုပုံနေပါသည်။

နောက်တစ်ဆင့်မှာ အပြောင်းအလဲများကို ဇယားအသစ်သို့ လွှဲပြောင်းရန်ဖြစ်သည်။ ရွှေ့ပြောင်းခြင်းအား အကြိမ်ကြိမ် ထပ်ခါထပ်ခါ လုပ်ဆောင်ပြီး မှတ်တမ်းဇယားတွင် ထည့်သွင်းမှု 20 ထက်နည်းသော အချိန်တွင်၊ pg_repack သည် ခိုင်မာသောသော့ကို ရယူပြီး နောက်ဆုံးဒေတာကို ရွှေ့ပြောင်းကာ Postgres စနစ်ဇယားရှိ ဇယားဟောင်းကို အသစ်နှင့် အစားထိုးသည်။ ဤအချိန်သည် သင် စားပွဲနှင့် အလုပ်တွဲလုပ်နိုင်မည်မဟုတ်သည့် တစ်ခုတည်းနှင့် အလွန်တိုတောင်းသော အချိန်ဖြစ်သည်။ ယင်းနောက်၊ ဇယားဟောင်းနှင့် မှတ်တမ်းပါရှိသော ဇယားကို ဖျက်ပြီး ဖိုင်စနစ်တွင် နေရာလွတ်များ ပေါ်လာသည်။ လုပ်ငန်းစဉ်ပြီးပါပြီ။

အရာအားလုံးသည် သီအိုရီအရ ကောင်းမွန်လှသော်လည်း လက်တွေ့တွင် ဘာဖြစ်သွားသနည်း။ ကျွန်ုပ်တို့သည် pg_repack ကို load နှင့် load မပါပဲ စမ်းသပ်ပြီး အချိန်မတန်မီ ရပ်တန့်သွားသောအခါတွင် ၎င်း၏လုပ်ဆောင်ချက်ကို စစ်ဆေးခဲ့သည် (တစ်နည်းအားဖြင့် Ctrl+C ကိုသုံး၍)။ စစ်ဆေးမှုအားလုံး အပြုသဘောဆောင်သည်။

ကျွန်တော်တို့ အစားအသောက်ဆိုင်ကို သွားပြီးတော့ အားလုံးက မျှော်လင့်ထားသလို ဖြစ်မလာဘူး။

ပထမဦးစွာ ပန်ကိတ်ရောင်းသည်။

ပထမအစုတွင် ထူးခြားသောကန့်သတ်ချက်ကို ချိုးဖောက်ခြင်းနှင့်ပတ်သက်၍ အမှားအယွင်းတစ်ခုရရှိခဲ့သည်-

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ဤကန့်သတ်ချက်တွင် အလိုအလျောက်ထုတ်ပေးသည့် အမည် index_16508 ပါရှိသည် - ၎င်းကို pg_repack မှ ဖန်တီးထားသည်။ ၎င်း၏ဖွဲ့စည်းမှုတွင်ပါဝင်သော အရည်အချင်းများအပေါ် အခြေခံ၍ ၎င်းနှင့်ကိုက်ညီသော "ကျွန်ုပ်တို့၏" ကန့်သတ်ချက်ကို ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သည်။ ပြဿနာက ဒါဟာ လုံးဝ သာမာန် ကန့်သတ်ချက် မဟုတ်ပါဘူး၊ ရွှေ့ဆိုင်းလိုက်တာ (ရွှေ့ဆိုင်းကန့်သတ်မှု), i.e. ၎င်း၏အတည်ပြုချက်ကို sql command ထက် နောက်ကျပြီးမှ လုပ်ဆောင်ပြီး မမျှော်လင့်ထားသော အကျိုးဆက်များကို ဖြစ်ပေါ်စေသည်။

ရွှေ့ဆိုင်းထားသော ကန့်သတ်ချက်များ- ၎င်းတို့သည် အဘယ်ကြောင့် လိုအပ်ပြီး ၎င်းတို့ မည်သို့အလုပ်လုပ်သနည်း။

ရွှေ့ဆိုင်းကန့်သတ်ချက်များအကြောင်း သီအိုရီအနည်းငယ်။
ရိုးရှင်းသောဥပမာတစ်ခုကို သုံးသပ်ကြည့်ကြပါစို့- ကျွန်ုပ်တို့တွင် ရည်ညွှန်းချက်နှစ်ခုပါရှိသော ကားများ၏ ဇယား-လမ်းညွှန်စာအုပ်တွင် ကား၏အမည်နှင့် အစီအစဥ်ရှိသည်။

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

ပထမနှင့် ဒုတိယကားများကို လဲလှယ်ရန် လိုအပ်သည်ဆိုပါစို့။ ရိုးရှင်းသောဖြေရှင်းချက်မှာ ပထမတန်ဖိုးကို ဒုတိယသို့ အပ်ဒိတ်လုပ်ပြီး ဒုတိယတန်ဖိုးကို ပထမသို့ အပ်ဒိတ်လုပ်ရန်ဖြစ်သည်-

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

သို့သော် ကျွန်ုပ်တို့သည် ဤကုဒ်ကို အသုံးပြုသောအခါတွင်၊ ဇယားရှိ တန်ဖိုးများ၏ အစီအစဥ်သည် ထူးခြားသောကြောင့်၊

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

ကွဲပြားအောင် ဘယ်လိုလုပ်ရမလဲ။ ရွေးချယ်စရာတစ်ခု- ဥပမာ “-1” ဇယားတွင် မရှိဟု အာမခံထားသော အမှာစာတစ်ခုသို့ အပိုတန်ဖိုးအစားထိုးမှုတစ်ခုကို ထည့်ပါ။ ပရိုဂရမ်ရေးဆွဲခြင်းတွင်၊ ၎င်းကို "ကိန်းရှင်နှစ်ခု၏တန်ဖိုးများကို သုံးပုံတစ်ပုံသို့ဖလှယ်ခြင်း" ဟုခေါ်သည်။ ဤနည်းလမ်း၏တစ်ခုတည်းသောအားနည်းချက်မှာ ထပ်လောင်းမွမ်းမံမှုဖြစ်သည်။

ရွေးချယ်စရာနှစ်ခု- ကိန်းပြည့်အစား အမှာစာတန်ဖိုးအတွက် floating point data type ကိုအသုံးပြုရန် ဇယားကို ပြန်လည်ဒီဇိုင်းဆွဲပါ။ ထို့နောက်၊ ဥပမာ၊ 1 မှ 2.5 သို့ တန်ဖိုးကို အပ်ဒိတ်လုပ်သောအခါ၊ ပထမ entry သည် ဒုတိယနှင့် တတိယကြားတွင် အလိုအလျောက် “ရပ်” လိမ့်မည်။ ဤဖြေရှင်းချက်သည် အလုပ်လုပ်သော်လည်း ကန့်သတ်ချက်နှစ်ခုရှိသည်။ ပထမဦးစွာ၊ တန်ဘိုးကို အင်တာဖေ့စ်၏ တစ်နေရာရာတွင် အသုံးပြုပါက သင့်အတွက် အဆင်မပြေပါ။ ဒုတိယအချက်၊ ဒေတာအမျိုးအစား၏တိကျမှုပေါ်မူတည်၍ မှတ်တမ်းအားလုံး၏တန်ဖိုးများကို ပြန်လည်မတွက်ချက်မီ ဖြစ်နိုင်သောထည့်သွင်းမှုအရေအတွက် အကန့်အသတ်ရှိမည်ဖြစ်သည်။

ရွေးချယ်မှု ၃- ကန့်သတ်ချက်ကို ရွှေ့ဆိုင်းထားရန်၊ ကတိက၀တ်ပြုသည့်အချိန်တွင်သာ စစ်ဆေးရန်၊

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

ကျွန်ုပ်တို့၏ ကနဦးတောင်းဆိုချက်၏ ယုတ္တိဗေဒသည် ကတိကဝတ်ပြုချိန်တွင် တန်ဖိုးများအားလုံးသည် ထူးခြားကြောင်း သေချာစေသောကြောင့်၊ ၎င်းသည် အောင်မြင်လိမ့်မည်။

အထက်တွင်ဖော်ပြထားသော ဥပမာသည် ပေါင်းစပ်ဖွဲ့စည်းမှုဖြစ်သည်၊ သို့သော် ၎င်းသည် စိတ်ကူးကိုဖော်ပြသည်။ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းတွင်၊ အသုံးပြုသူများသည် ဘုတ်ပေါ်တွင် မျှဝေထားသော ဝစ်ဂျက်အရာဝတ္ထုများနှင့် တစ်ပြိုင်နက် လုပ်ဆောင်သည့်အခါ ပဋိပက္ခများကို ဖြေရှင်းရန် တာဝန်ရှိသော ယုတ္တိဗေဒကို အကောင်အထည်ဖော်ရန် ရွှေ့ဆိုင်းကန့်သတ်ချက်များကို အသုံးပြုပါသည်။ ထိုကန့်သတ်ချက်များကို အသုံးပြုခြင်းဖြင့် ကျွန်ုပ်တို့သည် အပလီကေးရှင်းကုဒ်ကို အနည်းငယ်ရိုးရှင်းအောင် ပြုလုပ်နိုင်စေပါသည်။

ယေဘုယျအားဖြင့်၊ ကန့်သတ်အမျိုးအစားပေါ်မူတည်၍ Postgres တွင် ၎င်းတို့ကိုစစ်ဆေးရန်အတွက် အသေးစိတ်အဆင့်သုံးဆင့်ရှိသည်- အတန်း၊ ငွေပေးငွေယူနှင့် ဖော်ပြမှုအဆင့်များ။

source: begriffs

CHECK နှင့် NOT NULL ကို အတန်းအဆင့်တွင် အမြဲတမ်းစစ်ဆေးသည်၊ ဇယားမှတွေ့မြင်နိုင်သကဲ့သို့ အခြားသောကန့်သတ်ချက်များအတွက်၊ ရွေးချယ်စရာအမျိုးမျိုးရှိပါသည်။ စာများများဖတ်လို့ရတယ်။ ဒီမှာ.

အတိုချုံးချုပ်ရန်၊ အခြေအနေများစွာတွင် ရွှေ့ဆိုင်းထားသော ကန့်သတ်ချက်များသည် ပိုမိုဖတ်ရှုနိုင်သော ကုဒ်များနှင့် ညွှန်ကြားချက်များ နည်းပါးသည်။ သို့သော်၊ အမှားအယွင်းဖြစ်ပေါ်ပြီး သင်သိရှိလာသည့်အခိုက်အတန့်အချိန်၌ ကွဲကွာသွားသောကြောင့် အမှားရှာပြင်ခြင်းလုပ်ငန်းစဉ်ကို ရှုပ်ထွေးစေခြင်းဖြင့် ၎င်းအတွက် သင်ပေးဆပ်ရမည်ဖြစ်သည်။ နောက်ထပ်ဖြစ်နိုင်ချေရှိသော ပြဿနာမှာ အစီအစဉ်ဆွဲသူသည် တောင်းဆိုချက်တွင် ရွှေ့ဆိုင်းကန့်သတ်ချက်တစ်ခုပါ၀င်ပါက အချိန်ဇယားဆွဲသူသည် အကောင်းဆုံးအစီအစဉ်တစ်ခုကို တည်ဆောက်နိုင်မည်မဟုတ်ပေ။

pg_repack ၏တိုးတက်မှု

ရွှေ့ဆိုင်းထားသော ကန့်သတ်ချက်များကို ကျွန်ုပ်တို့ ခြုံငုံထားပြီးဖြစ်သော်လည်း ၎င်းတို့သည် ကျွန်ုပ်တို့၏ပြဿနာနှင့် မည်သို့ဆက်စပ်သနည်း။ စောစောကရရှိခဲ့တဲ့ အမှားကို သတိရကြရအောင်။

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

မှတ်တမ်းဇယားမှ ဇယားအသစ်သို့ ဒေတာကို ကူးယူသောအခါ ဖြစ်ပေါ်သည်။ ဒါက ထူးဆန်းနေလို့... မှတ်တမ်းဇယားရှိ ဒေတာကို အရင်းအမြစ်ဇယားရှိ ဒေတာနှင့်အတူ ကတိပြုပါသည်။ မူလဇယား၏ ကန့်သတ်ချက်များကို ကျေနပ်ပါက၊ အသစ်တွင် တူညီသောကန့်သတ်ချက်များကို မည်သို့ချိုးဖောက်နိုင်မည်နည်း။

ထွက်လာသည့်အတိုင်း၊ ပြဿနာ၏အရင်းမြစ်မှာ pg_repack ၏ ယခင်အဆင့်တွင်ဖြစ်ပြီး၊ အညွှန်းများကိုသာဖန်တီးပေးသော်လည်း ကန့်သတ်ချက်များမဟုတ်ပါ- ဇယားဟောင်းတွင် ထူးခြားသောကန့်သတ်ချက်တစ်ခုရှိကာ အသစ်ကမူထူးခြားသောအညွှန်းကိုဖန်တီးခဲ့သည်။

ကန့်သတ်ချက်သည် ပုံမှန်ဖြစ်ပြီး ရွှေ့ဆိုင်းခြင်းမရှိပါက၊ ၎င်းအစား ဖန်တီးထားသော ထူးခြားသောအညွှန်းသည် ဤကန့်သတ်ချက်နှင့် ညီမျှသောကြောင့် ဤနေရာတွင် မှတ်သားထားရန် အရေးကြီးပါသည်။ Postgres ရှိ သီးသန့်ကန့်သတ်ချက်များကို သီးသန့်အညွှန်းတစ်ခုဖန်တီးခြင်းဖြင့် အကောင်အထည်ဖော်ပါသည်။ သို့သော် ရွှေ့ဆိုင်းကန့်သတ်မှုတစ်ခုအတွက်၊ အညွှန်းကိန်းကို ရွှေ့ဆိုင်း၍မရသည့်အပြင် sql အမိန့်ကို လုပ်ဆောင်သည့်အချိန်တွင် အမြဲတမ်းစစ်ဆေးနေသောကြောင့် အပြုအမူသည် တူညီမည်မဟုတ်ပါ။

ထို့ကြောင့်၊ ပြဿနာ၏အနှစ်သာရမှာ check ၏ "နှောင့်နှေး" တွင် တည်ရှိသည်- မူရင်းဇယားတွင် ၎င်းသည် commit လုပ်သည့်အချိန်တွင် ဖြစ်ပေါ်ပြီး sql command ကို လုပ်ဆောင်သည့်အချိန်တွင် ဇယားအသစ်တွင်ဖြစ်သည်။ ဆိုလိုသည်မှာ စစ်ဆေးမှုနှစ်ခုစလုံးတွင် အလားတူလုပ်ဆောင်ကြောင်း သေချာစေရန် လိုအပ်သည်- အမြဲတမ်းနှောင့်နှေးခြင်း သို့မဟုတ် အမြဲတမ်းချက်ခြင်းဖြစ်စေရန် လိုအပ်သည်။

ဒါဆို ငါတို့မှာ ဘာစိတ်ကူးတွေရှိလဲ။

ကျာင်းတူအညွှန်းတစ်ခု ဖန်တီးပါ။

ပထမအကြံမှာ စစ်ဆေးချက်နှစ်ခုလုံးကို ချက်ချင်းမုဒ်တွင် လုပ်ဆောင်ရန်ဖြစ်သည်။ ၎င်းသည် မှားယွင်းသော အပြုသဘောဆောင်သည့် ကန့်သတ်ချက်များ အများအပြားကို ထုတ်ပေးနိုင်သော်လည်း ၎င်းတို့ထဲမှ အနည်းငယ်သာရှိပါက၊ ထိုသို့သော ပဋိပက္ခများသည် ၎င်းတို့အတွက် ပုံမှန်အခြေအနေဖြစ်သောကြောင့်၊ ၎င်းသည် အသုံးပြုသူများ၏ လုပ်ငန်းကို မထိခိုက်စေသင့်ပါ။ ဥပမာအားဖြင့်၊ အသုံးပြုသူနှစ်ဦးသည် တူညီသောဝစ်ဂျက်ကို တစ်ချိန်တည်းတည်းဖြတ်ခြင်းစတင်သည့်အခါ၊ ဒုတိယအသုံးပြုသူ၏ client သည် ပထမအသုံးပြုသူမှ တည်းဖြတ်ရန်အတွက် ဝစ်ဂျက်ကို ပိတ်ဆို့ထားပြီးဖြစ်သည့် အချက်အလက်ကို လက်ခံရရှိရန် အချိန်မရှိပါ။ ထိုသို့သောအခြေအနေမျိုးတွင်၊ ဆာဗာသည် ဒုတိယအသုံးပြုသူကို ငြင်းပယ်ပြီး ၎င်း၏ဖောက်သည်သည် အပြောင်းအလဲများကို ပြန်သိမ်းကာ ဝစ်ဂျက်ကို ပိတ်ဆို့သည်။ ခဏအကြာ၊ ပထမအသုံးပြုသူသည် တည်းဖြတ်မှုပြီးသွားသောအခါ၊ ဒုတိယသည် ဝစ်ဂျက်ကို ပိတ်ဆို့ထားခြင်းမရှိတော့သည့် အချက်အလက်များကို လက်ခံရရှိမည်ဖြစ်ပြီး ၎င်းတို့၏လုပ်ဆောင်ချက်ကို ပြန်လည်လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။

စစ်ဆေးမှုများသည် ရွှေ့ဆိုင်းခြင်းမရှိသည့်မုဒ်တွင် အမြဲရှိနေကြောင်း သေချာစေရန်၊ ကျွန်ုပ်တို့သည် မူလရွှေ့ဆိုင်းထားသော ကန့်သတ်ချက်နှင့် ဆင်တူသော အညွှန်းအသစ်တစ်ခုကို ဖန်တီးခဲ့သည်-

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

စမ်းသပ်မှုပတ်ဝန်းကျင်တွင်၊ ကျွန်ုပ်တို့သည် မျှော်လင့်ထားသည့် အမှားအယွင်းအနည်းငယ်မျှသာ ရရှိခဲ့သည်။ အောင်မြင် ကျွန်ုပ်တို့သည် pg_repack ကို ထုတ်လုပ်မှုတွင် ထပ်မံလုပ်ဆောင်ပြီး အလုပ်ချိန်တစ်နာရီအတွင်း ပထမအစုတွင် အမှားအယွင်း ၅ ခု ရခဲ့သည်။ ဤသည်မှာ လက်ခံနိုင်သောရလဒ်တစ်ခုဖြစ်သည်။ သို့သော်၊ ဒုတိယအစုအဝေးတွင်ရှိပြီးသား အမှားအယွင်းအရေအတွက် သိသိသာသာတိုးလာပြီး pg_repack ကို ရပ်တန့်ခဲ့ရသည်။

ဘာကြောင့်ဖြစ်တာလဲ။ အမှားအယွင်းတစ်ခု ဖြစ်ပွားနိုင်ခြေသည် တူညီသောဝစ်ဂျက်များနှင့် တစ်ပြိုင်နက်တည်းတွင် အသုံးပြုသူ မည်မျှအလုပ်လုပ်သည်အပေါ် မူတည်ပါသည်။ ထင်ရှားသည်မှာ၊ ထိုအချိန်တွင် ပထမအစုတွင် သိမ်းဆည်းထားသည့် ဒေတာနှင့် ပြိုင်ဆိုင်မှုများစွာ လျော့နည်းသွားသည်မှာ အခြားအရာများထက်၊ ဆိုလိုသည်မှာ၊ ငါတို့က "ကံကောင်းတယ်" ပဲ။

အကြံက အလုပ်မဖြစ်ဘူး။ ထိုအချိန်တွင်၊ ကျွန်ုပ်တို့သည် အခြားဖြေရှင်းချက်နှစ်ခုကို တွေ့ခဲ့သည်- ရွှေ့ဆိုင်းထားသော ကန့်သတ်ချက်များကို ပေးဆောင်ရန် ကျွန်ုပ်တို့၏ အပလီကေးရှင်းကုဒ်ကို ပြန်ရေးပါ သို့မဟုတ် ၎င်းတို့နှင့် အလုပ်လုပ်ရန် "သင်ပေး" pg_repack။ ကျွန်တော်တို့ ဒုတိယတစ်ခုကို ရွေးလိုက်တယ်။

မူရင်းဇယားမှ ရွှေ့ဆိုင်းထားသော ကန့်သတ်ချက်များဖြင့် ဇယားအသစ်ရှိ အညွှန်းများကို အစားထိုးပါ။

ပြန်လည်ပြင်ဆင်ခြင်း၏ ရည်ရွယ်ချက်မှာ ထင်ရှားသည် - မူလဇယားတွင် ရွှေ့ဆိုင်းကန့်သတ်ချက်တစ်ခုရှိနေပါက၊ အသစ်တစ်ခုအတွက် သင်သည် အညွှန်းတစ်ခုမဟုတ်ဘဲ ကန့်သတ်ချက်တစ်ခုဖန်တီးရန် လိုအပ်သည်။

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို စမ်းသပ်ရန်အတွက် ရိုးရှင်းသောစမ်းသပ်မှုတစ်ခုကို ကျွန်ုပ်တို့ရေးသားခဲ့သည်-

• ရွှေ့ဆိုင်းကန့်သတ်ချက်တစ်ခုပါရှိသော ဇယား၊
• ရှိပြီးသား မှတ်တမ်းတစ်ခုနှင့် ကွဲလွဲနေသော ကွင်းဆက်တစ်ခုတွင် ဒေတာကို ထည့်သွင်းပါ။
• အပ်ဒိတ်လုပ်ပါ - ဒေတာ ကွဲလွဲမှုမရှိတော့ပါ။
• အပြောင်းအလဲများကိုလုပ်ဆောင်ပါ။

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

pg_repack ၏မူရင်းဗားရှင်းသည် ပထမထည့်သွင်းမှုတွင် အမြဲပျက်သွားသည်၊ ပြုပြင်ထားသောဗားရှင်းသည် အမှားအယွင်းမရှိဘဲ အလုပ်လုပ်သည်။ မိုက်တယ်။

ကျွန်ုပ်တို့သည် ထုတ်လုပ်ရေးသို့သွားကာ မှတ်တမ်းဇယားမှ အချက်အလက်အသစ်တစ်ခုသို့ ကူးယူခြင်း၏တူညီသောအဆင့်တွင် အမှားတစ်ခု ထပ်မံရရှိသည်-

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ဂန္တဝင်အခြေအနေ- အရာအားလုံးသည် စမ်းသပ်မှုပတ်ဝန်းကျင်တွင် အဆင်ပြေသော်လည်း ထုတ်လုပ်မှုတွင် မဟုတ်ပါ။

APPLY_COUNT နှင့် အသုတ်နှစ်ခု၏ လမ်းဆုံ

ကျွန်ုပ်တို့သည် ကုဒ်ကို စာကြောင်းတစ်ကြောင်းချင်း ခွဲခြမ်းစိတ်ဖြာရန် စတင်ခဲ့ပြီး အရေးကြီးသောအချက်ကို ရှာဖွေတွေ့ရှိခဲ့သည်- ဒေတာများကို မှတ်တမ်းဇယားမှ အတွဲလိုက်အသစ်တစ်ခုသို့ လွှဲပြောင်းသည်၊ APPLY_COUNT ကိန်းသေက အသုတ်၏အရွယ်အစားကို ဖော်ပြသည်-

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

ပြဿနာမှာ လည်ပတ်မှုအများအပြားသည် ကန့်သတ်ချက်ကို ချိုးဖောက်နိုင်ချေရှိသည့် မူလငွေပေးငွေယူမှ ဒေတာကို လွှဲပြောင်းသည့်အခါတွင် အသုတ်နှစ်ခု၏ လမ်းဆုံတွင် အဆုံးသတ်နိုင်သည် - ညွှန်ကြားချက်တစ်ဝက်ကို ပထမအသုတ်တွင် ကျူးလွန်မည်ဖြစ်ပြီး ကျန်တစ်ဝက်ကို၊ ဒုတိယ၌။ ဤတွင်၊ သင်၏ကံအပေါ်မူတည်၍ ပထမအသုတ်တွင် အသင်းများသည် မည်သည့်အရာကိုမျှ မချိုးဖောက်ပါက၊ အားလုံးအဆင်ပြေသော်လည်း ၎င်းတို့ပြုလုပ်ပါက အမှားအယွင်းဖြစ်သွားသည်။

APPLY_COUNT သည် 1000 မှတ်တမ်းများနှင့် ညီမျှသည်၊ ၎င်းသည် ကျွန်ုပ်တို့၏စစ်ဆေးမှုများ အဘယ်ကြောင့် အောင်မြင်ကြောင်း ရှင်းပြသည် - ၎င်းတို့သည် “batch junction” ကိစ္စအား အကျုံးမဝင်ပါ။ ကျွန်ုပ်တို့သည် ညွှန်ကြားချက်နှစ်ခုကို အသုံးပြုသည် - ထည့်သွင်းခြင်းနှင့် အပ်ဒိတ်လုပ်ခြင်း ဖြစ်သောကြောင့် အမိန့်နှစ်ခု၏ ငွေပေးငွေယူ 500 အတိအကျကို တစ်သုတ်တွင် အမြဲထားရှိခဲ့ပြီး မည်သည့်ပြဿနာမျှ မတွေ့ကြုံခဲ့ရပါ။ ဒုတိယအပ်ဒိတ်ကို ပေါင်းထည့်ပြီးနောက်၊ ကျွန်ုပ်တို့၏တည်းဖြတ်မှုသည် အလုပ်မလုပ်တော့ပါ။

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

ထို့ကြောင့်၊ နောက်ထပ်လုပ်ဆောင်ရမည့်တာဝန်မှာ ငွေပေးငွေယူတစ်ခုတွင် ပြောင်းလဲထားသည့် မူရင်းဇယားမှဒေတာများသည် ဇယားအသစ်တွင် အရောင်းအ၀ယ်တစ်ခုအတွင်း၌လည်း ပြီးဆုံးကြောင်း သေချာစေရန်ဖြစ်သည်။

သုတ်လိမ်းခြင်းမှ ငြင်းဆန်ခြင်း။

နောက်တဖန် ကျွန်ုပ်တို့တွင် ဖြေရှင်းချက်နှစ်ခုရှိသည်။ ပထမဦးစွာ- အစုလိုက်အပိုင်းခွဲခြင်းကို လုံးဝစွန့်လွှတ်ပြီး အရောင်းအ၀ယ်တစ်ခုတွင် ဒေတာလွှဲပြောင်းကြပါစို့။ ဤဖြေရှင်းချက်၏အားသာချက်မှာ၎င်း၏ရိုးရှင်းမှုဖြစ်သည် - လိုအပ်သောကုဒ်အပြောင်းအလဲများသည်အနည်းငယ်မျှသာဖြစ်သည် (စကားအားဖြင့်၊ pg_reorg ဗားရှင်းအဟောင်းများတွင်ထိုကဲ့သို့အလုပ်လုပ်သည်)။ သို့သော် ပြဿနာတစ်ခုရှိသည် - ကျွန်ုပ်တို့သည် နှစ်ရှည်လများ ငွေပေးငွေယူကို ဖန်တီးနေပြီး ၎င်းသည် ယခင်ကပြောခဲ့သည့်အတိုင်း ဖောင်းပွမှုအသစ်တစ်ခု ပေါ်ပေါက်လာစေရန် ခြိမ်းခြောက်မှုတစ်ခုဖြစ်သည်။

ဒုတိယဖြေရှင်းချက်သည် ပိုမိုရှုပ်ထွေးသော်လည်း ပိုမှန်နိုင်သည်- ဇယားတွင် ဒေတာများထည့်ထားသည့် ငွေပေးငွေယူ၏ identifier ဖြင့် ကော်လံတစ်ခုကို ဖန်တီးပါ။ ထို့နောက် ကျွန်ုပ်တို့သည် ဒေတာကို ကူးယူသည့်အခါ၊ ၎င်းကို ဤ attribute ဖြင့် အုပ်စုဖွဲ့နိုင်ပြီး ဆက်စပ်ပြောင်းလဲမှုများကို အတူတကွ လွှဲပြောင်းကြောင်း သေချာစေပါသည်။ အစုလိုက်သည် ငွေပေးငွေယူများစွာ (သို့မဟုတ် အကြီးကြီးတစ်ခု) မှ ဖွဲ့စည်းမည်ဖြစ်ပြီး ၎င်းသည် ဤလွှဲပြောင်းမှုများတွင် ဒေတာမည်မျှပြောင်းလဲခဲ့သည်ပေါ်မူတည်၍ ၎င်း၏အရွယ်အစား ကွဲပြားမည်ဖြစ်သည်။ မတူညီသော ငွေပေးငွေယူများမှ ဒေတာများသည် ကျပန်းအစီအစဥ်ဖြင့် မှတ်တမ်းဇယားထဲသို့ ဝင်ရောက်လာသောကြောင့် ယခင်ကကဲ့သို့ ဆက်တိုက်ဖတ်ရန် မဖြစ်နိုင်တော့ကြောင်း သတိပြုရန် အရေးကြီးပါသည်။ tx_id ဖြင့် စစ်ထုတ်ခြင်းဖြင့် တောင်းဆိုမှုတစ်ခုစီအတွက် seqscan သည် စျေးကြီးလွန်းသည်၊ အညွှန်းတစ်ခု လိုအပ်သော်လည်း ၎င်းကို အပ်ဒိတ်လုပ်ခြင်း၏ overhead ကြောင့် နည်းလမ်းကိုလည်း နှေးကွေးစေမည်ဖြစ်သည်။ ယေဘူယျအားဖြင့်၊ အမြဲလိုလို၊ သင်သည် တစ်စုံတစ်ခုကို စွန့်လွှတ်ရန် လိုအပ်သည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ပိုမိုရိုးရှင်းသောကြောင့် ပထမရွေးချယ်မှုဖြင့် စတင်ရန် ဆုံးဖြတ်ခဲ့သည်။ ပထမဦးစွာ၊ ရှည်လျားသောငွေပေးငွေယူသည် တကယ့်ပြဿနာဟုတ်မဟုတ် နားလည်ရန် လိုအပ်ပါသည်။ ဇယားဟောင်းမှ ဒေတာအသစ်သို့ ပင်မလွှဲပြောင်းခြင်းသည် ရှည်လျားသော ငွေပေးငွေယူတစ်ခုတွင် ဖြစ်ပေါ်သောကြောင့်၊ "ဤငွေပေးငွေယူကို ကျွန်ုပ်တို့မည်မျှတိုးမြှင့်မည်နည်း" အဖြစ်သို့ ပြောင်းလဲသွားပါသည်။ ပထမ ငွေပေးငွေယူ၏ ကြာချိန်သည် ဇယား၏ အရွယ်အစားပေါ်တွင် အဓိက မူတည်ပါသည်။ အသစ်တစ်ခု၏ကြာချိန်သည် ဒေတာလွှဲပြောင်းမှုအတွင်း ဇယားတွင် အပြောင်းအလဲမည်မျှစုပုံနေသနည်း၊ ဆိုလိုသည်မှာ၊ ဝန်၏ပြင်းထန်မှုအပေါ်။ pg_repack လည်ပတ်မှုသည် အနည်းငယ်မျှသာ ဝန်ဆောင်မှုပေးသည့်အချိန်အတွင်း ဖြစ်ပွားခဲ့ပြီး အပြောင်းအလဲများ၏ ပမာဏသည် ဇယား၏မူလအရွယ်အစားနှင့် နှိုင်းယှဉ်ပါက အချိုးအစားမမျှပေ။ ငွေပေးငွေယူအသစ်တစ်ခု၏အချိန်ကို လျစ်လျူရှုနိုင်သည်ဟု ကျွန်ုပ်တို့ဆုံးဖြတ်ခဲ့သည် (နှိုင်းယှဉ်ရန်အတွက် ပျမ်းမျှအားဖြင့် 1 နာရီနှင့် 2-3 မိနစ်ဖြစ်သည်)။

စမ်းသပ်မှုတွေက အပြုသဘောဆောင်တယ်။ ထုတ်လုပ်မှုကိုလည်း စတင်ပါ။ ရှင်းရှင်းလင်းလင်းသိရန်၊ ဤနေရာတွင် လုပ်ဆောင်ပြီးနောက် ဒေတာဘေ့စ်တစ်ခု၏ အရွယ်အစားနှင့် ပုံတစ်ပုံဖြစ်သည်-

ဤဖြေရှင်းချက်ကို ကျွန်ုပ်တို့ လုံး၀ ကျေနပ်အားရသောကြောင့်၊ ကျွန်ုပ်တို့သည် ဒုတိယတစ်ခုကို အကောင်အထည် ဖော်ရန် မကြိုးစားဘဲ၊ ၎င်းကို extension developer များနှင့် ဆွေးနွေးရန် ဖြစ်နိုင်ခြေကို ကျွန်ုပ်တို့ စဉ်းစားနေပါသည်။ ကျွန်ုပ်တို့၏ လက်ရှိတည်းဖြတ်မှုမှာ ကံမကောင်းစွာဖြင့်၊ ကျွန်ုပ်တို့သည် ထူးခြားသောရွှေ့ဆိုင်းကန့်သတ်မှုများဖြင့် ပြဿနာကို ဖြေရှင်းပြီး ပြည့်စုံသော patch တစ်ခုအတွက် အခြားအမျိုးအစားများအတွက် ပံ့ပိုးမှုပေးရန် လိုအပ်သောကြောင့် ကျွန်ုပ်တို့၏ လက်ရှိပြန်လည်ပြင်ဆင်မှုကို ထုတ်ဝေရန်အတွက် အဆင်သင့်မဖြစ်သေးပါ။ အနာဂတ်မှာ ဒါကို လုပ်နိုင်မယ်လို့ ကျွန်တော်တို့ မျှော်လင့်ပါတယ်။

သင့်တွင်မေးခွန်းတစ်ခုရှိသည်၊ pg_repack ၏မွမ်းမံမှုနှင့်အတူကျွန်ုပ်တို့သည်အဘယ်ကြောင့်ဤဇာတ်လမ်းတွင်ပါ ၀ င်သနည်း၊ ဥပမာအားဖြင့်၎င်း၏ analogues များကိုမသုံးခဲ့ပါ။ တစ်ချိန်ချိန်တွင် ကျွန်ုပ်တို့လည်း ၎င်းကို စဉ်းစားခဲ့ကြသော်လည်း အစောပိုင်းက ၎င်းကို အသုံးပြုခြင်း၏ အပြုသဘောဆောင်သော အတွေ့အကြုံသည် ရွှေ့ဆိုင်းကန့်သတ်မှုများမရှိဘဲ စားပွဲများပေါ်တွင် ပြဿနာ၏အနှစ်သာရကို နားလည်ပြီး ဖြေရှင်းရန် ကြိုးစားရန် ကျွန်ုပ်တို့ကို လှုံ့ဆော်ပေးခဲ့သည်။ ထို့အပြင်၊ အခြားဖြေရှင်းနည်းများကိုအသုံးပြု၍ စမ်းသပ်မှုများပြုလုပ်ရန်လည်း အချိန်လိုအပ်သည်၊ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ၎င်းတွင်ရှိသောပြဿနာကို ဦးစွာဖြေရှင်းရန်ကြိုးစားရန် ဆုံးဖြတ်ခဲ့ပြီး သင့်လျော်သောအချိန်အတွင်း ကျွန်ုပ်တို့မလုပ်ဆောင်နိုင်ကြောင်း သိရှိပါက၊ ထို့နောက် analogues များကို စတင်ကြည့်ရှုမည်ဖြစ်သည်။ .

တွေ့ရှိချက်များ

ကျွန်ုပ်တို့၏ကိုယ်ပိုင်အတွေ့အကြုံအပေါ်အခြေခံ၍ ကျွန်ုပ်တို့အကြံပြုနိုင်သည်-

1. သင့်ဝမ်းဗိုက်ကို စောင့်ကြည့်ပါ။ စောင့်ကြည့်ဒေတာအပေါ် အခြေခံ၍ autovacuum ကို မည်ကဲ့သို့ ကောင်းစွာ configure လုပ်ထားသည်ကို သင်နားလည်နိုင်သည်။
2. လက်ခံနိုင်သောအဆင့်တွင် ဖောင်းနေစေရန် AUTOVACUUM ကို ချိန်ညှိပါ။
3. ဖောင်းနေသေးသည်နှင့် ပြင်ပကိရိယာများကို အသုံးပြု၍ မကျော်လွှားနိုင်ပါက ပြင်ပ extension များကို အသုံးပြုရန် မကြောက်ပါနှင့်။ အဓိကကတော့ အရာအားလုံးကို ကောင်းကောင်းစမ်းသပ်ဖို့ပါပဲ။
4. သင့်လိုအပ်ချက်များနှင့်ကိုက်ညီမည့် ပြင်ပဖြေရှင်းချက်များကို မွမ်းမံပြင်ဆင်ရန် မကြောက်ပါနှင့် - တစ်ခါတစ်ရံ ၎င်းသည် သင့်ကိုယ်ပိုင်ကုဒ်ကို ပြောင်းလဲခြင်းထက်ပင် ပိုမိုထိရောက်ပြီး လွယ်ကူနိုင်သည်။

source: www.habr.com