NewSQL = NoSQL+ACID

မကြာသေးမီအထိ၊ Odnoklassniki သည် SQL Server တွင် အချိန်နှင့်တပြေးညီ လုပ်ဆောင်ပြီး ဒေတာ 50 TB ခန့်ကို သိမ်းဆည်းထားသည်။ ထိုသို့သောပမာဏအတွက်၊ SQL DBMS ကိုအသုံးပြု၍ ဒေတာစင်တာပျက်ကွက်မှုဒဏ်ခံနိုင်သောဝင်ရောက်ခွင့်ကိုပင်လျှင်မြန်ပြီးယုံကြည်စိတ်ချရသောအသုံးပြုခွင့်ကိုပေးစွမ်းရန်မှာမဖြစ်နိုင်ပေ။ ပုံမှန်အားဖြင့်၊ ထိုသို့သောအခြေအနေမျိုးတွင်၊ NoSQL သိုလှောင်မှုထဲမှ တစ်ခုကို အသုံးပြုသော်လည်း အရာအားလုံးကို NoSQL သို့ လွှဲပြောင်းမရနိုင်ပါ- အချို့သော အရာများသည် ACID အရောင်းအ၀ယ်အာမခံချက် လိုအပ်ပါသည်။

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

ဘယ်လိုအလုပ်လုပ်သလဲ - ဖြတ်တောက်မှုအောက်မှာဖတ်ပါ။

ယနေ့တွင်၊ Odnoklassniki ၏လစဉ်ပရိသတ်သည် ထူးခြားသောလာရောက်လည်ပတ်သူ သန်း 70 ကျော်ရှိသည်။ ကျွန်တော်တို ကျွန်ုပ်တို့သည် ထိပ်ဆုံးငါးဦးတွင် ရှိသည်။ ကမ္ဘာပေါ်တွင် အကြီးဆုံး လူမှုကွန်ရက်များနှင့် သုံးစွဲသူများ အချိန်အများဆုံး အသုံးပြုသည့် ဆိုက်နှစ်ဆယ်တို့တွင် ဖြစ်သည်။ OK အခြေခံအဆောက်အအုံသည် အလွန်မြင့်မားသောဝန်များကို ကိုင်တွယ်သည်- ရှေ့တစ်ရက်လျှင် HTTP တောင်းဆိုချက်ပေါင်း တစ်သန်းကျော်။ အပိုင်း 8000 ကျော်ရှိသော ဆာဗာတပ်စုတစ်ခု၏ အစိတ်အပိုင်းများသည် တစ်ခုနှင့်တစ်ခု နီးကပ်စွာတည်ရှိသည် - ၎င်းတို့ကြားတွင် 1 ms ထက်နည်းသော network latency ကိုသေချာစေသည့် Moscow ဒေတာစင်တာလေးခုတွင်တည်ရှိသည်။

ကျွန်ုပ်တို့သည် ဗားရှင်း 2010 မှစတင်ကာ 0.6 ခုနှစ်ကတည်းက Cassandra ကိုအသုံးပြုခဲ့သည်။ ယနေ့တွင် လည်ပတ်နေသော အစုအဖွဲ့ ဒါဇင်များစွာရှိသည်။ အမြန်ဆုံးအစုအဖွဲ့သည် တစ်စက္ကန့်လျှင် လုပ်ဆောင်ချက်ပေါင်း 4 သန်းကျော်ကို လုပ်ဆောင်နေပြီး အကြီးဆုံး 260 TB စတိုးဆိုင်များ။

သို့သော်၊ ၎င်းတို့အားလုံးသည် သိုလှောင်မှုအတွက် အသုံးပြုသည့် သာမန် NoSQL အစုအဝေးများဖြစ်သည်။ ညှိနှိုင်းမှုအားနည်းတယ်။ ဒေတာ။ Odnoklassniki ကို စတင်တည်ထောင်ကတည်းက အသုံးပြုခဲ့သည့် အဓိက တသမတ်တည်း သိုလှောင်မှုဖြစ်သော Microsoft SQL Server ကို ကျွန်ုပ်တို့ အစားထိုးလိုပါသည်။ သိုလှောင်မှုတွင် ဒေတာ 300 TB ပါရှိသော SQL Server Standard Edition စက် 50 ကျော် ပါဝင်ပါသည်။ ဤဒေတာကို ACID အရောင်းအ၀ယ်လုပ်ငန်းများ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် ပြင်ဆင်ပြီး လိုအပ်ပါသည်။ မြင့်မားသောကိုက်ညီမှု.

SQL Server node များတစ်လျှောက် ဒေတာဖြန့်ဝေရန် ဒေါင်လိုက်နှင့် အလျားလိုက် နှစ်မျိုးလုံးကို အသုံးပြုခဲ့သည်။ ပိုင်းခြားခြင်း။ (ခွဲထုတ်ခြင်း)။ သမိုင်းအရ၊ ကျွန်ုပ်တို့သည် ရိုးရှင်းသောဒေတာခွဲထုတ်ခြင်းအစီအစဉ်ကို အသုံးပြုခဲ့သည်- တစ်ခုချင်းစီသည် တိုကင်တစ်ခုနှင့် ဆက်စပ်နေသည် - entity ID ၏လုပ်ဆောင်ချက်တစ်ခုဖြစ်သည်။ တူညီသော တိုကင်ပါသော အရာများကို တူညီသော SQL ဆာဗာတွင် ထားရှိခဲ့သည်။ ပင်မနှင့် ကလေးမှတ်တမ်းများ၏ တိုကင်များကို အမြဲတမ်းကိုက်ညီပြီး တူညီသောဆာဗာပေါ်တွင် တည်ရှိစေရန် မာစတာအသေးစိတ်ဆက်ဆံရေးကို အကောင်အထည်ဖော်ခဲ့သည်။ လူမှုကွန်ရက်တစ်ခုတွင်၊ အသုံးပြုသူကိုယ်စား မှတ်တမ်းများအားလုံးကို ထုတ်ပေးသည် - ဆိုလိုသည်မှာ အလုပ်လုပ်နိုင်သောစနစ်ခွဲတစ်ခုအတွင်းရှိ သုံးစွဲသူဒေတာအားလုံးကို ဆာဗာတစ်ခုပေါ်တွင် သိမ်းဆည်းထားသည်။ ဆိုလိုသည်မှာ၊ လုပ်ငန်းတစ်ခုတွင် SQL server တစ်ခုမှ ဇယားများ အမြဲလိုလို ပါ၀င်နေသောကြောင့် local ACID အရောင်းအ၀ယ်များကို အသုံးပြုစရာမလိုဘဲ data ကိုက်ညီမှုရှိစေရန်၊ နှေးကွေးပြီး စိတ်မချရပါ။ ဖြန့်ဝေထားသော ACID အရောင်းအ၀ယ်။

sharding နှင့် SQL ကိုအရှိန်မြှင့်ရန်ကျေးဇူးတင်ပါသည်။

• entity ID ကို ခွဲထုတ်သည့်အခါ အခြားဆာဗာတွင် ရှိနေနိုင်သောကြောင့် Foreign key ကန့်သတ်ချက်များကို ကျွန်ုပ်တို့ မသုံးပါ။
• DBMS CPU တွင် ထပ်လောင်းဝန်ကြောင့် သိမ်းဆည်းထားသော လုပ်ထုံးလုပ်နည်းများနှင့် အစပျိုးမှုများကို မသုံးပါ။
• အထက်ဖော်ပြပါအားလုံးနှင့် ဒစ်ခ်မှ ကျပန်းဖတ်ခြင်းများစွာကြောင့် JOIN များကို ကျွန်ုပ်တို့ မသုံးပါ။
• အရောင်းအ၀ယ်ပြင်ပတွင်၊ သော့ခတ်မှုများလျှော့ချရန် ကျွန်ုပ်တို့သည် Read Uncommitted isolation အဆင့်ကို အသုံးပြုပါသည်။
• ကျွန်ုပ်တို့သည် တိုတောင်းသော ငွေပေးငွေယူများကိုသာ လုပ်ဆောင်သည် (ပျမ်းမျှအားဖြင့် 100 ms ထက်တိုသည်)။
• ပိတ်ဆို့ခြင်းများစွာကြောင့် အတန်းပေါင်းများစွာ UPDATE နှင့် DELETE ကို မသုံးပါ - ကျွန်ုပ်တို့သည် တစ်ကြိမ်လျှင် မှတ်တမ်းတစ်ခုသာ အပ်ဒိတ်လုပ်ပါသည်။
• ကျွန်ုပ်တို့သည် အညွှန်းများပေါ်တွင်သာ စုံစမ်းမေးမြန်းမှုများကို အမြဲလုပ်ဆောင်သည် - ကျွန်ုပ်တို့အတွက် စားပွဲအပြည့်စကင်န်အစီအစဥ်ပါရှိသော query သည် ဒေတာဘေ့စ်ကို အလွန်အကျွံတင်စေပြီး ၎င်းကို ကျရှုံးစေပါသည်။

ဤအဆင့်များသည် SQL ဆာဗာများမှ အမြင့်ဆုံးစွမ်းဆောင်ရည်နီးပါးကို ညှစ်ထုတ်နိုင်စေပါသည်။ သို့သော် ပြဿနာများ ပိုများလာသည်။ သူတို့ကိုကြည့်ရအောင်။

SQL ပြဿနာများ

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

ဒါပေမယ့် အဓိကပြဿနာက

အမှားခံနိုင်ရည်

မူရင်း SQL ဆာဗာတွင် အမှားခံနိုင်ရည် ညံ့ဖျင်းသည်။ သင့်တွင်ဒေတာဘေ့စ်ဆာဗာတစ်ခုသာရှိသည်ဆိုပါစို့၊ ၎င်းသည်သုံးနှစ်တစ်ကြိမ်ပျက်ကွက်သည်ဆိုပါစို့။ ဤအချိန်အတောအတွင်း ဆိုက်သည် မိနစ် 20 ကြာ ပျက်သွားသည့်အတွက် လက်ခံနိုင်ဖွယ်ရှိသည်။ သင့်တွင် ဆာဗာ 64 ခုရှိပါက၊ ဆိုက်သည် သုံးပတ်လျှင် တစ်ကြိမ် ပျက်နေပါသည်။ အကယ်၍ သင့်တွင် ဆာဗာ 200 ရှိပါက၊ ဆိုက်သည် အပတ်စဉ် အလုပ်မလုပ်ပါ။ ဒါက ပြဿနာပါ။

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

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

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

ဒီအတွက် ကျွန်တော်တို့ သုံးနိုင်တယ်။ ဆရာကြီး SQL Server တွင် ကူးယူတည်ဆောက်ထားသည်။ ဤဖြေရှင်းချက်သည် ဆော့ဖ်ဝဲ၏ကုန်ကျစရိတ်ကြောင့် များစွာစျေးကြီးပြီး ကူးယူခြင်းဆိုင်ရာ လူသိများသည့်ပြဿနာများကို ကြုံတွေ့နေရသည် - တစ်ပြိုင်တည်းပုံတူကူးခြင်းနှင့် ထပ်တူပြုခြင်းအတွက် နှောင့်နှေးမှုများ (နှင့် ပေါင်းစပ်မွမ်းမံမှုများ လျှောက်ထားရာတွင် နှောင့်နှေးမှုများ) ဖြင့် ကူးယူခြင်းဆိုင်ရာ လူသိများသော ပြဿနာများကို ကြုံတွေ့နေရသည်။ အဓိပ္ပာယ်သက်ရောက်သည်။ လူကိုယ်တိုင် ပဋိပက္ခဖြေရှင်းခြင်း။ ဤရွေးချယ်မှုကို ကျွန်ုပ်တို့အတွက် လုံးဝ အသုံးမဝင်စေပါ။

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

ရိုးရှင်းသောငွေပေးငွေယူ

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

1. အယ်လ်ဘမ်ကို သော့ဖြင့် သော့ခတ်ထားသည်။
2. ဓာတ်ပုံဇယားတွင် ထည့်သွင်းမှုတစ်ခုကို ဖန်တီးပါ။
3. ဓာတ်ပုံတွင် အများသူငှာ အခြေအနေရှိပါက၊ ထို့နောက် အယ်လ်ဘမ်တွင် အများသူငှာ ဓာတ်ပုံကောင်တာတစ်ခုကို ထည့်ပါ၊ မှတ်တမ်းကို အပ်ဒိတ်လုပ်ပြီး ငွေပေးငွေယူပြုလုပ်ပါ။

သို့မဟုတ် pseudocode ဖြင့်-

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

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

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

အခြားအရေးကြီးသော လိုအပ်ချက်များမှာ-

• ဒေတာစင်တာတွင် ပျက်ကွက်ပါက၊ သိုလှောင်မှုအသစ်သို့ စာရေးခြင်းနှင့် စာဖတ်ခြင်း နှစ်ခုစလုံးကို ရနိုင်ရပါမည်။
• လက်ရှိ ဖွံ့ဖြိုးတိုးတက်မှု အရှိန်ကို ထိန်းသိမ်းပါ။ ဆိုလိုသည်မှာ repository အသစ်တစ်ခုနှင့်အလုပ်လုပ်သောအခါ၊ code ပမာဏသည် ခန့်မှန်းခြေအားဖြင့် တူညီသင့်သည်၊ repository တွင် မည်သည့်အရာကိုမျှ ထည့်ရန်မလိုအပ်ပါ၊ ပဋိပက္ခများကိုဖြေရှင်းရန်အတွက် algorithms များဖန်တီးရန်၊ ဒုတိယအညွှန်းကိန်းများကို ထိန်းသိမ်းထားရန်စသည်ဖြင့် မဖြစ်သင့်ပါ။
• သိုလှောင်မှုအသစ်၏ မြန်နှုန်းသည် ဒေတာကိုဖတ်ရှုသည့်အခါနှင့် ငွေပေးငွေယူများကို လုပ်ဆောင်သည့်အခါ နှစ်ခုစလုံးတွင် အလွန်မြင့်မားရမည်ဖြစ်ပြီး၊ ဥပမာ၊ ဥပမာ၊ ဥပမာ၊ ပညာရပ်ဆိုင်ရာ ပြင်းထန်သော၊ ကျယ်ကျယ်ပြန့်ပြန့်အသုံးပြုနိုင်သော်လည်း နှေးကွေးသောဖြေရှင်းနည်းများကို အသုံးချ၍မရပါ။ နှစ်ဆင့် ကျူးလွန်သည်။.
• အလိုအလျောက် ပျံသန်းမှု အတိုင်းအတာ။
• ထူးခြားဆန်းပြားသော ဟာ့ဒ်ဝဲများကို ဝယ်ယူစရာမလိုဘဲ ပုံမှန်စျေးပေါသော ဆာဗာများကို အသုံးပြုပါ။
• ကုမ္ပဏီ developer များမှ သိုလှောင်မှု ဖွံ့ဖြိုးတိုးတက်မှု ဖြစ်နိုင်ခြေ။ တစ်နည်းဆိုရသော် Java တွင် မူပိုင် သို့မဟုတ် open source ဖြေရှင်းချက်များအား ဦးစားပေးထားသည်။

ဆုံးဖြတ်ချက်များ၊ ဆုံးဖြတ်ချက်များ

ဖြစ်နိုင်ချေရှိသော ဖြေရှင်းချက်များကို ခွဲခြမ်းစိတ်ဖြာခြင်းဖြင့် ကျွန်ုပ်တို့သည် ဖြစ်နိုင်သော ဗိသုကာပညာ ရွေးချယ်မှုနှစ်ခုသို့ ရောက်လာသည်-

ပထမအချက်မှာ မည်သည့် SQL ဆာဗာကိုမဆို ရယူပြီး လိုအပ်သော အမှားအယွင်းများကို သည်းခံခြင်း၊ အတိုင်းအတာချဲ့ထွင်ခြင်း ယန္တရား၊ ပျက်ကွက်မှုအစုအဝေး၊ ပဋိပက္ခဖြေရှင်းခြင်းနှင့် ဖြန့်ဝေခြင်း၊ ယုံကြည်စိတ်ချရပြီး မြန်ဆန်သော ACID အရောင်းအ၀ယ်များကို အကောင်အထည်ဖော်ရန်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ဤရွေးချယ်မှုအား အလွန်အသေးအဖွဲမဟုတ်သော၊ လုပ်သားအထူးပြုအဖြစ် အဆင့်သတ်မှတ်ထားသည်။

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

Cassandra နှင့် CQL

ဒါဆို Cassandra ရဲ့ စိတ်ဝင်စားစရာက ဘာတွေလဲ၊ သူ့မှာ ဘယ်လိုစွမ်းရည်တွေ ရှိလဲ။

ပထမဦးစွာ၊ ဤနေရာတွင် သင်သည် ဒေတာအမျိုးအစားအမျိုးမျိုးကို ပံ့ပိုးပေးသည့် ဇယားများကို ဖန်တီးနိုင်သည်၊ သင်သည် အဓိကသော့ပေါ်တွင် SELECT သို့မဟုတ် UPDATE ပြုလုပ်နိုင်သည်။

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

ပုံတူဒေတာ ညီညွတ်မှုရှိစေရန် Cassandra ကို အသုံးပြုသည်။ quorum ချဉ်းကပ်မှု. အရိုးရှင်းဆုံးအခြေအနေတွင်၊ တူညီသောအတန်း၏ပုံတူသုံးပုံတူများကို အစုအဝေး၏မတူညီသော node များပေါ်တွင်တင်သောအခါ၊ node အများစု (ဆိုလိုသည်မှာ သုံးခုအနက်မှ နှစ်ခု) သည် ဤရေးရန်လုပ်ဆောင်ချက်၏အောင်မြင်မှုကိုအတည်ပြုပါက write ကိုအောင်မြင်သည်ဟုယူဆပါသည်။ . အတန်းဒေတာကို ဖတ်သည့်အခါ၊ node အများစုကို စစ်တမ်းကောက်ယူပြီး အတည်ပြုပါက အတန်းဒေတာသည် တစ်သမတ်တည်းဟု ယူဆပါသည်။ ထို့ကြောင့်၊ ပုံစံတူသုံးမျိုးဖြင့် node တစ်ခုပျက်သွားပါက ပြီးပြည့်စုံပြီး ချက်ချင်းဒေတာညီညွတ်မှုကို အာမခံပါသည်။ ဤချဉ်းကပ်မှုသည် ကျွန်ုပ်တို့အား ပို၍ယုံကြည်စိတ်ချရသော အစီအစဥ်ကို အကောင်အထည်ဖော်နိုင်စေသည်- အလျင်မြန်ဆုံးနှစ်ခုထံမှ တုံ့ပြန်မှုကို စောင့်မျှော်လျက် ပုံစံတူသုံးမျိုးစလုံးထံ တောင်းဆိုမှုများကို အမြဲပေးပို့ပါ။ ဤကိစ္စတွင် တတိယပုံတူ၏ နောက်ကျတုံ့ပြန်မှုကို ပယ်ချပါသည်။ တုံ့ပြန်မှုနောက်ကျသော ကုဒ်တစ်ခုတွင် ဘရိတ်များ၊ JVM တွင် အမှိုက်စုဆောင်းမှု၊ Linux kernel တွင် တိုက်ရိုက်မှတ်ဉာဏ် ပြန်လည်ရယူမှု၊ ဟာ့ဒ်ဝဲချို့ယွင်းမှု၊ ကွန်ရက်ချိတ်ဆက်မှု ပြတ်တောက်သွားနိုင်သည်။ သို့သော်၊ ၎င်းသည် သုံးစွဲသူ၏ လုပ်ငန်းဆောင်ရွက်မှု သို့မဟုတ် ဒေတာကို မည်သည့်နည်းဖြင့်မျှ မထိခိုက်စေပါ။

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

Cassandra ၏နောက်ထပ်အကျိုးကျေးဇူးမှာ Batchlog သည် သင်ပြုလုပ်သောပြောင်းလဲမှုအသုတ်များကို အပြည့်အဝအသုံးချသည်ဖြစ်စေ လုံးဝမအသုံးချကြောင်းသေချာစေသည့်ယန္တရားတစ်ခုဖြစ်သည်။ ၎င်းသည် ကျွန်ုပ်တို့အား ACID တွင် A မှဖြေရှင်းနိုင်စေပါသည်။

Cassandra တွင် အရောင်းအ၀ယ်နှင့် အနီးစပ်ဆုံးအရာမှာ "ပေါ့ပါးသော အရောင်းအဝယ်များ” . သို့သော် ၎င်းတို့သည် “စစ်မှန်သော” ACID အရောင်းအ၀ယ်များနှင့် ဝေးကွာသည်- အမှန်တွင်၊ ၎င်းသည် လုပ်ဆောင်ရန် အခွင့်အရေးတစ်ခုဖြစ်သည်။ CAS ဟဲဗီးဝိတ် Paxos ပရိုတိုကောကို အသုံးပြု၍ သဘောတူညီမှုကို အသုံးပြု၍ တစ်ခုတည်းသော မှတ်တမ်းမှ ဒေတာအပေါ်။ ထို့ကြောင့် ထိုသို့သော အရောင်းအ၀ယ်များ၏ အရှိန်မှာ နိမ့်ကျနေသည်။

Cassandra တွင် ကျွန်ုပ်တို့ ပျောက်ဆုံးနေသောအရာများ

ဒါကြောင့် Cassandra မှာ တကယ့် ACID အရောင်းအ၀ယ်တွေကို အကောင်အထည်ဖော်ခဲ့ရပါတယ်။ ဂန္ထဝင် DBMS ၏ အခြားအဆင်ပြေသည့် အင်္ဂါရပ်နှစ်ခုကို ကျွန်ုပ်တို့ အလွယ်တကူ အကောင်အထည်ဖော်နိုင်သည်- အဓိကကီးဖြင့်သာမက ဒေတာရွေးချယ်မှုများကို လုပ်ဆောင်နိုင်စေမည့် တသမတ်တည်း မြန်ဆန်သော အညွှန်းကိန်းများနှင့် မိုနိုတိုနစ် အလိုအလျောက် တိုးလာနေသော ID များ၏ ပုံမှန် ဂျင်နရေတာတစ်ခု။

C*One

ထို့ကြောင့် DBMS အသစ်တစ်ခု မွေးဖွားလာခဲ့သည်။ C*Oneserver node အမျိုးအစားသုံးမျိုး ပါဝင်သော၊

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

အမျိုးအစားအားလုံး၏ဆာဗာများသည် ဘုံအစုအဝေးတစ်ခု၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်၊ တစ်ခုနှင့်တစ်ခု ဆက်သွယ်ရန်အတွက် အတွင်းပိုင်း Cassandra မက်ဆေ့ချ်ပရိုတိုကောကို အသုံးပြု၍ အမနာပစကား အစုအဖွဲ့အချက်အလက် ဖလှယ်ရန်အတွက်။ Heartbeat ဖြင့် ဆာဗာများသည် အပြန်အလှန်ကျရှုံးမှုများအကြောင်း လေ့လာသင်ယူကြပြီး၊ တစ်ခုတည်းသောဒေတာအစီအစဉ် - ဇယားများ၊ ၎င်းတို့၏ဖွဲ့စည်းပုံနှင့် ပုံတူပွားမှုများကို ထိန်းသိမ်းပါ။ partitioning scheme၊ cluster topology စသည်ဖြင့်၊

client များ

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

C*One Transaction Coordinator

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

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

သော့ခလောက်များ

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

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

ကျွန်ုပ်တို့၏အခြေအနေတွင် SQL ရှိ ဒေသတွင်း ငွေပေးငွေယူအုပ်စုများကြားတွင် ဒေတာကို ဖြန့်ဝေထားပြီးဖြစ်သောကြောင့်၊ ဒေသန္တရ ငွေပေးငွေယူအဖွဲ့များကို ညှိနှိုင်းရေးမှူးများထံ တာဝန်ပေးအပ်ရန် ဆုံးဖြတ်ခဲ့သည်- ညှိနှိုင်းရေးမှူးတစ်ဦးသည် တိုကင်များ 0 မှ 9 အထိ အရောင်းအ၀ယ်အားလုံးကို လုပ်ဆောင်သည်၊ ဒုတိယ - တိုကင် 10 မှ 19 အထိ၊ နောက် ... ပြီးတော့။ ရလဒ်အနေဖြင့်၊ ညှိနှိုင်းရေးမှူးဖြစ်ရပ်တစ်ခုစီသည် ငွေပေးငွေယူအဖွဲ့၏ မာစတာဖြစ်လာသည်။

ထို့နောက် သော့ခတ်မှုများကို ညှိနှိုင်းရေးမှူး၏ မှတ်ဉာဏ်တွင် banal HashMap ပုံစံဖြင့် အကောင်အထည်ဖော်နိုင်သည်။

ညှိနှိုင်းရေးမှူး မအောင်မြင်ပါ။

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

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

၎င်းတို့၏နှလုံးခုန်သံမက်ဆေ့ခ်ျ၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့် အခြားသူများထံမှအလားတူအချက်အလက်များကို လက်ခံရယူခြင်းဖြင့် ညှိနှိုင်းရေးမှူးတစ်ဦးစီသည် မည်သည့်အစုအဝေးများလုပ်ဆောင်နေပြီး မည်သည့်အရာသည် မလုပ်ဆောင်သည်ကို သူ့ကိုယ်သူဆုံးဖြတ်သည်- quorum နိယာမအရ Node X သည် ပုံမှန်နှင့်ပတ်သက်သည့် အစုအဝေးများရှိ node အများစုထံမှ သတင်းအချက်အလက်ကို လက်ခံရရှိပါက၊ node Y မှ မက်ဆေ့ချ်လက်ခံရရှိခြင်း ၊ ထို့နောက် Y သည် အလုပ်လုပ်သည်။ အပြန်အလှန်အားဖြင့်၊ အများစုသည် node Y မှ ပျောက်ဆုံးနေသော မက်ဆေ့ချ်များကို သတင်းပို့သည်နှင့် Y သည် ငြင်းဆိုထားသည်။ အကယ်၍ quorum သည် node X မှ မက်ဆေ့ချ်များကို လက်ခံရရှိတော့မည် မဟုတ်ကြောင်းကို quorum က အသိပေးပါက node X ကိုယ်တိုင်က မအောင်မြင်ဟု ယူဆပါလိမ့်မည်။

နှလုံးခုန်သံစာတိုများကို အကြိမ်ရေ 20 ms ဖြင့် တစ်စက္ကန့်လျှင် အကြိမ် 50 ခန့် ကြိမ်နှုန်းမြင့်ဖြင့် ပေးပို့ပါသည်။ Java တွင်၊ အမှိုက်စုဆောင်းသူ၏ နှိုင်းယှဉ်နိုင်သော ခေတ္တရပ်နားသည့်ကြာချိန်ကြောင့် 50 ms အတွင်း လျှောက်လွှာတုံ့ပြန်မှုကို အာမခံရန် ခက်ခဲသည်။ GC ခေတ္တရပ်သည့်ကြာချိန်အတွက် ပစ်မှတ်တစ်ခုကို သတ်မှတ်ခွင့်ပြုသည့် G1 အမှိုက်စုဆောင်းသူကို အသုံးပြု၍ ဤတုံ့ပြန်မှုအချိန်ကို ကျွန်ုပ်တို့ ရရှိနိုင်ပါသည်။ သို့သော်၊ တစ်ခါတစ်ရံတွင်၊ စုဆောင်းသူသည် 50 ms ထက်ကျော်လွန်၍ ခေတ္တရပ်သည်၊ ၎င်းသည် မှားယွင်းသောအမှားရှာဖွေတွေ့ရှိမှုကို ဖြစ်ပေါ်စေနိုင်သည်။ ထိုသို့မဖြစ်ပွားစေရန်အတွက်၊ ညှိနှိုင်းရေးမှူးသည် ၎င်းမှပထမနှလုံးခုန်ချက်မက်ဆေ့ချ် ပျောက်သွားသောအခါတွင် အဝေးထိန်းခလုတ်၏ ချို့ယွင်းချက်ကို အစီရင်ခံမည်မဟုတ်ပါ၊ ဆက်တိုက်အများအပြား ပျောက်ကွယ်သွားမှသာ 200 တွင် ညှိနှိုင်းရေးနိတ်၏ ပျက်ကွက်မှုကို ကျွန်ုပ်တို့ သိရှိနိုင်ပုံဖြစ်ပါသည်။ ဒေါ်။

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

ယူထား

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

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

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

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

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

အရောင်းအဝယ်ဘယ်လိုအလုပ်လုပ်လဲ။

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

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

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

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

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

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

နောက်ပြန်ဆွဲရန်၊ ညှိနှိုင်းရေးမှူးသည် ငွေပေးငွေယူအခြေအနေမှ သိမ်းပိုက်ထားသော မမ်မိုရီကို ဖယ်ရှားရန်သာ လိုအပ်သည်။

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

• ပြည်တော်သာ. ဤသည်မှာ ငွေပေးငွေယူစနစ်တွင် တစ်စိတ်တစ်ပိုင်းမှတ်တမ်းတင်မည်မဟုတ်ကြောင်း အာမခံချက်ဖြစ်ပြီး ၎င်း၏လုပ်ငန်းခွဲများအားလုံးကို ပြီးမြောက်စေမည် သို့မဟုတ် ပြီးမြောက်မည်မဟုတ်ကြောင်း အာမခံချက်ဖြစ်သည်။ Cassandra တွင် logged batch ဖြင့် ကျွန်ုပ်တို့သည် ဤမူကို လိုက်နာပါသည်။
• ရှေ့နောက်ညီညွတ်မှု. အောင်မြင်သော ငွေပေးငွေယူတစ်ခုစီသည် အဓိပ္ပါယ်အားဖြင့် မှန်ကန်သောရလဒ်များကိုသာ မှတ်တမ်းတင်ပါသည်။ ငွေပေးငွေယူတစ်ခုဖွင့်ပြီး လုပ်ဆောင်ချက်များ၏ အစိတ်အပိုင်းကို လုပ်ဆောင်ပြီးနောက်၊ ရလဒ်သည် မမှန်ကန်ကြောင်း တွေ့ရှိပါက၊ ပြန်လှည့်ခြင်းကို လုပ်ဆောင်ပါသည်။
• သီးသန့်ထားခြင်း၊ ခွဲထားခြင်း. ငွေပေးငွေယူကို လုပ်ဆောင်သောအခါ၊ တစ်ပြိုင်တည်း ငွေပေးငွေယူများသည် ၎င်း၏ရလဒ်ကို မထိခိုက်စေသင့်ပါ။ ညှိနှိုင်းရေးမှူးပေါ်ရှိ အဆိုးမြင်သောသော့ခလောက်များကို အသုံးပြု၍ ပြိုင်ဆိုင်သော ငွေပေးငွေယူများကို သီးခြားခွဲထားသည်။ ငွေပေးငွေယူပြင်ပတွင်ဖတ်ရှုခြင်းအတွက်၊ သီးခြားခွဲထုတ်ခြင်းနိယာမကို Read Committed အဆင့်တွင်တွေ့ရှိရသည်။
• တည်ငြိမ်ခြင်း. အောက်ခြေအဆင့်တွင် ပြဿနာများ—စနစ်ပျက်ခြင်း၊ ဟာ့ဒ်ဝဲချို့ယွင်းမှု—လုပ်ငန်းဆောင်ရွက်မှုများ ပြန်လည်စတင်သောအခါတွင် အောင်မြင်စွာပြီးဆုံးသွားသော အပြောင်းအလဲများကို ထိန်းသိမ်းထားသင့်သည်။

အညွှန်းများဖြင့်ဖတ်ခြင်း။

ရိုးရှင်းတဲ့ စားပွဲကို ကြည့်ရအောင်။

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

၎င်းတွင် ID (ပင်မသော့)၊ ပိုင်ရှင်နှင့် ပြုပြင်မွမ်းမံသည့်ရက်စွဲတစ်ခု ပါရှိသည်။ သင်သည် အလွန်ရိုးရှင်းသော တောင်းဆိုမှုတစ်ခု ပြုလုပ်ရန် လိုအပ်သည် - "နောက်ဆုံးနေ့အတွက်" ပြောင်းလဲသည့်ရက်စွဲဖြင့် ပိုင်ရှင်ရှိ ဒေတာကို ရွေးချယ်ပါ။

SELECT *
WHERE owner=?
AND modified>?

ထိုသို့သောမေးခွန်းကို လျင်မြန်စွာလုပ်ဆောင်နိုင်ရန်၊ ဂန္တဝင် SQL DBMS တွင် ကော်လံများ (ပိုင်ရှင်၊ ပြင်ဆင်ထားသည်) ဖြင့် အညွှန်းတစ်ခုတည်ဆောက်ရန် လိုအပ်သည်။ ယခုကျွန်ုပ်တို့၌ ACID အာမခံချက်ရှိသောကြောင့် ၎င်းကိုကျွန်ုပ်တို့အတော်လေးလွယ်ကူစွာပြုလုပ်နိုင်ပါသည်။

C*One တွင် အညွှန်းများ

မှတ်တမ်း ID သည် အဓိကသော့ချက်ဖြစ်သည့် ဓာတ်ပုံများပါသည့် အရင်းအမြစ်ဇယားတစ်ခုရှိသည်။

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

ယခု "နောက်ဆုံးနေ့အတွက် ပိုင်ရှင်" အတွက် မေးမြန်းချက်ကို အခြားဇယားမှ ရွေးချယ်မှုအဖြစ် ပြန်လည်ရေးသားနိုင်သည်-

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

ACID ကို အသုံးပြု၍ SQL-like indexes များကို အကောင်အထည်ဖော်နိုင်ခဲ့သည်။ ၎င်းတို့သည် တသမတ်တည်း၊ အရွယ်တင်နိုင်သော၊ မြန်ဆန်သည်၊ ပေါင်းစပ်နိုင်သော၊ CQL query language တွင် တည်ဆောက်ထားသည်။ အညွှန်းများကို ပံ့ပိုးရန်အတွက် အပလီကေးရှင်းကုဒ်ကို ပြောင်းလဲရန် မလိုအပ်ပါ။ အရာအားလုံးသည် SQL တွင်ကဲ့သို့ရိုးရှင်းသည်။ အရေးအကြီးဆုံးကတော့၊ အညွှန်းကိန်းများသည် မူလငွေပေးငွေယူဇယားသို့ ပြုပြင်ပြောင်းလဲမှုများ၏ လုပ်ဆောင်မှုအမြန်နှုန်းကို မထိခိုက်စေပါ။

ဘာဖြစ်သွားတာလဲ

ကျွန်ုပ်တို့သည် C*One ကို လွန်ခဲ့သည့် သုံးနှစ်က တီထွင်ခဲ့ပြီး စီးပွားဖြစ်လည်ပတ်မှုအဖြစ် စတင်ခဲ့သည်။

အဆုံးမှာ ငါတို့ ဘာရခဲ့လဲ။ လူမှုကွန်ရက်ရှိ အရေးကြီးဆုံးဒေတာအမျိုးအစားများထဲမှ တစ်ခုဖြစ်သော ဓာတ်ပုံလုပ်ဆောင်ခြင်းနှင့် သိုလှောင်မှုစနစ်ခွဲ၏ ဥပမာကို အသုံးပြု၍ ၎င်းကို အကဲဖြတ်ကြပါစို့။ ကျွန်ုပ်တို့သည် ဓာတ်ပုံများ၏ အလောင်းများအကြောင်းကို မပြောဘဲ မက်တာ-အချက်အလက် အမျိုးမျိုးအကြောင်း ပြောနေပါသည်။ ယခုအခါ Odnoklassniki တွင် ထိုကဲ့သို့သော မှတ်တမ်းများ ဘီလီယံ 20 ခန့်ရှိပြီး စနစ်သည် တစ်စက္ကန့်လျှင် 80 read requests 8 ၊ data ပြုပြင်မွမ်းမံမှု နှင့်ဆက်စပ်သော တစ်စက္ကန့်လျှင် ACID ငွေလွှဲမှု XNUMX အထိ လုပ်ဆောင်ပေးပါသည်။

ကျွန်ုပ်တို့သည် SQL ကို ပုံတူပွားမှုအချက် = 1 ဖြင့်အသုံးပြုသောအခါ (သို့သော် RAID 10 တွင်)၊ ဓာတ်ပုံရိုက်ကူးမှုပုံစံကို Microsoft SQL Server လည်ပတ်သည့် စက် 32 လုံး၏ အစုအဝေးတွင် သိမ်းဆည်းထားသည်။ အရန်သိမ်းဆည်းခြင်းအတွက် ဆာဗာ ၁၀ ခုကိုလည်း ခွဲဝေပေးထားသည်။ စုစုပေါင်း တန်ဖိုးကြီးကား အစီး ၅၀။ တစ်ချိန်တည်းမှာပင်၊ စနစ်သည် အရံမပါဘဲ အဆင့်သတ်မှတ်ထားသောဝန်ဖြင့် လုပ်ဆောင်သည်။

စနစ်အသစ်သို့ ပြောင်းရွှေ့ပြီးနောက်၊ ဒေတာစင်တာတစ်ခုစီရှိ မိတ္တူကူးယူခြင်းအချက် = 3 ကို ရရှိခဲ့ပါသည်။ စနစ်တွင် Cassandra သိုလှောင်မှုအမှတ် 63 နှင့် ညှိနှိုင်းရေးစက် 6 ခု ပါ၀င်ပြီး စုစုပေါင်း ဆာဗာ 69 ခု ပါဝင်သည်။ ဒါပေမယ့် ဒီစက်တွေက အများကြီးစျေးသက်သာတယ်၊ သူတို့ရဲ့ စုစုပေါင်းကုန်ကျစရိတ်က SQL စနစ်တစ်ခုရဲ့ ကုန်ကျစရိတ်ရဲ့ 30% လောက်ရှိပါတယ်။ တစ်ချိန်တည်းမှာပင်, ဝန်ကို 30% တွင်ထိန်းသိမ်းထားသည်။

C*One ၏နိဒါန်းနှင့်အတူ၊ latency လည်း လျော့ကျသွားသည်- SQL တွင် စာရေးခြင်းလုပ်ဆောင်ချက်သည် 4,5 ms ခန့်ကြာသည်။ C*One တွင် - 1,6 ms ခန့်။ ငွေပေးငွေယူကြာချိန်သည် ပျှမ်းမျှ 40 ms ထက်နည်းသည်၊ commit ကို 2 ms တွင်ပြီးစီးသည်၊ ဖတ်ရှုပြီးရေးကြာချိန်သည် ပျမ်းမျှ 2 ms ဖြစ်သည်။ 99th percentile - 3-3,1 ms သာရှိပြီး၊ အချိန်ကုန်သည့်အရေအတွက်သည် အဆ 100 လျော့ကျသွားသည် - အားလုံးသည် ထင်ကြေးပေးသည့် ကျယ်ကျယ်ပြန့်ပြန့်အသုံးပြုမှုကြောင့်ဖြစ်သည်။

ယခုအချိန်တွင်၊ SQL Server node အများစုကို ဖျက်သိမ်းလိုက်ပါပြီ၊ ထုတ်ကုန်အသစ်များသည် C*One ကို အသုံးပြု၍သာ ထုတ်လုပ်လျက်ရှိသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ cloud တွင် အလုပ်လုပ်ရန် C*One ကို အဆင်ပြေအောင်ပြုလုပ်ထားပါသည်။ one-cloud၎င်းသည် အစုအသစ်များ ဖြန့်ကျက်မှုကို အရှိန်မြှင့်ရန်၊ ဖွဲ့စည်းမှုပုံစံကို ရိုးရှင်းစေပြီး အလိုအလျောက်လုပ်ဆောင်မှုကို လွယ်ကူစေသည်။ အရင်းအမြစ်ကုဒ်မရှိရင်၊ ဒါကိုလုပ်ရတာ ပိုခက်ပြီး ခက်လိမ့်မယ်။

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

source: www.habr.com