DBA bot ဂျိုး။ Anatoly Stansler (Postgres.ai)

SQL query သည် “prod” တွင် ကောင်းမွန်စွာအလုပ်လုပ်နိုင်သည်ကို backend developer က မည်သို့နားလည်သနည်း။ ကြီးမားသော သို့မဟုတ် လျင်မြန်စွာ ကြီးထွားလာသော ကုမ္ပဏီများတွင် လူတိုင်းသည် "ထုတ်ကုန်" ကို အသုံးပြုခွင့်မရှိပါ။ ဝင်ရောက်အသုံးပြုခြင်းဖြင့်၊ တောင်းဆိုမှုအားလုံးကို နာကျင်မှုမရှိ စစ်ဆေးနိုင်မည်မဟုတ်ကြောင်း၊ ဒေတာဘေ့စ်ကော်ပီကို ဖန်တီးရာတွင် နာရီပေါင်းများစွာ ကြာတတ်သည်။ ဤပြဿနာများကိုဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည်အတု DBA - Joe ကိုဖန်တီးခဲ့သည်။ ၎င်းကို ကုမ္ပဏီများစွာတွင် အောင်မြင်စွာ အကောင်အထည်ဖော်ပြီးဖြစ်ကာ developer တစ်ဒါဇင်ကျော်ကို ကူညီပေးပါသည်။

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

အားလုံးမင်္ဂလာပါ! ကျွန်တော့်နာမည် Anatoly Stansler ပါ။ ကျွန်တော်က ကုမ္ပဏီတစ်ခုမှာ အလုပ်လုပ်တယ်။ postgres.ai. ဆော့ဖ်ဝဲအင်ဂျင်နီယာများ၊ DBAs နှင့် QAs များမှ Postgres ၏အလုပ်နှင့်ဆက်စပ်နေသောနှောင့်နှေးမှုများကိုဖယ်ရှားခြင်းဖြင့် ဖွံ့ဖြိုးတိုးတက်ရေးလုပ်ငန်းစဉ်ကိုအရှိန်မြှင့်ရန် ကျွန်ုပ်တို့ကတိပြုပါသည်။

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

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

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

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

ပထမနည်းလမ်းမှာ ထုတ်ကုန်စမ်းသပ်ခြင်း ဖြစ်သည်။ သို့မဟုတ်၊ developer သည် local machine တစ်ခုပေါ်တွင်ထိုင်သောအခါ၊ သူ့တွင် test data ရှိသည်၊ အချို့သောကန့်သတ်ရွေးချယ်မှုမျိုးရှိသည်။ ပြီး​တော့ ကျွန်​​တော်​တို့ ​ခြေ​ထောက်​နဲ့ လှိမ့်​လိုက်​ပြီး ဒီ​အ​ခြေအ​နေ​ကို ​ရောက်​သွား​တယ်။

နာကျင်တယ်၊ ဈေးကြီးတယ်။ မလုပ်တာ အကောင်းဆုံးဖြစ်နိုင်ပါတယ်။

၎င်းကိုပြုလုပ်ရန် အကောင်းဆုံးနည်းလမ်းမှာ အဘယ်နည်း။

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

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

ပြဿနာတွေက ဘာတွေလဲ။

• ပြဿနာမှာ ကျွန်ုပ်တို့သည် ဤဇာတ်ကြောင်းကို လုပ်ဖော်ကိုင်ဖက်များနှင့် မျှဝေခြင်းဖြစ်သည်။ မကြာခဏဆိုသလိုမျိုး အပြောင်းအလဲတစ်ခုခုလုပ်မိတာမျိုး bam - ဒေတာမရှိဘူး၊ အလုပ်က ယိုစီးကျနေတယ်။ Staging သည် multi-terabyte ဖြစ်သည်။ ပြီးတော့ ပြန်တက်လာဖို့ အချိန်အကြာကြီး စောင့်ရမှာပေါ့။ ပြီးတော့ မနက်ဖြန်မှာ အပြီးသတ်ဖို့ ဆုံးဖြတ်တယ်။ ဒါပဲ၊ ကျွန်တော်တို့မှာ ဖွံ့ဖြိုးတိုးတက်မှုရှိတယ်။
• ပြီးတော့၊ ငါတို့မှာ လုပ်ဖော်ကိုင်ဖက်တွေ အများကြီးရှိတယ်၊ အဖွဲ့တွေအများကြီးရှိတယ်။ ၎င်းကို ကိုယ်တိုင်လုပ်ဆောင်ရမည်။ ပြီးတော့ ဒါက အဆင်မပြေဘူး။

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

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

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

terabyte ထက် ပိုကြီးတဲ့ ဒေတာဘေ့စ်က ဘယ်သူလဲ။ အခန်းတစ်ဝက်ကျော်။

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

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

အခြေခံအဆောက်အအုံအတွင်း၌ ၎င်းကို သင်ပြုလုပ်လျှင်ပင် တစ်နာရီလျှင် ဒေတာတစ် terabyte ကို ဒေါင်းလုဒ်လုပ်ခြင်းသည် အလွန်ကောင်းမွန်နေပြီဖြစ်သည်။ ဒါပေမယ့် သူတို့က ယုတ္တိမဲ့အမှိုက်တွေကို အသုံးပြုပြီး cloud ကနေ ပြည်တွင်းမှာ ဒေါင်းလုဒ်လုပ်ကြတယ်။ ၎င်းတို့အတွက် မြန်နှုန်းမှာ တစ်နာရီလျှင် 200 gigabytes ခန့်ရှိသည်။ ယုတ္တိတန်သောအမှိုက်ပုံမှ လှည့်ပတ်ရန်၊ အညွှန်းကိန်းများကို လှိမ့်ရန်၊ စသည်ဖြင့် အချိန်ယူရသေးသည်။

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

ဤနေရာတွင် ကျွန်ုပ်တို့ ဘာလုပ်နိုင်သနည်း။ စမ်းသပ်ခုံများကို စျေးသက်သက်သာသာဖြင့် ဖန်တီးပြီး developer တိုင်းကို ၎င်းတို့၏ ကိုယ်ပိုင်စမ်းသပ်ခုံတန်းများ ပေးကြပါစို့။

ပြီးတော့ ဒါက ဖြစ်နိုင်တယ်။

ဤချဉ်းကပ်မှုတွင်၊ developer တစ်ခုစီအတွက် ပါးလွှာသော clones ပြုလုပ်သောအခါ၊ ၎င်းကို စက်တစ်ခုတည်းတွင် မျှဝေနိုင်သည်။ ဥပမာအားဖြင့်၊ သင့်တွင် 10TB ဒေတာဘေ့စ်တစ်ခုရှိပြီး developer 10 ဦးအား ပေးလိုပါက၊ သင့်တွင် XNUMX x XNUMXTB ဒေတာဘေ့စ်များ ရှိရန် မလိုအပ်ပါ။ စက်တစ်လုံးသုံးပြီး developer တစ်ခုစီအတွက် သေးငယ်သော သီးခြားကော်ပီများ ပြုလုပ်ရန် စက်တစ်ခုသာ လိုအပ်ပါသည်။ ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာကို နောက်မှပြောပြမယ်။

တကယ့်ဥပမာ-

• DB - 4,5 terabytes

• ကျွန်ုပ်တို့သည် စက္ကန့် 30 အတွင်း လွတ်လပ်သောမိတ္တူများကို ရရှိနိုင်ပါသည်။

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

ဒါကြီးပဲ။ ဤတွင် ကျွန်ုပ်တို့သည် မှော်ပညာနှင့် အပြိုင်စကြာဝဠာအကြောင်း ပြောနေပါသည်။

ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ၎င်းသည် OpenZFS စနစ်ကို အသုံးပြု၍ အလုပ်လုပ်သည်။

OpenZFS သည် ပုံးအတွင်းမှ လျှပ်တစ်ပြက်ရိုက်ချက်များနှင့် clones များကို ပံ့ပိုးပေးသည့် ကော်ပီ-on-write ဖိုင်စနစ်တစ်ခုဖြစ်သည်။ ၎င်းသည် ယုံကြည်စိတ်ချရသော အရွယ်ဖြစ်သည်။ သူမသည်စီမံခန့်ခွဲရန်အလွန်လွယ်ကူသည်။ ၎င်းကို အဖွဲ့နှစ်ဖွဲ့ဖြင့် လက်တွေ့ကျကျ အသုံးချနိုင်သည်။

အခြားရွေးချယ်စရာများ ရှိပါသည်-

• LVM၊

• သိုလှောင်မှု (ဥပမာ၊ Pure Storage)။

ကျွန်တော်ပြောနေတဲ့ Database Lab က modular ပါ။ ဤရွေးချယ်မှုများကို အသုံးပြု၍ အကောင်အထည်ဖော်နိုင်သည်။ သို့သော် ယခုအချိန်တွင်၊ ကျွန်ုပ်တို့သည် LVM နှင့် အထူးပြဿနာများရှိသောကြောင့် OpenZFS ကို အာရုံစိုက်ထားပါသည်။

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

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

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

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

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

• ပထမအချက်က ဒေတာရဲ့ ရင်းမြစ်ဖြစ်ပြီး၊ ဘယ်ကနေ ယူမလဲ။ ထုတ်လုပ်မှုဖြင့် ပုံတူကူးခြင်းကို သင်သတ်မှတ်နိုင်သည်။ သင် configure လုပ်ထားတဲ့ အရန်ကူးတွေကို သင်သုံးနိုင်ပြီလို့ မျှော်လင့်ပါတယ်။ WAL-E၊ WAL-G သို့မဟုတ် Barman။ RDS သို့မဟုတ် Cloud SQL ကဲ့သို့သော Cloud ဖြေရှင်းချက်အချို့ကို သင်အသုံးပြုနေလျှင်ပင်၊ သင်သည် ယုတ္တိမဲ့အမှိုက်များကို အသုံးပြုနိုင်သည်။ သို့သော် ကျွန်ုပ်တို့သည် သင့်အား အရန်ကူးယူခြင်းကို အသုံးပြုရန် အကြံပြုထားဆဲဖြစ်သည်၊ အကြောင်းမှာ ဤနည်းလမ်းဖြင့် သင်သည် ဖိုင်များ၏ ရုပ်ပိုင်းဆိုင်ရာဖွဲ့စည်းပုံကို ထိန်းသိမ်းထားနိုင်သောကြောင့် ၎င်းသည် တည်ရှိနေသောပြဿနာများကို ဖမ်းဆုပ်နိုင်ရန် ထုတ်လုပ်ရေးတွင် သင်တွေ့မြင်ရမည့် မက်ထရစ်များနှင့် ပိုမိုနီးကပ်စေမည်ဖြစ်သည်။

• ဒုတိယတစ်ခုကတော့ Database Lab ကို လက်ခံကျင်းပလိုတဲ့ နေရာပါ။ ၎င်းသည် Cloud ဖြစ်နိုင်သည်၊ ၎င်းသည် On-premise ဖြစ်နိုင်သည်။ ZFS သည် data compression ကို ပံ့ပိုးပေးသည်ဟု ဤနေရာတွင် ပြောရန် အရေးကြီးပါသည်။ ပြီးတော့ အဲဒါက တော်တော်ကောင်းတယ်။

ထိုကဲ့သို့ clone တစ်ခုစီအတွက် အခြေခံနှင့် ကျွန်ုပ်တို့လုပ်ဆောင်သည့် လုပ်ဆောင်ချက်များအပေါ် မူတည်၍ အချို့သော dev သည် ကြီးထွားလာမည်ဟု စိတ်ကူးကြည့်ပါ။ ယင်းအတွက်၊ dev သည်လည်း နေရာလွတ် လိုအပ်မည်ဖြစ်သည်။ သို့သော် ကျွန်ုပ်တို့သည် 4,5 terabytes ၏အခြေခံကိုယူထားသောကြောင့် ZFS သည် ၎င်းအား 3,5 terabytes သို့ချုံ့မည်ဖြစ်သည်။ ၎င်းသည် ဆက်တင်များပေါ်မူတည်၍ ကွဲပြားနိုင်သည်။ ပြီးတော့ dev အတွက် နေရာကျန်ပါသေးတယ်။

ထိုသို့သောစနစ်ကို မတူညီသောကိစ္စများတွင် အသုံးပြုနိုင်သည်။

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

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

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

ဤချဉ်းကပ်မှုဖြင့်-

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

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

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

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

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

1. ကျွန်ုပ်တို့သည် စမ်းသပ်ခုံတန်းလျားများ၏ အရင်းအမြစ်များကို မျှဝေပေးသောကြောင့် ၎င်းသည် အကျိုးရှိသည်။

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

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

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

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

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

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

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

ဒါပေမယ့် ပြဿနာတွေလည်း ရှိတယ်။ ဤသည်မှာ တကယ့်ကမ္ဘာဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် တစ်ပြိုင်နက်တွင် clones အများအပြားကို လက်ခံဆောင်ရွက်ပေးနေသော ဆာဗာကို အသုံးပြုနေသောကြောင့်၊ ကျွန်ုပ်တို့သည် clones အတွက် ရရှိနိုင်သော memory နှင့် CPU ပမာဏကို ချုံ့ရန် လိုအပ်ပါသည်။

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

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

ထုတ်လုပ်မှုတွင် တူညီသော ဟာ့ဒ်ဝဲရှိခြင်းသည် အေးသော်လည်း ကွဲပြားနိုင်သည်။

Postgres သည် မှတ်ဉာဏ်ဖြင့် မည်သို့အလုပ်လုပ်သည်ကို သတိရလိုက်ကြပါစို့။ ကျွန်ုပ်တို့တွင် ကက်ရှ်နှစ်ခုရှိသည်။ ဖိုင်စနစ်မှ တစ်ခုနှင့် မူရင်း Postgres တစ်ခု၊ ဆိုလိုသည်မှာ မျှဝေထားသော Buffer Cache။

Postgres စတင်သောအခါတွင် Shared Buffer Cache ကို ခွဲဝေပေးကြောင်း မှတ်သားထားရန်မှာ အရေးကြီးသည်မှာ သတိပြုရန်မှာ အရေးကြီးသည်မှာ ပြုပြင်မှုတွင် သင်သတ်မှတ်ထားသော အရွယ်အစား။

ဒုတိယ cache သည် ရနိုင်သောနေရာအားလုံးကို အသုံးပြုသည်။

ကျွန်ုပ်တို့သည် စက်တစ်ခုတွင် clone အများအပြားကို ပြုလုပ်သောအခါတွင်၊ ကျွန်ုပ်တို့သည် မှတ်ဉာဏ်အား တဖြည်းဖြည်း ဖြည့်သွင်းလာပါသည်။ နည်းလမ်းကောင်းတစ်ခုအနေဖြင့်၊ Shared Buffer Cache သည် စက်ပေါ်တွင်ရရှိနိုင်သည့် စုစုပေါင်းမှတ်ဉာဏ်ပမာဏ၏ 25% ဖြစ်သည်။

ကျွန်ုပ်တို့သည် ဤကန့်သတ်ဘောင်ကို မပြောင်းလဲပါက၊ ဥပမာအားဖြင့် စက်တစ်ခုတွင် ဥပမာ (၄) ခုသာ လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ ပြီးတော့ ဒါက မကောင်းဘူး၊ ငါတို့က သူတို့ထဲက အများကြီး ပိုလိုချင်လို့။

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

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် prod တွင် ကြီးမားသော cache ရှိပါက၊ Postgres သည် အညွှန်းတစ်ခုကို အသုံးပြုရန် နှစ်သက်လိမ့်မည်။ မဟုတ်ပါက SeqScan ရှိလိမ့်မည်။ ကျွန်ုပ်တို့၏အစီအစဉ်များ မကိုက်ညီပါက အဘယ်အချက်ဖြစ်မည်နည်း။

သို့သော် အမှန်တကယ်တော့ Postgres ရှိ အစီအစဉ်သည် အစီအစဉ်ရှိ Shared Buffer တွင် သတ်မှတ်ထားသည့် အရွယ်အစားပေါ်တွင် မမူတည်ပါ၊ ၎င်းသည် effective_cache_size ပေါ်မူတည်၍ ဤနေရာတွင် ကျွန်ုပ်တို့ နိဂုံးချုပ်လာပါသည်။

Effective_cache_size သည် ကျွန်ုပ်တို့အတွက် ရရှိနိုင်သော ခန့်မှန်းခြေပမာဏဖြစ်ပြီး၊ ဆိုလိုသည်မှာ Buffer Cache နှင့် ဖိုင်စနစ် ကက်ရှ်များ၏ ပေါင်းလဒ်ဖြစ်သည်။ ၎င်းကို config မှသတ်မှတ်ထားသည်။ ပြီးတော့ ဒီမှတ်ဉာဏ်ကို ခွဲဝေမပေးပါဘူး။

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

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

• ၎င်းသည် လက်ရှိထုတ်ကုန်ပေါ်ရှိ ဝန်ပေါ် မူတည်သည်။

• စက်၏ဝိသေသလက္ခဏာများကိုယ်တိုင်အပေါ် မူတည်.

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

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

Joe က ဘယ်လို အထူး ပြုပြင်ထားလဲ ဆိုတာ ကြည့်ရအောင်။

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

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

B Joe သည် အစီအစဉ်နှင့် တိုင်းတာမှုများအပေါ် အခြေခံ၍ အလိုအလျောက် အကြံပြုချက်များကို သင့်အား ပြသပါမည်။

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

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

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

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

အညွှန်းကို ပိုတိကျအောင်ကြိုးစားပြီး query execution က ဘယ်လိုပြောင်းသွားလဲ ကြည့်ရအောင်။

အညွှန်းကိုဖန်တီးရာတွင် အချိန်အတော်ကြာယူခဲ့ရသော်လည်း ယခုကျွန်ုပ်တို့သည် စုံစမ်းမေးမြန်းမှုကို စစ်ဆေးပြီး 2,5 မိနစ်အစား အချိန်သည် 156 မီလီစက္ကန့်သာရှိသည့်အတွက် လုံလောက်ကောင်းမွန်ကြောင်း တွေ့ရှိရပါသည်။ ပြီးတော့ ဒေတာ 6 megabytes ပဲ ဖတ်တယ်။

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

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

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

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

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

ဤအကြောင်းအရာကို မလေ့လာရသေးသော developer များသည် မည်သည့် မက်ထရစ်များသည် အရေးကြီးပြီး မည်သည့်အရာမဟုတ်သည်ကို ရှာဖွေရန် ၎င်းတို့အတွက် ပိုမိုလွယ်ကူသောကြောင့် ရှင်းပြရန်.depesz.com ကို အသုံးပြုပါသည်။

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

ပူးပေါင်းဆောင်ရွက်ခြင်း

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

full-size data တွင် စမ်းသပ်ရန် အရေးကြီးသည်ဟု ကျွန်ုပ်တို့ထင်သည်။ ဒါကိုလုပ်ဖို့၊ Open Source မှာရနိုင်တဲ့ Update Database Lab tool ကိုလုပ်ထားပါတယ်။ Joe bot ကိုလည်း သုံးနိုင်ပါတယ်။ ယခုချက်ချင်းယူ၍ သင့်နေရာတွင် အကောင်အထည်ဖော်နိုင်ပါသည်။ လမ်းညွှန်အားလုံး ထိုနေရာတွင် ရနိုင်သည်။

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

ဤနေရာတွင် ငါအဆုံးသတ်သည်။ ကျေးဇူးတင်ပါသည်!

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

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

ဒီပတ်ဝန်းကျင်အတွက် နေရာကို ဘယ်လိုတွက်ရမလဲလို့ တွေးမိတယ်။ နည်းပညာဆိုသည်မှာ အချို့သောအခြေအနေများတွင် သင်၏ clones သည် အများဆုံးအရွယ်အစားအထိ ကြီးထွားနိုင်သည်ဟု ဆိုလိုသည်။ အကြမ်းဖျင်းပြောရလျှင် သင့်တွင် ၁၀ terabyte database နှင့် 10 clones ရှိပါက၊ clone တစ်ခုစီသည် ထူးခြားသော data 10 အလေးချိန်ရှိသော အခြေအနေတစ်ခုကို ပုံဖော်ရန် လွယ်ကူသည်။ သင်ပြောခဲ့သော မြစ်ဝကျွန်းပေါ်ဒေသ၊ ဤကိုယ်ပွားများ နေထိုင်မည့်နေရာကို သင်မည်ကဲ့သို့ တွက်ချက်သနည်း။

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

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

clone တစ်ခုစီအတွက် ttl အချို့ရှိသည်။ အခြေခံအားဖြင့်၊ ကျွန်ုပ်တို့တွင် ပုံသေ ttl ရှိသည်။

လျှို့ဝှက်ချက်မဟုတ်ရင် ဘာဖြစ်မလဲ။

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

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

ZFS ၏အဓိကပြဿနာကဘာလဲ။ တူညီသော host တွင် run ရမည်ဟူသောအချက်မှာ ဥပမာအားလုံးသည် တူညီသော OS တွင်ရှိနေမည်ဖြစ်သည်။ သိုလှောင်မှုကိစ္စတွင် သင်သည် မတူညီသော ပစ္စည်းကိရိယာများကို ချိတ်ဆက်နိုင်သည်။ ပိတ်ဆို့မှုများသည် သိုလှောင်မှုစနစ်တွင်ရှိသော တုံးများသာဖြစ်သည်။ နည်းပညာရွေးချယ်မှုမေးခွန်းက စိတ်ဝင်စားစရာပါ။ ဘာကြောင့် LVM မလုပ်တာလဲ။

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

Nikolai Samokhvalov- နောက်ထပ် မှတ်ချက်ပေးလို့ရမလား။ ငါ့နာမည်က Nikolay ပါ၊ ငါတို့ Anatoly နဲ့ အတူအလုပ်လုပ်တယ်။ သိုလှောင်မှုကောင်းသည်ဟု ကျွန်တော်သဘောတူပါသည်။ ကျွန်ုပ်တို့၏ဖောက်သည်အချို့တွင် Pure Storage စသည်တို့ရှိသည်။

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

ဒါပေမယ့် ZFS ကို လူတိုင်းရနိုင်ပါတယ်။ DelPhix သည် လုံလောက်နေပြီ၊ ၎င်းတို့တွင် ဖောက်သည် ၃၀၀ ရှိသည်။ အဲဒီအထဲမှာ Fortune 300 မှာ ဖောက်သည် 100 ရှိပါတယ်၊ ဆိုလိုသည်မှာ ၎င်းတို့သည် NASA ကို ရည်ရွယ်ထားခြင်း၊ စသဖြင့်၊ ဤနည်းပညာကို လူတိုင်းရရန် အချိန်တန်ပြီဖြစ်သည်။ ထို့ကြောင့် ကျွန်ုပ်တို့တွင် open source Core တစ်ခုရှိသည်။ ကျွန်ုပ်တို့တွင် open source မဟုတ်သော interface အပိုင်းတစ်ခုရှိသည်။ ဤသည်မှာ ကျွန်ုပ်တို့ပြသမည့် platform ဖြစ်သည်။ ဒါပေမယ့် လူတိုင်းလက်လှမ်းမီစေချင်တယ်။ စမ်းသပ်သူများအားလုံး လက်ပ်တော့များကို မှန်းဆခြင်းကို ရပ်သွားစေရန် တော်လှန်ရေးတစ်ရပ်ကို ပြုလုပ်လိုပါသည်။ SELECT ရေးပြီး နှေးနေတာကို ချက်ချင်းတွေ့ရပါမယ်။ ဒီအကြောင်းပြောပြဖို့ DBA ကို စောင့်မနေပါနဲ့။ ဤတွင် အဓိကပန်းတိုင်ဖြစ်သည်။ ပြီးတော့ ငါတို့အားလုံး ဒီကိုလာမယ်လို့ ငါထင်တယ်။ ပြီးတော့ ဒီအရာကို လူတိုင်းရှိဖို့ ကျွန်တော်တို့ လုပ်ပါတယ်။ ထို့ကြောင့် ZFS ကို နေရာတိုင်းတွင် ရနိုင်သောကြောင့်ဖြစ်သည်။ ပြဿနာများကိုဖြေရှင်းပေးသည့်အတွက်နှင့် open source လိုင်စင်ရှိခြင်းစသဖြင့်။*

မင်္ဂလာပါ အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်တော့်နာမည် Maxim ပါ။ တူညီသောပြဿနာများကို ကျွန်ုပ်တို့ဖြေရှင်းခဲ့ပြီးဖြစ်သည်။ သူတို့ဘာသာသူတို့ဆုံးဖြတ်တယ်။ ဤ clone များကြားတွင် အရင်းအမြစ်များကို သင်မည်သို့မျှဝေမည်နည်း။ ကိုယ်ပွားတစ်ခုစီသည် သတ်မှတ်ထားသည့်အချိန်တိုင်းတွင် ၎င်း၏ကိုယ်ပိုင်အရာကို လုပ်ဆောင်နိုင်သည်- တစ်ခုသည် အရာတစ်ခုကို စမ်းသပ်သည်၊ နောက်တစ်ခုက၊ တစ်စုံတစ်ဦးသည် အညွှန်းကိန်းတစ်ခုကို တည်ဆောက်သည်၊ တစ်စုံတစ်ဦးသည် လေးလံသောအလုပ်ရှိသည်။ CPU နဲ့ ခွဲနိုင်သေးရင် IO နဲ့ ဘယ်လိုခွဲမလဲ။ ဒါက ပထမမေးခွန်းပါ။

ဒုတိယမေးခွန်းကတော့ ရပ်တည်မှုရဲ့ ကွဲပြားမှုအကြောင်းပါ။ ငါ့မှာ ZFS ရှိတယ်ဆိုပါစို့၊ အရာအားလုံးက အေးဆေးပါပဲ၊ ဒါပေမယ့် prod ပေါ်က client မှာ ZFS မရှိဘူး၊ ဥပမာ ext4။ ဒီကိစ္စမှာ ဘယ်လိုလဲ။

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

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

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

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

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

သို့သော် စနစ်သည် တိုးချဲ့နိုင်သောကြောင့်၊ ၎င်းကို MySQL တွင်လည်း အသုံးပြုနိုင်သည်။ ပြီးတော့ အဲဒီလို ဥပမာတွေရှိတယ်။ Yandex တွင် အလားတူအရာတစ်ခုရှိသော်လည်း ၎င်းတို့သည် မည်သည့်နေရာတွင်မျှ ထုတ်ဝေခြင်းမပြုပါ။ ၎င်းတို့သည် Yandex.Metrica တွင် အသုံးပြုသည်။ ပြီးတော့ MySQL နဲ့ ပတ်သက်တဲ့ ဇာတ်လမ်းတစ်ခုပဲ ရှိပါတယ်။ ဒါပေမယ့် နည်းပညာတွေက ZFS နဲ့အတူတူပါပဲ။

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

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

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

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

အညွှန်းကို အချိန်တိုင်း ဖန်တီးပေးမှာလား။

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

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

ဒါကလည်း ပြဿနာပါ။ အကယ်၍ သင်သည် cloud ဖြေရှင်းချက်ကို အသုံးပြုပါက၊ ယုတ္တိတန်သော အမှိုက်ပုံများသာ ရရှိနိုင်သည်၊ အကြောင်းမှာ Google၊ Amazon သည် သင့်အား ရုပ်ပိုင်းဆိုင်ရာ ကော်ပီယူရန် ခွင့်မပြုသောကြောင့် ဖြစ်သည်။ ပြဿနာရှိလာမယ်။

အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါတယ်။ ဤနေရာတွင် MySQL နှင့် အရင်းအမြစ်မျှဝေခြင်းဆိုင်ရာ မေးခွန်းကောင်းနှစ်ခုရှိသည်။ သို့သော်၊ အမှန်မှာ၊ ဤအရာသည် သီးခြား DBMS ၏အကြောင်းအရာမဟုတ်သော်လည်း ဖိုင်စနစ်တစ်ခုလုံး၏အချက်တစ်ချက်ဖြစ်သည်။ ထို့ကြောင့်၊ အရင်းအမြစ်ခွဲဝေမှုဆိုင်ရာ ပြဿနာများကို အဆုံးတွင် မဟုတ်ဘဲ Postgres မဟုတ်ဘဲ ဖိုင်စနစ်၊ ဆာဗာတွင်၊ ဥပမာအားဖြင့် ဖြေရှင်းသင့်ပါသည်။

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

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

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

ယခင်ပုံတူပွားမှုများမှ ဖြစ်ခဲ့သော ယခင်အလွှာများမှ။

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

ယေဘူယျအားဖြင့် ဟုတ်ပါတယ်။

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

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

မင်္ဂလာပါ အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါတယ်။ ဂျိုးအကြောင်းမေးခွန်း။ ဖောက်သည်က လူတိုင်းကို ဒေတာကို ဝင်သုံးခွင့်မပေးလိုကြောင်း သင်ပြောခဲ့သည်။ အတိအကျပြောရလျှင် လူတစ်ဦးသည် Explain Analyze ၏ ရလဒ်များ ရှိပါက အချက်အလက်ကို ပြနိုင်မည်ဖြစ်သည်။

အဲဒါက ဒီလိုပါပဲ။ ဥပမာအားဖြင့်၊ "SELECT FROM WHERE email = to that" ဟု ရေးနိုင်သည်။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် ဒေတာကို ကိုယ်တိုင်မြင်ရမည်မဟုတ်သော်လည်း အချို့သော သွယ်ဝိုက်သောလက္ခဏာများကို ကျွန်ုပ်တို့တွေ့မြင်နိုင်ပါသည်။ ဒါကို နားလည်ရမယ်။ ဒါပေမယ့် တစ်ဖက်မှာလည်း အဲဒါတွေရှိတယ်။ ကျွန်ုပ်တို့တွင် မှတ်တမ်းစာရင်းစစ်တစ်ခုရှိပြီး ဆော့ဖ်ဝဲရေးသားသူများ လုပ်ဆောင်နေသည်ကိုလည်း တွေ့မြင်ရသော အခြားလုပ်ဖော်ကိုင်ဖက်များကို ထိန်းချုပ်နိုင်သည်။ တစ်စုံတစ်ယောက်က ဒါကိုလုပ်ဖို့ကြိုးစားရင် လုံခြုံရေးဝန်ဆောင်မှုက သူတို့ဆီလာပြီး ဒီကိစ္စကို လုပ်ဆောင်ပါလိမ့်မယ်။

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

ယခု Slack သို့ လင့်ခ်တစ်ခု ရှိလာသည်၊ ဆိုလိုသည်မှာ အခြား messenger မရှိတော့သော်လည်း အခြား messenger များအတွက်လည်း အထောက်အကူ ဖြစ်စေလိုပါသည်။ သင်ဘာလုပ်နိုင်သလဲ။ Joe မပါဘဲ DB Lab ကို သင်အသုံးပြုနိုင်သည်၊ REST API ၏အကူအညီဖြင့် သို့မဟုတ် ကျွန်ုပ်တို့၏ပလပ်ဖောင်း၏အကူအညီဖြင့် သွားပြီး clones ဖန်တီးပြီး PSQL နှင့်ချိတ်ဆက်နိုင်သည်။ သို့သော် သင်သည် သင်၏ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအား ဒေတာအသုံးပြုခွင့်ပေးရန် အဆင်သင့်ဖြစ်နေပါက၊ မည်သည့်စခရင်မှ ရှိတော့မည်မဟုတ်သောကြောင့် ၎င်းကို လုပ်ဆောင်နိုင်ပါသည်။

ဒီအလွှာကို မလိုပါဘူး၊ ဒါပေမယ့် အခွင့်အရေးတစ်ခုတော့ လိုအပ်တယ်။

ဒါဆိုရင်တော့ လုပ်လို့ရတယ်။

source: www.habr.com