HighLoad++၊ Mikhail Tyulenev (MongoDB)- အကြောင်းရင်းညီညွတ်မှု- သီအိုရီမှ လက်တွေ့

လာမည့် HighLoad++ ကွန်ဖရင့်ကို စိန့်ပီတာစဘတ်တွင် 6 ခုနှစ် ဧပြီလ 7 ရက်နှင့် 2020 ရက်တို့တွင် ကျင်းပမည်ဖြစ်သည်။
အသေးစိတ်အချက်အလက်များနှင့်လက်မှတ်များ လင့်ခ်. HighLoad++ ဆိုက်ဘေးရီးယား 2019။ ခန်းမ "Krasnoyarsk"။ ဇွန်လ 25 ရက်နေ့ 12:00 ။ ဤအကြောင်းအရာများနှင့် တင်ဆက်မှု.

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

Mikhail Tyulenev (နောင် MT အဖြစ်ရည်ညွှန်းသည်) - Causal ညီညွတ်မှုအကြောင်းပြောပါမယ် - ဒါက MongoDB မှာ ကျွန်တော်တို့ လုပ်ဆောင်ခဲ့တဲ့ အင်္ဂါရပ်တစ်ခုပါ။ ဖြန့်ဝေတဲ့စနစ်အုပ်စုမှာ ကျွန်တော်အလုပ်လုပ်တယ်၊ လွန်ခဲ့တဲ့နှစ်နှစ်လောက်က လုပ်ခဲ့တယ်။

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

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

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

စစချင်းမှာ Causal ညီညွတ်ခြင်းဆိုတာ ယေဘူယျအားဖြင့် ပြောချင်ပါတယ်။ Leonard နှင့် Penny (တီဗီစီးရီး "The Big Bang Theory") တွင် ဇာတ်ကောင် နှစ်ဦးရှိသည်။

Penny သည် ဥရောပတွင်ရှိပြီး Leonard သည် သူမအား အံ့အားသင့်ဖွယ် ပါတီပွဲတစ်ခု ပြုလုပ်လိုသည်ဟု ဆိုကြပါစို့။ ပြီးတော့ သူ့သူငယ်ချင်းစာရင်းကနေ ဖယ်ထုတ်လိုက်တာထက် ပိုကောင်းတဲ့အရာကို မတွေးနိုင်တော့ဘဲ သူ့သူငယ်ချင်းအားလုံးကို feed မှာ အပ်ဒိတ်တစ်ခု ပို့လိုက်တယ်- "Penny ပျော်ရအောင်!" (သူမက ဥရောပမှာနေပြီး အိပ်ပျော်နေချိန်မှာ ဒါတွေအားလုံးကို မမြင်ရတာကြောင့် မမြင်နိုင်ပါဘူး)။ နောက်ဆုံးတွင်၊ သူမသည် ဤပို့စ်ကို ဖျက်လိုက်သည်၊ ၎င်းကို ဖိဒ်မှ ဖျက်ကာ မည်သည့်အရာကိုမျှ သတိမထားမိစေရန်နှင့် အရှုပ်အရှင်းမရှိစေရန်အတွက် ဝင်ရောက်ခွင့်ကို ပြန်လည်ရယူသည်။
ဤအရာအားလုံး ကောင်းမွန်ပြီး ကောင်းမွန်သော်လည်း စနစ်သည် ဖြန့်ဝေနေပြီး အရာအနည်းငယ် မှားယွင်းသွားသည်ဟု ယူဆကြပါစို့။ ဥပမာအားဖြင့်၊ ဖြစ်ရပ်များသည် အကြောင်းတရားနှင့် အကျိုးသက်ရောက်မှုဖြင့် မသက်ဆိုင်ပါက ဤပို့စ်တွင် ပေါ်လာပြီးနောက် Penny ၏ ဝင်ရောက်ခွင့် ကန့်သတ်ချက် ဖြစ်သွားနိုင်သည်။ တကယ်တော့၊ ဒါက လုပ်ငန်းတစ်ခုလုပ်ဆောင်ဖို့အတွက် Causal ညီညွတ်မှုလိုအပ်တဲ့အခါ ဥပမာတစ်ခု (ဒီကိစ္စမှာ)။

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

ကိုက်ညီမှုပုံစံများ

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

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

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

Model Strong ပါ။

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

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

External Consistency ဟုခေါ်သော Spanner တွင် ပံ့ပိုးထားသည့် နောက်ထပ် ပိုမိုအားကောင်းသည့် ပိုင်ဆိုင်မှုတစ်ခုရှိသည်။ အဲဒါကို နောက်မှပြောမယ်။

အကြောင်းရင်း

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

အကြောင်းရင်းများသည် အမှန်တကယ်အားဖြင့် ဖြစ်ရပ်များနှင့် အကျိုးဆက်ဆက်စပ်မှုဖြင့် ဆက်စပ်နေသည့် အခြေအနေတစ်ခုဖြစ်သည်။ ဖောက်သည်၏အမြင်မှ Read your on rights ဟု အများအားဖြင့် ထင်မြင်ကြသည်။ အကယ်၍ client သည် အချို့သောတန်ဖိုးများကို သတိပြုမိပါက၊ သူသည် အတိတ်ကတန်ဖိုးများကို မမြင်နိုင်ပါ။ သူသည် ရှေ့ပြေးစာဖတ်ခြင်းကို စတင်မြင်နေပြီဖြစ်သည်။ အားလုံးက အတူတူပါပဲ။
ညီညွတ်မှုပုံစံတစ်ခုအနေဖြင့် အကြောင်းရင်းများသည် ဆာဗာပေါ်ရှိ အဖြစ်အပျက်များ၏ တစ်စိတ်တစ်ပိုင်း စီစဥ်မှုတစ်ခုဖြစ်ပြီး သုံးစွဲသူများအားလုံးမှ အဖြစ်အပျက်များကို တူညီသောအစီအစဥ်ဖြင့် ကြည့်ရှုသည်။ ဤကိစ္စတွင် Leonard နှင့် Penny ။

နောက်ဆုံးတွင်

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

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

နှိုင်းယှဥ်ပုံအချို့ကို တင်ပြလိုပါသည်။

ဒီမြှားတွေက ဘာကို ဆိုလိုတာလဲ။

• ငံနေချိန်။ ညီညွတ်မှုအားကောင်းလာသည်နှင့်အမျှ၊ ၎င်းသည် ထင်ရှားသောအကြောင်းပြချက်များအတွက် ပိုမိုကြီးမားလာသည်- သင်သည် မှတ်တမ်းများပိုမိုပြုလုပ်ရန် လိုအပ်ပြီး၊ ဒေတာရှိပြီးသားဖြစ်ကြောင်း အစုအဝေးတွင်ပါဝင်သည့် host နှင့် node အားလုံးထံမှ အတည်ပြုချက်ရယူပါ။ ထို့ကြောင့်၊ Eventual Consistency တွင် အလျင်မြန်ဆုံးအဖြေရှိသည်၊ အကြောင်းမှာ၊ စည်းကမ်းအတိုင်း၊ သင်သည် ၎င်းအား မှတ်ဉာဏ်တွင်ပင် အပ်နှံနိုင်ပြီး၊ မူအားဖြင့် လုံလောက်မည်ဖြစ်သည်။
• ရရှိနိုင်။ ကွန်ရက်ပြတ်တောက်မှုများ၊ အပိုင်းပိုင်းများ သို့မဟုတ် ချို့ယွင်းမှုအချို့ရှိနေချိန်တွင် ဤအရာကို စနစ်၏တုံ့ပြန်နိုင်စွမ်းအဖြစ် ကျွန်ုပ်တို့နားလည်ပါက၊ အိမ်ရှင်တစ်ဦးသည် ကျွန်ုပ်တို့နှင့် အတူတူနေထိုင်ရန် လုံလောက်သောကြောင့် အမှားခံနိုင်ရည်တိုးလာပါသည်။ အချိန်သည် အချက်အလက်အချို့ကို ထုတ်လုပ်သည်။ နောက်ဆုံး ကိုက်ညီမှုရှိသော အချက်အလက်နှင့် ပတ်သက်၍ မည်သည့်အရာကိုမျှ အာမမခံနိုင်ပါ - ၎င်းသည် ဘာမဆို ဖြစ်နိုင်သည်။
• ကွဲလွဲချက်များ။ တစ်ချိန်တည်းမှာပင်၊ ဟုတ်ပါတယ်၊ ကွဲလွဲချက်အရေအတွက် တိုးလာပါတယ်။ Strong Consistency တွင် ၎င်းတို့သည် လုံးဝနီးပါး မဖြစ်သင့်သော်လည်း နောက်ဆုံး Consistency တွင် ၎င်းတို့သည် ဘာမဆို ဖြစ်နိုင်သည်။ မေးခွန်းပေါ်လာသည်- ၎င်းတွင် ကွဲလွဲချက်များပါရှိလျှင် လူတို့သည် အဘယ်ကြောင့် နောက်ဆုံးတွင် ကိုက်ညီမှုကို ရွေးချယ်ကြသနည်း။ အဖြေမှာ နောက်ဆုံးသော ကိုက်ညီမှုရှိသော ပုံစံများသည် အသုံးချနိုင်ပြီး ကွဲလွဲချက်များ ရှိသည်၊ ဥပမာ၊ အချိန်တိုအတွင်း၊ တစ်သမတ်တည်းဒေတာကိုဖတ်ရန် wizard ကိုသုံး၍ အနည်းနှင့်အများဖတ်ရန် ဖြစ်နိုင်သည်။ ခိုင်ခံ့သော လိုက်လျောညီထွေမှုရှိသော ပုံစံများကို အသုံးပြုရန် မကြာခဏ ဖြစ်နိုင်သည်။ လက်တွေ့တွင် ယင်းသည် အလုပ်ဖြစ်ပြီး မကြာခဏ ကွဲလွဲချက်များ အရေအတွက်မှာ အချိန်အကန့်အသတ်ရှိသည်။

CAP သီအိုရီ

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

CAP သီအိုရီသည် ညီညွတ်မှု၊ ရရှိနိုင်မှု၊ အပိုင်းခွဲများ- ၂၀၀၀ ပြည့်နှစ်များတွင် ရေးဆွဲထားသည့် နိယာမတစ်ခုဖြစ်သည်။ ဒါဟာ တိကျတဲ့ နိယာမတစ်ခုပါ။ Gilbert နှင့် Lynch တို့က နှစ်အနည်းငယ်ကြာပြီးနောက် သီအိုရီတစ်ခုအဖြစ် သက်သေပြခဲ့သည်။ ထို့နောက် ၎င်းကို မန္တန်တစ်ခုအဖြစ် စတင်အသုံးပြုခဲ့သည် - စနစ်များကို CA၊ CP၊ AP စသည်ဖြင့် ခွဲခြားစပြုလာသည်။

ဤသီအိုရီကို အောက်ပါကိစ္စများအတွက် အမှန်တကယ် သက်သေပြခဲ့သည်... ပထမဦးစွာ၊ ရရှိနိုင်မှုကို သုညမှ ရာဂဏန်းအထိ ဆက်တိုက်တန်ဖိုးအဖြစ် မယူဆပါ (0 - စနစ်သည် "သေပြီ"၊ 100 - လျင်မြန်စွာ တုံ့ပြန်သည်၊ ၎င်းကို ကျွန်ုပ်တို့ စဉ်းစားလေ့ရှိသည်) ဒါပေမယ့် algorithm ရဲ့ ပိုင်ဆိုင်မှုတစ်ခုအနေနဲ့ သူ့ရဲ့လုပ်ဆောင်မှုအားလုံးအတွက် ဒေတာကို ပြန်ပေးတယ်လို့ အာမခံပါတယ်။

တုံ့ပြန်ချိန်နှင့်ပတ်သက်ပြီး စကားလုံးဝမရှိပါ။ အနှစ် 100 ပြီးနောက် ဒေတာကို ပြန်ပေးသည့် အယ်လဂိုရီသမ်တစ်ခု ရှိသည် - CAP သီအိုရီ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည့် လုံးဝကို အံ့သြဖွယ်ရရှိနိုင်သော အယ်လဂိုရီသမ်တစ်ခုရှိသည်။
ဒုတိယအချက်- ဤပြောင်းလဲမှုများသည် အရွယ်အစားပြောင်းလဲနိုင်သောအချက်များရှိနေသော်လည်း တူညီသောသော့တန်ဖိုးများ၏ပြောင်းလဲမှုများအတွက် သီအိုရီကို သက်သေပြခဲ့သည်။ ဆိုလိုသည်မှာ လက်တွေ့တွင် ၎င်းတို့သည် လက်တွေ့ကျကျ အသုံးမချနိုင်သောကြောင့် မော်ဒယ်များသည် Eventual Consistency၊ Strong Consistency (ဖြစ်နိုင်သည်)။

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

အကြောင်းရင်း ညီညွတ်မှုသည် အခိုင်မာဆုံး မော်ဒယ်ဖြစ်သည်။

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

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

MongoDB အတွင်းပိုင်းမီးဖိုချောင်

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

MongoDB (နောင်တွင် “MongoDB” ဟုရည်ညွှန်းသည်) သည် အလျားလိုက်စကေးဖြတ်ခြင်းကို ပံ့ပိုးပေးသည့် ဖြန့်ဝေသည့်စနစ်တစ်ခုဖြစ်ပြီး၊ နှင့် shard တစ်ခုစီတွင်၎င်းသည် data redundancy ၊ ဆိုလိုသည်မှာ replication ကိုလည်းထောက်ပံ့ပေးသည်။

MongoDB တွင် Sharding (ဆက်စပ်ဒေတာဘေ့စ်မဟုတ်) သည် အလိုအလျောက်ချိန်ခွင်လျှာကိုလုပ်ဆောင်သည်၊ ဆိုလိုသည်မှာ စာရွက်စာတမ်းများစုစည်းမှုတစ်ခုစီ (သို့မဟုတ် ဆက်စပ်အချက်အလက်များ၏သတ်မှတ်ချက်အရ "ဇယား") ကိုအပိုင်းပိုင်းများခွဲကာ ဆာဗာသည် ၎င်းတို့ကို shards များကြားတွင် အလိုအလျောက်ရွှေ့ပေးပါသည်။

တောင်းဆိုမှုများကို ဖြန့်ဝေပေးသော Query Router သည် client တစ်ခုအတွက် အလုပ်လုပ်သော client အချို့ဖြစ်သည်။ ၎င်းသည် မည်သည့်နေရာနှင့် မည်သည့်ဒေတာတည်ရှိသည်ကို သိရှိထားပြီး တောင်းဆိုမှုအားလုံးကို မှန်ကန်သော shard သို့ လမ်းညွှန်ပေးသည်။

နောက်ထပ်အရေးကြီးသောအချက်- MongoDB သည် မာစတာတစ်ခုတည်းဖြစ်သည်။ Primary တစ်ခုရှိသည် - ၎င်းတွင်ပါရှိသောသော့များကိုပံ့ပိုးပေးသောမှတ်တမ်းများကိုယူနိုင်သည်။ Multi-master ရေးလို့ မရပါဘူး။

ကျွန်ုပ်တို့သည် 4.2 ကိုဖြန့်ချိခဲ့သည် - အဲဒီမှာ စိတ်ဝင်စားစရာကောင်းတဲ့ အရာအသစ်တွေပေါ်လာတယ်။ အထူးသဖြင့်၊ ၎င်းတို့သည် Lucene - search - အမည်ရ executable java ကို Mongo သို့ တိုက်ရိုက်ထည့်သွင်းခဲ့ပြီး Elastica ကဲ့သို့ပင် Lucene မှတဆင့် ရှာဖွေမှုများ လုပ်ဆောင်နိုင်ခဲ့သည်။

၎င်းတို့သည် ထုတ်ကုန်အသစ်တစ်ခုပြုလုပ်ခဲ့သည် - Charts၊ ၎င်းကို Atlas (Mongo ၏ကိုယ်ပိုင် Cloud) တွင်လည်း ရရှိနိုင်ပါသည်။ ၎င်းတို့တွင် Free Tier ရှိသည် - သင် ၎င်းနှင့် အတူကစားနိုင်သည်။ Charts တွေကို အရမ်းကြိုက်တယ် - data visualization ကို အရမ်းအလိုလိုသိတယ်။

ပါဝင်ပစ္စည်းများ အကြောင်းရင်း ညီညွတ်မှု

Leslie Lampert မှ ဤအကြောင်းအရာနှင့် ပတ်သက်၍ ထုတ်ဝေထားသော ဆောင်းပါး 230 ခန့်ကို ကျွန်ုပ်ရေတွက်ခဲ့ပါသည်။ ယခု ကျွန်ုပ်၏ မှတ်ဉာဏ်မှ ဤပစ္စည်းများ၏ အစိတ်အပိုင်းအချို့ကို သင့်အား ပြောပြပါမည်။

1970 ခုနှစ်များအတွင်း ရေးသားခဲ့သော Leslie Lampert ၏ ဆောင်းပါးဖြင့် အစပြုခဲ့သည်။ သင်တွေ့မြင်ရသည့်အတိုင်း ဤအကြောင်းအရာနှင့်ပတ်သက်၍ သုတေသနအချို့ကို ဆက်လက်လုပ်ဆောင်နေဆဲဖြစ်သည်။ ယခု Causal တစ်သမတ်တည်းဖြစ်မှုသည် ဖြန့်ဝေမှုစနစ်များ ဖွံ့ဖြိုးတိုးတက်ရေးနှင့် စပ်လျဉ်း၍ စိတ်ဝင်စားမှုကို ခံနေရပါသည်။

ကန့်သတ်

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

• ပထမဦးစွာ၊ "MongoDB" သည်ကျွန်ုပ်ပြောခဲ့သည့်အတိုင်း (၎င်းသည်အလွန်ရိုးရှင်းသည်) ။
• စနစ်သည် shard 10 ခန့်ကိုထောက်ပံ့ပေးသင့်သည်ဟုကျွန်ုပ်တို့ယုံကြည်သည်။ ဤတန်ဖိုးကို ပြတ်သားစွာ ကန့်သတ်မည့် ဗိသုကာဆိုင်ရာ ဆုံးဖြတ်ချက်များကို ကျွန်ုပ်တို့ မပြုလုပ်နိုင်ပါ။
• ကျွန်ုပ်တို့တွင် cloud တစ်ခုရှိသော်လည်း လူတစ်ဦးသည် binary ကိုဒေါင်းလုဒ်လုပ်ကာ ၎င်း၏လက်ပ်တော့ပေါ်တွင် run သည့်အခါတွင် အခွင့်အရေးရှိနေဆဲဟု ကျွန်ုပ်တို့ယူဆပါသည်။
• သုတေသနမှ ရှားရှားပါးပါး ယူဆသည့် အရာတစ်ခုဟု ကျွန်ုပ်တို့ ယူဆသည်- ပြင်ပဖောက်သည်များသည် ၎င်းတို့ လိုချင်သမျှကို လုပ်ဆောင်နိုင်သည်။ MongoDB သည် open source ဖြစ်သည်။ ထို့ကြောင့်၊ ဖောက်သည်များသည် အလွန်ထက်မြက်ပြီး စိတ်ဆိုးနိုင်သည် - ၎င်းတို့သည် အရာအားလုံးကို ဖောက်ဖျက်ချင်နိုင်သည်။ Byzantine Feilors မှအစပြုနိုင်သည်ဟုကျွန်ုပ်တို့ယူဆပါသည်။
• ပတ်၀န်းကျင်ပြင်ပရှိ ပြင်ပဖောက်သည်များအတွက် အရေးကြီးသောကန့်သတ်ချက်တစ်ခုရှိသည်- ဤအင်္ဂါရပ်ကိုပိတ်ထားပါက၊ စွမ်းဆောင်ရည်ကျဆင်းခြင်းကို သတိပြုသင့်သည်။
• အခြားအချက်မှာ ယေဘုယျအားဖြင့် ဆန့်ကျင်ဘက်ဖြစ်သော ပညာရေးဖြစ်သည်- ယခင်ဗားရှင်းများနှင့် အနာဂတ်ဗားရှင်းများ၏ လိုက်ဖက်ညီမှုဖြစ်သည်။ ဒရိုက်ဘာဟောင်းများသည် အပ်ဒိတ်အသစ်များကို ပံ့ပိုးပေးရမည်၊ ဒေတာဘေ့စ်သည် ဒရိုက်ဗာအဟောင်းများကို ပံ့ပိုးပေးရမည်ဖြစ်သည်။

ယေဘုယျအားဖြင့်၊ ဤအရာအားလုံးသည် ကန့်သတ်ချက်များ ချမှတ်ထားသည်။

အကြောင်းရင်း ညီညွတ်မှု အစိတ်အပိုင်းများ

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

အပြည့်အဝမှီခိုခြေရာခံခြင်း။

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

ဤဥပမာတွင်၊ curly brackets ရှိ နံပါတ်သည် မှတ်တမ်းနံပါတ်များဖြစ်သည်။ တစ်ခါတစ်ရံတွင် ဤတန်ဖိုးများပါသော မှတ်တမ်းများကို ၎င်းတို့၏ တစ်ခုလုံးကို လွှဲပြောင်းပေးသည်၊ တစ်ခါတစ်ရံ အချို့သောဗားရှင်းများကို လွှဲပြောင်းပေးပါသည်။ အဓိကအချက်မှာ ပြောင်းလဲမှုတစ်ခုစီတွင် ယခင်တစ်ခုနှင့်ပတ်သက်သည့် အချက်အလက်ပါရှိသည် (ဤအရာအားလုံးကို သူ့အလိုလို သယ်ဆောင်သွားသည်မှာ သိသာထင်ရှားသည်)။

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

တိကျသောမှီခိုမှုခြေရာခံခြင်း။

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

မှတ်တမ်း 5 သည် မှတ်တမ်း 1၊ 2၊ 3၊ 4 ပေါ်တွင်မူတည်သည်ဟု သူမမြင်သည် - ထို့ကြောင့်၊ ယခင်ပြောင်းလဲမှုအားလုံးသည် ဒေတာဘေ့စ်မှဖြတ်သန်းပြီးသောအခါတွင် သုံးစွဲသူသည် Penny ၏ဝင်ရောက်ခွင့်ဆုံးဖြတ်ချက်မှပြုလုပ်သော အပြောင်းအလဲများကို မဝင်ရောက်မီ စောင့်မျှော်နေပါသည်။

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

Lamport နာရီ

သူတို့က အရမ်းဟောင်းတယ်။ Lamport Clock ဆိုသည်မှာ ဤမှီခိုအားထားမှုများကို Lamport Clock ဟုခေါ်သော scalar လုပ်ဆောင်ချက်အဖြစ် ခေါက်ထားသည်။

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

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

Feed ပေါ်ရှိ တန်ပြန်အချိန်သည် ယုတ္တိနည်းကျကျ တိုးလာသည်ကို သင်မြင်ရသည်-

ထို့ကြောင့် ဤ Lamport Clock နှင့် Causal ညီညွတ်မှု (Lamport Clock မှတဆင့် ရှင်းပြထားသည်) သည် ဤအရာဖြစ်သည်- အကယ်၍ ကျွန်ုပ်တို့တွင် Events A နှင့် B ရှိပါက Event B သည် Event A* ပေါ်တွင်မူတည်သည်၊ ထို့နောက် Event A ၏ LogicalTime သည် A ထက်နည်းနေပါသည်။ Event B မှ LogicalTime

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

ဆန့်ကျင်ဘက်သည် မမှန်ပါ။ ဤသည်မှာ Lamport Clock ၏ အဓိက အားနည်းချက်များထဲမှ တစ်ခုဖြစ်ပြီး တစ်စိတ်တစ်ပိုင်း မှာယူမှုဖြစ်သည်။ တစ်ပြိုင်နက်တည်း အဖြစ်အပျက်များအကြောင်း အယူအဆတစ်ခု ရှိသည်၊ ဆိုလိုသည်မှာ (A မဖြစ်မီ B) နှင့် (A မဖြစ်မီ B) ဖြစ်ခဲ့သော အဖြစ်အပျက်များဖြစ်သည်။ ဥပမာတစ်ခုသည် အခြားသူတစ်ဦးအား သူငယ်ချင်းအဖြစ် လီယိုနာ့ဒ်၏ ပြိုင်တူပေါင်းထည့်ခြင်းဖြစ်သည် (ဥပမာ လီယိုနာ့ဒ်ပင်မဟုတ်၊ Sheldon၊)။
ဤအရာသည် Lamport နာရီများနှင့် အလုပ်လုပ်သောအခါတွင် မကြာခဏအသုံးပြုလေ့ရှိသည့် ပိုင်ဆိုင်မှုဖြစ်သည်- ၎င်းတို့သည် လုပ်ဆောင်ချက်ကို အတိအကျကြည့်ကာ ဤဖြစ်ရပ်များပေါ်တွင်မူတည်သည်ဟု ကောက်ချက်ချကြသည်။ နည်းလမ်းတစ်ခုသည် မှန်သောကြောင့်ဖြစ်သည်- LogicalTime A သည် LogicalTime B ထက်နည်းပါက၊ B သည် A မတိုင်မီမဖြစ်နိုင်ပါ။ ပိုရင်၊ ဖြစ်ကောင်းဖြစ်မယ်။

Vector နာရီ

Lamport နာရီ၏ ယုတ္တိနည်းကျ ဖွံ့ဖြိုးတိုးတက်မှုသည် Vector Clock ဖြစ်သည်။ ၎င်းတို့သည် ဤနေရာတွင်ရှိသော node တစ်ခုစီတွင် ၎င်း၏သီးခြားနာရီများပါ၀င်ပြီး ၎င်းတို့ကို vector တစ်ခုအဖြစ် ပေးပို့ခြင်းတွင် ကွဲပြားသည်။
ဤကိစ္စတွင်၊ vector ၏ သုညညွှန်းကိန်းသည် Feed အတွက် တာဝန်ရှိသည်ကို သင်တွေ့မြင်ရပြီး vector ၏ ပထမအညွှန်းသည် Friends (ဤ node တစ်ခုစီ) အတွက်ဖြစ်သည်။ ယခု ၎င်းတို့ တိုးလာပါမည်- "Feed" ၏ သုညအညွှန်းကိန်း တိုးလာသည် - 1၊ 2၊ 3-

Vector Clock က ဘာကြောင့် ပိုကောင်းတာလဲ။ အဘယ်ကြောင့်ဆိုသော် ၎င်းတို့သည် သင့်အား မည်သည့်ဖြစ်ရပ်များ တပြိုင်နက်တည်းဖြစ်ပြီး ၎င်းတို့သည် မတူညီသော node များတွင် ဖြစ်ပျက်နေသည်ကို တွက်ချက်နိုင်သောကြောင့်ဖြစ်သည်။ ၎င်းသည် MongoDB ကဲ့သို့သော ခွဲခြမ်းစိပ်ဖြာစနစ်အတွက် အလွန်အရေးကြီးပါသည်။ ဒါပေမယ့် အဲဒါက အံ့ဩစရာ ကောင်းပေမယ့် အဲဒါကို ငါတို့က မရွေးဘဲ၊ အဲဒါက အရမ်းကောင်းပြီး ငါတို့နဲ့ လိုက်ဖက်မယ့်...

အကယ်၍ ကျွန်ုပ်တို့တွင် shard 10 ရှိပါက၊ ၎င်းကို compress သို့မဟုတ် အခြားတစ်ခုခုနှင့် ပေါ်လာလျှင်ပင် အစိတ်အပိုင်း 10 ကို လွှဲပြောင်းပေးနိုင်မည် မဟုတ်ပါ - payload သည် ဤ vector တစ်ခုလုံး၏ volume ထက် အဆများစွာ သေးငယ်နေသေးသည်။ ထို့ကြောင့် ကျွန်ုပ်တို့၏ နှလုံးသားနှင့် သွားများကို အံကြိတ်ကာ ဤချဉ်းကပ်မှုကို စွန့်လွှတ်ကာ အခြားသို့ ဆက်သွားခဲ့သည်။

Spanner TrueTime အနုမြူနာရီ

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

ဘာအကြံလဲ? “Spanner” သည် မကြာသေးမီကပင် လူများအတွက် အသုံးပြုခွင့်ရရှိခဲ့သည့် Google စနစ်တစ်ခုဖြစ်သည် (၎င်းတို့၌ SQL ထည့်သွင်းထားသည်)။ ငွေပေးငွေယူတစ်ခုစီတွင် အချိန်တံဆိပ်ခေါင်းအချို့ပါရှိသည်။ အချိန်ကို ထပ်တူကျစေသောကြောင့်*၊ ဖြစ်ရပ်တစ်ခုစီကို အချိန်တစ်ခုစီ သတ်မှတ်နိုင်သည် - အက်တမ်နာရီများတွင် စောင့်ဆိုင်းချိန်တစ်ခုရှိသည်၊ ထို့နောက် မတူညီသောအချိန်ကို “ဖြစ်ပျက်” ရန် အာမခံပါသည်။

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

* ဤသည်မှာ Lampart နာရီများအတွက် အဓိကပြဿနာဖြစ်သည် - ၎င်းတို့သည် ဖြန့်ဝေသည့်စနစ်များတွင် ဘယ်တော့မှ ထပ်တူမကျပါ။ ၎င်းတို့သည် ကွဲပြားနိုင်သည်၊ NTP နှင့်ပင်၊ ၎င်းတို့သည် အလွန်အလုပ်မလုပ်သေးပါ။ "Spanner" တွင် အက်တမ်နာရီတစ်ခု ရှိပြီး ထပ်တူပြုခြင်း သည် မိုက်ခရိုစက္ကန့် ဖြစ်သည် ။

ငါတို့ဘာကြောင့်မရွေးချယ်ခဲ့တာလဲ။ ကျွန်ုပ်တို့၏အသုံးပြုသူများသည် တပ်ဆင်ထားသော အနုမြူနာရီတစ်လုံးရှိသည်ဟု ကျွန်ုပ်တို့ မယူဆပါ။ ၎င်းတို့ ပေါ်လာသောအခါ၊ လက်ပ်တော့တိုင်းတွင် တည်ဆောက်ထားသည့် အလွန်အေးမြသော GPS ထပ်တူပြုခြင်းမျိုး ရှိလိမ့်မည် - ထို့နောက် ဟုတ်ကဲ့... သို့သော် ယခုအချိန်တွင် ဖြစ်နိုင်ချေအကောင်းဆုံးမှာ Amazon၊ Base Stations ဖြစ်သည် - ဝါသနာရှင်များအတွက် ... ထို့ကြောင့် ကျွန်ုပ်တို့သည် အခြားနာရီများကို အသုံးပြုခဲ့သည်။ .

ဟိုက်ဘရစ်နာရီ

Causal ညီညွတ်မှုကို သေချာစေသောအခါတွင် ဤအရာသည် MongoDB တွင် အမှန်ခြစ်များဖြစ်သည်။ ဘယ်လိုမျိုးစပ်ကြတာလဲ။ Hybrid သည် scalar တန်ဖိုးတစ်ခုဖြစ်သည်၊ သို့သော် ၎င်းတွင် အစိတ်အပိုင်းနှစ်ခုရှိသည်-

• ပထမအချက်မှာ Unix ခေတ် (“ကွန်ပြူတာကမ္ဘာအစ” မှစ၍ စက္ကန့်မည်မျှကြာသွားသည်)။
• ဒုတိယသည် အနည်းငယ်တိုးခြင်း၊ 32-bit unsigned int လည်းဖြစ်သည်။

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

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

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

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

နာရီကို ထပ်တူပြုခြင်း။

သိပ္ပံစာပေများတွင် ဖော်ပြထားသော ထပ်တူပြုခြင်းနည်းလမ်းများစွာရှိသည်။ မတူညီတဲ့ shard နှစ်ခုရှိတဲ့အခါ ထပ်တူကျအောင်ပြောတာပါ။ ပုံတူအတွဲတစ်ခုရှိလျှင်၊ ထပ်တူပြုရန်မလိုအပ်ပါ- ၎င်းသည် "တစ်ခုတည်းသောမာစတာ" ဖြစ်ပါသည်; ကျွန်ုပ်တို့တွင် ပြောင်းလဲမှုများအားလုံး ကျသွားနိုင်သည့် OpLog တစ်ခုရှိသည် - ဤအခြေအနေတွင်၊ အရာအားလုံးကို "Oplog" ကိုယ်တိုင်တွင် ဆင့်ကဲစီယူထားပြီးဖြစ်သည်။ ဒါပေမယ့် ကျွန်တော်တို့မှာ မတူညီတဲ့ shard နှစ်ခုရှိရင်၊ time synchronization က ဒီနေရာမှာ အရေးကြီးတယ်။ ဤသည်မှာ vector clock က ပို၍ အထောက်အကူ ဖြစ်စေပါသည်။ ဒါပေမယ့် ကျွန်တော်တို့မှာ သူတို့ မရှိပါဘူး။

ဒုတိယတစ်ခုသည် သင့်လျော်သည် - ၎င်းသည် "နှလုံးခုန်ခြင်း" ဖြစ်သည်။ အချိန်ယူနစ်တိုင်းတွင် ဖြစ်ပေါ်သော အချက်ပြအချို့ကို ဖလှယ်နိုင်သည်။ သို့သော် Heartbeats နှေးလွန်းသည်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ client ကို latency မပေးနိုင်ပါ။

စစ်မှန်သောအချိန်သည် အံ့သြဖွယ်ကောင်းသောအရာဖြစ်သည်။ သို့သော်၊ နောက်တစ်ကြိမ်၊ ၎င်းသည် အနာဂတ်ဖြစ်နိုင်သည်... ၎င်းကို Atlas တွင် လုပ်ဆောင်နိုင်သော်လည်း၊ လျင်မြန်သော “Amazon” time synchronizers များလည်း ရှိနေပြီဖြစ်သည်။ ဒါပေမယ့် လူတိုင်းအတွက် မရနိုင်ပါ။

အတင်းအဖျင်းပြောခြင်းသည် မက်ဆေ့ချ်များအားလုံး အချိန်ပါဝင်သည့်အချိန်ဖြစ်သည်။ ဒါက ခန့်မှန်းခြေအားဖြင့် ကျွန်တော်တို့ သုံးပါတယ်။ node များ၊ driver ၊ data node router များကြားရှိ မက်ဆေ့ဂျ်တိုင်း၊ MongoDB အတွက် လုံးဝအရာအားလုံးသည် ဒြပ်စင်တစ်မျိုးဖြစ်သည်၊ အလုပ်လုပ်သည့်နာရီပါရှိသော database အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ ၎င်းတို့သည် နေရာတိုင်းတွင် ပေါင်းစပ်အချိန်၏ အဓိပ္ပာယ်ရှိ၍ ၎င်းကို ကူးစက်သည်။ 64 bits လား? ဒါကဖြစ်နိုင်တယ်၊ ဒါကဖြစ်နိုင်တယ်။

အားလုံးက ဘယ်လိုအလုပ်လုပ်လဲ?

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

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

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

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

“Oplog” တွင်ရေးပြီးသားတန်ဖိုးကို ပြန်ပေးသည် - “Oplog” တွင် ဤတန်ဖိုးပါရှိပြီး ၎င်း၏အချိန်သည် 12 ဖြစ်သည်ကို ကျွန်ုပ်တို့သိပါသည်။ ယခုပြောပါ၊ စာဖတ်ခြင်းသည် အခြား node မှစတင်သည် (Secondary) ဖြစ်ပြီး ၎င်းသည် ပြီးနောက် ClusterTime တွင် ပေးပို့ပါသည်။ သတင်းစကား။ သူဤသို့ဆိုသည်– “အနည်းဆုံး ၁၂ နှစ်နောက်ပိုင်း ဒါမှမဟုတ် ၁၂ နှစ်တာကာလအတွင်းမှာ ဖြစ်ပျက်ခဲ့တဲ့အရာအားလုံးကို လိုအပ်တယ်” (အထက်ပုံတွင်ကြည့်ပါ)။

၎င်းကို Causal a ကိုက်ညီမှု (CAT) ဟုခေါ်သည်။ ဤသည်မှာ အချိန်အပိုင်းအခြားတစ်ခုဖြစ်သည်ဟူသော သီအိုရီအရ၊ ၎င်းသည် သူ့အလိုလို ကိုက်ညီနေပါသည်။ ဤကိစ္စတွင်၊ ဤသည်မှာ အချိန် 12 တွင်ပြုလုပ်ခဲ့သောစနစ်၏အခြေအနေဖြစ်သည်ဟုကျွန်ုပ်တို့ပြောနိုင်သည်။

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

ဒါအကုန်လုံး အလုပ်လုပ်ပုံပါပဲ။ နီးပါး။

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

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

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

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

ကျွန်ုပ်တို့၏နည်းလမ်းမှာ clusterTime ကို လက်မှတ်ထိုးရန်ဖြစ်သည်။

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

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

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

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

မြန်မြန်လုပ်ပါ။

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

ထိုသို့သောလက်မှတ်ကိုရရှိခြင်းဖြင့်၊ ကျွန်ုပ်တို့သည် စနစ်အား အကြိမ် 65 (အတော်လေး) မြန်ဆန်စေသည်။ ၎င်းသည် ကောင်းမွန်စွာအလုပ်လုပ်သည်- ကျွန်ုပ်တို့သည် စမ်းသပ်မှုများပြုလုပ်သောအခါ၊ ကျွန်ုပ်တို့တွင် ဆက်တိုက်မွမ်းမံမှုတစ်ခုပြုလုပ်သောအခါ အချိန်သည် အမှန်တကယ် အကြိမ်ရေ 10 လျော့နည်းသွားသည်။ ကွဲလွဲနေတဲ့အခါ ဒါက အလုပ်မဖြစ်ဘူးဆိုတာ ရှင်းပါတယ်။ ဒါပေမယ့် လက်တွေ့အကျဆုံးကိစ္စတွေမှာ အဲဒါက အဆင်ပြေပါတယ်။ Range signature နှင့် လက်မှတ်ပေါင်းစပ်မှုသည် လုံခြုံရေးပြဿနာကို ဖြေရှင်းပေးသည်။

ငါတို့ ဘာသင်ယူခဲ့လဲ။

ဤအရာမှ ကျွန်ုပ်တို့ သင်ယူခဲ့သော သင်ခန်းစာများ

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

  ယေဘုယျအားဖြင့်၊ ပညာရှင်ကွန်ဖရင့်တစ်ခုရှိသောအခါ (ဥပမာ Sigmon) - လူတိုင်းသည် စိတ်ကူးသစ်များကို အာရုံစိုက်ကြသည်။ ကျွန်ုပ်တို့၏ အယ်လဂိုရီသမ်နှင့် ပတ်သက်၍ အသစ်ကဘာလဲ။ ဤနေရာတွင် အထူးအဆန်း ဘာမှ မရှိပါ။ အသစ်အဆန်းသည် ကျွန်ုပ်တို့ရှိပြီးသားချဉ်းကပ်နည်းများကို ပေါင်းစပ်ထားသည့်ပုံစံဖြင့် တည်ရှိနေပါသည်။ ထို့ကြောင့်၊ ပထမဆုံးအချက်မှာ Lampart မှစတင်၍ ဂန္ထဝင်များကိုဖတ်ရန်ဖြစ်သည်။

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

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

ဒီဟာနဲ့ ပြီးမယ်။ ကျေးဇူးတင်ပါသည်!

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

ပရိသတ်ထံမှမေးခွန်း (နောင် B ဟုရည်ညွှန်းသည်) - အစီရင်ခံစာအတွက်ကျေးဇူးတင်ပါတယ် Mikhail။ အချိန်နဲ့ပတ်သက်တဲ့ အကြောင်းအရာက စိတ်ဝင်စားစရာပါ။ Gossiping ကို သင်အသုံးပြုနေပါသည်။ လူတိုင်းမှာ ကိုယ်ပိုင်အချိန်ရှိတယ်၊ လူတိုင်းက ကိုယ့်ဒေသအချိန်ကို သိတယ်လို့ ပြောကြတယ်။ ကျွန်တော်နားလည်သလိုပဲ၊ ကျွန်တော်တို့မှာ driver တစ်ခုရှိပါတယ် - drivers၊ query-planners နဲ့ shards တွေ အများကြီးရှိနိုင်ပါတယ်... ပြီးတော့ ကျွန်တော်တို့ရုတ်တရက် ကွဲလွဲမှုတစ်ခုရှိနေရင် system ကဘာဖြစ်လာနိုင်သလဲ- တစ်စုံတစ်ယောက်က အဲဒါကိုဆုံးဖြတ်ပါတယ်။ ရှေ့တစ်မိနစ်၊ တစ်မိနစ်နောက်ကျနေသူတစ်ယောက်လား။ ငါတို့ဘယ်မှာအဆုံးသတ်မလဲ။

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

IN: – သူတို့ ဘယ်လိုထပ်တူကျပြီး ကျိုးကြောင်းဆီလျော်တဲ့ အချိန်တစ်ခုကို ရွေးချယ်ရမလဲသိချင်တယ်။

MT- - ထပ်တူပြုရန်အလွန်လွယ်ကူသည်။ Shard သည် ClusterTime ပြီးနောက် သူ့ထံရောက်လာပြီး "Oplog" တွင် အချိန်မရှာသောအခါ၊ အတည်ပြုခြင်းမရှိပါ။ ဆိုလိုသည်မှာ၊ သူသည် သူ၏အချိန်များကို ဤတန်ဖိုးသို့ မြှင့်တင်ပေးသည်။ ဆိုလိုသည်မှာ ဤတောင်းဆိုချက်နှင့် ကိုက်ညီသော အစီအစဉ်များ မရှိဟု ဆိုလိုသည်။ သူသည် ဤဖြစ်ရပ်ကို အတုအယောင်ဖန်တီးပြီး Causal Consistent ဖြစ်လာသည်။

IN: - ဒီနောက်ပိုင်းမှာ ကွန်ရက်တစ်နေရာမှာ ပျောက်ဆုံးသွားခဲ့တဲ့ သူ့ဆီ တခြားဖြစ်ရပ်တချို့ ရောက်လာရင် ဘာဖြစ်မလဲ။

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

IN: - တန်းစီတာနဲ့ ပတ်သက်ပြီး မေးစရာတွေ အများကြီးရှိတယ်။ အကြောင်းရင်း ညီညွတ်မှုသည် လုပ်ဆောင်ရန် လိုအပ်သည့် လုပ်ဆောင်ချက်များ၏ တန်းစီတစ်ခု ရှိသည်ဟု ယူဆသည်။ ကျွန်ုပ်တို့၏ ပက်ကေ့ဂျ်များထဲမှ တစ်ခု ပျောက်သွားပါက မည်သို့ဖြစ်မည်နည်း။ 10 ရက်နေ့၊ 11 ရက်နေ့ရောက်ပါပြီ... 12 ရက်နေ့ ပျောက်ကွယ်သွားတော့ တခြားလူတွေအားလုံးက အစစ်အမှန်ဖြစ်လာဖို့ စောင့်နေကြတယ်။ ချက်ခြင်းပဲ ငါတို့ကား ဆုံးသွားတယ် ငါတို့ ဘာမှလုပ်လို့မရဘူး။ မလုပ်ဆောင်မီ စုပုံနေသည့် တန်းစီ၏ အများဆုံး အရှည်ရှိပါသလား။ အခြေအနေတစ်ခု ဆုံးရှုံးသွားတဲ့အခါ ဘယ်လို ဆိုးရွားတဲ့ ချို့ယွင်းမှု ဖြစ်ပေါ်တတ်လဲ။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ယခင်အခြေအနေအချို့ရှိနေကြောင်း ရေးမှတ်ထားပါက ၎င်းကို တစ်နည်းနည်းဖြင့် စတင်သင့်ပါသလား။ ဒါ​ပေမယ့်​ သူ့ကိုမဖယ်​လိုက်​ဘူး!

MT- – မေးခွန်းကောင်းတစ်ခုလည်းဖြစ်သည်။ ငါတို့ဘာလုပ်နေတာလဲ? MongoDB တွင် quorum ရေးသည် ၊ quorum read ၏ သဘောတရားရှိသည်။ ဘယ်လိုအခြေအနေမျိုးမှာ မက်ဆေ့ချ် ပျောက်သွားနိုင်မလဲ။ စာရေးခြင်းသည် အထမြောက်ခြင်းမဟုတ်သည့်အခါ သို့မဟုတ် ဖတ်သည့်အချိန်သည် အထမြောက်ခြင်းမဟုတ်သည့်အခါ (အချို့သော အမှိုက်များလည်း ကပ်နေနိုင်သည်)။
အကြောင်းရင်းခံညီညွတ်မှုနှင့်ပတ်သက်၍ ကြီးမားသောစမ်းသပ်စစ်ဆေးမှုတစ်ခုကို ပြုလုပ်ခဲ့ပြီး ရလဒ်မှာ ရေးခြင်းနှင့်ဖတ်ခြင်းတွင် အထမြောက်ခြင်းမရှိ၊ အကြောင်းရင်းခံညီညွတ်မှုကို ချိုးဖောက်မှုများ ဖြစ်ပေါ်ခဲ့ကြောင်း တွေ့ရှိရသည်။ မင်းပြောတာ အတိအကျပဲ။

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

IN: - ကျွန်ုပ်တို့အတွက် sharding လုပ်ဆောင်ပေးသည့် ဥပမာတစ်ခုကို ဖန်တီးသောအခါ (သခင်မဟုတ်သော်လည်း ကျွန်၊ အသီးသီး)၊ ၎င်းသည် ၎င်း၏ကိုယ်ပိုင်စက်၏ Unix အချိန် သို့မဟုတ် "သခင်" ၏အချိန်အပေါ် မူတည်သည်။ ၎င်းသည် ပထမအကြိမ် သို့မဟုတ် အချိန်အခါအလိုက် ထပ်တူပြုပါသလား။

MT- - အခုရှင်းလိုက်မယ်။ Shard (ဆိုလိုသည်မှာ အလျားလိုက် အပိုင်းပိုင်း) - အဲဒီမှာ အမြဲတမ်း Primary တစ်ခုရှိတယ်။ ပြီးတော့ shard တစ်ခုမှာ "မာစတာ" ရှိနိုင်ပြီး ပုံတူတွေလည်း ရှိနိုင်ပါတယ်။ သို့သော် shard သည် အချို့သော domain ကို ပံ့ပိုးပေးရမည်ဖြစ်သောကြောင့် (shard တွင် Primary ပါရှိသည်)။

IN: “ဒါဆို အရာအားလုံးက “သခင်” အပေါ်မှာပဲ မူတည်တယ်။ မာစတာအချိန်ကို အမြဲအသုံးပြုပါသလား။

MT- - ဟုတ်ကဲ့။ ပုံသဏ္ဌာန်အားဖြင့် သင်ပြောနိုင်သည်- "မာစတာ" ထဲသို့ ၀င်သွားသောအခါ "Oplog" ထဲသို့ နာရီက အမှတ်ခြစ်နေပါသည်။

IN: - ကျွန်ုပ်တို့တွင် ချိတ်ဆက်ထားသော client ရှိပြီး အချိန်နှင့် ပတ်သက်၍ ဘာမှ သိရန်မလိုအပ်ပါ။

MT- - မင်း ဘာမှ သိဖို့ မလိုဘူး။ ကလိုင်းယင့်အပေါ် မည်သို့လုပ်ဆောင်ကြောင်းကို ကျွန်ုပ်တို့ပြောဆိုပါက- client သည် Causal ညီညွတ်မှုကို အသုံးပြုလိုသောအခါ၊ သူသည် session တစ်ခုဖွင့်ရန် လိုအပ်သည်။ ယခု အရာအားလုံးသည် ထိုနေရာတွင် ရှိနေသည်- စက်ရှင်အတွင်း ငွေပေးငွေယူများနှင့် လုပ်ပိုင်ခွင့်များကို ပြန်လည်ရယူခြင်း... စက်ရှင်တစ်ခုသည် သုံးစွဲသူနှင့် ဖြစ်ပျက်နေသည့် ယုတ္တိတန်သော အဖြစ်အပျက်များကို စီစဥ်ခြင်းဖြစ်ပါသည်။

သူက ဒီ session ကိုဖွင့်ပြီး Causal ညီညွတ်မှုကို လိုချင်တယ်လို့ ပြောရင် (စက်ရှင်က Causal ညီညွတ်မှုကို ပုံမှန်အတိုင်း ထောက်ခံတယ်ဆိုရင်) အရာအားလုံးက အလိုအလျောက် အလုပ်လုပ်ပါတယ်။ ယာဉ်မောင်းသည် ဤအချိန်ကို မှတ်မိပြီး မက်ဆေ့ချ်အသစ်တစ်ခုရရှိသောအခါ ၎င်းကို တိုးစေသည်။ ၎င်းသည် ဒေတာကို ပြန်ပေးသည့် ဆာဗာမှ ယခင်တစ်ခုက ပြန်ပေးခဲ့သည့် တုံ့ပြန်မှုကို မှတ်မိသည်။ နောက်တောင်းဆိုချက်တွင် afterCluster("ဤထက်ကြီးသောအချိန်") ပါဝင်ပါမည်။

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

IN: - တွက်ချက်မှုသိပ္ပံ၏ အလွှာအသစ် - CRDT (ပဋိပက္ခကင်းစင်သော ထပ်တူပြုထားသည့် ဒေတာအမျိုးအစားများ) ဒေတာအမျိုးအစားများ - သည် ဖြစ်ပေါ်လာသော ကိုက်ညီမှု၏ ခေါင်းစဉ်နှင့် ပြင်းထန်စွာ ဆက်စပ်နေသည်။ ဒီဒေတာအမျိုးအစားတွေကို ဒေတာဘေ့စ်ထဲကို ပေါင်းစည်းဖို့ စဉ်းစားပြီးပြီလား၊ အဲဒါနဲ့ပတ်သက်ပြီး ဘာပြောနိုင်မလဲ။

MT- - မေးခွန်းကောင်း! CRDT သည် MongoDB တွင်၊ single master တွင် ရေးရန်ပဋိပက္ခများအတွက် အဓိပ္ပါယ်ရှိသည်။

IN: - ငါ သာသနာ့ဝန်ထမ်းတွေဆီက မေးစရာရှိတယ်။ လက်တွေ့ကမ္ဘာတွင်၊ Byzantine Failure ပေါ်ပေါက်လာသောအခါတွင် ထိုသို့သော Jesuitical အခြေအနေများ ရှိနေပြီး၊ ကာကွယ်ထားသော ပတ်၀န်းကျင်ရှိ လူဆိုးများသည် ပရိုတိုကောထဲသို့ စတင်ဝင်ရောက်ကာ အထူးနည်းလမ်းဖြင့် craft packages များ ပေးပို့လာကြသည်။

MT- - ပတ်၀န်းကျင်အတွင်းရှိ လူဆိုးများသည် Trojan မြင်းတစ်ကောင်နှင့်တူသည်။ ပတ်၀န်းကျင်အတွင်းမှ လူဆိုးများသည် မကောင်းမှုများစွာကို ပြုလုပ်နိုင်သည်။

IN: - အကြမ်းဖျင်းပြောရလျှင် ဆင်များကို တိရစ္ဆာန်ရုံတွင် ထားရှိကာ အစုအဝေးတစ်ခုလုံးကို ထာဝရပြိုကျသွားစေနိုင်သည့် ဆာဗာရှိ အပေါက်တစ်ခုမှ ထွက်သွားသည်မှာ ရှင်းရှင်းလင်းလင်းပင်ဖြစ်သည်... ၎င်းသည် လူကိုယ်တိုင် ပြန်လည်ရယူရန်အတွက် အချိန်ယူရလိမ့်မည်...။ မှားတယ်။ အခြားတစ်ဖက်တွင်၊ ဤအရာသည် စိတ်ဝင်စားစရာကောင်းသည်- လက်တွေ့ဘဝတွင်၊ သဘာဝအတိုင်း အလားတူအတွင်းပိုင်းတိုက်ခိုက်မှုများ ဖြစ်ပွားသည့်အခါ အခြေအနေများ ရှိပါသလား။

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

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

IN: – ကာကွယ်ထားသော ပတ်၀န်းကျင်တွင်၊ တစ်စုံတစ်ဦးသည် ဆာဗာကို လုံးလုံးလျားလျား ဖျက်ဆီးရန်အတွက် မမျှော်လင့်ထားသော ပရိုတိုကောများကို ဖန်တီးရန် ကြိုးစားခဲ့ပြီး သင်ကံကောင်းပါက၊ အစုအဝေးတစ်ခုလုံး... ၎င်းသည် "ကောင်း" သည်လား?

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

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

MT- - ကျွန်ုပ်တို့တွင် node 40 ပါသောပုံစံတူများရှိသည်။ အမြဲတမ်း အများစုရှိတယ်။ ဘယ်ဗားရှင်းလဲမသိဘူး...

IN: - Replica Set တွင် သင်သည် မဲပေးခြင်းမဟုတ်သောအဖွဲ့ဝင်များကို လည်ပတ်နိုင်သော်လည်း အများဆုံးမဲပေးသည့်အဖွဲ့ဝင် 7 ဦးရှိသည်။ ကျွန်ုပ်တို့၏ပုံတူသတ်မှတ်မှုသည် ဒေတာစင်တာ 3 ခုတွင် ပျံ့နှံ့နေပါက ဤကိစ္စတွင် ပိတ်သွားခြင်းအား ကျွန်ုပ်တို့ မည်သို့ ရှင်သန်နိုင်မည်နည်း။ ဒေတာစင်တာတစ်ခုသည် အလွယ်တကူ ပိတ်နိုင်ပြီး အခြားစက်သည် ပြုတ်ကျနိုင်သည်။

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

ကြော်ငြာအချို့ 🙂

ကျွန်ုပ်တို့နှင့်အတူရှိနေသည့်အတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်ုပ်တို့၏ဆောင်းပါးများကို သင်နှစ်သက်ပါသလား။ ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အကြောင်းအရာတွေကို ကြည့်ချင်ပါသလား။ မှာယူမှုတစ်ခုပြုလုပ်ခြင်း သို့မဟုတ် သူငယ်ချင်းများကို အကြံပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား ပံ့ပိုးကူညီပါ၊ $4.99 မှ developer များအတွက် cloud VPS, မင်းအတွက် ငါတို့က တီထွင်ထားတဲ့ entry-level server တွေရဲ့ ထူးခြားတဲ့ analogue တစ်ခု။ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps သို့မဟုတ် $19 မှ ဆာဗာတစ်ခုမျှဝေပုံနှင့်ပတ်သက်သော အမှန်တရားတစ်ခုလုံး။ (RAID1 နှင့် RAID10၊ 24 cores အထိနှင့် 40GB DDR4 အထိ)။

အမ်စတာဒမ်ရှိ Equinix Tier IV ဒေတာစင်တာတွင် Dell R730xd သည် ၂ ဆ စျေးသက်သာသည်။ ဒီမှာသာ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ကို $199 မှ နယ်သာလန်မှာ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 မှ။ အကြောင်းဖတ်ပါ။ Infrastructure Corp ကို ဘယ်လိုတည်ဆောက်မလဲ။ တစ်ပြားတစ်ချပ်အတွက် ယူရို ၉၀၀၀ တန် Dell R730xd E5-2650 v4 ဆာဗာများကို အသုံးပြုခြင်း။

source: www.habr.com