မင်္ဂလာပါ။
ကျွန်တော့်နာမည်က Vanya ဖြစ်ပြီး Java developer တစ်ယောက်ပါ။ ဒေတာဘေ့စ်ကိုတည်ဆောက်ခြင်း၊ ဖွဲ့စည်းပုံ၊ စွမ်းဆောင်ရည်ကို ကောင်းမွန်အောင်ပြုလုပ်ခြင်းနှင့် စနေ၊
မကြာသေးမီက ကျွန်ုပ်သည် ကျွန်ုပ်တို့၏ microservices များရှိ databases အများအပြားကို သပ်သပ်ရပ်ရပ်ပြင်ဆင်ပြီး java Library တစ်ခုကို ရေးသားခဲ့သည်။
ခွင
ကျွန်တော်နှင့်အလုပ်လုပ်သော PostgreSQL ၏အဓိကဗားရှင်းမှာ 10 ဖြစ်သည်။ ကျွန်ုပ်အသုံးပြုသော SQL queries အားလုံးကို ဗားရှင်း 11 တွင်လည်း စမ်းသပ်ထားပါသည်။ အနိမ့်ဆုံးပံ့ပိုးထားသောဗားရှင်းမှာ 9.6 ဖြစ်သည်။
စောပိုငျးကာလ
ကျွန်ုပ်အတွက် ထူးဆန်းသည့် အခြေအနေတစ်ခုဖြင့် လွန်ခဲ့သော တစ်နှစ်နီးပါးက စတင်ခဲ့သည်- အပြာရောင်အညွှန်းတစ်ခု၏ အပြိုင်အဆိုင်ဖန်တီးမှုသည် အမှားတစ်ခုနှင့် အဆုံးသတ်သွားခဲ့သည်။ ပုံမှန်အတိုင်းပင် အညွှန်းကိုယ်တိုင်က ဒေတာဘေ့စ်တွင် မမှန်ကန်သော အခြေအနေတွင် ရှိနေသည်။ မှတ်တမ်း ခွဲခြမ်းစိတ်ဖြာမှု ပြတ်တောက်မှုကို ပြသခဲ့သည်။
ပြဿနာတစ်ခု - ပုံသေဖွဲ့စည်းပုံ
ကော်ဖီဖျော်စက်တစ်ခုတွင်သုံးနိုင်သော Postgres နှင့်ပတ်သက်သည့်အလင်္ကာကိုလူတိုင်းတော်တော်ငြီးငွေ့နေပုံရသော်လည်း... ပုံသေဖွဲ့စည်းပုံသည် အမှန်တကယ်မေးခွန်းများစွာကိုပေါက်ဖွားစေပါသည်။ အနည်းဆုံးတော့ သတိထားရကျိုးနပ်ပါတယ်။ maintenance_work_mem, temp_file_limit, ထုတ်ပြန်ချက်_ အချိန်ကုန်ခြင်း။ и lock_timeout.
ငါတို့ကိစ္စ maintenance_work_mem မူရင်း 64 MB နှင့် temp_file_limit 2 GB ဝန်းကျင် - ကျွန်ုပ်တို့တွင် စားပွဲကြီးတစ်ခုပေါ်တွင် အညွှန်းတစ်ခုဖန်တီးရန် လုံလောက်သော memory မရှိပါ။
ထို့ကြောင့်၊ pg-index-ကျန်းမာရေး စီးရီးတစ်ခု စုဆောင်းခဲ့တယ်။
ပြဿနာနှစ်ခု - ပွားနေသော အညွှန်းများ
ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်များသည် SSD drives တွင်နေထိုင်ကြပြီး ကျွန်ုပ်တို့အသုံးပြုပါသည်။ HA- များစွာသောဒေတာစင်တာများ၊ master host နှင့် configuration n- ပုံတူအရေအတွက်။ Disk space သည် ကျွန်ုပ်တို့အတွက် အလွန်တန်ဖိုးရှိသော အရင်းအမြစ်တစ်ခုဖြစ်သည်။ ၎င်းသည် စွမ်းဆောင်ရည်နှင့် CPU သုံးစွဲမှုထက် အရေးကြီးသည်။ ထို့ကြောင့်၊ တစ်ဖက်တွင်၊ ကျွန်ုပ်တို့သည် လျင်မြန်သောစာဖတ်ခြင်းအတွက် အညွှန်းများလိုအပ်ပြီး အခြားတစ်ဖက်တွင်၊ ၎င်းတို့သည် နေရာလွတ်ကိုစား၍ ဒေတာအပ်ဒိတ်လုပ်ခြင်းကို နှေးကွေးစေသောကြောင့် ဒေတာဘေ့စ်တွင် မလိုအပ်သောအညွှန်းများကို မမြင်လိုပါ။
ယခုလည်း အရာအားလုံးကို ပြန်လည်ရရှိပြီးဖြစ်သည်။
ပြဿနာ သုံးခု - လမ်းဆုံညွှန်းကိန်း
အတွေ့အကြုံမရှိသေးသော developer အများစုသည် ကော်လံတစ်ခုတည်းတွင် အညွှန်းများကို ဖန်တီးကြသည်။ တဖြည်းဖြည်းနှင့် ဤလုပ်ငန်းကို စေ့စေ့စပ်စပ် တွေ့ကြုံလာရသောအခါ လူများသည် ၎င်းတို့၏ မေးမြန်းချက်များကို အကောင်းဆုံးဖြစ်အောင် စတင်ကြပြီး ကော်လံအများအပြားပါရှိသော ပိုမိုရှုပ်ထွေးသော အညွှန်းများကို ပေါင်းထည့်ကြသည်။ ဤသည်မှာ ကော်လံများရှိ အညွှန်းများ ပေါ်လာပုံဖြစ်သည်။ A, A + B ကို, A+B+C နောက် ... ပြီးတော့။ ဤအညွှန်းကိန်းများထဲမှ ပထမနှစ်ခုသည် တတိယ၏ရှေ့ဆက်ဖြစ်သောကြောင့် ဘေးကင်းစွာ ဖယ်ထုတ်နိုင်သည်။ ၎င်းသည် ဒစ်ခ်နေရာအများအပြားကိုလည်း သက်သာစေပြီး ၎င်းအတွက် ရောဂါရှာဖွေမှုများလည်း ရှိပါသည်။
ပြဿနာ လေးခု - အညွှန်းမပါသော နိုင်ငံခြားကီးများ
Postgres သည် ကျောထောက်နောက်ခံအညွှန်းကို မသတ်မှတ်ဘဲ နိုင်ငံခြားသော့ကန့်သတ်ချက်များကို ဖန်တီးနိုင်သည်။ အခြေအနေတော်တော်များများမှာ ဒါက ပြဿနာမဟုတ်သလို သူ့အလိုလို ထုတ်ဖော်မပြတတ်ပါဘူး...။
၎င်းသည် ကျွန်ုပ်တို့နှင့် အတူတူပင်ဖြစ်သည်- အချိန်ဇယားတစ်ခုအရ အလုပ်တစ်ခုသည် အချိန်ဇယားတစ်ခုအတိုင်း လုပ်ဆောင်နေပြီး စမ်းသပ်မှုအမှာစာများ၏ဒေတာဘေ့စ်ကို ရှင်းလင်းခြင်းတွင် မာစတာအိမ်ရှင်မှ ကျွန်ုပ်တို့ထံ “ထည့်သည်” ကို စတင်လိုက်ပါသည်။ CPU နှင့် IO သည် ပျက်စီးသွားသည်၊ တောင်းဆိုမှုများ နှေးကွေးကာ အချိန်ကုန်သွားသည်၊ ဝန်ဆောင်မှုမှာ ငါးရာဖြစ်သည်။ အမြန်ခွဲခြမ်းစိတ်ဖြာ
delete from <table> where id in (…)
ဤကိစ္စတွင်၊ ပစ်မှတ်ဇယားတွင် id အလိုက် အညွှန်းတစ်ခုရှိနေသည်၊ အခြေအနေအရ မှတ်တမ်းအနည်းငယ်ကို ဖျက်ပစ်လိုက်ပါသည်။ အရာအားလုံးက အလုပ်ဖြစ်သင့်တယ်လို့ ထင်ရပေမယ့် ဖြစ်ချင်တော့ မဖြစ်ခဲ့ပါဘူး။
အံ့သြဖွယ်ကောင်းသူသည် ကယ်တင်ခြင်းသို့ ရောက်ခဲ့သည်။ ခွဲခြမ်းစိတ်ဖြာရှင်းပြပါ။ ပစ်မှတ်ဇယားရှိ မှတ်တမ်းများကို ဖျက်ခြင်းအပြင်၊ ကိုးကားမှုဆိုင်ရာ သမာဓိစစ်ဆေးမှုလည်း ရှိကြောင်း၊ ဆက်စပ်ဇယားများထဲမှ တစ်ခုတွင် ဤစစ်ဆေးမှုသည် ပျက်ကွက်သည်ဟု ဆိုသည်။ ဆင့်ကဲစကင်န် သင့်လျော်သောအညွှန်းမရှိခြင်းကြောင့်ဖြစ်သည်။ ဒီလိုနဲ့ ရောဂါရှာဖွေမှုတွေ ပေါ်ပေါက်လာပါတယ်။
ပြဿနာငါး – အညွှန်းကိန်းများတွင် အချည်းနှီးသောတန်ဖိုး
မူရင်းအားဖြင့်၊ Postgres သည် btree အညွှန်းများတွင် null တန်ဖိုးများပါ၀င်သော်လည်း ၎င်းတို့သည် များသောအားဖြင့် ထိုနေရာတွင် မလိုအပ်ပါ။ ထို့ကြောင့် ဤ null များကို ဖယ်ထုတ်ရန် ဝီရိယရှိရှိ ကြိုးစားပါ (ရောဂါရှာဖွေခြင်း) where <A> is not null
. ဤနည်းဖြင့် ကျွန်ုပ်တို့၏ အညွှန်းကိန်းတစ်ခု၏ အရွယ်အစားကို 1877 MB မှ 16 KB သို့ လျှော့ချနိုင်ခဲ့သည်။ ဝန်ဆောင်မှုများထဲမှ တစ်ခုတွင်၊ အညွှန်းကိန်းများမှ null တန်ဖိုးများကို ချန်လှပ်ထားခြင်းကြောင့် စုစုပေါင်းဒေတာဘေ့စ်အရွယ်အစားသည် စုစုပေါင်း 16% (အကြွင်းမဲ့နံပါတ်များ 4.3 GB) လျော့နည်းသွားသည်။ အလွန်ရိုးရှင်းသော ပြုပြင်မွမ်းမံမှုများဖြင့် disk space တွင် ကြီးမားသော ခြွေတာမှု။ 🙂
ပြဿနာခြောက် – အဓိကသော့မရှိခြင်း။
ယန္တရား၏သဘောသဘာဝကြောင့်ဖြစ်သည်။
တစ်နေ့တွင်၊ အံ့သြဖွယ်ကောင်းသော ရွှေ့ပြောင်းနေထိုင်မှုတစ်ခုသည် ကြီးမားပြီး တက်ကြွစွာအသုံးပြုထားသော ဇယားတစ်ခုတွင် မှတ်တမ်းအားလုံးကို သိမ်းဆည်းခဲ့သည်။ အပြာရောင်ကနေ စားပွဲအရွယ်အစားအတွက် +100 GB ရခဲ့ပါတယ်။ ဒါဟာ ရှက်စရာကြီးဘဲ၊ ဒါပေမယ့် ငါတို့ရဲ့ စွန့်စားမှုတွေက အဲ့ဒီမှာ မပြီးဆုံးခဲ့ပါဘူး။ ဤဇယားရှိ အလိုအလျောက် လေဟာနယ်သည် 15 နာရီအကြာတွင် ပြီးဆုံးပြီးနောက်၊ ရုပ်ပိုင်းဆိုင်ရာတည်နေရာသည် ပြန်မလာတော့ကြောင်း ထင်ရှားလာသည်။ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုကို ရပ်တန့်ပြီး VACUUM အပြည့်ဖြစ်အောင် မလုပ်နိုင်ခဲ့သောကြောင့် အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။
စာကြည့်တိုက်ဗားရှင်းတွင် 0.1.5 ဇယားကွက်များနှင့် အညွှန်းကိန်းများ စုစည်းကာ အချိန်နှင့်တပြေးညီ တုံ့ပြန်နိုင်စွမ်းကို ထည့်သွင်းထားသည်။
ပြဿနာ ခုနစ်ခုနှင့် ရှစ်ခု - အညွှန်းများ မလုံလောက်ခြင်းနှင့် အသုံးမပြုသော အညွှန်းများ
အောက်ပါရောဂါရှာဖွေရေးနှစ်ခုမှာ-
ကျွန်တော်ရေးပြီးသားအတိုင်း၊ ကျွန်ုပ်တို့သည် ပုံတူများစွာဖြင့် ဖွဲ့စည်းမှုပုံစံကို အသုံးပြုပြီး မတူညီသော host များတွင် ဖတ်ရှုခြင်းဝန်သည် အခြေခံအားဖြင့် ကွဲပြားပါသည်။ ရလဒ်အနေဖြင့်၊ အချို့သော host များရှိ ဇယားများနှင့် အညွှန်းများကို လက်တွေ့ကျကျအသုံးမပြုကြောင်းနှင့် ခွဲခြမ်းစိတ်ဖြာရန်အတွက် သင်သည် အစုအဝေးရှိ host အားလုံးထံမှ ကိန်းဂဏန်းများကို စုဆောင်းရန်လိုအပ်ပါသည်။
ဤနည်းလမ်းသည် အသုံးမပြုဖူးသော အညွှန်းများကို ဖယ်ရှားကာ အသုံးနည်းသောဇယားများတွင် ပျောက်ဆုံးနေသော အညွှန်းများကို ပေါင်းထည့်ခြင်းဖြင့် ဆယ်ဂဏန်းဂစ်ဂါဗိုက်များစွာကို သိမ်းဆည်းနိုင်စေခဲ့သည်။
နိဂုံးချုပ်
ဟုတ်ပါတယ်၊ ရောဂါရှာဖွေမှုအားလုံးနီးပါးအတွက် သင် configure လုပ်နိုင်ပါတယ်။
ဒေတာဘေ့စ် ရွှေ့ပြောင်းခြင်းကို စတင်ပြီးနောက် အချို့သော ရောဂါရှာဖွေမှုများကို လုပ်ဆောင်နိုင်သော စမ်းသပ်မှုများတွင် လုပ်ဆောင်နိုင်သည်။ ၎င်းသည် ကျွန်ုပ်၏စာကြည့်တိုက်၏ အစွမ်းထက်ဆုံးသောအင်္ဂါရပ်များထဲမှတစ်ခု ဖြစ်နိုင်သည်။ အသုံးပြုပုံ ဥပမာကို မှာကြည့်နိုင်ပါတယ်။
အသုံးမပြုသော သို့မဟုတ် ပျောက်ဆုံးနေသော အညွှန်းများအပြင် ဒေတာဘေ့စ်တစ်ခုပေါ်တွင်သာ bloat အတွက် စစ်ဆေးမှုများ ပြုလုပ်ခြင်းသည် အဓိပ္ပာယ်ရှိလှသည်။ စုဆောင်းထားသော တန်ဖိုးများကို မှတ်တမ်းတင်နိုင်သည်။
ငါတကယ်မျှော်လင့်ပါတယ်။ pg-index-ကျန်းမာရေး အသုံးဝင်ပြီး ဝယ်လိုအားရှိပါလိမ့်မယ်။ သင်တွေ့ရှိသောပြဿနာများကို သတင်းပို့ပြီး ရောဂါရှာဖွေမှုအသစ်များကို အကြံပြုခြင်းဖြင့် စာကြည့်တိုက်၏ဖွံ့ဖြိုးတိုးတက်မှုကိုလည်း ပံ့ပိုးကူညီနိုင်ပါသည်။
source: www.habr.com