လုပ်ငန်းအတွက် DBMS ဖြန့်ဝေထားသည်။

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

ရှင်းရှင်းလင်းလင်းမသိသာသောအရာမှာ "P" အက္ခရာ၏အဓိပ္ပါယ်ဖြစ်သည်။ အစုအဝေးကို ခွဲလိုက်သောအခါ၊ အထမြောက်ခြင်းသို့ မရောက်ရှိမချင်း တုံ့ပြန်ခြင်းမပြုရန်၊ သို့မဟုတ် ရရှိနိုင်သောဒေတာကို ပြန်လည်ပေးအပ်ရန် ဆုံးဖြတ်သည်။ ဤရွေးချယ်မှု၏ရလဒ်များအပေါ် မူတည်၍ စနစ်အား CP သို့မဟုတ် AP တစ်ခုအဖြစ် အမျိုးအစားခွဲခြားထားသည်။ ဥပမာ Cassandra သည် အစုအဖွဲ့ဆက်တင်များပေါ်တွင်ပင်မဟုတ်ဘဲ သီးခြားတောင်းဆိုမှုတစ်ခုစီ၏ ဘောင်များပေါ်တွင်မူတည်၍ တစ်ခုခုကို ပြုမူနိုင်သည်။ ဒါပေမယ့် စနစ်က "P" မဟုတ်ပဲ ကွဲသွားရင် ဘာဖြစ်မလဲ။

ဤမေးခွန်းအတွက် အဖြေသည် အနည်းငယ်မျှော်လင့်ထားသည်- CA အစုအဝေးသည် မခွဲနိုင်ပါ။
မခွဲမခွာနိုင်သော အစုအဝေးက ဘယ်လိုမျိုးလဲ။

ထိုသို့သော အစုအဝေးတစ်ခု၏ မရှိမဖြစ် အရည်အချင်းမှာ မျှဝေထားသော ဒေတာသိမ်းဆည်းမှုစနစ်ဖြစ်သည်။ အများစုတွင်၊ ၎င်းသည် SAN အခြေခံအဆောက်အအုံကို ထိန်းသိမ်းနိုင်သည့် လုပ်ငန်းကြီးများအတွက် CA ဖြေရှင်းချက်များကို အသုံးပြုခြင်းကို ကန့်သတ်ထားသည့် SAN တစ်ခုနှင့် ချိတ်ဆက်ခြင်းကို ဆိုလိုသည်။ ဆာဗာများစွာသည် တူညီသောဒေတာဖြင့် အလုပ်လုပ်နိုင်စေရန်အတွက်၊ အစုလိုက်ပြုလုပ်ထားသော ဖိုင်စနစ်တစ်ခု လိုအပ်ပါသည်။ ထိုကဲ့သို့သော ဖိုင်စနစ်များကို HPE (CFS)၊ Veritas (VxCFS) နှင့် IBM (GPFS) အစုစုများတွင် ရရှိနိုင်ပါသည်။

Oracle RAC

Real Application Cluster option ကို Oracle 2001i ဖြင့် ၂၀၀၁ ခုနှစ်တွင် စတင်တွေ့ရှိခဲ့သည်။ ထိုသို့သောအစုအဝေးတွင်၊ များစွာသော server ဖြစ်ရပ်များသည် တူညီသောဒေတာဘေ့စ်ဖြင့်အလုပ်လုပ်သည်။
Oracle သည် အစုလိုက်အပြုံလိုက် ဖိုင်စနစ်နှင့် ၎င်း၏ကိုယ်ပိုင်ဖြေရှင်းချက် - ASM၊ အလိုအလျောက် သိုလှောင်မှု စီမံခန့်ခွဲမှုဖြင့် လုပ်ဆောင်နိုင်သည်။

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

ဖြစ်ရပ်များအားလုံးသည် ၎င်းတို့၏ကိုယ်ပိုင် ကက်ရှ်ကို ထိန်းသိမ်းထားပြီး တူညီသောစာမျက်နှာများ (ဘလောက်များ) သည် တစ်ချိန်တည်းတွင် များစွာသော ဖြစ်ရပ်များ၏ ကက်ရှ်များတွင် ရှိနေနိုင်သည်။ ထို့အပြင်၊ ဥပမာတစ်ခုသည် စာမျက်နှာတစ်ခုလိုအပ်ပြီး ၎င်းသည် အခြားဥပမာတစ်ခု၏ cache တွင်ရှိနေပါက၊ ၎င်းသည် disk မှဖတ်မည့်အစား cache fusion mechanism ကိုအသုံးပြု၍ ၎င်း၏အိမ်နီးနားချင်းထံမှ ၎င်းကိုရနိုင်သည်။

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

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

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

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

Oracle RAC ၏ မှန်ကန်သောအသုံးပြုမှုသည် ဒေတာကို ရုပ်ပိုင်းပိုင်းခွဲရန် (ဥပမာ၊ ပိုင်းခြားထားသော ဇယားယန္တရားတစ်ခုကို အသုံးပြုခြင်း) နှင့် သီးခြား node တစ်ခုစီမှ အပိုင်းတစ်ခုစီကို ဝင်ရောက်ကြည့်ရှုခြင်း ဖြစ်သည်။ RAC ၏ အဓိကရည်ရွယ်ချက်မှာ အလျားလိုက် အတိုင်းအတာမဟုတ်သော်လည်း အမှားခံနိုင်ရည်ရှိစေရန်ဖြစ်သည်။

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

• ပျောက်ဆုံးနေသော node ၏ cache အတွင်းရှိ စာမျက်နှာအားလုံးကို “အေးခဲသည်”၊
• ပျောက်ဆုံးနေသော node များ၏ မှတ်တမ်းများကို ဖတ်ပြီး ဤမှတ်တမ်းများတွင် မှတ်တမ်းတင်ထားသော အပြောင်းအလဲများကို ပြန်လည်အသုံးချကာ အခြား node များမှ စာမျက်နှာများ၏ မကြာသေးမီကဗားရှင်းများ ပြောင်းလဲသွားခြင်းရှိမရှိကို တစ်ပြိုင်နက် စစ်ဆေးခြင်း၊
• ဆိုင်းငံ့ထားသော အရောင်းအ၀ယ်များကို ပြန်လှည့်သည်။

node များကြားတွင် ရိုးရှင်းစွာပြောင်းရန်အတွက် Oracle တွင် ဝန်ဆောင်မှုတစ်ခု - virtual instance တစ်ခုရှိသည်။ ဥပမာတစ်ခုသည် ဝန်ဆောင်မှုများစွာကို ဆောင်ရွက်ပေးနိုင်ပြီး ဝန်ဆောင်မှုတစ်ခုသည် node များကြားတွင် ရွေ့လျားနိုင်သည်။ ဒေတာဘေ့စ်၏ အစိတ်အပိုင်းအချို့ကို ဝန်ဆောင်မှုပေးသည့် အပလီကေးရှင်းတစ်ခု (ဥပမာ၊ ဖောက်သည်များအုပ်စု) သည် ဝန်ဆောင်မှုတစ်ခုနှင့် အလုပ်လုပ်ပြီး ဒေတာဘေ့စ်၏ ဤအစိတ်အပိုင်းအတွက် တာဝန်ရှိသည့်ဝန်ဆောင်မှုသည် node တစ်ခုပျက်သွားသောအခါ အခြား node သို့ ရွှေ့သွားပါသည်။

ငွေပေးငွေယူများအတွက် IBM Pure Data Systems

DBMS အတွက် အစုလိုက်ဖြေရှင်းချက်တစ်ခု 2009 ခုနှစ်တွင် Blue Giant အစုစုတွင် ပေါ်လာခဲ့သည်။ သဘောတရားအရ၊ ၎င်းသည် "ပုံမှန်" စက်ကိရိယာများပေါ်တွင်တည်ဆောက်ထားသော Parallel Sysplex အစုအဝေး၏ဆက်ခံသူဖြစ်သည်။ 2009 ခုနှစ်တွင် DB2 pureScale ကို ဆော့ဖ်ဝဲလ်အစုံအလင်အဖြစ် ထုတ်ဝေခဲ့ပြီး 2012 ခုနှစ်တွင် IBM သည် ငွေပေးငွေယူများအတွက် Pure Data Systems ဟုခေါ်သော စက်ပစ္စည်းတစ်ခုကို ကမ်းလှမ်းခဲ့သည်။ Netezza ဟု အမည်ပြောင်းရုံမျှမကသည့် Pure Data Systems for Analytics နှင့် မရောထွေးသင့်ပါ။

ပထမတစ်ချက်တွင်၊ pureScale ဗိသုကာသည် Oracle RAC နှင့်ဆင်တူသည်- ထိုနည်းအတူ၊ node အများအပြားသည် ဘုံဒေတာသိုလှောင်မှုစနစ်သို့ချိတ်ဆက်ထားပြီး node တစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင်မှတ်ဉာဏ်ဧရိယာများနှင့် ငွေပေးငွေယူမှတ်တမ်းများဖြင့် ၎င်း၏ကိုယ်ပိုင် DBMS instance ကိုလုပ်ဆောင်သည်။ သို့သော် Oracle နှင့်မတူဘဲ၊ DB2 တွင် db2LLM* လုပ်ငန်းစဉ်အစုံဖြင့် ကိုယ်စားပြုသော သော့ခတ်ခြင်းဝန်ဆောင်မှုတစ်ခုရှိသည်။ အစုအဝေးဖွဲ့စည်းမှုပုံစံတစ်ခုတွင်၊ ဤဝန်ဆောင်မှုကို Parallel Sysplex ရှိ ချိတ်ဆက်မှုအသုံးအဆောင် (CF) ဟုခေါ်သော သီးခြား node တစ်ခုပေါ်တွင် ထားရှိကာ Pure Data တွင် PowerHA ဖြစ်သည်။

PowerHA သည် အောက်ပါဝန်ဆောင်မှုများကို ဆောင်ရွက်ပေးသည်-

• သော့ခတ်မန်နေဂျာ;
• ကမ္ဘာလုံးဆိုင်ရာ ကြားခံကက်ရှ်၊
• interprocess ဆက်သွယ်ရေးဧရိယာ။

PowerHA မှ ဒေတာကို ဒေတာဘေ့စ် ဆုံမှတ်များနှင့် နောက်ကျောသို့ လွှဲပြောင်းရန် အဝေးထိန်းမှတ်ဉာဏ် ဝင်ရောက်မှုကို အသုံးပြုသည်၊ ထို့ကြောင့် အစုအဖွဲ့ အပြန်အလှန်ချိတ်ဆက်မှုသည် RDMA ပရိုတိုကောကို ပံ့ပိုးပေးရမည်ဖြစ်သည်။ PureScale သည် Ethernet မှတဆင့် Infiniband နှင့် RDMA နှစ်မျိုးလုံးကို အသုံးပြုနိုင်သည်။

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

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

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

"Dirty" ဆိုသည်မှာ ပြောင်းလဲထားသော စာမျက်နှာများကို ပုံမှန် node တစ်ခုမှ နှင့် PowerHA (castout) မှ disk သို့ စာရေးနိုင်သည်။

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

PowerHA သည် ဆာဗာနှစ်ခုပေါ်တွင် အလုပ်လုပ်ပြီး မာစတာ node သည် ၎င်း၏အခြေအနေကို တပြိုင်နက်တည်း ထပ်တူပွားသည်။ ပင်မ PowerHA node သည် ပျက်ကွက်ပါက၊ အစုအဝေးသည် အရန်မှတ်စုနှင့်အတူ ဆက်လက်လည်ပတ်နေပါသည်။
သေချာပါတယ်၊ အကယ်၍ သင်သည် node တစ်ခုတည်းမှတစ်ဆင့် သတ်မှတ်ဒေတာကို ဝင်ရောက်ကြည့်ရှုပါက၊ အစုအဝေး၏ အလုံးစုံစွမ်းဆောင်ရည်သည် ပိုမိုမြင့်မားလာမည်ဖြစ်သည်။ PureScale သည် node တစ်ခုမှ ဒေတာအချို့ကို လုပ်ဆောင်နေသည် ကိုပင် သတိပြုမိနိုင်ပြီး၊ ထို့နောက် PowerHA နှင့် ဆက်သွယ်ခြင်းမပြုဘဲ ထိုဧရိယာနှင့် ဆက်စပ်သော သော့များအားလုံးကို စက်တွင်း၌ လုပ်ဆောင်သွားမည်ဖြစ်သည်။ သို့သော် အပလီကေးရှင်းသည် အခြား node တစ်ခုမှတဆင့် ဤဒေတာကို ဝင်ရောက်ရန် ကြိုးစားသည်နှင့် တပြိုင်နက်၊ ဗဟိုချုပ်ကိုင်မှုရှိသော လော့ခ်ချခြင်းလုပ်ငန်းကို ပြန်လည်စတင်မည်ဖြစ်သည်။

IBM ၏ အတွင်းပိုင်းစစ်ဆေးမှုများသည် 90% read နှင့် 10% write ၊ real-world production workloads နှင့် အလွန်ဆင်တူသည့် 128 nodes အထိ linear scaling ကိုပြသထားသည်။ ကံမကောင်းစွာပဲ စမ်းသပ်မှုအခြေအနေများကို ထုတ်ဖော်ပြောကြားခြင်းမရှိပါ။

HPE NonStop SQL

Hewlett-Packard Enterprise အစုစုတွင် ၎င်း၏ကိုယ်ပိုင် အလွန်ရရှိနိုင်သော ပလပ်ဖောင်းလည်း ရှိသည်။ ၎င်းသည် Tandem Computers မှ 1976 ခုနှစ်တွင် စျေးကွက်သို့ ဖြန့်ချိခဲ့သည့် NonStop ပလပ်ဖောင်းဖြစ်သည်။ 1997 ခုနှစ်တွင် ကုမ္ပဏီကို Compaq မှ ဝယ်ယူခဲ့ပြီး 2002 ခုနှစ်တွင် Hewlett-Packard နှင့် ပေါင်းစပ်ခဲ့သည်။

NonStop ကို အရေးပါသော အပလီကေးရှင်းများ တည်ဆောက်ရန် အသုံးပြုသည် - ဥပမာ၊ HLR သို့မဟုတ် ဘဏ်ကတ် လုပ်ဆောင်ခြင်း။ ပလပ်ဖောင်းကို ဆော့ဖ်ဝဲလ်နှင့် ဟာ့ဒ်ဝဲရှုပ်ထွေးသော (စက်ပစ္စည်း) ပုံစံဖြင့် ပေးပို့သည် ServerNet ကွန်ရက် (ခေတ်မီစနစ်များတွင် - Infiniband) သည် nodes များကြား အပြန်အလှန်ဖလှယ်ရန်နှင့် ဒေတာသိမ်းဆည်းမှုစနစ်သို့ ဝင်ရောက်ရန်အတွက် နှစ်မျိုးလုံးဆောင်ရွက်ပေးသည်။

စနစ်၏ အစောပိုင်းဗားရှင်းများသည် တစ်ခုနှင့်တစ်ခု ထပ်တူပြုထားသည့် သီးသန့်ပရိုဆက်ဆာများကို အသုံးပြုခဲ့သည်- လုပ်ဆောင်ချက်အားလုံးကို ပရိုဆက်ဆာများစွာဖြင့် တပြိုင်တည်းလုပ်ဆောင်ပြီး ပရိုဆက်ဆာများထဲမှ တစ်ခု မှားယွင်းသွားသည်နှင့်တပြိုင်နက် ၎င်းကို ပိတ်လိုက်ပြီး ဒုတိယသည် ဆက်လက်လုပ်ဆောင်သွားခဲ့သည်။ နောက်ပိုင်းတွင်၊ စနစ်သည် သမားရိုးကျ ပရိုဆက်ဆာများ (ပထမ MIPS၊ ထို့နောက် Itanium နှင့် နောက်ဆုံးတွင် x86) သို့ပြောင်းခဲ့ပြီး အခြားယန္တရားများကို ထပ်တူပြုရန် စတင်အသုံးပြုလာသည်-

• မက်ဆေ့ချ်များ- စနစ်လုပ်ငန်းစဉ်တစ်ခုစီတွင် “အရိပ်” အမွှာတစ်ခု ပါ၀င်ပြီး ၎င်းတွင် တက်ကြွသောလုပ်ငန်းစဉ်သည် ၎င်း၏အခြေအနေနှင့်ပတ်သက်သည့် မက်ဆေ့ချ်များကို အခါအားလျော်စွာ ပေးပို့ပါသည်။ ပင်မလုပ်ငန်းစဉ်မအောင်မြင်ပါက၊ အရိပ်လုပ်ငန်းစဉ်သည် နောက်ဆုံးမက်ဆေ့ချ်မှ ဆုံးဖြတ်သည့်အခိုက်အတန့်မှ စတင်အလုပ်လုပ်ပါသည်။
• မဲပေးခြင်း- သိုလှောင်မှုစနစ်တွင် ထပ်တူထပ်မျှသောဝင်ရောက်ခွင့်အများအပြားကိုလက်ခံပြီး accesses များကိုက်ညီမှသာ လုပ်ဆောင်ပေးသည့် အထူးဟာ့ဒ်ဝဲအစိတ်အပိုင်းတစ်ခုပါရှိသည်။ ရုပ်ပိုင်းဆိုင်ရာထပ်တူပြုခြင်းအစား၊ ပရိုဆက်ဆာများသည် အချိန်ကိုက်လုပ်ဆောင်ကြပြီး ၎င်းတို့၏အလုပ်၏ရလဒ်များကို I/O အခိုက်အတန့်တွင်သာ နှိုင်းယှဉ်ပါသည်။

1987 ခုနှစ်ကတည်းက၊ ဆက်စပ် DBMS သည် NonStop ပလပ်ဖောင်း - ပထမ SQL/MP နှင့် နောက်ပိုင်းတွင် SQL/MX တွင် လုပ်ဆောင်နေပါသည်။

ဒေတာဘေ့စ်တစ်ခုလုံးကို အပိုင်းများခွဲထားပြီး အစိတ်အပိုင်းတစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင် Data Access Manager (DAM) လုပ်ငန်းစဉ်အတွက် တာဝန်ရှိသည်။ ၎င်းသည် ဒေတာမှတ်တမ်းတင်ခြင်း၊ သိမ်းဆည်းခြင်းနှင့် လော့ခ်ချခြင်း ယန္တရားများကို ထောက်ပံ့ပေးသည်။ Data processing ကို သက်ဆိုင်ရာ data managers များကဲ့သို့ တူညီသော node များပေါ်တွင် လုပ်ဆောင်နေသော Executor Server Processes မှ ဆောင်ရွက်ပါသည်။ SQL/MX အစီအစဉ်ဆွဲသူသည် executors များအကြား လုပ်ဆောင်စရာများကို ပိုင်းခြားပြီး ရလဒ်များကို စုစည်းပေးသည်။ သဘောတူထားသော အပြောင်းအလဲများ ပြုလုပ်ရန် လိုအပ်သောအခါ၊ TMF (Transaction Management Facility) စာကြည့်တိုက်မှ ပံ့ပိုးပေးသော နှစ်ဆင့် commit protocol ကို အသုံးပြုပါသည်။

NonStop SQL သည် ရှည်လျားသော ခွဲခြမ်းစိတ်ဖြာမေးမြန်းမှုများသည် ငွေပေးငွေယူလုပ်ဆောင်မှုကို အနှောင့်အယှက်မပေးစေရန် လုပ်ငန်းစဉ်များကို ဦးစားပေးနိုင်သည်။ သို့ရာတွင်၊ ၎င်း၏ရည်ရွယ်ချက်မှာ ခွဲခြမ်းစိတ်ဖြာခြင်းမဟုတ်ဘဲ တိုတောင်းသော ငွေပေးငွေယူများကို လုပ်ဆောင်ခြင်းဖြစ်သည် ။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် “ကိုးကိုး” အဆင့်တွင် မရပ်မနားအစုအဝေး၏ရရှိနိုင်မှုကို အာမခံသည်၊ ဆိုလိုသည်မှာ၊ စက်ရပ်ချိန်သည် တစ်နှစ်လျှင် 5 မိနစ်သာရှိသည်။

SAP Hana

HANA DBMS (1.0) ၏ ပထမဆုံး တည်ငြိမ်သော ဖြန့်ချိမှုကို 2010 ခုနှစ် နိုဝင်ဘာလတွင် ပြုလုပ်ခဲ့ပြီး SAP ERP ပက်ကေ့ချ်ကို 2013 ခုနှစ် မေလတွင် HANA သို့ ပြောင်းခဲ့သည်။ ပလက်ဖောင်းသည် ဝယ်ယူထားသော နည်းပညာများအပေါ် အခြေခံသည်- TREX ရှာဖွေရေးအင်ဂျင် (ကော်လံဘားသိုလှောင်မှုတွင် ရှာဖွေမှု)၊ P*TIME DBMS နှင့် MAX DB တို့ဖြစ်သည်။

“HANA” ဟူသော စကားလုံးသည် စွမ်းဆောင်ရည်မြင့်မားသော ခွဲခြမ်းစိတ်ဖြာမှုဆိုင်ရာ ကိရိယာ၏ အတိုကောက်ဖြစ်သည်။ ဤ DBMS သည် မည်သည့် x86 ဆာဗာများတွင်မဆို လုပ်ဆောင်နိုင်သော ကုဒ်ပုံစံဖြင့် ပံ့ပိုးပေးသော်လည်း၊ စက်မှုတပ်ဆင်မှုများကို လက်မှတ်ရစက်ပစ္စည်းများတွင်သာ ခွင့်ပြုထားသည်။ HP၊ Lenovo၊ Cisco၊ Dell၊ Fujitsu၊ Hitachi၊ NEC တို့မှ ရရှိနိုင်သော ဖြေရှင်းနည်းများ။ အချို့သော Lenovo configurations များသည် SAN မပါဘဲ လုပ်ဆောင်မှုကိုပင် ခွင့်ပြုသည် - ဘုံသိုလှောင်မှုစနစ်၏ အခန်းကဏ္ဍကို local disks များပေါ်တွင် GPFS အစုအဝေးတစ်ခုက ဖွင့်ထားသည်။

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

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

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

coordinator node သည် ပွားနေသောကြောင့် coordinator မအောင်မြင်ပါက၊ backup node သည် ချက်ချင်းကျော်သွားပါသည်။ သို့သော် ဒေတာပါသော node တစ်ခု ပျက်ကွက်ပါက ၎င်း၏ဒေတာကို ဝင်ရောက်ရန် တစ်ခုတည်းသောနည်းလမ်းမှာ node ကို ပြန်လည်စတင်ရန်ဖြစ်သည်။ စည်းကမ်းအတိုင်း၊ HANA အစုအဝေးများသည် ၎င်းပေါ်ရှိ ဆုံးရှုံးသွားသော node ကို မြန်နိုင်သမျှမြန်စွာ ပြန်လည်စတင်ရန်အတွက် လပ်ဆာဗာကို ထိန်းသိမ်းထားသည်။

source: www.habr.com