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

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

ဇာတ်လမ်းအကျဉ်းမှ အလွန်ကောင်းတဲ့ဆောင်းပါး:

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

ဤငွေလွှဲပြောင်းမှုပြီးသွားပြီးနောက် အချိန်အတန်ကြာတွင်၊ ဗားရှင်းအဟောင်း သို့မဟုတ် ဗားရှင်းအသစ်ပေါ်မူတည်သည်။ COMMIT/ROOLBACK, အသိအမှတ်ပြုလိမ့်မည်။ အသေ tuples ဖြတ်သန်းတဲ့အခါ 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;

ယခု ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်တွင် ဤထည့်သွင်းမှုဗားရှင်းမည်မျှရှိသနည်း။ ဟုတ်တယ် လေး။ ၎င်းတို့ထဲမှ တစ်ခုသည် လက်ရှိဖြစ်ပြီး သုံးခုကို [အလိုအလျောက်]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 သည် "သော့ခတ်ခြင်း" ခံရမည်ဖြစ်ပါသည်။

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

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

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

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

ဖြေရှင်းချက် နံပါတ် ၁: အကြံပေးသော့ခလောက်များ

ဤသည်မှာ သီးခြားဆောင်းပါးတစ်ခုအတွက် ခေါင်းစဉ်ကြီးတစ်ခုဖြစ်ပြီး ၎င်းအကြောင်းကို သင်ဖတ်ရှုနိုင်ပါသည်။ အသုံးချနည်းများ နှင့် အကြံပေး ပိတ်ဆို့ခြင်း၏ ချို့ယွင်းချက်များ.

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

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

source: www.habr.com