Cassandra Oracle သာသိရင် မသေရဘူး။

ဟေး ဟာဘ

ကျွန်တော့်နာမည် Misha Butrimov ပါ၊ Cassandra အကြောင်း နည်းနည်းပြောပြချင်ပါတယ်။ ကျွန်ုပ်၏ဇာတ်လမ်းသည် NoSQL ဒေတာဘေ့စ်များကို တစ်ခါမှမကြုံဖူးသူများအတွက် အသုံးဝင်လိမ့်မည် - ၎င်းတွင် သင်သိထားရမည့် အကောင်အထည်ဖော်မှုအင်္ဂါရပ်များနှင့် ချို့ယွင်းချက်များများစွာရှိသည်။ Oracle သို့မဟုတ် အခြားဆက်စပ်ဒေတာဘေ့စ်မှလွဲ၍ အခြားမည်သည့်အရာကိုမျှ မမြင်ရသေးပါက၊ ဤအရာများသည် သင့်အသက်ကို ကယ်တင်မည်ဖြစ်သည်။

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

သူမ ဘာပညာရှိလဲ၊ တောင်းဆိုမှု အများအပြားကို ကိုင်တွယ်ခြင်း နှင့် ပတ်သက်သည် ။ ဒါပေမယ့် ဘယ်လောက်များလဲ? 10, 20, 30, 40 တောင်းဆိုမှုတစ်စက္ကန့်ကိုအများကြီးမဟုတ်ပါဘူး။ မှတ်တမ်းတင်ရန်အတွက် တစ်စက္ကန့်လျှင် တောင်းဆိုချက် ၁၀၀,ဝဝဝ၊ တစ်စက္ကန့်လျှင် တောင်းဆိုချက်ပေါင်း ၂ သန်းကို သိမ်းဆည်းထားသည်ဟု ပြောသောကုမ္ပဏီများ ရှိပါသည်။ သူတို့ ယုံရမှာပေါ့။

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

ပုံသဏ္ဍာန်တူသော အရာတိုင်းသည် တူညီသည်မဟုတ်။

လုပ်ဖော်ကိုင်ဖက်တစ်ဦးသည် ကျွန်ုပ်ထံသို့ ရောက်ရှိလာပြီး “ဤသည်မှာ CQL Cassandra query language ဖြစ်ပြီး၊ ၎င်းတွင် ရွေးချယ်ထားသော ထုတ်ပြန်ချက်တစ်ခု ပါရှိသည်၊ ၎င်းတွင် နေရာ၊ ၎င်းတွင် ရှိသည်။ စာတွေရေးလို့ အဆင်မပြေဘူး။ အဘယ်ကြောင့်?"။ Cassandra ကို ဆက်စပ်ဒေတာဘေ့စ်တစ်ခုလို ဆက်ဆံခြင်းသည် ရက်စက်စွာသတ်သေရန် အကောင်းဆုံးနည်းလမ်းဖြစ်သည်။ ပြီးတော့ ကျွန်တော်က အဲဒါကို မကြော်ငြာဘူး၊ ရုရှားမှာ တားမြစ်ထားတယ်။ မင်း ဒီဇိုင်း တစ်ခုခု မှားနေလိမ့်မယ်။

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

အဘယ်ကြောင့်ဆိုသော် Cassandra သည် ပေါင်းစပ်ဒေတာဘေ့စ်ဖြစ်သောကြောင့်၊ ၎င်းသည် သော့တန်ဖိုးကို တစ်ပြိုင်နက်တည်း ထောက်ပံ့ပေးပြီး ကျယ်ပြန့်သောကော်လံများတွင် ဒေတာများကို သိမ်းဆည်းထားသည်။ Java သို့မဟုတ် Kotlin တွင်၎င်းကိုဤကဲ့သို့ဖော်ပြနိုင်သည်။

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

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

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

Partition key လို့ ခေါ်တဲ့ hash function ကိုသုံးပြီး ဒီနံပါတ်ကို ယူပါတယ်။ ၎င်းသည် Primary key ညွှန်ကြားချက်တွင် သတ်မှတ်ထားသည့် ကော်လံဖြစ်ပြီး၊ ၎င်းသည် မြေပုံ၏ ပထမဆုံးနှင့် အခြေခံအကျဆုံးသော့ဖြစ်မည့် ကော်လံဖြစ်သည်။ ၎င်းသည် မည်သည့် node မှ မည်သည့်ဒေတာကို လက်ခံမည်ကို ဆုံးဖြတ်သည်။ SQL တွင်ကဲ့သို့တူညီသော syntax နီးပါးဖြင့် Cassandra တွင်ဇယားတစ်ခုကိုဖန်တီးသည်-

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

ဤကိစ္စတွင် Primary key သည် ကော်လံတစ်ခုပါဝင်ပြီး ၎င်းသည် partitioning key လည်းဖြစ်သည်။

ကျွန်ုပ်တို့၏အသုံးပြုသူများသည် မည်သို့လုပ်ဆောင်မည်နည်း။ အချို့က node တစ်ခုသို့၊ အချို့မှ အခြားတစ်ခုသို့သွားမည်ဖြစ်ပြီး အချို့မှာ တတိယတစ်ခုသို့သွားမည်ဖြစ်သည်။ ရလဒ်မှာ Python တွင် အဘိဓာန်အဖြစ် လူသိများသော မြေပုံတစ်ခုဟုလည်း လူသိများသော သာမန် hash table တစ်ခု သို့မဟုတ် တန်ဖိုးများအားလုံးကို ဖတ်နိုင်၊ သော့ဖြင့် ရေးနိုင်၊ ရိုးရှင်းသော Key တန်ဖိုး တည်ဆောက်မှုဖြစ်သည်။

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

ရွေးချယ်ထားသော ထုတ်ပြန်ချက်အချို့ကို ရေးသားကြပါစို့။ select * from users where, userid = . ၎င်းသည် Oracle တွင်ကဲ့သို့ဖြစ်သည်- ကျွန်ုပ်တို့သည် ရွေးချယ်ရန်၊ အခြေအနေများကို သတ်မှတ်ပေးပြီး အရာအားလုံး အဆင်ပြေစေကာ အသုံးပြုသူများသည် ၎င်းကို ရရှိသည်။ သို့သော် ဥပမာအားဖြင့်၊ မွေးဖွားသည့်နှစ်ရှိသော သုံးစွဲသူကို သင်ရွေးချယ်ပါက၊ Cassandra သည် တောင်းဆိုချက်ကို မဖြည့်ဆည်းပေးနိုင်ကြောင်း တိုင်ကြားထားသည်။ မွေးနှစ်နှင့်ပတ်သက်သည့် ဒေတာဖြန့်ဝေပုံနှင့်ပတ်သက်၍ သူမ လုံးဝမသိသောကြောင့်ဖြစ်သည် - သူ့တွင် သော့ညွှန်ထားသည့် ကော်လံတစ်ခုသာရှိသည်။ ထို့နောက်သူမက “ကောင်းပြီ၊ ငါ ဒီတောင်းဆိုချက်ကို ဖြည့်ဆည်းပေးနိုင်သေးတယ်။ ခွင့်ပြုရန် စစ်ထုတ်ခြင်းကို ထည့်ပါ။" ညွှန်ကြားချက်ကို ပေါင်းထည့်လိုက်တာနဲ့ အားလုံး အဆင်ပြေပါတယ်။ ပြီးတော့ ဒီအချိန်မှာ ကြောက်စရာကောင်းတဲ့ တစ်ခုခု ဖြစ်သွားတယ်။

ကျွန်ုပ်တို့သည် စမ်းသပ်ဒေတာကို အသုံးပြုသောအခါ၊ အားလုံးအဆင်ပြေပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် မှတ်တမ်းပေါင်း 4 သန်းရှိသည့် ထုတ်လုပ်မှုတွင် စုံစမ်းမေးမြန်းမှုကို သင်လုပ်ဆောင်သောအခါ၊ အရာအားလုံးသည် ကျွန်ုပ်တို့အတွက် အလွန်ကောင်းမွန်မည်မဟုတ်ပေ။ အဘယ်ကြောင့်ဆိုသော် ခွင့်ပြုစစ်ထုတ်ခြင်းသည် Cassandra သည် ဤဇယားမှ node များအားလုံး၊ ဒေတာစင်တာများအားလုံး (ဤအစုအဝေးတွင် များစွာရှိနေပါက) မှဒေတာအားလုံးကို စုဆောင်းရန် Cassandra အား ခွင့်ပြုပေးသော ညွှန်ကြားချက်ဖြစ်သောကြောင့် ၎င်းကို စစ်ထုတ်ခြင်းဖြစ်သည်။ ၎င်းသည် Full Scan ၏ analogue ဖြစ်ပြီး မည်သူမျှ ၎င်းကို နှစ်သက်ခြင်းမရှိပါ။

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

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

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

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

Primary key ညွှန်ကြားချက်ကို ဂရုပြုပါ၊ ၎င်း၏ပထမအငြင်းအခုံ (ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ နှစ်) သည် အမြဲတမ်း Partition key ဖြစ်သည်။ ၎င်းတွင် ကော်လံတစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ကော်လံများ ပါဝင်နိုင်သည်၊ အရေးမကြီးပါ။ ကော်လံအများအပြားရှိနေပါက၊ ၎င်းကို ဘာသာစကားကြိုတင်ပရိုဆက်ဆာက ၎င်းသည် Primary key ဖြစ်ကြောင်း နားလည်နိုင်စေရန်နှင့် ၎င်းနောက်တွင် အခြားကော်လံများအားလုံးသည် Clustering key ဖြစ်သည် ။ ဤကိစ္စတွင်၊ ၎င်းတို့ကို ပေါ်လာသည့်အစီအစဥ်အတိုင်း နှိုင်းယှဉ်မှုတွင် ထုတ်လွှင့်မည်ဖြစ်သည်။ ဆိုလိုသည်မှာ ပထမကော်လံသည် ပိုသိသာသည်၊ ဒုတိယကော်လံသည် သိသာမှုနည်းသည် စသည်တို့ဖြစ်သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့ရေးသားပုံသည် ဒေတာအတန်းများအတွက် အကွက်များကို ညီမျှသည်- ကျွန်ုပ်တို့သည် ကွက်လပ်များကို စာရင်းပြုစုပြီး ၎င်းတို့အတွက် မည်သည့်အရာများ ပိုကြီးပြီး အသေးမည်သည်ကို ရေးပါသည်။ Cassandra တွင်၊ ဤအရာများသည် အတိအကျပြောရလျှင် ၎င်းအတွက် ရေးထားသော ညီမျှခြင်းများကို အသုံးချမည့် data class ၏ နယ်ပယ်များဖြစ်သည်။

ခွဲခြားသတ်မှတ်ပြီး ကန့်သတ်ချက်များ ချမှတ်ထားသည်။

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

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

ငါတို့အလုပ်က ပြန်ပေါ်လာတယ်။ where, andသုံးစွဲသူများရရှိပြီး အားလုံးအဆင်ပြေသွားပါသည်။ သို့သော် အကယ်၍ ကျွန်ုပ်တို့သည် Clustering key ၏ အစိတ်အပိုင်းတစ်ခုမျှသာဖြစ်ပြီး သိသာထင်ရှားသည့်အပိုင်းကိုသာအသုံးပြုရန်ကြိုးစားပါက၊ ထို့နောက်တွင် Cassandra သည် null comparator အတွက် ဤအကွက်များပါရှိသော ဤအရာဝတ္တု၏နေရာအား ကျွန်ုပ်တို့၏မြေပုံတွင် ရှာမတွေ့နိုင်ကြောင်း ချက်ချင်းတိုင်ကြားပါမည်။ သူ လိမ်တဲ့ နေရာ မှာ ပဲ သတ်မှတ် ထား တယ် ။ ဤ node မှဒေတာအားလုံးကို ထပ်မံထုတ်ယူပြီး ၎င်းကို စစ်ထုတ်ရပါမည်။ ၎င်းသည် node တစ်ခုအတွင်း Full Scan ၏ analogue တစ်ခုဖြစ်ပြီး၊ ၎င်းသည်မကောင်းပါ။

မရှင်းလင်းသောအခြေအနေတွင် ဇယားအသစ်တစ်ခုဖန်တီးပါ။

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

ကျွန်ုပ်တို့သည် မလိုအပ်သော နေရာလပ်များကို ရောင်းဝယ်ဖောက်ကားပြီး ကောင်းစွာ အတိုင်းအတာနှင့် စိတ်ချယုံကြည်စွာ လည်ပတ်နိုင်စေရန်အတွက် ပုံမှန်မဟုတ်သော အချက်အလက်များကို ရောင်းဝယ်ဖောက်ကားပါသည်။ အမှန်တော့၊ ဒေတာစင်တာ သုံးခုပါ၀င်သော အစုအဝေးတစ်ခုစီတွင် ဒေတာထိန်းသိမ်းမှုအဆင့် (ဘာမှပျောက်ပျက်သွားသောအခါ) လက်ခံနိုင်သော node ငါးခုပါရှိသော ဒေတာစင်တာတစ်ခုသည် ဒေတာစင်တာတစ်ခု၏သေဆုံးမှုကို လုံးဝရှင်သန်နိုင်မည်ဖြစ်သည်။ ကျန်နှစ်ခု၏ တစ်ခုစီတွင် နောက်ထပ် node နှစ်ခု။ ပြီးမှသာ ပြဿနာများ စတင်မည်။ ဤအရာသည် အလွန်ကောင်းမွန်သော ထပ်လောင်းမှုတစ်ခုဖြစ်ပြီး၊ ၎င်းသည် အပို SSD ဒရိုက်များနှင့် ပရိုဆက်ဆာအချို့ကို တန်ဖိုးရှိစေပါသည်။ ထို့ကြောင့်၊ ဘယ်တော့မှ SQL မဟုတ်သည့် Cassandra ကိုအသုံးပြုရန်အတွက်၊ ဆက်ဆံရေးမရှိသောပြည်ပသော့များကိုအသုံးပြုရန်အတွက်ရိုးရှင်းသောစည်းမျဉ်းများကိုသိရန်လိုအပ်သည်။

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

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

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

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

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

source: www.habr.com