ဘဝမှာ အရာရာတိုင်းဟာ အနည်းဆုံး တစ်ကြိမ်လောက်တော့ ကြိုးစားရကျိုးနပ်တယ်လို့ ဆိုကြပါတယ်။ အကယ်၍ သင်သည် ဆက်စပ် DBMSs များနှင့် အလုပ်လုပ်ရာတွင် အသုံးပြုဖူးပါက၊ လက်တွေ့တွင် NoSQL နှင့် အကျွမ်းတဝင်ရှိရန်၊ အနည်းဆုံး၊ ယေဘုယျ ဖွံ့ဖြိုးတိုးတက်မှုအတွက် ပထမဆုံးဖြစ်သည်။ ယခုအခါ ဤနည်းပညာ၏ အရှိန်အဟုန်ဖြင့် ဖွံ့ဖြိုးတိုးတက်လာမှုကြောင့်၊ အထူးသဖြင့် အကျိုးစီးပွားကို လှုံ့ဆော်ပေးသည့် ဤအကြောင်းအရာနှင့် ပတ်သက်၍ သဘောထားကွဲလွဲမှုများနှင့် အပြင်းအထန် ငြင်းခုံမှုများ အများအပြား ရှိနေပါသည်။
ဤအငြင်းပွားမှုအားလုံး၏ အနှစ်သာရကို စေ့စေ့စပ်စပ်ကြည့်လျှင် ၎င်းတို့သည် မှားယွင်းသောချဉ်းကပ်မှုကြောင့် ဖြစ်ပေါ်လာသည်ကို သင်တွေ့နိုင်သည်။ NoSQL ဒေတာဘေ့စ်များကို လိုအပ်သည့်နေရာတွင် အတိအကျအသုံးပြုသူများသည် ကျေနပ်ကြပြီး ဤဖြေရှင်းချက်မှ အကျိုးကျေးဇူးအားလုံးကို ရရှိကြသည်။ ၎င်းသည် လုံးဝအသုံးမဝင်နိုင်သော panacea အဖြစ် ဤနည်းပညာကို အားကိုးသော စမ်းသပ်သူများသည် သိသာထင်ရှားသော အကျိုးကျေးဇူးများမရရှိဘဲ ဆက်စပ်ဒေတာဘေ့စ်များ၏ အားသာချက်များကို ဆုံးရှုံးလိုက်ရသည့်အတွက် စိတ်ပျက်ကြသည်။
Cassandra DBMS ကို အခြေခံ၍ ဖြေရှင်းချက်တစ်ခုကို အကောင်အထည်ဖော်ရာတွင် ကျွန်ုပ်တို့၏အတွေ့အကြုံကို ပြောပြပါမည်- ကျွန်ုပ်တို့ရင်ဆိုင်ခဲ့ရသည့်အရာများ၊ ခက်ခဲသောအခြေအနေများမှ ကျွန်ုပ်တို့ မည်သို့ရုန်းထွက်နိုင်သည်ဖြစ်စေ NoSQL ကိုအသုံးပြုခြင်းမှ အကျိုးအမြတ်ရရှိနိုင်ပြီး အပိုအားထုတ်မှုများ/ရန်ပုံငွေများ ရင်းနှီးမြှုပ်နှံရမည့်နေရာ .
ကနဦးတာဝန်မှာ သိုလှောင်မှုတစ်မျိုးမျိုးတွင် ဖုန်းခေါ်ဆိုမှုများကို မှတ်တမ်းတင်သည့်စနစ်တစ်ခု တည်ဆောက်ရန်ဖြစ်သည်။
စနစ်၏လည်ပတ်မှုနိယာမမှာအောက်ပါအတိုင်းဖြစ်သည်။ ထည့်သွင်းမှုတွင် ခေါ်ဆိုမှု၏ဖွဲ့စည်းပုံကို ဖော်ပြသည့် သီးခြားဖွဲ့စည်းပုံပါရှိသော ဖိုင်များပါဝင်သည်။ ထို့နောက် အပလီကေးရှင်းသည် ဤဖွဲ့စည်းပုံကို သင့်လျော်သောကော်လံများတွင် သိမ်းဆည်းထားကြောင်း သေချာစေသည်။ အနာဂတ်တွင်၊ စာရင်းသွင်းသူများအတွက် ယာဉ်အသွားအလာ သုံးစွဲမှုဆိုင်ရာ အချက်အလက် (အခကြေးငွေများ၊ ခေါ်ဆိုမှုများ၊ လက်ကျန်မှတ်တမ်း) ကို ပြသရန်အတွက် သိမ်းဆည်းထားသော ခေါ်ဆိုမှုများကို အသုံးပြုပါသည်။
Cassandra ကို သူတို့ ဘာကြောင့် ရွေးချယ်ခဲ့တာလဲ ရှင်းပါတယ် - သူက စက်သေနတ်လို ရေးတယ်၊ အရွယ်အစား လွယ်တယ်၊ အမှားကို ခံနိုင်ရည်ရှိတယ်။
ဒီတော့ ဒါက ကျွန်တော်တို့ကို အတွေ့အကြုံတွေပေးတယ်။
ဟုတ်ကဲ့၊ မအောင်မြင်သော node သည် ဝမ်းနည်းစရာမဟုတ်ပါ။ ဤသည်မှာ Cassandra ၏အမှားခံနိုင်ရည်၏ အနှစ်သာရဖြစ်သည်။ ဒါပေမယ့် node သည် အသက်ရှင်နေနိုင်ပြီး တစ်ချိန်တည်းမှာပင် စွမ်းဆောင်ရည်ကို စတင်ခံစားလာရသည်။. ထွက်ပေါ်လာသည့်အတိုင်း၊ ၎င်းသည် အစုအဖွဲ့တစ်ခုလုံး၏ စွမ်းဆောင်ရည်ကို ချက်ချင်းအကျိုးသက်ရောက်စေသည်။
Oracle က သင့်အား ၎င်း၏ကန့်သတ်ချက်များဖြင့် ကယ်တင်ခဲ့သော Cassandra သည် သင့်အား ကာကွယ်ပေးမည်မဟုတ်ပါ။. အကယ်၍ အပလီကေးရှင်းရေးသားသူသည် ၎င်းကိုကြိုတင်နားမလည်ပါက Cassandra အတွက်ရောက်ရှိလာသောနှစ်ဆသည် မူရင်းထက်မဆိုးပါ။ ရောက်တာနဲ့ သွင်းလိုက်မယ်။
IB သည် အလကား Cassandra ကို သေတ္တာထဲမှ ပြင်းပြင်းထန်ထန် မကြိုက်ပါ ။ အသုံးပြုသူ လုပ်ဆောင်ချက်များကို မှတ်တမ်းမှတ်ခြင်း မရှိဘဲ၊ အခွင့်အရေးများကို ခွဲခြားခြင်းမရှိပါ။. ခေါ်ဆိုမှုများနှင့်ပတ်သက်သည့် အချက်အလက်ကို ကိုယ်ရေးကိုယ်တာဒေတာဟု ယူဆသည်၊ ဆိုလိုသည်မှာ ၎င်းကို မည်သည့်နည်းဖြင့်မဆို တောင်းဆိုရန်/ပြောင်းလဲရန် ကြိုးပမ်းမှုအားလုံးကို နောက်ဆက်တွဲစာရင်းစစ်နိုင်ခြေဖြင့် မှတ်တမ်းတင်ထားရမည်ဖြစ်သည်။ ထို့အပြင်၊ မတူညီသောအသုံးပြုသူများအတွက် မတူညီသောအဆင့်များတွင် ရပိုင်ခွင့်များကို ခွဲခြားထားရန် လိုအပ်ကြောင်းကိုလည်း သိရှိထားရန်လိုသည်။ ရိုးရှင်းသော လည်ပတ်မှုအင်ဂျင်နီယာတစ်ဦးနှင့် သော့စကွက်တစ်ခုလုံးကို လွတ်လပ်စွာဖျက်နိုင်သည့် စူပါစီမံခန့်ခွဲသူသည် မတူညီသောအခန်းကဏ္ဍများ၊ မတူညီသောတာဝန်များနှင့် အရည်အချင်းများဖြစ်သည်။ ထိုသို့သောဝင်ရောက်ခွင့်အခွင့်အရေးများကို ကွဲပြားမှုမရှိပါက၊ ဒေတာ၏တန်ဖိုးနှင့် သမာဓိသည် မည်သည့်ကိုက်ညီမှုအဆင့်ထက်မဆို ချက်ချင်းမေးခွန်းထုတ်လာမည်ဖြစ်သည်။
ဖုန်းခေါ်ဆိုမှုများသည် အခြေအနေအမျိုးမျိုးအတွက် လေးနက်သောခွဲခြမ်းစိတ်ဖြာမှုနှင့် အချိန်အပိုင်းအခြားအလိုက်နမူနာနှစ်ခုစလုံးလိုအပ်ကြောင်း ထည့်သွင်းစဉ်းစားခြင်းမရှိပါ။ ရွေးချယ်ထားသော မှတ်တမ်းများကို ဖျက်ပြီး ပြန်လည်ရေးသားရမည်ဖြစ်သောကြောင့် (လုပ်ငန်း၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ ဒေတာသည် ကျွန်ုပ်တို့၏ loop တွင် မှားယွင်းစွာဝင်ရောက်လာသောအခါတွင် ဒေတာမွမ်းမံခြင်းလုပ်ငန်းစဉ်ကို ပံ့ပိုးပေးရမည်)၊ Cassandra သည် ကျွန်ုပ်တို့၏မိတ်ဆွေမဟုတ်ပါ။ Cassandra သည် piggy bank နှင့်တူသည် - ပစ္စည်းများထည့်ရန်အဆင်ပြေသော်လည်း၎င်းကိုသင်ထည့်မတွက်နိုင်ပါ။
စမ်းသပ်ဇုန်များသို့ ဒေတာလွှဲပြောင်းရာတွင် ပြဿနာတစ်ခု ကြုံတွေ့ခဲ့ရသည်။ (စာမေးပွဲတွင် ဆုံမှတ် ၅ ခုနှင့် ကျောင်းပွဲတွင် 5)။ ဤကိစ္စတွင်၊ အမှိုက်ပုံးကို အသုံးမပြုနိုင်ပါ။
Cassandra သို့ အပလီကေးရှင်းတစ်ခု၏ ဒေတာအစီအစဉ်ကို အပ်ဒိတ်လုပ်ရာတွင် ပြဿနာဖြစ်သည်။ ပြန်လှည့်ခြင်းသည် မှန်းမရသောနည်းလမ်းများဖြင့် ကုန်ထုတ်စွမ်းအားကို ဆုံးရှုံးသွားစေနိုင်သည့် ဂူသင်္ချိုင်းအများအပြားကို ထုတ်ပေးမည်ဖြစ်သည်။. Cassandra သည် အသံဖမ်းရန်အတွက် အကောင်းဆုံးဖြစ်ပြီး စာမရေးမီတွင် များစွာမစဉ်းစားပါ။ ၎င်းတွင် ရှိပြီးသား data ပါသည့် မည်သည့်လုပ်ဆောင်ချက်သည် အသံသွင်းခြင်းလည်းဖြစ်သည်။ ဆိုလိုသည်မှာ မလိုအပ်သောအရာများကို ဖျက်ခြင်းဖြင့် ကျွန်ုပ်တို့သည် ပို၍ပင် မှတ်တမ်းများ ထုတ်နိုင်မည်ဖြစ်ပြီး ၎င်းတို့ထဲမှ အချို့ကိုသာ အုတ်ဂူကျောက်များဖြင့် မှတ်သားထားမည်ဖြစ်သည်။
ထည့်သွင်းသည့်အခါ အချိန်ကုန်သွားသည်။ Cassandra သည် အသံသွင်းရာတွင် လှပသော်လည်း၊ တစ်ခါတစ်ရံ ဝင်လာသော စီးဆင်းမှုသည် သူမကို သိသိသာသာ ပဟေဠိ ဖြစ်စေနိုင်သည်။. အပလီကေးရှင်းသည် အကြောင်းတစ်ခုခုကြောင့် ထည့်သွင်း၍မရသော မှတ်တမ်းများစွာကို လည်ပတ်နေသည့်အခါ ၎င်းသည် ဖြစ်ပေါ်လာသည်။ နှေးကွေးသော စုံစမ်းမေးမြန်းမှုများ၊ ချဲ့ထွင်မှုဆိုင်းငံ့ထားသည့် မက်ထရစ်များအတွက် gc.log၊ စနစ်နှင့် အမှားရှာပြင်မှတ်တမ်းများကို စောင့်ကြည့်မည့် တကယ့် DBA တစ်ဦး လိုအပ်ပါမည်။
အစုအဝေးတစ်ခုအတွင်း ဒေတာစင်တာများစွာ။ ဘယ်ကနေဖတ်ရ၊ ဘယ်မှာရေးရမလဲ။
စာဖတ်ခြင်း နှင့် စာရေးခြင်း ကွဲသွားခြင်း ဖြစ်နိုင်ပါသလား။ သို့ဆိုလျှင်၊ စာရေးရန် သို့မဟုတ် စာဖတ်ရန် အပလီကေးရှင်းနှင့် ပို၍နီးကပ်သော DC ရှိသင့်ပါသလား။ ညီညွတ်မှုအဆင့်ကို မှားယွင်းစွာရွေးချယ်ပါက ကျွန်ုပ်တို့သည် အမှန်တကယ်ကွဲထွက်သွားသော ဦးနှောက်နှင့် အဆုံးသတ်မည်မဟုတ်ပါ။ မေးခွန်းများစွာ၊ မသိသောဆက်တင်များစွာ၊ သင်အမှန်တကယ်လုပ်ဆောင်လိုသော ဖြစ်နိုင်ခြေများရှိသည်။
ငါတို့ဘယ်လိုဆုံးဖြတ်လဲ။
node နစ်မြုပ်ခြင်းမှ ကာကွယ်ရန် SWAP ကို ပိတ်ထားသည်။. ယခု၊ မှတ်ဉာဏ်ချို့တဲ့ပါက၊ node သည် အောက်သို့ကျသွားပြီး ကြီးမားသော gc ခေတ္တရပ်ခြင်းကို မဖန်တီးသင့်ပါ။
ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်ရှိ ယုတ္တိဗေဒကို အားမကိုးတော့ပါ။ အပလီကေးရှင်းဆော့ဖ်ဝဲရေးသားသူများသည် ၎င်းတို့ကိုယ်မိမိ ပြန်လည်လေ့ကျင့်နေကြပြီး ၎င်းတို့၏ကိုယ်ပိုင်ကုဒ်တွင် ကြိုတင်သတိထားမှုများကို စတင်လုပ်ဆောင်နေကြသည်။ စံပြရှင်းလင်းစွာ ဒေတာသိမ်းဆည်းခြင်းနှင့် စီမံဆောင်ရွက်ခြင်း။
ကျွန်ုပ်တို့သည် DataStax မှပံ့ပိုးကူညီမှုအား ဝယ်ယူခဲ့သည်။ သေတ္တာ Cassandra ၏ဖွံ့ဖြိုးတိုးတက်မှုသည်ရပ်တန့်ပြီး (နောက်ဆုံးကတိကဝတ်သည် 2018 ဖေဖော်ဝါရီလတွင်ဖြစ်သည်)။ တစ်ချိန်တည်းမှာပင်၊ Datastax သည် ကောင်းမွန်သောဝန်ဆောင်မှုနှင့် ရှိပြီးသား IP ဖြေရှင်းချက်များအတွက် ပြုပြင်ပြောင်းလဲပြီး လိုက်လျောညီထွေဖြစ်စေသော ဖြေရှင်းချက်များစွာကို ပေးဆောင်ပါသည်။
Cassandra သည် ရွေးချယ်မှုမေးမြန်းချက်များအတွက် အလွန်အဆင်ပြေကြောင်းကိုလည်း သတိပြုစေလိုပါသည်။ ဟုတ်ပါတယ်၊ CQL သည် သုံးစွဲသူများအတွက် (Trift နှင့် နှိုင်းယှဉ်လျှင်) ကြီးမားသော ခြေလှမ်းတစ်ခုဖြစ်သည်။ သို့သော် အကယ်၍ သင့်တွင် ဤကဲ့သို့သော အဆင်ပြေသော ပူးပေါင်းပါဝင်မှုများ၊ မည်သည့်နယ်ပယ်နှင့်မဆို စုံစမ်းမေးမြန်းမှု ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်နိုင်မှုတို့ဖြင့် အခမဲ့စစ်ထုတ်လေ့ရှိပြီး အဆိုပါဌာနများသည် တိုင်ကြားမှုများနှင့် မတော်တဆမှုများကို ဖြေရှင်းရန် လုပ်ဆောင်နေပါက၊ Cassandra ရှိ ဖြေရှင်းချက်သည် ၎င်းတို့အတွက် ဒေါသဖြစ်ပြီး မိုက်မဲပုံရသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏လုပ်ဖော်ကိုင်ဖက်များ မည်သို့နမူနာပြုလုပ်သင့်သည်ကို စတင်ဆုံးဖြတ်ခဲ့ပါသည်။
ရွေးချယ်စရာနှစ်ခုကို ကျွန်ုပ်တို့စဉ်းစားခဲ့သည်။ ပထမရွေးချယ်မှုတွင်၊ ကျွန်ုပ်တို့သည် ခေါ်ဆိုမှုများကို C* တွင်သာမက သိမ်းဆည်းထားသော Oracle ဒေတာဘေ့စ်တွင်လည်း ရေးပါသည်။ C* နှင့်မတူဘဲ၊ ဤဒေတာဘေ့စ်မှသာလျှင် လက်ရှိလအတွက်ခေါ်ဆိုမှုများကိုသာ သိမ်းဆည်းသည် (ပြန်လည်အားသွင်းသည့်ကိစ္စများအတွက် လုံလောက်သောခေါ်ဆိုမှုသိုလှောင်မှုအတိမ်အနက်)။ ဤတွင် အောက်ပါပြဿနာကို ကျွန်ုပ်တို့ ချက်ချင်းတွေ့မြင်ခဲ့သည်- ကျွန်ုပ်တို့သည် တပြိုင်တည်းရေးသားပါက၊ အမြန်ထည့်သွင်းခြင်းနှင့်ဆက်စပ် C* ၏ အားသာချက်များအားလုံးကို ကျွန်ုပ်တို့ဆုံးရှုံးရမည်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် တပြိုင်တည်းရေးသားပါက၊ လိုအပ်သောခေါ်ဆိုမှုများအားလုံးကို Oracle တွင် လုံးဝရောက်ရှိကြောင်း အာမခံချက်မရှိပါ။ အပေါင်းတစ်ခုရှိသော်လည်း ကြီးကြီးမားမားတစ်ခုရှိသည်- လုပ်ငန်းဆောင်ရွက်မှုအတွက် တူညီသောအကျွမ်းတဝင်ရှိသော PL/SQL Developer သည် "Facade" ပုံစံကို လက်တွေ့ကျကျ အကောင်အထည်ဖော်နေပါသည်။ အခြားရွေးချယ်စရာတစ်ခု။ ကျွန်ုပ်တို့သည် C* မှ ခေါ်ဆိုမှုများကို ဖယ်ရှားပြီး Oracle ရှိ သက်ဆိုင်ရာ ဇယားများမှ ကြွယ်ဝလာစေရန် ဒေတာအချို့ကို ဆွဲထုတ်ကာ ရလဒ်နမူနာများနှင့် ပေါင်းစပ်ကာ ရလဒ်ကို ကျွန်ုပ်တို့အား တစ်နည်းနည်းဖြင့် ပေးဆောင်သည် (နောက်ပြန်လှည့်၊ ထပ်ခါထပ်ခါ၊ ခွဲခြမ်းစိတ်ဖြာ၊ သဘောကျသည်)။ အားနည်းချက်- လုပ်ငန်းစဉ်သည် အဆင့်များစွာရှိပြီး၊ ထို့အပြင်၊ လုပ်ငန်းလည်ပတ်ဝန်ထမ်းများအတွက် ကြားခံစနစ်မရှိပါ။
အဆုံးတွင်၊ ကျွန်ုပ်တို့သည် ဒုတိယရွေးချယ်မှုအပေါ် အခြေချခဲ့သည်။ Apache Spark ကို အိုးအမျိုးမျိုးမှ နမူနာယူရန် အသုံးပြုခဲ့သည်။ သတ်မှတ်ထားသောသော့များ (စာရင်းသွင်းသူ၊ ဖုန်းခေါ်ဆိုသည့်အချိန် - အပိုင်းသော့များ) ကိုအသုံးပြု၍ C* မှဒေတာအပြင် အခြားဒေတာဘေ့စ်မှ ဖြည့်တင်းရန်အတွက် လိုအပ်သောဒေတာများကို ထုတ်ယူသည့်ယန္တရား၏အနှစ်သာရကို Java ကုဒ်သို့ လျှော့ချထားသည်။ ထို့နောက် ၎င်းသည် ၎င်းတို့ကို ၎င်း၏မှတ်ဉာဏ်တွင် ပေါင်းစည်းကာ ရလဒ်ဇယားတွင် ရလဒ်ကို ပြသသည်။ မီးပွားပေါ်မှ ဝဘ်မျက်နှာတစ်ခုကို ကျွန်ုပ်တို့ဆွဲလိုက်သည်နှင့် ၎င်းသည် အလွန်အသုံးဝင်ပါသည်။
စက်မှုစမ်းသပ်မှုဒေတာမွမ်းမံခြင်းပြဿနာကိုဖြေရှင်းသောအခါ၊ ကျွန်ုပ်တို့သည် ဖြေရှင်းနည်းများစွာကို ထပ်မံစဉ်းစားခဲ့သည်။ Sstloader မှတစ်ဆင့် လွှဲပြောင်းခြင်းနှင့် စမ်းသပ်ဇုန်ရှိ အစုအဝေးကို အပိုင်းနှစ်ပိုင်းခွဲရန် ရွေးချယ်ခွင့်၊ တစ်ခုစီသည် ပရိုမိုးရှင်းတစ်ခုနှင့် တူညီသော အစုအဝေးတွင် အလှည့်ကျပိုင်ဆိုင်သောကြောင့် ၎င်းကို ပံ့ပိုးပေးထားသည်။ စမ်းသပ်မှုကို အပ်ဒိတ်လုပ်သောအခါ၊ ၎င်းတို့ကို လဲလှယ်ရန် စီစဉ်ထားသည်- စမ်းသပ်မှုတွင် လုပ်ဆောင်ခဲ့သည့် အပိုင်းကို ရှင်းလင်းပြီး ထုတ်လုပ်ရေးသို့ ဝင်ရောက်ကာ အခြားတစ်ခုသည် သီးခြားဒေတာဖြင့် စတင်လုပ်ဆောင်ပါသည်။ သို့သော် ထပ်မံစဉ်းစားပြီးနောက်၊ ကျွန်ုပ်တို့သည် လွှဲပြောင်းရကျိုးနပ်သည့် ဒေတာကို ပို၍ ဆင်ခြင်တုံတရားဖြင့် အကဲဖြတ်ကာ ခေါ်ဆိုမှုများသည် စမ်းသပ်မှုများအတွက် ကိုက်ညီမှုမရှိသော အရာဖြစ်ကြောင်း သိရှိလာကာ လိုအပ်ပါက အမြန်ထုတ်ပေးကာ ၎င်းသည် လွှဲပြောင်းမှုအတွက် တန်ဖိုးမရှိသော ပရိုမိုးရှင်းဒေတာအစုံဖြစ်သည်။ စမ်းသပ်။ ရွှေ့ရကျိုးနပ်သော သိုလှောင်သည့် အရာများစွာ ရှိသည်၊ သို့သော် ၎င်းတို့သည် စာသားအရ စားပွဲနှစ်ခုဖြစ်ပြီး အလွန်လေးသော အရာများ မဟုတ်ပါ။ ထို့ကြောင့် ကျွန်ုပ်တို့ ဖြေရှင်းချက်အနေဖြင့် Spark သည် ကျွန်ုပ်တို့ရေးသားခဲ့သောအကူအညီဖြင့် ဇယားကွက်များကြားဒေတာလွှဲပြောင်းခြင်းအတွက် script တစ်ခုအားတက်ကြွစွာအသုံးပြုခြင်း၏အကူအညီဖြင့် Spark မှပြန်လည်ကယ်ဆယ်လာခဲ့ပါသည်။
ကျွန်ုပ်တို့၏ လက်ရှိဖြန့်ကျက်မှုမူဝါဒသည် ကျွန်ုပ်တို့အား နောက်ပြန်ဆုတ်ခြင်းမရှိဘဲ လုပ်ဆောင်နိုင်စေပါသည်။ ပရိုမိုရှင်းမပြုလုပ်မီ၊ အမှားတစ်ခုသည် အလွန်စျေးမကြီးသည့် မဖြစ်မနေ စမ်းသပ်မှုတစ်ခု ရှိပါသည်။ ချို့ယွင်းချက်ရှိပါက၊ သင်သည် casespace ကို အမြဲတမ်း လွှတ်ချနိုင်ပြီး အစီအစဉ်တစ်ခုလုံးကို အစမှ လှိမ့်နိုင်သည်။
Cassandra ကို စဉ်ဆက်မပြတ်ရရှိနိုင်စေရန်အတွက်၊ သင်သည် dba တစ်ခုတည်းသာမကဘဲ သင်လိုအပ်ပါသည်။ အပလီကေးရှင်းနှင့်အလုပ်လုပ်သူတိုင်းသည် လက်ရှိအခြေအနေနှင့် ပြဿနာများကို အချိန်နှင့်တစ်ပြေးညီသိရှိနိုင်စေရန် မည်သည့်နေရာနှင့် မည်သို့ကြည့်ရှုရမည်ကို နားလည်ရပါမည်။ ထိုသို့လုပ်ဆောင်ရန်၊ ကျွန်ုပ်တို့သည် DataStax OpsCenter (လုပ်ငန်းဆောင်တာများကို စီမံခန့်ခွဲခြင်းနှင့် စောင့်ကြည့်ခြင်း)၊ Cassandra Driver စနစ်မက်ထရစ်များ (C* သို့ စာရေးရန် အချိန်ကုန်သွားသော အရေအတွက်၊ C* မှ ဖတ်ရန် အချိန်ကုန်ဆုံးမှု အရေအတွက်၊ အများဆုံး latency စသည်ဖြင့်)၊ လုပ်ဆောင်ချက်ကို စောင့်ကြည့်ပါ Cassandra နှင့်အလုပ်လုပ်သော application ကိုယ်တိုင်။
ယခင်မေးခွန်းကို တွေးကြည့်သောအခါတွင် ကျွန်ုပ်တို့၏ အဓိကအန္တရာယ်သည် မည်သည့်နေရာတွင် ရှိနေနိုင်သည်ကို ကျွန်ုပ်တို့ သဘောပေါက်ပါသည်။ ဤအရာများသည် သီးခြားမေးမြန်းချက်များစွာမှ အချက်အလက်များကို သိုလှောင်ခန်းသို့ ပြသသည့် ဒေတာပြသမှုပုံစံများဖြစ်သည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် ကွဲလွဲနေသော အချက်အလက်များကို ရရှိနိုင်သည်။ သို့သော် ကျွန်ုပ်တို့သည် ဒေတာစင်တာတစ်ခုတွင်သာ လုပ်ဆောင်ပါက ဤပြဿနာသည် သက်ဆိုင်ပါသည်။ ထို့ကြောင့် ဤနေရာတွင် ကျိုးကြောင်းဆီလျော်မှုအရှိဆုံးအရာမှာ အချိန်အတိုင်းအတာတစ်ခုအတွင်း data ကိုလက်ခံရရှိကြောင်းသေချာစေမည့် Third-party application တစ်ခုပေါ်တွင်ဒေတာဖတ်ရှုခြင်းအတွက် batch function ကိုဖန်တီးရန်ဖြစ်သည်။ စွမ်းဆောင်ရည်အရ စာဖတ်ခြင်းနှင့် စာရေးခြင်းအပိုင်းအတွက် DCs များကြားတွင် ချိတ်ဆက်မှုအချို့ ဆုံးရှုံးသွားသဖြင့်၊ တစ်ခုနှင့်တစ်ခု လုံးဝကွဲလွဲနေသော အစုအဝေးနှစ်ခုနှင့် အဆုံးသတ်သွားနိုင်သည့် အန္တရာယ်ကြောင့် ဤနေရာတွင် ကျွန်ုပ်တို့ ရပ်တန့်သွားခဲ့ပါသည်။
ထို့ကြောင့် ယခုပင် EACH_QUORUM ရေးသားခြင်းအတွက် ညီညွတ်မှုအဆင့်တွင် ရပ်တန့်ခဲ့သည် - LOCAL_QUORUM
ထင်မြင်ချက်များနှင့် ကောက်ချက်အတိုချုံး
လုပ်ငန်းလည်ပတ်မှုဆိုင်ရာ ပံ့ပိုးကူညီမှုနှင့် ရှေ့ဆက်ဖွံ့ဖြိုးတိုးတက်မှုအတွက် အလားအလာများ ရှုထောင့်မှ ထွက်ပေါ်လာသော အဖြေကို အကဲဖြတ်ရန်အတွက်၊ ဤကဲ့သို့သော ဖွံ့ဖြိုးတိုးတက်မှုကို အခြားမည်သည့်နေရာတွင် အသုံးချနိုင်သည်ကို စဉ်းစားရန် ဆုံးဖြတ်ခဲ့သည်။
bat ကိုပိတ်ပါ၊ ထို့နောက် "အဆင်ပြေသောအခါတွင် ပေးချေပါ" ကဲ့သို့သော ပရိုဂရမ်များအတွက် ဒေတာအမှတ်ပေးခြင်း (အချက်အလက်များကို C* သို့ ကျွန်ုပ်တို့ တင်သည်၊ Spark scripts များကို အသုံးပြု၍ တွက်ချက်ခြင်း)၊ ဧရိယာအလိုက် အရေးဆိုမှုများကို စုစည်းခြင်း၊ အခန်းကဏ္ဍများ သိမ်းဆည်းခြင်းနှင့် အခန်းကဏ္ဍအပေါ် အခြေခံ၍ အသုံးပြုသူဝင်ရောက်ခွင့်ကို တွက်ချက်ခြင်း မက်ထရစ်။
မင်းမြင်တဲ့အတိုင်းပဲ repertoire က ကျယ်ပြန့်ပြီး ကွဲပြားတယ်။ အကယ်၍ ကျွန်ုပ်တို့သည် NoSQL ၏ထောက်ခံသူများ/ဆန့်ကျင်သူများ၏စခန်းကိုရွေးချယ်ပါက၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏အားသာချက်များနှင့် ကျွန်ုပ်တို့မျှော်လင့်ထားသည့်နေရာအတိအကျဖြစ်သောကြောင့် ထောက်ခံသူများနှင့်ပူးပေါင်းမည်ဖြစ်သည်။
သေတ္တာထဲက Cassandra ရွေးချယ်မှုပင်လျှင် အလျားလိုက် အတိုင်းအတာကို အချိန်နှင့်တပြေးညီ ခွင့်ပြုနိုင်ပြီး စနစ်အတွင်း ဒေတာတိုးလာမှုပြဿနာကို နာကျင်မှုမရှိဘဲ လုံးဝဖြေရှင်းနိုင်သည်။ ခေါ်ဆိုမှုပေါင်းစည်းမှုများကို သီးခြားဆားကစ်တစ်ခုသို့ တွက်ချက်ခြင်းအတွက် အလွန်မြင့်မားသောဝန်ယန္တရားကို ရွှေ့နိုင်ခဲ့ပြီး ဒေတာဘေ့စ်အတွင်း စိတ်ကြိုက်အလုပ်များနှင့် အရာဝတ္ထုများကို ရေးသားခြင်း၏ ဆိုးရွားသောအလေ့အကျင့်ကို ဖယ်ရှားကာ application schema နှင့် logic တို့ကိုလည်း ခွဲခြားနိုင်ခဲ့သည်။ ကျွန်ုပ်တို့သည် ရွေးချယ်ရန်နှင့် ပြင်ဆင်သတ်မှတ်ရန်၊ အရှိန်မြှင့်ရန်၊ မည်သည့် DCs များကို ကျွန်ုပ်တို့ တွက်ချက်လုပ်ဆောင်မည်ဖြစ်ပြီး မည်သည့်ဒေတာကို ကျွန်ုပ်တို့ မှတ်တမ်းတင်မည်၊ ကျွန်ုပ်တို့သည် တစ်ဦးချင်း node များနှင့် DC တစ်ခုလုံး၏ ပျက်ကျခြင်းမှ မိမိကိုယ်ကို အာမခံထားပါသည်။
ကျွန်ုပ်တို့၏ဗိသုကာပညာကို ပရောဂျက်အသစ်များတွင် အသုံးချကာ အတွေ့အကြုံအချို့ရှိထားပြီး၊ ကျွန်ုပ်သည် အထက်တွင်ဖော်ပြထားသော ကွဲပြားမှုများကို ချက်ချင်းထည့်သွင်းစဉ်းစားကာ အမှားအချို့ကို ကာကွယ်ကာ အစပိုင်းတွင် ရှောင်လွှဲ၍မရသော ချွန်ထက်သောထောင့်အချို့ကို ဖယ်ရှားပစ်လိုပါသည်။
ဥပမာအားဖြင့်, Cassandra ၏အပ်ဒိတ်များကို အချိန်နှင့်တစ်ပြေးညီ ခြေရာခံပါ။ဘာကြောင့်လဲ ဆိုတော့ ကျွန်တော်တို့ ရလာတဲ့ ပြဿနာတွေ တော်တော်များများကို သိပြီး ပြေလည်သွားပါပြီ။
ဒေတာဘေ့စ်ကိုယ်တိုင်နှင့် Spark နှစ်ခုလုံးကို တူညီသော node များပေါ်တွင် မတင်ပါနှင့် Spark သည် မျှော်လင့်ထားသည်ထက်ပို၍ OP ကိုစားနိုင်သောကြောင့် (သို့မဟုတ်ခွင့်ပြုနိုင်သောအရင်းအမြစ်အသုံးပြုမှုပမာဏဖြင့် တင်းကြပ်စွာပိုင်းခြားခြင်း)၊ အဘယ်ကြောင့်ဆိုသော် Spark သည် မျှော်လင့်ထားသည်ထက်ပိုမိုစားသုံးနိုင်ပြီး ကျွန်ုပ်တို့၏စာရင်းမှ ပြဿနာနံပါတ် 1 ကို အမြန်ရနိုင်မည်ဖြစ်သည်။
ပရောဂျက်စမ်းသပ်ခြင်းအဆင့်တွင် စောင့်ကြည့်ခြင်းနှင့် လုပ်ငန်းဆောင်ရွက်မှုစွမ်းရည်ကို မြှင့်တင်ပါ။ ကနဦးတွင်၊ ကျွန်ုပ်တို့၏ဖြေရှင်းချက်၏ ဖြစ်နိုင်ချေရှိသော သုံးစွဲသူအားလုံးကို တတ်နိုင်သမျှ ထည့်သွင်းစဉ်းစားပါ။အဘယ်ကြောင့်ဆိုသော်၎င်းသည် ဒေတာဘေ့စ်ဖွဲ့စည်းပုံအပေါ်တွင် နောက်ဆုံးတွင်မူတည်နေသောကြောင့်ဖြစ်သည်။
ဖြစ်နိုင်ချေ အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ရန်အတွက် ထွက်ပေါ်လာသော circuit ကို အကြိမ်များစွာ လှည့်ပါ။ ဘယ်အကွက်တွေကို အမှတ်အသားပြုနိုင်တယ်ဆိုတာကို ရွေးပါ။ အမှန်ကန်ဆုံးနှင့် အကောင်းဆုံး ထည့်သွင်းစဉ်းစားနိုင်ရန် နောက်ထပ်ဇယားများကို ကျွန်ုပ်တို့ပြုလုပ်သင့်သည်များကို နားလည်ပြီး တောင်းဆိုမှုအရ လိုအပ်သောအချက်အလက်များကို ပေးဆောင်ပါ (ဥပမာ၊ ကျွန်ုပ်တို့သည် တူညီသောဒေတာကို မတူညီသောဇယားများတွင် သိမ်းဆည်းနိုင်သည်ဟု ယူဆခြင်းဖြင့် မတူညီသောကွဲကွဲမှုများကို ထည့်သွင်းစဉ်းစားခြင်းဖြင့်၊ ကွဲပြားခြားနားသောစံနှုန်းများ၊ ကျွန်ုပ်တို့သည်ဖတ်ရှုရန်တောင်းဆိုမှုများအတွက် CPU အချိန်ကိုသိသိသာသာချွေတာနိုင်သည်။)
မဆိုး TTL ကိုပူးတွဲပြီး ခေတ်မမီတော့သောဒေတာကို သန့်ရှင်းရေးလုပ်ရန်အတွက် ချက်ချင်းဆောင်ရွက်ပေးပါ။
Cassandra မှဒေတာကိုဒေါင်းလုဒ်လုပ်သောအခါ အပလီကေးရှင်းလော့ဂျစ်သည် FETCH နိယာမတွင် အလုပ်လုပ်သင့်သည်၊ ထို့ကြောင့် အတန်းအားလုံးကို မန်မိုရီထဲသို့ တစ်ကြိမ်တည်းမတင်ဘဲ အတွဲလိုက်ဖြင့် ရွေးချယ်ထားသည်။
ဖော်ပြထားသော ဖြေရှင်းချက်သို့ ပရောဂျက်ကို မလွှဲပြောင်းမီ အကြံပြုလိုပါသည်။ ပျက်စီးမှုစမ်းသပ်မှုများ ဆက်တိုက်ပြုလုပ်ခြင်းဖြင့် စနစ်၏ ချို့ယွင်းမှု သည်းခံနိုင်မှုကို စစ်ဆေးပါ။ဒေတာစင်တာတစ်ခုရှိ ဒေတာဆုံးရှုံးမှု၊ သတ်မှတ်ကာလတစ်ခုအတွင်း ပျက်စီးနေသောဒေတာကို ပြန်လည်ရယူခြင်း၊ ဒေတာစင်တာများကြားတွင် ကွန်ရက်ပြတ်တောက်ခြင်းကဲ့သို့သော၊ ထိုသို့သောစမ်းသပ်မှုများသည် အဆိုပြုထားသောဗိသုကာ၏ ကောင်းကျိုးဆိုးကျိုးများကို အကဲဖြတ်နိုင်ရုံသာမက ၎င်းတို့ကိုလုပ်ဆောင်နေသော အင်ဂျင်နီယာများအတွက် ကောင်းမွန်သောနွေးထွေးမှုအလေ့အကျင့်ကိုလည်း ပေးစွမ်းမည်ဖြစ်ပြီး၊ စနစ်ကျရှုံးမှုကို ပြန်လည်ထုတ်လုပ်ပါက ရရှိထားသောကျွမ်းကျင်မှုမှာ မလိုအပ်ဘဲ ဝေးကွာမည်ဖြစ်သည်။
အကယ်၍ ကျွန်ုပ်တို့သည် အရေးကြီးသောအချက်အလက် (ဥပမာ ငွေတောင်းခံခြင်းအတွက် ဒေတာ၊ စာရင်းသွင်းသူကြွေးမြီတွက်ချက်ခြင်း) နှင့် လုပ်ဆောင်ပါက DBMS ၏အင်္ဂါရပ်များကြောင့် ဖြစ်ပေါ်လာနိုင်သည့် အန္တရာယ်များကို လျှော့ချပေးမည့် ကိရိယာများကိုလည်း အာရုံစိုက်သင့်သည်။ ဥပမာအားဖြင့်၊ ၎င်း၏အသုံးပြုမှုအတွက် အကောင်းမွန်ဆုံးသောဗျူဟာကို တီထွင်ပြီး nodesync utility (Dataastax) ကို အသုံးပြုပါ။ ညီညွတ်မှုအတွက်၊ Cassandra အပေါ် အလွန်အကျွံ ဝန်မဖန်တီးပါနှင့် ၎င်းကို အချိန်ကာလတစ်ခုအတွင်း အချို့ဇယားများအတွက်သာ အသုံးပြုပါ။
အသက်ခြောက်လကြာပြီးနောက် Cassandra ဘာဖြစ်သွားမလဲ။ ယေဘုယျအားဖြင့် မဖြေရှင်းနိုင်သော ပြဿနာများ မရှိပါ။ ပြင်းထန်သော မတော်တဆမှု သို့မဟုတ် ဒေတာ ဆုံးရှုံးခြင်းကိုလည်း ကျွန်ုပ်တို့ ခွင့်မပြုပါ။ ဟုတ်တယ်၊ အရင်က မပေါ်ပေါက်ခဲ့တဲ့ ပြဿနာတချို့အတွက် လျော်ကြေးပေးဖို့ စဉ်းစားခဲ့ရပေမယ့် အဆုံးမှာတော့ ဒါက ကျွန်တော်တို့ရဲ့ ဗိသုကာဆိုင်ရာ ဖြေရှင်းချက်တွေကို ကြီးကြီးမားမား တိမ်မြုပ်မသွားပါဘူး။ အသစ်အဆန်းတွေကို စမ်းကြည့်ဖို့ မကြောက်ချင်ဘူးဆိုရင် အရမ်းစိတ်ပျက်မနေချင်ဘူးဆိုရင်တော့ ဘယ်အရာကမှ အလကားမဟုတ်ဘူးဆိုတဲ့အချက်အတွက် ပြင်ဆင်လိုက်ပါ။ သင်နားလည်သဘောပေါက်ပြီး စာရွက်စာတမ်းများကို စေ့စေ့စပ်စပ်လေ့လာပြီး သင့်ကိုယ်ပိုင်လူယုတ်မာတစ်ဦးချင်းစီကို အမွေအနှစ်ဖြေရှင်းချက်ဟောင်းတွင်ထက်ပို၍စုစည်းထားရမည်ဖြစ်ပြီး မည်သည့်သီအိုရီက သင့်အားစောင့်ဆိုင်းနေမည်ကို ကြိုတင်ပြောပြမည်မဟုတ်ပါ။
source: www.habr.com