ချစ်လှစွာသော DELETE။ Nikolay Samokhvalov (Postgres.ai)

ဝေးကွာသောအနာဂတ်တွင် တစ်ချိန်ချိန်တွင် မလိုအပ်သောဒေတာများကို အလိုအလျောက်ဖယ်ရှားခြင်းသည် DBMS [1] ၏အရေးကြီးသောအလုပ်များထဲမှတစ်ခုဖြစ်လိမ့်မည်။ ဤအတောအတွင်း၊ ကျွန်ုပ်တို့ကိုယ်တိုင် မလိုအပ်သောဒေတာများကို စျေးနည်းသော သိုလှောင်မှုစနစ်များသို့ ဖျက်ခြင်း သို့မဟုတ် ရွှေ့ခြင်းတို့ကို ဂရုစိုက်ရန် လိုအပ်ပါသည်။ သင်သည် အတန်း သန်းအနည်းငယ်ကို ဖျက်ရန် ဆုံးဖြတ်ခဲ့သည်ဆိုပါစို့။ အထူးသဖြင့် အခြေအနေများကိုသိရှိပြီး သင့်လျော်သောအညွှန်းတစ်ခုရှိလျှင် မျှမျှတတရိုးရှင်းသောအလုပ်တစ်ခုဖြစ်သည်။ "DELETE FROM table1 WHERE col1 = :value" - ဘယ်အရာက ပိုရိုးရှင်းနိုင်လဲ ဟုတ်တယ်ဟုတ်။

ဗီဒီယိုများ:

• ကျွန်ုပ်သည် ပထမနှစ်မှစ၍ Highload ပရိုဂရမ်ကော်မတီတွင် ပါဝင်ခဲ့သည်၊ ဆိုလိုသည်မှာ ၂၀၀၇ ခုနှစ်ကတည်းက ဖြစ်သည်။

• ပြီးတော့ ကျွန်တော် 2005 ခုနှစ်ကတည်းက Postgres နဲ့ အတူရှိခဲ့ပါတယ်။ ပရောဂျက်များစွာတွင် အသုံးပြုခဲ့သည်။

• RuPostges နှင့်လည်း 2007 ခုနှစ်ကတည်းက အဖွဲ့ဖွဲ့ခဲ့သည်။

• Meetup တွင် ပါဝင်သူ ၂၁၀၀ ကျော်အထိ တိုးလာပါသည်။ ဆန်ဖရန်စစ္စကိုကို အချိန်အတော်ကြာအောင် ကျော်တက်ခဲ့သော နယူးယောက်ပြီးလျှင် ကမ္ဘာပေါ်တွင် ဒုတိယမြောက်ဖြစ်သည်။

• ကယ်လီဖိုးနီးယားမှာ နှစ်အတော်ကြာနေခဲ့တယ်။ ကြီးကြီးမားမား အပါအဝင် အမေရိကန် ကုမ္ပဏီတွေနဲ့ ပိုဆက်ဆံတယ်။ ၎င်းတို့သည် Postgres ၏တက်ကြွစွာအသုံးပြုသူများဖြစ်သည်။ ပြီးတော့ စိတ်ဝင်စားစရာတွေ အမျိုးမျိုးရှိတယ်။

https://postgres.ai/ ငါ့ကုမ္ပဏီ ကျွန်ုပ်တို့သည် ဖွံ့ဖြိုးတိုးတက်မှု နှေးကွေးမှုကို ဖယ်ရှားပေးသည့် အလိုအလျောက်လုပ်ဆောင်သည့် လုပ်ငန်းများကို လုပ်ဆောင်နေပါသည်။

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

ကျွန်တော် မကြာသေးမီက Los Angeles ရှိ VLDB တွင်ရှိခဲ့သည်။ ဤသည်မှာ ဒေတာဘေ့စ်များဆိုင်ရာ အကြီးမားဆုံးညီလာခံဖြစ်သည်။ အနာဂတ်တွင် DBMS သည် သိမ်းဆည်းရုံသာမက ဒေတာများကိုလည်း အလိုအလျောက် ဖျက်ပစ်မည်ဖြစ်ကြောင်း အစီရင်ခံစာတစ်ခုရှိခဲ့သည်။ ဒါက ခေါင်းစဉ်အသစ်ပါ။

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

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

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

ပိုက်ဆံရေတွက်နိုင်တဲ့သူတွေက နှစ်ခုလိုချင်တယ်။ သူတို့က ကျွန်တော်တို့ကို ဖျက်စေချင်တဲ့အတွက် နည်းပညာပိုင်းအရ လုပ်နိုင်ရမယ်။

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

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

ယေဘူယျအားဖြင့်၊ အလုပ်မှာ အချို့သောဇယားရှိ သီးခြားအရာများ၊ တိကျသောလိုင်းများကို အလိုအလျောက်ဖျက်ရန်ဖြစ်သည်။

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

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

ဒေတာဘေ့စ်သည် ကြီးထွားပြီး ကြီးထွားလာသည်။ နေ့စဥ် DELETE သည် အနည်းငယ် ပိုနှေးကွေးစွာ စတင်အလုပ်လုပ်ပါသည်။

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

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

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

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

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

• ဥပမာအားဖြင့်၊ သုံးသပ်ချက်မရှိပါ၊ ဆိုလိုသည်မှာ DBA ကျွမ်းကျင်သူသည် ၎င်းကိုမကြည့်ဘဲ။ သူသည် အတွေ့အကြုံရှိသောမျက်လုံးဖြင့် ပြဿနာကိုချက်ချင်းတွေ့လိမ့်မည်၊ ထို့အပြင်၊ လိုင်းသန်းပေါင်းများစွာစုပုံနေသည့် prod ကိုဝင်ရောက်နိုင်သည်။

• တစ်ခုခု မှားနေသလားလို့ သူတို့ စစ်ဆေးခဲ့တာ ဖြစ်နိုင်တယ်။

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

• သို့မဟုတ် ဒေတာဘေ့စ်ကိုယ်နှိုက်တွင် တစ်ခုခုမှားယွင်းနေပြီး ကျွန်ုပ်တို့သည် Postgres မှ MySQL သို့ ရွှေ့ရန် လိုအပ်သည်။

• ဒါမှမဟုတ် ခွဲစိတ်မှုမှာ တစ်ခုခု မှားယွင်းနေတာမျိုး ဖြစ်နိုင်ပါတယ်။

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

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

ပြီးတော့ မင်း disk IO နဲ့ ပြဿနာရှိလိမ့်မယ်၊ လုပ်ငန်းစဉ်တွေအားလုံး ရူးသွပ်သွားလိမ့်မယ်၊ သော့တွေရှိနိုင်တယ်၊ ပြီးတော့ မင်းလည်း မိနစ်အနည်းငယ်ကြာအောင် autovacuum ကို ပိတ်ဆို့လိမ့်မယ်၊ ဒါကြောင့် ဒါက မကောင်းပါဘူး။

http://bit.ly/nancy-hl2018-2

ဒုတိယအမှား - သူတို့မှားတဲ့နေရာကို စစ်တယ်။ prod တွင် junk data အများအပြားစုဆောင်းမိကြောင်းကိုကျွန်ုပ်တို့တွေ့ခဲ့ရသည်၊ သို့သော် developer သည်ဤဒေတာဘေ့စ်တွင်စုဆောင်းထားသောဒေတာမရှိပါ၊ နှင့်ဇာတ်ခုံတွင်ဤအမှိုက်ကိုမည်သူမျှမဖန်တီးပါ။ ထို့ကြောင့်၊ လိုင်း ၁၀၀၀ သည် လျင်မြန်စွာ ပြီးစီးခဲ့သည်။

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

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

ကျွန်တော်တို့ရဲ့ စက်ပစ္စည်းက မကောင်းဘူးလား။ ကြည့်လျှင် latency ခုန်တက်သွားသည်။ 100% အသုံးချတာကို ကျွန်တော်တို့ တွေ့ခဲ့ရပါတယ်။ ဟုတ်ပါတယ်၊ ဒါတွေက ခေတ်မီ NVMe drive တွေဆိုရင်၊ အဲဒါက ကျွန်တော်တို့အတွက် အများကြီး ပိုလွယ်ပါလိမ့်မယ်။ ပြီးတော့ ငါတို့က အဲဒါကို လှဲနေမှာ မဟုတ်ဘူး။

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

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

စစ်ဆေးရေးဂိတ်ဆိုတာဘာလဲ။ ၎င်းသည် မည်သည့် DBMS တွင်မဆိုရှိသည်။ ပြောင်းလဲသွားတဲ့ Memory ထဲမှာ ဒေတာတွေ ရှိနေတဲ့အခါ၊ အဲဒါကို Disk မှာ ချက်ချင်းရေးလို့မရပါဘူး။ ဒေတာပြောင်းလဲသွားသော အချက်အလက်ကို ရေးမှတ်ထားသော မှတ်တမ်းတွင် ဦးစွာရေးသားပါသည်။ တစ်ချိန်ချိန်တွင်၊ DBMS သည် မှန်ကန်သောစာမျက်နှာများကို disk သို့ လွှင့်ပစ်ရန်အချိန်ရောက်ပြီဟု ဆုံးဖြတ်သည်၊ ထို့ကြောင့် ကျွန်ုပ်တို့တွင် ချို့ယွင်းမှုရှိပါက ကျွန်ုပ်တို့ REDO လျော့နည်းနိုင်မည်ဖြစ်သည်။ အရုပ်တစ်ခုလိုပါပဲ။ အသတ်ခံရပါက နောက်ဆုံးစစ်ဆေးရေးဂိတ်မှ ဂိမ်းကို စတင်ပါမည်။ ပြီးတော့ DBMS အားလုံးက အဲဒါကို အကောင်အထည်ဖော်တယ်။

Postgres ရှိ ဆက်တင်များသည် နောက်ကျကျန်နေပါသည်။ ၎င်းတို့ကို 10-15 နှစ်သက်တမ်းရှိ ဒေတာပမာဏများနှင့် အရောင်းအဝယ်များအတွက် ဒီဇိုင်းထုတ်ထားသည်။ ပြီးတော့ စစ်ဆေးရေးဂိတ်က ခြွင်းချက်မရှိပါဘူး။

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

ဘာကိုဆိုလိုတာလဲ? အဲဒီမှာ ဆက်တင်နှစ်ခုရှိတယ်။ ဥပမာအားဖြင့် ၁၀ မိနစ်တွင် စစ်ဆေးရေးဂိတ်သည် အချိန်ကုန်သွားနိုင်သည်။ ဒါမှမဟုတ် ဒေတာတွေ အများကြီး ဖြည့်ပြီးတဲ့အခါ ဖြစ်လာနိုင်တယ်။

ပုံမှန်အားဖြင့် max_wal_saze ကို 1 gigabyte ဟု သတ်မှတ်ထားသည်။ တကယ်တော့ ဒါဟာ 300-400 megabytes ပြီးနောက် Postgres မှာ တကယ်ဖြစ်ပျက်ပါတယ်။ သင်သည် ဒေတာများစွာကို ပြောင်းလဲခဲ့ပြီး သင်၏ စစ်ဆေးရေးဂိတ် ဖြစ်သွားပါသည်။

အကယ်၍ မည်သူမျှ ၎င်းကို ချိန်ညှိခြင်းမရှိပါက၊ ဝန်ဆောင်မှု တိုးလာကာ ကုမ္ပဏီသည် ငွေအမြောက်အမြားရရှိပါက၊ ၎င်းတွင် အရောင်းအ၀ယ်များစွာရှိပြီး၊ စစ်ဆေးရေးဂိတ်သည် တစ်မိနစ်လျှင် တစ်ကြိမ်၊ တစ်ခါတစ်ရံ စက္ကန့် 30 တိုင်းတိုင်း၊ တစ်ခါတစ်ရံ ထပ်နေပါသည်။ ဒါက တော်တော်ဆိုးတယ်။

မကြာခဏဆိုသလို လျော့နည်းလာကြောင်း သေချာရန် လိုအပ်ပါသည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် max_wal_size ကို မြှင့်တင်နိုင်သည်။ ပြီးတော့ ခဏခဏ လာလိမ့်မယ်။

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

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်များပေါ်တွင် စမ်းသပ်မှု နှစ်ခုကို လုပ်ဆောင်နေပါသည်။

ပထမစီးရီး - ကျွန်ုပ်တို့သည် max_wal_size ကိုပြောင်းသည်။ ပြီးတော့ ကြီးမားတဲ့ စစ်ဆင်ရေးတစ်ခု လုပ်နေတယ်။ ပထမဦးစွာ ကျွန်ုပ်တို့သည် ၎င်းကို 1 gigabyte ၏ ပုံသေဆက်တင်တွင် ပြုလုပ်သည်။ ပြီးတော့ လိုင်းသန်းပေါင်းများစွာကို အကြီးအကျယ် ဖျက်ပစ်လိုက်တယ်။

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

နောက်တစ်ခုကတော့ max_wal_size ကို တိုးမယ်။ ပြန်လုပ်တယ်။ တိုးတယ်၊ ထပ်လုပ်တယ်။ အကြိမ်များစွာ။ မူအရ၊ 10 မှတ်သည် 1၊ 2၊ 4၊ 8 ဂစ်ဂါဘိုက်ရှိရာ ကောင်းသည်။ ပြီးတော့ စနစ်တစ်ခုရဲ့ အပြုအမူကို ကြည့်တယ်။ ဤနေရာတွင် ပစ္စည်းကိရိယာသည် ထုတ်ကုန်ကဲ့သို့ ဖြစ်သင့်သည်မှာ ရှင်းပါသည်။ တူညီသောဒစ်များ၊ တူညီသောမှတ်ဉာဏ်ပမာဏနှင့် တူညီသော Postgres ဆက်တင်များ ရှိရပါမည်။

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

စစ်ဆေးရေးဂိတ်များသည် ရုရှားဘာသာဖြင့် စစ်ဆေးရေးဂိတ်များဖြစ်သည်။

ဥပမာ- အညွှန်းအားဖြင့် အတန်းပေါင်း သန်းပေါင်းများစွာကို ဖျက်ပါ၊ အတန်းများသည် စာမျက်နှာများပေါ်တွင် "ပြန့်ကျဲနေ" ပါသည်။

ဒါက ဥပမာတစ်ခုပါ။ ဒါက အခြေခံတစ်ခုပါ။ ထို့အပြင် max_wal_size အတွက် 1 gigabyte ၏ ပုံသေဆက်တင်ဖြင့်၊ ကျွန်ုပ်တို့၏ဒစ်များသည် အသံသွင်းရန်အတွက် စင်သို့သွားကြောင်း အလွန်ရှင်းလင်းပါသည်။ ဤပုံသည် အလွန်ဖျားနာသော လူနာတစ်ဦး၏ သာမာန် လက္ခဏာ ဖြစ်သည်၊ ဆိုလိုသည်မှာ သူသည် အမှန်တကယ်ပင် ဆိုးရွားနေပါသည်။ တစ်ခုတည်းသောလုပ်ဆောင်မှုတစ်ခုရှိ၍ လိုင်းသန်းပေါင်းများစွာကို ဖျက်လိုက်ရုံသာရှိသေးသည်။

အကယ်၍ ဤကဲ့သို့ ခွဲစိတ်မှုအား ပရော့ဒ်ဖြင့် ခွင့်ပြုပါက၊ DELETE တစ်ဦးသည် ကျွန်ုပ်တို့အား တပ်ရင်းတွင် သတ်ပစ်ကြောင်း ထင်ရှားသောကြောင့် ကျွန်ုပ်တို့ လှဲလျောင်းနေပါမည်။

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

64 gigabytes သည် လုံးဝ ပိုကောင်းလာသည်ကို တွေ့နိုင်သည်။ သွားများသည် အသံထွက်နေပြီး၊ အခြားလုပ်ဆောင်မှုများကို ရှင်သန်ရန်နှင့် disk ဖြင့် တစ်ခုခုလုပ်ရန် အခွင့်အလမ်းပိုများသည်။

အဘယ်ကြောင့်ဤမျှ?

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

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

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

ဒါတွေအားလုံးတော့ မဟုတ်ပါဘူး။ စာမျက်နှာများသည် Postgres တွင် 8 ကီလိုဘိုက်နှင့် Linux တွင် 4 ကီလိုဘိုက်ရှိသည်။ ပြီးတော့ full_page_writes ဆက်တင်ရှိပါတယ်။ ၎င်းကို မူရင်းအတိုင်း ဖွင့်ထားသည်။ အဘယ်ကြောင့်ဆိုသော် ကျွန်ုပ်တို့ ၎င်းကို ပိတ်ပါက ပျက်သွားပါက စာမျက်နှာ၏ ထက်ဝက်သာ ကယ်တင်ခံရမည့် အန္တရာယ်ရှိသောကြောင့် ၎င်းသည် မှန်ပါသည်။

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

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

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

ထို့ကြောင့်၊ ကျွန်ုပ်တို့တွင် ထပ်လောင်းနှစ်ခုရှိသည်။

ကျွန်ုပ်တို့သည် max_wal_size ကိုတိုးပါက၊ checkpoint နှင့် wal writer နှစ်ခုလုံးအတွက် ပိုမိုလွယ်ကူစေကြောင်း ထွက်ပေါ်လာပါသည်။ ပြီးတော့ အဲဒါ အရမ်းကောင်းတယ်။

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

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

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

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

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

ဒီနေရာမှာ စိတ်ဝင်စားစရာအချက်တစ်ခုပါ။ ညီလာခံတွင် Patroni နှင့်ပတ်သက်သောအစီရင်ခံစာနှစ်စောင်ရှိသည်။ ပြီးတော့ မင်းအဲဒါကို သုံးနေတာ ဖြစ်နိုင်တယ်။ ၎င်းသည် Postgres အတွက် အလိုအလျောက်အောင်မြင်မှုတစ်ခုဖြစ်သည်။ GitLab နှင့် Data Egret တို့က ဤအကြောင်းကို ဆွေးနွေးခဲ့ကြသည်။

အကယ်၍ သင့်တွင် စက္ကန့် 30 အတွင်း autofailover ပေါ်လာပါက၊ ကျွန်ုပ်တို့သည် 10 မိနစ်ကြာအောင် အိပ်နိုင်ပါသလား။ အကြောင်းမှာ ကျွန်ုပ်တို့သည် ဤအချက်ဖြင့် ပုံစံတူသို့ပြောင်းမည်ဖြစ်ပြီး အရာအားလုံး အဆင်ပြေသွားပါမည်။ ဒါက အမိုက်စားအချက်ပါ။ ရှင်းရှင်းလင်းလင်း အဖြေတော့ မသိဘူး။ ဤအကြောင်းအရာသည် ပျက်စီးမှုပြန်လည်ရယူခြင်းအတွက်သာမဟုတ်ဟု ကျွန်ုပ်ခံစားရပါသည်။

အကယ်၍ ကျွန်ုပ်တို့သည် ရှုံးနိမ့်ပြီးနောက် အချိန်အတော်ကြာ ပြန်လည်ကောင်းမွန်လာပါက၊ အခြားအခြေအနေများစွာတွင် ကျွန်ုပ်တို့ အဆင်မပြေဖြစ်လိမ့်မည်။ ဥပမာအားဖြင့်၊ တူညီသောစမ်းသပ်မှုများတွင်၊ ကျွန်ုပ်တို့သည် တစ်ခုခုလုပ်သည့်အခါ တစ်ခါတစ်ရံ ၁၀ မိနစ်ခန့် စောင့်ရပေမည်။

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

ထပ်ခါထပ်ခါပြုလုပ်ရန်၊ ဥပမာ၊ max_wal_size =1၊ 8၊ အစုလိုက်အပြုံလိုက်လုပ်ဆောင်မှုကို အကြိမ်များစွာ ထပ်လုပ်ရန်လိုသည်။ မင်းလုပ်နိုင်ခဲ့တယ်။ တူညီတဲ့အခြေခံပေါ်မှာ သင်ထပ်လုပ်ချင်ပေမယ့် အရာအားလုံးကို သင်ဖျက်ပြီးပါပြီ။ ဘာလုပ်မလဲ?

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

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

ROLLBACK ဖြင့် ဤဖျက်ပစ်ခြင်းသည် သင့်တွင် ကောင်းမွန်စွာအသုံးချထားသော ဒေတာဘေ့စ်ဓာတ်ခွဲခန်းများ မရှိလျှင်ပင် စစ်ဆေးရေးဂိတ်ချိန်ညှိခြင်းအတွက် အကောင်းဆုံးဖြစ်သည်။

ကော်လံတစ်ခု "i" ဖြင့် ပန်းကန်ပြားတစ်ခု ပြုလုပ်ခဲ့သည်။ Postgres တွင် အသုံးဝင်သောကော်လံများရှိသည်။ အထူးတလည် တောင်းဆိုထားခြင်းမရှိလျှင် ၎င်းတို့သည် မမြင်နိုင်ပေ။ ၎င်းတို့မှာ ctid၊ xmid၊ xmax တို့ဖြစ်သည်။

Ctid သည် ရုပ်ပိုင်းဆိုင်ရာလိပ်စာတစ်ခုဖြစ်သည်။ သုညစာမျက်နှာ၊ စာမျက်နှာရှိ ပထမဆုံး tuple။

ROOLBACK ပြီးနောက် tuple သည် တစ်နေရာတည်းတွင် ရှိနေသည်ကို တွေ့မြင်နိုင်သည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့ ထပ်မံကြိုးစားနိုင်သည်၊ ၎င်းသည် ထိုနည်းအတိုင်း ပြုမူလိမ့်မည်။ ဒါက အဓိကပါပဲ။

Xmax သည် tuple ၏သေဆုံးချိန်ဖြစ်သည်။ ၎င်းကို တံဆိပ်တုံးထုထားသော်လည်း Postgres သည် ငွေပေးငွေယူကို နောက်ကြောင်းပြန်လှည့်ကြောင်း သိသည်၊ ထို့ကြောင့် ၎င်းသည် 0 သို့မဟုတ် ၎င်းသည် ပြန်လှန်ထားသော အရောင်းအ၀ယ်ဖြစ်ရန် ကိစ္စမရှိပါ။ ၎င်းသည် DELETE ကို ထပ်ခါတလဲလဲ လုပ်ပြီး စနစ်အပြုအမူ၏ အစုလိုက်လုပ်ဆောင်မှုများကို စစ်ဆေးရန် ဖြစ်နိုင်ကြောင်း အကြံပြုထားသည်။ ဆင်းရဲနွမ်းပါးသူများအတွက် ဒေတာဘေ့စ်ဓာတ်ခွဲခန်းများ ပြုလုပ်နိုင်သည်။

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

ရှင်းပါတယ်၊ ငါတို့က အပိုင်းပိုင်းမခွဲဘူး။ ရှင်းပါပြီ။ လိုင်းပေါင်း သန်းပေါင်းများစွာကို အပိုင်းပိုင်းအဖြစ်သို့ ဖျက်ရန် ထိုကဲ့သို့ ဖျက်ရန် မဖြစ်နိုင်ပါ။ မိနစ် 20 ကြာအောင်ပြုလုပ်ပြီး အားလုံး အိပ်ပျော်သွားပါလိမ့်မယ်။ သို့သော် ကံမကောင်းစွာဖြင့်၊ အတွေ့အကြုံရှိသော developer များပင်လျှင် အလွန်ကြီးမားသော ကုမ္ပဏီများတွင်ပင် အမှားများလုပ်တတ်ပါသည်။

ချိုးဖို့ ဘာကြောင့် အရေးကြီးတာလဲ။

• Disk က ခက်နေတာတွေ့ရင် အဲဒါကို နှေးလိုက်ကြရအောင်။ အကယ်၍ ကျွန်ုပ်တို့သည် ပျက်သွားပါက၊ ခေတ္တရပ်ထားနိုင်သည်၊ ကျွန်ုပ်တို့သည် အရှိန်ထိန်းခြင်းကို နှေးကွေးစေနိုင်ပါသည်။

• ကျွန်ုပ်တို့သည် အခြားသူများကို အချိန်အကြာကြီး ပိတ်ပင်မည်မဟုတ်ပါ။ အချို့သောကိစ္စများတွင်၊ သင်သည်မည်သူမျှအလုပ်မလုပ်သောအမှိုက်အစစ်အမှန်ကိုဖျက်ပါက၊ autovacuum အလုပ်မှလွဲ၍မည်သူ့ကိုမျှပိတ်ဆို့မည်မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော်၎င်းသည်ငွေပေးငွေယူပြီးစီးရန်စောင့်ဆိုင်းလိမ့်မည်။ ဒါပေမယ့် တစ်စုံတစ်ယောက် တောင်းဆိုနိုင်တဲ့ အရာကို ဖယ်ရှားလိုက်ရင်တော့ သူတို့ကို ပိတ်ဆို့သွားမှာဖြစ်ပြီး ကွင်းဆက်တုံ့ပြန်မှု တစ်မျိုးမျိုး ရှိလာပါလိမ့်မယ်။ ဝဘ်ဆိုဒ်များနှင့် မိုဘိုင်းအက်ပလီကေးရှင်းများတွင် ရှည်လျားသော ငွေပေးငွေယူမှုများကို ရှောင်ကြဉ်သင့်သည်။

https://postgres.ai/products/joe/

ဒါက စိတ်ဝင်စားစရာပါ။ developer များက "မည်သည့် pack size ကို ရွေးသင့်လဲ" ဟု မေးလေ့ရှိသည်ကို တွေ့ဖူးသည်။

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

ကျွန်ုပ်တွင် အလွန်ရိုးရှင်းသော စည်းမျဉ်းတစ်ခုရှိသည်- သင်တတ်နိုင်သမျှယူပါ၊ သို့သော် တစ်စက္ကန့်လျှင် အကောင်အထည်ဖော်နိုင်သည့်အရာများကို မကျော်ပါနှင့်။

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

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

အထုပ်၏အရွယ်အစားကိုကျွန်ုပ်တို့ရွေးချယ်သည်။ ကိစ္စတိုင်းတွင်၊ ကျွန်ုပ်တို့သည် ကွဲပြားခြားနားစွာ လုပ်ဆောင်နိုင်သည်။ အလိုအလျောက်လုပ်ဆောင်နိုင်သည်။ ပြီးတော့ pack တစ်ခုရဲ့ processing ရဲ့ ထိရောက်မှုကို ကျွန်တော်တို့ ယုံကြည်ပါတယ်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် pack တစ်ခုမှ DELETE သို့မဟုတ် UPDATE လုပ်သည်။

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

ပြီးတော့ အစီအစဥ်က ကောင်းပါတယ်။ အညွှန်းစကင်န်ကိုသင်တွေ့နိုင်သည်၊ index only scan သည်ပိုကောင်းသည်။ ပြီးတော့ ကျွန်တော်တို့မှာ ပါဝင်တဲ့ အချက်အလက် အနည်းငယ်ပဲ ရှိပါတယ်။ တစ်စက္ကန့်ထက်မနည်း ဖြည့်ဆည်းပေးသည်။ စူပါ

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

ပိုင်းခြားခြင်းဗျူဟာများကား အဘယ်နည်း။ pack ပေါ်ရှိ developer များအသုံးပြုနေသည့် မတူညီသော partitioning strateg 3 ခုကို ကျွန်ုပ်တွေ့မြင်ပါသည်။

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

ဒုတိယနည်းဗျူဟာသည် မျှတသောချဉ်းကပ်မှုဖြစ်သည်။ ၎င်းကို Gitlab တွင်အသုံးပြုသည်။ စားပွဲကို ယူ၍ စကင်န်ဖတ်ကြသည်။ ID packs များ၏ နယ်နိမိတ်များကို ကျွန်ုပ်တို့တွေ့ရှိခဲ့ပြီး pack တစ်ခုစီတွင် မှတ်တမ်း 10 တိတိပါရှိသည်။ ပြီးတော့ သူတို့ကို တန်းစီခိုင်းတယ်။ ပြီးတော့ ကျနော်တို့ စီမံတယ်။ ဤအရာကို ကဏ္ဍများစွာတွင် သင်လုပ်ဆောင်နိုင်သည်။

ပထမနည်းဗျူဟာတွင်လည်း၊ စကားမစပ်၊ သင်သည် ဤအရာကို တွဲများစွာဖြင့် ပြုလုပ်နိုင်သည်။ မခက်ပါဘူး။

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

ယေဘုယျအားဖြင့် index only scan သည် index scan ထက် ပိုမြန်သည်။

ကျွန်ုပ်တို့ ဖယ်ရှားလိုသော ကျွန်ုပ်တို့၏ ID များကို လျင်မြန်စွာ ရှာဖွေတွေ့ရှိပါသည်။ BATCH_SIZE ကို ကျွန်ုပ်တို့ ကြိုတင်ရွေးချယ်ထားပါသည်။ ၎င်းတို့ကို ကျွန်ုပ်တို့ ရရှိရုံသာမက အထူးနည်းလမ်းဖြင့် ၎င်းတို့ကို ရယူပြီး ၎င်းတို့ကို ချက်ချင်း hack ပါ။ ဒါပေမယ့် သော့ခတ်ထားပြီးသားဆိုရင်တော့ သော့မခတ်ပါဘူး၊ ဒါပေမယ့် ရှေ့ဆက်ပြီး နောက်တစ်ခုကို ယူသွားနိုင်အောင် ကျွန်တော်တို့ သော့ခတ်နေပါတယ်။ ဤသည်မှာ အပ်ဒိတ်ကို ကျော်သွားခြင်းအတွက်ဖြစ်သည်။ Postgres ၏ ဤစူပါအင်္ဂါရပ်သည် ကျွန်ုပ်တို့ကို အလိုရှိပါက စာတွဲများစွာဖြင့် လုပ်ဆောင်နိုင်စေပါသည်။ စမ်းချောင်းတစ်ခုတွင် ဖြစ်နိုင်သည်။ ဤတွင် CTE တစ်ခုရှိသည် - ဤတောင်းဆိုချက်တစ်ခုဖြစ်သည်။ ဤ CTE ၏ဒုတိယထပ်တွင်ကျွန်ုပ်တို့သည်အမှန်တကယ်ဖျက်ခြင်းတစ်ခုရှိသည် - returning *. သင်သည် id ကို ပြန်ပေးနိုင်သော်လည်း ပိုကောင်းပါသည်။ *စာကြောင်းတစ်ကြောင်းစီမှာ ဒေတာအများကြီးမရှိရင်။

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

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

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

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

အရောင်းအဝယ်ကွာသည်။ https://gitlab.com/snippets/1890447

ပိတ်ဆို့ထားသော အော်တိုလေဟာနယ် - https://gitlab.com/snippets/1889668

ပိတ်ဆို့ခြင်းပြဿနာ - https://gitlab.com/snippets/1890428

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

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

IO ကြီးကြီးမားမားရှိရင် ဒါက မကောင်းဘူးဆိုတာ ရှင်းပါတယ်။

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

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

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

ပြီးတော့ ကိစ္စတုံး။ ပိတ်ဆို့သစ်ပင်တောများ။ တစ်စုံတစ်ယောက်ဆီက တစ်ခုခုယူပြီး တိုးတက်အောင်လုပ်ရတာကို ကြိုက်တယ်။ ဤနေရာတွင် ကျွန်ုပ်သည် သော့ခတ်သစ်ပင်များ၏သစ်တောကိုပြသသည့် Data Egret မှ အေးမြသောပြန်ယူနိုင်သော CTE ကိုယူလိုက်ပါသည်။ ဤသည်မှာ ကောင်းမွန်သော ရောဂါရှာဖွေရေးကိရိယာတစ်ခုဖြစ်သည်။ ၎င်း၏အခြေခံပေါ်တွင်, သင်သည်လည်းစောင့်ကြည့်ရေးတည်ဆောက်နိုင်ပါတယ်။ ဒါပေမယ့် ဒါကို သေသေချာချာ လုပ်ရမယ်။ သင်ကိုယ်တိုင်အတွက် သေးငယ်သော statement_timeout ပြုလုပ်ရန် လိုအပ်ပါသည်။ lock_timeout သည် နှစ်လိုဖွယ်ကောင်းသည်။

တခါတရံတွင် ဤအမှားများအားလုံးကို ပေါင်းစည်းမိပါသည်။

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

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

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

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

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

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

သင့်တွင် 10 terabytes ရှိသည်ဆိုပါစို့၊ ကျွန်ုပ်တို့သည် database lab ကိုလည်း 10 terabytes ပြုလုပ်သည်။ တစ်ပြိုင်နက်တည်း 10 terabyte ဒေတာဘေ့စ်များနှင့်အတူ၊ ဆော့ဖ်ဝဲရေးသားသူ 10 ဦးသည် တစ်ပြိုင်နက် လုပ်ဆောင်နိုင်သည်။ လူတိုင်းက သူတို့လုပ်ချင်တာကို လုပ်နိုင်တယ်။ ဖျက်နိုင်၊ လွှတ်ချနိုင်သည် စသည်တို့သည် ထိုသို့သော စိတ်ကူးယဉ်မှုဖြစ်သည်။ မနက်ဖြန် ဒီအကြောင်း ပြောမယ်။

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

ဥပမာ- 5 terabyte ဒေတာဘေ့စ်၊ စက္ကန့် 30 ထက်နည်းသော ကော်ပီကို ရယူပါ။ ၎င်းသည် အရွယ်အစားပေါ်တွင်ပင် မမူတည်ပါ၊ ဆိုလိုသည်မှာ တာရာဘိုက်မည်မျှရှိသည်ကို အရေးမကြီးပါ။

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

မေးခွန်းများကို

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

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

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

GitHub ပေါ်ရှိ pg_repack ကိုကြည့်ရှုပါက၊ ID တစ်ခုကို int 4 မှ int 8 သို့ပြောင်းရန် လုပ်ဆောင်စရာတစ်ခုရှိသောအခါ၊ ထို့နောက် pg_repack ကိုယ်တိုင်အသုံးပြုရန် စိတ်ကူးတစ်ခုရှိသည်။ ဒါကလည်း ဖြစ်နိုင်တယ်၊ ဒါပေမယ့် နည်းနည်းတော့ ဟက်ခ်တယ်၊ ဒါပေမယ့် ဒါကလည်း အလုပ်ဖြစ်လိမ့်မယ်။ pg_repack အသုံးပြုသည့် အစပျိုးတွင် သင်သည် ကြားဝင်စွက်ဖက်နိုင်ပြီး၊ "ကျွန်ုပ်တို့သည် ဤဒေတာကို မလိုအပ်ပါ"၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့ လိုအပ်သည်များကိုသာ လွှဲပြောင်းပေးနိုင်သည်။ ပြီးတော့ သူကပဲ ပြောင်းလိုက်တာ ဒါပဲ။

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

Bloat သည် ပစ္စုပ္ပန်မဟုတ်ပါ၊ ကောင်းသောချဉ်းကပ်မှုဖြစ်သည်။ ဒါပေမယ့် အဲဒါအတွက် automation တစ်ခုကို တီထွင်ဖို့ ကြိုးပမ်းမှုတွေရှိတယ်၊ ဆိုလိုသည်မှာ universal solution တစ်ခုကို ပြုလုပ်ရန် ငါသိပါတယ်။ ဤအလိုအလျောက်စနစ်ဖြင့် သင့်အား ကျွန်ုပ်ဆက်သွယ်နိုင်ပါသည်။ Python နဲ့ ရေးထားတာ ကောင်းပါတယ်။

ကျွန်ုပ်သည် MySQL ၏ကမ္ဘာမှအနည်းငယ်သာရှိသေးသောကြောင့်နားထောင်ရန်လာခဲ့သည်။ ပြီးတော့ ငါတို့က ဒီချဉ်းကပ်နည်းကို သုံးတယ်။

ဒါပေမယ့် ကျွန်တော်တို့မှာ 90% ရှိမှဖြစ်မယ်။ ငါတို့မှာ 5% ရှိရင် သုံးရတာ သိပ်အဆင်မပြေဘူး။

အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ prod ၏ ကော်ပီ အပြည့်အစုံကို ပြုလုပ်ရန် အရင်းအမြစ်များ မရှိပါက၊ load သို့မဟုတ် အရွယ်အစားကို တွက်ချက်ရန် algorithm သို့မဟုတ် formula ရှိပါသလား။

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

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

အရောင်းအ၀ယ်တစ်ခုတွင် မှတ်တမ်းများစွာကို ဖျက်ရန် သို့မဟုတ် အပ်ဒိတ်လုပ်ရန် SQL တွင် ပြောကြားပါက၊ Postgres သည် ၎င်းကို ၎င်းကို မည်သို့ဖြန့်ဝေနိုင်မည်နည်း။ စစ်ဆင်ရေးများတွင် ကျွန်ုပ်တို့သည် ရုပ်ပိုင်းဆိုင်ရာ အကန့်အသတ်ရှိသည်။ ငါတို့က အချိန်အကြာကြီး လုပ်နေလိမ့်မယ်။ ပြီးတော့ ဒီအချိန်မှာ သော့ခတ်မယ် စသဖြင့်ပေါ့။

အညွှန်းများဖြင့် ပြီးပါပြီ။

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

မေးစရာက၊ ဒီနေရာနဲ့ ဟိုမှာသွားနေတဲ့ ဖွံ့ဖြိုးတိုးတက်မှုပုံစံတစ်ခု ရှိသလား၊ ဒါက မင်းရဲ့အပြိုင် ဖြစ်နေတယ်။ အဲဒါတွေ။ အဲဒါကို မစဉ်းစားကြသေးဘူးလား။

အခုသုံးလို့ရတဲ့ အခြေခံမူတွေအကြောင်း ပြောခဲ့တယ်။ နောက်ထပ် bot တစ်ခုရှိပါသေးတယ်။ နန်စီဤအရာဖြင့် သင်သည် အလိုအလျောက် စစ်ဆေးရေးဂိတ်ချိန်ညှိခြင်းကို ပြုလုပ်နိုင်သည်။ တစ်နေ့နေ့တွင် Postgres တွင်ရှိမည်လား။ မသိဘူး၊ မဆွေးနွေးရသေးဘူး။ အဲဒါနဲ့ ငါတို့ဝေးနေသေးတယ်။ ဒါပေမယ့် စနစ်သစ်ကို ဖန်တီးတဲ့ သိပ္ပံပညာရှင်တွေရှိတယ်။ ပြီးတော့ သူတို့က ကျွန်တော်တို့ကို အလိုအလျောက် အညွှန်းကိန်းတွေထဲကို တွန်းပို့တယ်။ တိုးတက်မှုတွေရှိတယ်။ ဥပမာအားဖြင့်၊ သင်သည် auto tuning ကိုကြည့်ရှုနိုင်သည်။ ၎င်းသည် parameters များကိုအလိုအလျောက်ရွေးချယ်သည်။ ဒါပေမယ့် သူက မင်းအတွက် စစ်ဆေးရေးဂိတ်ချိန်ညှိမှု မလုပ်သေးဘူး။ ဆိုလိုသည်မှာ ၎င်းသည် စွမ်းဆောင်ရည်၊ shell buffer စသည်တို့အတွက် ကောက်ယူမည်ဖြစ်သည်။

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

မင်္ဂလာနေ့လည်ခင်းပါ ရှည်လျားသော အရောင်းအ၀ယ်များ၏ အန္တရာယ်များအကြောင်း သင်ပြောခဲ့သည်။ ဖျက်သည့်အခါတွင် autovacuum ကို ပိတ်ဆို့ထားကြောင်း သင်ပြောခဲ့သည်။ အခြားမည်ကဲ့သို့ ကျွန်ုပ်တို့ကို ထိခိုက်နစ်နာစေသနည်း။ ဘာလို့လဲဆိုတော့ နေရာလွတ်တွေ လွတ်လာပြီး သုံးလို့ရတာကို ပိုပြောနေတာကြောင့်ပါ။ ငါတို့ ဘာများ လွဲနေသေးလဲ။

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

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

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

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

၎င်းသည် Postgres တွင် အလိုအလျောက် လေဟာနယ်က အလိုအလျောက် လုပ်ဆောင်သည့် အရာဖြစ်သည်။

အိုး၊ သူလုပ်သလား။

Autovacuum သည် အမှိုက်စုဆောင်းသူဖြစ်သည်။

Thank you!

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

ဟုတ်ပါတယ်။

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

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

source: www.habr.com