PostgreSQL Antipatterns- "သေ" ၏အလုံးအရင်းကိုတိုက်ခိုက်သည်။

PostgreSQL ၏အတွင်းပိုင်းယန္တရားများ၏ထူးခြားချက်များသည်အချို့သောအခြေအနေများတွင်အလွန်မြန်ရန်နှင့်အခြားသူများတွင် "အလွန်မြန်သည်" ကိုခွင့်ပြုသည်။ ယနေ့ကျွန်ုပ်တို့သည် DBMS အလုပ်လုပ်ပုံနှင့် developer နှင့် ၎င်းနှင့်ပြုလုပ်သည့် ပဋိပက္ခကြားရှိ ဂန္တဝင်နမူနာတစ်ခုအား အာရုံစိုက်ပါမည်။ UPDATE vs MVCC အခြေခံမူများ.

ဇာတ်လမ်းအကျဉ်း ဆောင်းပါးကောင်း:

အတန်းတစ်ခုကို UPDATE အမိန့်ဖြင့် မွမ်းမံသောအခါ၊ လုပ်ဆောင်ချက်နှစ်ခုကို အမှန်တကယ်လုပ်ဆောင်သည်- DELETE နှင့် INSERT။ IN string ၏လက်ရှိဗားရှင်း xmax သည် UPDATE ကိုလုပ်ဆောင်သော ငွေပေးငွေယူ အရေအတွက်နှင့် ညီမျှသည်။ ထို့နောက် ဖန်တီးသည်။ ဗားရှင်းအသစ် တူညီသောလိုင်း; ၎င်း၏ xmin တန်ဖိုးသည် ယခင်ဗားရှင်း၏ xmax တန်ဖိုးနှင့် တိုက်ဆိုင်နေသည်။

ဤငွေလွှဲပြောင်းမှုပြီးသွားပြီးနောက် အချိန်အတန်ကြာတွင်၊ ဗားရှင်းအဟောင်း သို့မဟုတ် ဗားရှင်းအသစ်ပေါ်မူတည်သည်။ COMMIT/ROOLBACK, အသိအမှတ်ပြုလိမ့်မည်။ "သေ" (အသေကောင်များ) ဖြတ်သန်းတဲ့အခါ VACUUM ဇယားအတိုင်းရှင်းလင်းပါ။

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

နံပါတ် 1: ရွှေ့ရတာကြိုက်တယ်။

သင့်နည်းလမ်းသည် စီးပွားရေးဆိုင်ရာ ယုတ္တိဗေဒအရ လုပ်ဆောင်နေသည်ဟု ဆိုကြပါစို့၊ အချို့သော မှတ်တမ်းများတွင် X အကွက်ကို အပ်ဒိတ်လုပ်ရန် လိုအပ်မည်ဖြစ်ကြောင်း ရုတ်တရက် သဘောပေါက်သွားသည်-

UPDATE tbl SET X = <newX> WHERE pk = $1;

ထို့နောက်၊ လုပ်ဆောင်မှု တိုးတက်လာသည်နှင့်အမျှ Y အကွက်ကိုလည်း မွမ်းမံသင့်သည်-

UPDATE tbl SET Y = <newY> WHERE pk = $1;

ပြီးတော့ Z - ဘာကြောင့် အသေးအဖွဲလေးတွေနဲ့ အချိန်ဖြုန်းနေတာလဲ။

UPDATE tbl SET Z = <newZ> WHERE pk = $1;

ယခု ကျွန်ုပ်တို့ဒေတာဘေ့စ်တွင် ဤမှတ်တမ်းဗားရှင်းမည်မျှရှိသနည်း။ ဟုတ်တယ်၊ 4 ခု။ ယင်းတို့အနက် တစ်ခုသည် သက်ဆိုင်ရာဖြစ်ပြီး၊ 3 ကို [အလိုအလျောက်]VACUUM ဖြင့် ရှင်းထုတ်ရပါမည်။

ဒီနည်းနဲ့ မလုပ်ပါနဲ့! သုံးပါ။ တောင်းဆိုချက်တစ်ခုတည်းတွင် အကွက်အားလုံးကို အပ်ဒိတ်လုပ်ခြင်း။ - နည်းလမ်း၏ယုတ္တိကို အမြဲတမ်းလိုလို ဤကဲ့သို့ ပြောင်းလဲနိုင်သည်။

UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;

#2- ခြားနားချက်ကို အသုံးပြုပါ၊ လုကာ။

ဒါဆို မင်း လိုချင်နေသေးလား။ ဇယားတစ်ခုရှိ မှတ်တမ်းများစွာ၊ များစွာကို အပ်ဒိတ်လုပ်ပါ။ (ဥပမာ၊ script သို့မဟုတ် converter ကိုအသုံးပြုနေစဉ်)။ ပြီးတော့ ဒီဇာတ်ညွှန်းထဲကို ပျံသွားတာမျိုး၊

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;

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

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;

ဤကဲ့သို့ အံ့သြဖွယ် အော်ပရေတာ တည်ရှိမှုကို လူအတော်များများက မသိကြသောကြောင့် ဤနေရာတွင် လိမ်လည်လှည့်ဖြားမှုတစ်ခုဖြစ်သည်။ IS DISTINCT FROM ကူညီရန် အခြားယုတ္တိတန်သော အော်ပရေတာများနှင့်

... စစ်ဆင်ရေးနှင့်ပတ်သက်ပြီး အနည်းငယ်ရှုပ်ထွေးသည်။ ROW()- အသုံးအနှုန်းများ

#3 : ငါ့ချစ်သူကို... ပိတ်ဆို့ခြင်းအားဖြင့် ငါမှတ်မိတယ်။

စတင်ဆောင်ရွက်လျက်ရှိပါသည်။ တူညီသော မျဉ်းပြိုင်ဖြစ်စဉ်နှစ်ခု၊ တစ်ခုစီသည် ၎င်းသည် "လုပ်ဆောင်ဆဲ" ဖြစ်သည်ကို အမှတ်အသားပြုရန် ကြိုးစားသည်-

UPDATE tbl SET processing = TRUE WHERE pk = $1;

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

ဖြေရှင်းချက် # 1: လုပ်ဆောင်စရာကို ယခင်တစ်ခုသို့ လျှော့ချထားသည်။

ထပ်ထည့်လိုက်ရအောင် IS DISTINCT FROM:

UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;

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

ဖြေရှင်းချက် # 2: အကြံပေးသော့ခလောက်များ

သင်ဖတ်နိုင်သော သီးခြားဆောင်းပါးအတွက် ခေါင်းစဉ်ကြီးတစ်ခု လျှောက်လွှာတင်နည်းများနှင့် အကြံပြုချက်ပိတ်ဆို့ခြင်း၏ “ထွန်ခြစ်”.

ဖြေရှင်းချက် # 3: ငတုံးဖုန်းခေါ်ဆိုမှု

ဒါပေမယ့် ဒါက မင်းအတွက် ဖြစ်သင့်တဲ့အရာပါ။ တူညီသောမှတ်တမ်းနှင့်အတူတစ်ပြိုင်နက်အလုပ်လုပ်? သို့မဟုတ် ဥပမာအားဖြင့် client ဘက်မှ business logic ကိုခေါ်ရန်အတွက် algorithms များနှင့်ရှုပ်နေပါသလား။ တွေးကြည့်ရင်ကော..?

source: www.habr.com