NoSQL အတွက် ဒေတာမော်ဒယ်ကို ဒီဇိုင်းဆွဲခြင်း၏ အင်္ဂါရပ်များ

နိဒါန်း

” အရပ်ထဲမှာနေဖို့ ပြေးနိုင်သမျှ မြန်မြန်ပြေးရမယ်၊
တစ်နေရာရာကိုရောက်ဖို့ မင်း အနည်းဆုံး နှစ်ဆလောက် မြန်မြန်ပြေးရမယ်။"
(ဂ) Alice in Wonderland

ဟိုးအရင်တုန်းက ဟောပြောပွဲတစ်ခုလုပ်ဖို့ တောင်းဆိုတယ်။ အကဲခတ် ကျွန်ုပ်တို့၏ ကုမ္ပဏီသည် ပရောဂျက်များကို အချိန်အကြာကြီး (တစ်ခါတစ်ရံ နှစ်ပေါင်းများစွာ) ထိုင်နေသောကြောင့် အိုင်တီနည်းပညာလောကတွင် ကျွန်ုပ်တို့ပတ်ဝန်းကျင်တွင် ဖြစ်ပျက်နေသည့်အရာများကို မျက်ခြည်ပြတ်သွားသောကြောင့် ကျွန်ုပ်တို့၏ကုမ္ပဏီသည် ဒေတာမော်ဒယ်များကို ဒီဇိုင်းရေးဆွဲခြင်း၏ ခေါင်းစဉ်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ကုမ္ပဏီတွင် (ဤမျှသာဖြစ်ပေသည်) ပရောဂျက်များစွာသည် NoSQL databases (အနည်းဆုံး ယခုလက်ရှိတွင်) မသုံးကြသောကြောင့် ကျွန်ုပ်၏ဟောပြောပွဲ၌ HBase ၏နမူနာကိုအသုံးပြု၍ ၎င်းတို့အား သီးခြားအာရုံစိုက်ခဲ့ပြီး ၎င်းတို့အား အကြောင်းအရာတင်ပြမှုကို ဦးတည်ရန်ကြိုးစားခဲ့သည်။ မသုံးဖူးတဲ့ သူတွေလည်း အလုပ်လုပ်တယ်။ အထူးသဖြင့်၊ ကျွန်ုပ်သည် လွန်ခဲ့သောနှစ်ပေါင်းများစွာက ဖတ်ခဲ့သော ဥပမာကို အသုံးပြု၍ data model design ၏အင်္ဂါရပ်အချို့ကို သရုပ်ဖော်ပါသည်။ Amandeep Khurana ၏ “HB ase Schema Design” ဆောင်းပါးတွင်. ဥပမာများကို ခွဲခြမ်းစိတ်ဖြာသောအခါတွင်၊ အဓိက အယူအဆများကို ပရိသတ်ထံ ပိုမိုကောင်းမွန်စွာ ထုတ်ပြနိုင်ရန် တူညီသောပြဿနာကို ဖြေရှင်းရန်အတွက် ရွေးချယ်စရာများစွာကို နှိုင်းယှဉ်ထားပါသည်။

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

နမူနာခွဲခြမ်းစိတ်ဖြာ

ကျွန်တော့်အမြင်အရ၊ သင် NoSQL databases ကိုစသုံးခင်မှာ သေချာစဉ်းစားပြီး ကောင်းကျိုးဆိုးကျိုးတွေကို ချိန်ဆဖို့ လိုပါတယ်။ မကြာခဏဆိုသလို ပြဿနာကို သမားရိုးကျ ဆက်နွှယ်သော DBMSs များဖြင့် ဖြေရှင်းနိုင်သည် ။ ထို့ကြောင့်၊ ထင်ရှားသောအကြောင်းပြချက်မရှိဘဲ NoSQL ကိုအသုံးမပြုခြင်းသည် ပိုကောင်းသည်။ အကယ်၍ သင်သည် NoSQL ဒေတာဘေ့စ်ကို အသုံးပြုရန် ဆုံးဖြတ်ခဲ့လျှင် ဤနေရာတွင် ဒီဇိုင်းချဉ်းကပ်မှုများသည် အနည်းငယ်ကွဲပြားကြောင်း ထည့်သွင်းစဉ်းစားသင့်သည်။ အထူးသဖြင့် ၎င်းတို့ထဲမှ အချို့သည် ယခင်က ဆက်စပ် DBMS များနှင့်သာ ဆက်ဆံဖူးသူများ (ကျွန်ုပ်၏ လေ့လာတွေ့ရှိချက်များအရ) အထူးအဆန်းဖြစ်နိုင်သည်။ ထို့ကြောင့်၊ "ဆက်နွယ်မှု" ကမ္ဘာတွင်၊ ကျွန်ုပ်တို့သည် များသောအားဖြင့် ပြဿနာဒိုမိန်းကို စံနမူနာပြုခြင်းဖြင့် စတင်ကြပြီး လိုအပ်ပါက မော်ဒယ်ကို ပုံမှန်မဟုတ်အောင် ပြုလုပ်ပါ။ NoSQL မှာ ကျွန်တော်တို ဒေတာနှင့် လုပ်ဆောင်ရန်အတွက် မျှော်လင့်ထားသည့် အခြေအနေများကို ချက်ချင်း ထည့်သွင်းစဉ်းစားသင့်သည်။ နှင့် ကနဦးတွင် ဒေတာကို ပုံပျက်စေသည်။ ထို့အပြင် အောက်တွင် ဆွေးနွေးမည့် အခြားသော ကွဲပြားမှုများလည်း ရှိသေးသည်။

ကျွန်ုပ်တို့ ဆက်လက်လုပ်ဆောင်မည့် အောက်ပါ "ဓာတု" ပြဿနာကို သုံးသပ်ကြည့်ကြပါစို့။

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

• အသုံးပြုသူ A သည် အသုံးပြုသူ B ကိုဖတ်ခြင်းရှိမရှိ မေးခွန်းကို ဖြေပါ
• အသုံးပြုသူ B ထံမှ စာရင်းသွင်းခြင်း/စာရင်းသွင်းခြင်းမှ ရပ်ဆိုင်းခြင်းအတွက် ချိတ်ဆက်မှုများကို ပေါင်းထည့်ခြင်း/ဖယ်ရှားခြင်းအား ခွင့်ပြုပါ။

ဟုတ်ပါတယ်၊ ပြဿနာကိုဖြေရှင်းဖို့ရွေးချယ်စရာတွေအများကြီးရှိပါတယ်။ ပုံမှန်ဆက်စပ်ဒေတာဘေ့စ်တစ်ခုတွင်၊ ကျွန်ုပ်တို့သည် ဆက်ဆံရေးဇယားတစ်ခုကို ရိုးရိုးရှင်းရှင်းပြုလုပ်နိုင်သည် (ဥပမာ၊ ကျွန်ုပ်တို့သည် အသုံးပြုသူအုပ်စုကို သိမ်းဆည်းရန် လိုအပ်ပါက၊ ဤ “သူငယ်ချင်း” အပါအဝင်) နှင့် ပိုကောင်းအောင်ပြုလုပ်ရန် ဖြစ်နိုင်ခြေရှိသည် access speed သည် indexes/partitioning ကို ပေါင်းထည့်မည်ဖြစ်သည်။ နောက်ဆုံးဇယားသည် ဤကဲ့သို့သောပုံပေါ်နိုင်သည်-

သုံးစွဲသူအိုင်ဒီ
friend_id

Vasya
Petya

Vasya
Olya

ယင်းနောက် ရှင်းလင်းပြတ်သားစွာ နားလည်နိုင်စေရန်အတွက် ID များအစား အမည်များကို ဖော်ပြပါမည်။

HBase ကိစ္စတွင်၊ ကျွန်ုပ်တို့သိသည်မှာ-

• ဇယားအပြည့်စကင်န်မရလဒ် ထိရောက်သောရှာဖွေမှုသည် ဖြစ်နိုင်သည်။ သော့ဖြင့်သီးသန့်
  • တကယ်တော့၊ ဒါကြောင့် SQL queries တော်တော်များများနဲ့ အကျွမ်းတဝင်ရှိတဲ့ SQL queries တွေကိုရေးတာဟာ မကောင်းတဲ့အကြံပါ။ နည်းပညာပိုင်းအရ၊ သင်သည် Joins နှင့် အခြားသော ယုတ္တိဗေဒဖြင့် SQL query ကို တူညီသော Impala မှ HBase သို့ ပေးပို့နိုင်သော်လည်း ၎င်းသည် မည်မျှထိရောက်မည်နည်း...

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

RowKey
အသံချဲ့စက်

Vasya
1: Petya
2: Olya
3: Dasha

Petya
1: Masha
2: Vasya

ဤတွင်၊ လိုင်းတစ်ခုစီသည် ကွန်ရက်အသုံးပြုသူတစ်ဦးနှင့် သက်ဆိုင်သည်။ ကော်လံများတွင် အမည်များ- 1၊ 2၊ ... - သူငယ်ချင်းအရေအတွက်အရ၊ သူငယ်ချင်း ID များကို ကော်လံများတွင် သိမ်းဆည်းထားသည်။ အတန်းတစ်ခုစီတွင် ကော်လံအရေအတွက် မတူညီကြောင်း သတိပြုရန် အရေးကြီးသည်။ အထက်ပုံပါ ဥပမာတွင်၊ အတန်းတစ်ခုတွင် ကော်လံသုံးခု (1၊ 2 နှင့် 3) ရှိပြီး ဒုတိယတစ်ခုတွင် နှစ်ခု (1 နှင့် 2) သာရှိသည် - ဤနေရာတွင် ကျွန်ုပ်တို့သည် ဆက်စပ်ဒေတာဘေ့စ်များတွင် မရှိသော HBase ဂုဏ်သတ္တိနှစ်ခုကို အသုံးပြုခဲ့သည်-

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

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

• အချက်အလက်ဖတ်ခြင်း။: Vasya သည် Olya သို့ စာရင်းသွင်းထားခြင်း ရှိ၊ မရှိ နားလည်ရန်အတွက် ကျွန်ုပ်တို့ နုတ်ထွက်ရန် လိုအပ်ပါသည်။ လိုင်းတစ်ခုလုံး RowKey = “Vasya” သော့ဖြင့် ကော်လံတန်ဖိုးများကို စီတန်းပြီး ၎င်းတို့တွင် Olya ကို “တွေ့ဆုံ” သည်အထိ စီစစ်ပါ။ သို့မဟုတ် ကော်လံအားလုံး၏တန်ဖိုးများကို "မတွေ့ဆုံပါ" Olya နှင့် ပြန်၍ False ပြန်ပေးပါ။
• ဒေတာကိုတည်းဖြတ်ခြင်း- သူငယ်ချင်းတစ်ဦးကို ထည့်ခြင်း။: အလားတူအလုပ်တစ်ခုအတွက် ကျွန်ုပ်တို့လည်း နုတ်ရန် လိုအပ်ပါသည်။ လိုင်းတစ်ခုလုံး သော့ RowKey = “Vasya” ကို အသုံးပြု၍ သူ၏ သူငယ်ချင်း စုစုပေါင်း အရေအတွက်ကို တွက်ချက်ပါ။ သူငယ်ချင်းအသစ်၏ ID ကို ရေးမှတ်ရန် လိုအပ်သော ကော်လံအရေအတွက်ကို ဆုံးဖြတ်ရန် ဤစုစုပေါင်း သူငယ်ချင်းအရေအတွက် လိုအပ်ပါသည်။
• ဒေတာပြောင်းလဲခြင်း- သူငယ်ချင်းတစ်ဦးကို ဖျက်ခြင်း။:
  • နုတ်ဖို့ လိုတယ်။ လိုင်းတစ်ခုလုံး RowKey = “Vasya” သော့ဖြင့် ဖျက်ပစ်မည့် သူငယ်ချင်းကို မှတ်တမ်းတင်ထားသည်ကို ရှာတွေ့ရန်အတွက် ကော်လံများကို စီပါ။
  • ထို့နောက်၊ သူငယ်ချင်းတစ်ဦးကို ဖျက်ပြီးနောက်၊ ၎င်းတို့၏ နံပါတ်စဉ်တွင် “ကွာဟချက်” မရရှိစေရန် ဒေတာအားလုံးကို ကော်လံတစ်ခုထဲသို့ “ပြောင်း” ရန် လိုအပ်သည်။

“အခြေအနေအလိုက် အသုံးချပလီကေးရှင်း” ဘက်တွင် ကျွန်ုပ်တို့ အကောင်အထည်ဖော်ရန် လိုအပ်သည့် ဤ အယ်လဂိုရီသမ်များ မည်မျှအကျိုးဖြစ်ထွန်းစေမည်ကို ယခု အကဲဖြတ်ကြည့်ကြပါစို့။ အို-သင်္ကေတ. ကျွန်ုပ်တို့၏ အယူအဆဆိုင်ရာ လူမှုကွန်ရက်၏ အရွယ်အစားကို n အဖြစ် ဖေါ်ပြကြပါစို့။ ထို့နောက် သုံးစွဲသူတစ်ဦးရှိနိုင်သည့် အများဆုံးသူငယ်ချင်းအရေအတွက်မှာ (n-1) ဖြစ်သည်။ O-သင်္ကေတများအသုံးပြုမှုဘောင်အတွင်း ၎င်းသည် အရေးမကြီးသောကြောင့် ကျွန်ုပ်တို့၏ရည်ရွယ်ချက်များအတွက် ဤ (-1) ကို ထပ်မံလျစ်လျူရှုနိုင်ပါသည်။

• အချက်အလက်ဖတ်ခြင်း။: စာကြောင်းတစ်ခုလုံးကို နုတ်ပြီး ကန့်သတ်အတွင်းရှိ ၎င်း၏ကော်လံများအားလုံးကို ထပ်လောင်းရန် လိုအပ်သည်။ ဆိုလိုသည်မှာ ကုန်ကျစရိတ်၏ အထက်ခန့်မှန်းချက်မှာ ခန့်မှန်းခြေ O(n) ဖြစ်လိမ့်မည်၊
• ဒေတာကိုတည်းဖြတ်ခြင်း- သူငယ်ချင်းတစ်ဦးကို ထည့်ခြင်း။: သူငယ်ချင်းအရေအတွက်ကို ဆုံးဖြတ်ရန်၊ အတန်း၏ ကော်လံအားလုံးကို ထပ်လောင်းရန် လိုအပ်ပြီး ကော်လံအသစ်တစ်ခု ထပ်ထည့်ပါ => O(n)
• ဒေတာပြောင်းလဲခြင်း- သူငယ်ချင်းတစ်ဦးကို ဖျက်ခြင်း။:
  • ပေါင်းထည့်ခြင်း နှင့် ဆင်တူသည် - ကန့်သတ်ချက်ရှိ ကော်လံများအားလုံးကို ဖြတ်သွားရန်လိုအပ်ပါသည်။ => O(n)
  • ကော်လံများကို ဖယ်ရှားပြီးနောက် ၎င်းတို့ကို “ရွှေ့” ရန် လိုအပ်သည်။ အကယ်၍ သင်သည် ဤ "head-on" ကိုအကောင်အထည်ဖော်ပါက၊ ကန့်သတ်ချက်တွင် သင်သည် (n-1) လုပ်ဆောင်ချက်များအထိ လိုအပ်မည်ဖြစ်သည်။ သို့သော် ဤနေရာတွင်နှင့် လက်တွေ့ကျသောအပိုင်းတွင် ပုံသေလုပ်ဆောင်မှုများစွာအတွက် "pseudo-shift" ကို အကောင်အထည်ဖော်မည့် ကွဲပြားသောချဉ်းကပ်မှုကို ကျွန်ုပ်တို့အသုံးပြုပါမည် - ဆိုလိုသည်မှာ၊ n ကိုမခွဲခြားဘဲ စဉ်ဆက်မပြတ်အချိန်ကို သုံးစွဲမည်ဖြစ်သည်။ ဤကိန်းသေအချိန် (O(2) အတိအကျဖြစ်ရန်) O(n) နှင့် နှိုင်းယှဉ်၍ လစ်လျူရှုထားနိုင်သည်။ ချဉ်းကပ်ပုံကို အောက်ဖော်ပြပါပုံတွင် သရုပ်ဖော်ထားသည်- ကျွန်ုပ်တို့သည် "နောက်ဆုံး" ကော်လံမှ ဒေတာကို ကျွန်ုပ်တို့ ဖျက်လိုသော ဒေတာထံသို့ ကူးယူပြီး နောက်ဆုံးကော်လံကို ဖျက်ပါ-
    

စုစုပေါင်း၊ အခြေအနေအားလုံးတွင် O(n) ၏ asymptotic computational ရှုပ်ထွေးမှုကို ကျွန်ုပ်တို့ ရရှိခဲ့ပါသည်။
ဒေတာဘေ့စ်မှ အတန်းတစ်ခုလုံးကို အမြဲလိုလို ဖတ်နေရပြီး ကော်လံအားလုံးကို ဖြတ်သန်းပြီး သူငယ်ချင်းအရေအတွက်ကို တွက်ချက်ရန် သုံးခုထဲမှ နှစ်ခုတွင် ကော်လံအားလုံးကို ဖြတ်သွားရုံဖြင့် သင်သတိပြုမိပြီးသားဖြစ်သည်။ ထို့ကြောင့်၊ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် ကြိုးပမ်းမှုအနေဖြင့်၊ သင်သည် ကွန်ရက်အသုံးပြုသူတိုင်း၏ သူငယ်ချင်းအရေအတွက် စုစုပေါင်းကို သိမ်းဆည်းထားသည့် “count” ကော်လံကို ထည့်သွင်းနိုင်သည်။ ဤကိစ္စတွင်၊ သူငယ်ချင်းစုစုပေါင်းအရေအတွက်ကို တွက်ချက်ရန် အတန်းတစ်ခုလုံးကို ကျွန်ုပ်တို့ မဖတ်နိုင်သော်လည်း "ရေတွက်ခြင်း" ကော်လံတစ်ခုသာ ဖတ်ပါ။ အဓိကအချက်မှာ ဒေတာကို ကိုင်တွယ်သည့်အခါ “count” ကို အပ်ဒိတ်လုပ်ရန် မမေ့ပါနှင့်။ အဲဒါ။ ကျွန်ုပ်တို့ တိုးတက်လာသည်။ ရွေးချယ်မှု 2 (အရေအတွက်)-

RowKey
အသံချဲ့စက်

Vasya
1: Petya
2: Olya
3: Dasha
အရေအတွက်: 3

Petya
1: Masha
2: Vasya

အရေအတွက်: 2

ပထမရွေးချယ်ခွင့်နှင့် နှိုင်းယှဉ်သည်-

• အချက်အလက်ဖတ်ခြင်း။" Vasya က Olya ကိုဖတ်သလား" ဆိုတဲ့ မေးခွန်းအတွက် အဖြေတစ်ခုရဖို့။ ဘာမှမပြောင်းလဲပါ => O(n)
• ဒေတာကိုတည်းဖြတ်ခြင်း- သူငယ်ချင်းတစ်ဦးကို ထည့်ခြင်း။− ယခု ကျွန်ုပ်တို့သည် စာကြောင်းတစ်ခုလုံးကိုဖတ်ပြီး ၎င်း၏ကော်လံများပေါ်တွင် ထပ်လောင်းရန်မလိုအပ်တော့သောကြောင့်၊ ကျွန်ုပ်တို့သည် သူငယ်ချင်းအသစ်၏ထည့်သွင်းခြင်းကို ရိုးရှင်းစေပါသည်။ သူငယ်ချင်းအသစ်ထည့်ရန် ကော်လံနံပါတ်ကို ချက်ချင်းဆုံးဖြတ်ပါ။ ၎င်းသည် တွက်ချက်မှုဆိုင်ရာ ရှုပ်ထွေးမှုကို O(1) သို့ လျှော့ချပေးသည်။
• ဒေတာပြောင်းလဲခြင်း- သူငယ်ချင်းတစ်ဦးကို ဖျက်ခြင်း။− သူငယ်ချင်းတစ်ဦးကို ဖျက်သည့်အခါ၊ ဒေတာကို ဆဲလ်တစ်ခုအား ဘယ်ဘက်သို့ “ပြောင်းသည်” သောအခါတွင် I/O လုပ်ဆောင်ချက် အရေအတွက်ကို လျှော့ချရန်အတွက်လည်း ဤကော်လံကို အသုံးပြုနိုင်သည်။ ဒါပေမယ့် ဖျက်ပစ်ဖို့ လိုအပ်တာကို ရှာဖို့ ကော်လံတွေကို ထပ်တလဲလဲ လုပ်ဖို့ လိုသေးတာမို့ => O(n)
• တစ်ဖက်တွင်၊ ယခု ဒေတာမွမ်းမံသည့်အခါ ကျွန်ုပ်တို့သည် “ရေတွက်” ကော်လံကို အကြိမ်တိုင်း အပ်ဒိတ်လုပ်ရန် လိုအပ်သော်လည်း၊ O-သင်္ကေတဘောင်ဘောင်အတွင်း လျစ်လျူရှုထားနိုင်သောကြောင့် ၎င်းသည် အချိန်အဆက်မပြတ် လိုအပ်ပါသည်။

ယေဘူယျအားဖြင့်၊ ရွေးချယ်မှု 2 သည် အနည်းငယ်ပို၍ အကောင်းဆုံးဟုထင်ရသော်လည်း ၎င်းသည် "တော်လှန်ရေးအစား ဆင့်ကဲဖြစ်စဉ်" နှင့် ပိုတူသည်။ “တော်လှန်ရေး” လုပ်ဖို့ လိုအပ်တယ်။ ရွေးချယ်မှု 3 (col).
အရာအားလုံးကို "ဇောက်ထိုး" လှန်ကြပါစို့- ကျွန်ုပ်တို့ တာဝန်ပေးပါမည်။ ကော်လံအမည် အသုံးပြုသူ ID! ကော်လံတွင်ရေးမည့်အရာသည် ကျွန်ုပ်တို့အတွက် အရေးမကြီးတော့ပါ၊ ၎င်းသည် နံပါတ် 1 ဖြစ်ပါစေ (ယေဘုယျအားဖြင့်၊ အသုံးဝင်သောအရာများကို ထိုနေရာတွင် သိမ်းဆည်းထားနိုင်သည်၊ ဥပမာ၊ အုပ်စု “မိသားစု/သူငယ်ချင်းများ/စသည်ဖြင့်”)။ ဤချဉ်းကပ်မှုသည် NoSQL ဒေတာဘေ့စ်များနှင့်အလုပ်လုပ်ရာတွင်ယခင်အတွေ့အကြုံမရှိသောမပြင်ဆင်ရသေးသော "လူနေ" ကိုအံ့အားသင့်စေသည်၊ သို့သော်၎င်းသည်သင့်အားဤလုပ်ငန်းဆောင်တာတွင် HBase ၏အလားအလာကိုပိုမိုထိရောက်စွာအသုံးပြုနိုင်စေမည့်ဤချဉ်းကပ်မှုဖြစ်သည်-

RowKey
အသံချဲ့စက်

Vasya
Petya: ၁
Olya: ၁
Dasha: ၁

Petya
Masha: ၁
Vasya: ၁

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

• အချက်အလက်ဖတ်ခြင်း။: Vasya ကို Olya မှာ စာရင်းသွင်းထားသလားဆိုတဲ့ မေးခွန်းကို ဖြေဖို့အတွက် "Olya" ကော်လံတစ်ကြောင်းကို ဖတ်ကြည့်ဖို့ လုံလောက်ပါပြီ- အဲဒီမှာရှိရင် အဖြေက မှန်၊ မဟုတ်ရင် - False => O(1)
• ဒေတာကိုတည်းဖြတ်ခြင်း- သူငယ်ချင်းတစ်ဦးကို ထည့်ခြင်း။− သူငယ်ချင်းထည့်ခြင်း- “Friend ID” => O(1) ကော်လံအသစ်တစ်ခုကို ပေါင်းထည့်ရုံပါပဲ။
• ဒေတာပြောင်းလဲခြင်း- သူငယ်ချင်းတစ်ဦးကို ဖျက်ခြင်း။: သူငယ်ချင်း ID ကော်လံ => O(1) ကို ဖယ်လိုက်ပါ

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

ဒေတာဘေ့စ်ကိုဝင်ရောက်သည့်အခါတွင် စွမ်းဆောင်ရည်ပိုကောင်းအောင်နှင့် I/O လုပ်ဆောင်ချက်များကို လျှော့ချရန် သင်သည် ပဟေဌိဖြစ်နိုင်ပြီး အနည်းငယ်ပို၍သွားနိုင်သည်။ ပြီးပြည့်စုံသော ဆက်ဆံရေးအချက်အလက်များကို အတန်းသော့ကိုယ်တိုင်က တိုက်ရိုက်သိမ်းဆည်းထားလျှင်ကော။ ဆိုလိုသည်မှာ၊ userID.friendID ကဲ့သို့သော့ပေါင်းစပ်မှုကို ပြုလုပ်ပါ။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် စာကြောင်း၏ကော်လံများကို လုံးဝဖတ်ရန်ပင်မလိုအပ်ပါ (ရွေးချယ်မှု 4 (အတန်း)):

RowKey
အသံချဲ့စက်

Vasya.Petya
Petya: ၁

Vasya.Olya
Olya: ၁

Vasya.Dasha
Dasha: ၁

Petya.Masha
Masha: ၁

Petya.Vasya
Vasya: ၁

ယခင်ဗားရှင်းတွင်ကဲ့သို့ ဖွဲ့စည်းပုံရှိ ဒေတာခြယ်လှယ်မှု အခြေအနေအားလုံးကို အကဲဖြတ်ခြင်းသည် O(1) ဖြစ်မည်မှာ ထင်ရှားပါသည်။ ရွေးချယ်မှု 3 နှင့် ကွာခြားချက်သည် ဒေတာဘေ့စ်ရှိ I/O လုပ်ဆောင်ချက်များ၏ ထိရောက်မှုတွင်သာ ဖြစ်လိမ့်မည်။

ကောင်းပြီ၊ နောက်ဆုံး "ညွှတ်" ။ ရွေးချယ်မှု 4 တွင်၊ အတန်းကီးသည် စွမ်းဆောင်ရည်ကို ထိခိုက်စေနိုင်သည် (ဤနေရာတွင် HBase သည် ဒေတာများကို သိမ်းဆည်းထားသည့် ဘိုက်အစုတစ်ခုအနေနှင့် ဇယားများရှိ အတန်းများကို သော့ဖြင့်စီထားသည်) ကို ပြောင်းလဲနိုင်သောအလျားရှိမည်ကို သိရန် လွယ်ကူသည်။ ထို့အပြင် ကျွန်ုပ်တို့တွင် အချို့သောအခြေအနေများတွင် ကိုင်တွယ်ရန်လိုအပ်နိုင်သည့် ခြားနားချက်တစ်ခုရှိသည်။ ဤသြဇာလွှမ်းမိုးမှုကို ဖယ်ရှားရန် သင်သည် userID နှင့် friendID မှ hash များကို အသုံးပြုနိုင်ပြီး hash နှစ်ခုလုံးသည် အဆက်မပြတ် အရှည်ရှိမည်ဖြစ်သဖြင့် ခွဲခြားခြင်းမရှိဘဲ ၎င်းတို့ကို ရိုးရှင်းစွာ ပေါင်းစပ်နိုင်သည်။ ထို့နောက် ဇယားရှိ ဒေတာသည် ဤကဲ့သို့ ဖြစ်လိမ့်မည် (ရွေးချယ်မှု 5 (hash)):

RowKey
အသံချဲ့စက်

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petya: ၁

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Olya: ၁

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Dasha: ၁

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Masha: ၁

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasya: ၁

ကျွန်ုပ်တို့စဉ်းစားနေသောအခြေအနေများတွင်ထိုကဲ့သို့သောဖွဲ့စည်းပုံနှင့်လုပ်ဆောင်ခြင်း၏ algorithmic ရှုပ်ထွေးမှုသည် option 4 ၏တူညီလိမ့်မည် - ဆိုလိုသည်မှာ O(1)။
စုစုပေါင်း၊ ကျွန်ုပ်တို့၏ ခန့်မှန်းတွက်ချက်မှုဆိုင်ရာ ရှုပ်ထွေးမှုအားလုံးကို ဇယားတစ်ခုတွင် အကျဉ်းချုံးကြပါစို့။

သူငယ်ချင်းတစ်ယောက်ထည့်ခြင်း။
သူငယ်ချင်းတစ်ယောက်ကို စစ်ဆေးကြည့်တယ်။
သူငယ်ချင်းကို ဖယ်ရှားခြင်း။

ရွေးချယ်မှု 1 (မူလ)
အို (ဎ)
အို (ဎ)
အို (ဎ)

ရွေးချယ်မှု 2 (အရေအတွက်)
အို (၁)
အို (ဎ)
အို (ဎ)

ရွေးချယ်မှု 3 (ကော်လံ)
အို (၁)
အို (၁)
အို (၁)

ရွေးချယ်မှု 4 (အတန်း)
အို (၁)
အို (၁)
အို (၁)

ရွေးချယ်မှု 5 (hash)
အို (၁)
အို (၁)
အို (၁)

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

စမ်းသပ်မှုပြင်ဆင်ခြင်း။

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

• သူငယ်ချင်းအသစ်တစ်ယောက်ထပ်ထည့်တယ်။
• အသုံးပြုသူ A သည် အသုံးပြုသူ B ၏ သူငယ်ချင်းဖြစ်မဖြစ် စစ်ဆေးခြင်း။
• သူငယ်ချင်းတယောက်ကို ဖြုတ်တယ်။

ထို့ကြောင့် ကနဦးထုတ်ပြန်ချက်တွင်ဖော်ပြထားသည့် လိုအပ်ချက်များကို ထည့်သွင်းစဉ်းစား၍ အတည်ပြုခြင်းအခြေအနေသည် အောက်ပါအတိုင်း ထွက်ပေါ်လာသည်-

• ဒေတာမှတ်တမ်းတင်ခြင်း။. အရွယ်အစား n ၏ ကနဦးကွန်ရက်ကို ကျပန်းထုတ်ပေးသည်။ “အစစ်အမှန်ကမ္ဘာ” နှင့် ပိုမိုနီးကပ်လာစေရန်၊ အသုံးပြုသူတိုင်းတွင်ရှိသော သူငယ်ချင်းအရေအတွက်သည်လည်း ကျပန်းပြောင်းလဲမှုတစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့၏ "အခြေအနေဆိုင်ရာ အက်ပ်လီကေးရှင်း" မှ ထုတ်လုပ်လိုက်သော အချက်အလက်အားလုံးကို HBase သို့ ရေးပေးသည့်အချိန်ကို တိုင်းတာပါ။ ထို့နောက် သူငယ်ချင်းပေါင်းထည့်ထားသော စုစုပေါင်းအရေအတွက်ဖြင့် ရလာသောအချိန်ကို ပိုင်းခြားပါ - ဤသည်မှာ "လုပ်ငန်းလည်ပတ်မှု" တစ်ခုအတွက် ပျမ်းမျှအချိန်ကို ရရှိပုံ၊
• အချက်အလက်ဖတ်ခြင်း။. အသုံးပြုသူတစ်ဦးစီအတွက်၊ အသုံးပြုသူစာရင်းသွင်းထားခြင်းရှိ၊မရှိ အဖြေတစ်ခုရရန် လိုအပ်သည့် “ကိုယ်ရည်ကိုယ်သွေးများ” စာရင်းတစ်ခုကို ဖန်တီးပါ။ စာရင်း၏ အရှည် = အသုံးပြုသူ၏ သူငယ်ချင်း အရေအတွက် ခန့်မှန်းခြေ နှင့် စစ်ဆေးထားသော သူငယ်ချင်း တစ်ဝက်အတွက် အဖြေမှာ "Yes" ဖြစ်သင့်ပြီး ကျန်တစ်ဝက်မှာ - "No" ဖြစ်သည်။ အဖြေများ "Yes" နှင့် "No" တို့ကို တစ်လှည့်စီ ပြုလုပ်ပေးသည် (ဆိုလိုတာက၊ ဒုတိယ ကိစ္စတိုင်းတွင် ရွေးချယ်စရာ 1 နှင့် 2 အတွက် မျဉ်းကြောင်း၏ ကော်လံအားလုံးကို ဖြတ်သန်းရပါမည်)။ ထို့နောက် ဘာသာရပ်တစ်ခုစီ၏ ပျမ်းမျှစစ်ဆေးချိန်ရရှိရန် စမ်းသပ်ထားသည့် သူငယ်ချင်းအရေအတွက်ဖြင့် စုစုပေါင်းစစ်ဆေးချိန်ကို ပိုင်းခြားပါသည်။
• ဒေတာဖျက်ခြင်း။. အသုံးပြုသူမှ သူငယ်ချင်းအားလုံးကို ဖယ်ရှားပါ။ ထို့အပြင်၊ ဖျက်ခြင်းအမှာစာသည် ကျပန်းဖြစ်သည် (ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် ဒေတာမှတ်တမ်းတင်ရန်အသုံးပြုသည့် မူရင်းစာရင်းကို “ပွတ်ဆွဲခြင်းဖြစ်သည်)။ ထို့နောက် စစ်ဆေးမှုတစ်ခုအတွက် ပျမ်းမျှအချိန်ရရှိရန် စုစုပေါင်းစစ်ဆေးချိန်ကို ဖယ်ရှားလိုက်သော သူငယ်ချင်းအရေအတွက်ဖြင့် ပိုင်းခြားပါသည်။

ဒေတာမော်ဒယ်ရွေးချယ်စရာ ၅ ခုမှ တစ်ခုစီအတွက် အခြေအနေများနှင့် လူမှုကွန်ရက် ကြီးထွားလာသည်နှင့်အမျှ အချိန်မည်မျှ ပြောင်းလဲလာသည်ကို ကြည့်ရှုရန် ကွဲပြားခြားနားသော အရွယ်အစားများအတွက် အခြေအနေများကို လုပ်ဆောင်ရန် လိုအပ်သည်။ n တစ်ခုအတွင်းတွင်၊ ကွန်ရက်ရှိချိတ်ဆက်မှုများနှင့် စစ်ဆေးရန်အသုံးပြုသူများစာရင်းသည် ရွေးချယ်စရာ ၅ ခုစလုံးအတွက် အတူတူပင်ဖြစ်ရပါမည်။
ပိုမိုနားလည်သဘောပေါက်ရန်၊ အောက်တွင်ဖော်ပြထားသည်မှာ n= 5 အတွက်ထုတ်လုပ်ထားသောဒေတာ၏နမူနာတစ်ခုဖြစ်သည်။ ရေးထားသော "ဂျင်နရေတာ" သည် ID အဘိဓာန်သုံးခုကို output အဖြစ်ထုတ်ပေးသည်-

• ပထမတစ်ခုသည် ထည့်သွင်းရန်ဖြစ်သည်။
• ဒုတိယအချက်မှာ စစ်ဆေးရန်ဖြစ်သည်။
• တတိယ - ဖျက်ရန်

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

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

စမ်းသပ်မှုကို HBase သည် Docker container တစ်ခုတွင် လုပ်ဆောင်နေသည့် Windows 10 အသုံးပြုသည့် လက်ပ်တော့တစ်လုံးတွင် ပြုလုပ်ခဲ့ပြီး Python with Jupyter Notebook သည် အခြားတစ်ခုတွင် လုပ်ဆောင်နေပါသည်။ Docker သည် CPU core 2 ခုနှင့် RAM 2 GB ကို ခွဲဝေပေးထားသည်။ စမ်းသပ်မှုဒေတာနှင့် တိုင်းတာသည့်အချိန်ကိုထုတ်ပေးရန်အတွက် “အခြေအနေဆိုင်ရာအသုံးချပလီကေးရှင်း” နှင့် “ပိုက်တင်ခြင်း” တို့ကို အတုယူခြင်းကဲ့သို့ ယုတ္တိဗေဒအားလုံးကို Python ဖြင့် ရေးသားထားသည်။ စာကြည့်တိုက်ကို HBase နှင့်အလုပ်လုပ်ရန်အသုံးပြုခဲ့သည်။ ပျော်ရွှင်စရာရွေးချယ်မှု 5 အတွက် hashes (MD5) ကိုတွက်ချက်ရန်၊

လက်ပ်တော့တစ်လုံး၏ ကွန်ပြူတာ ပါဝါကို ထည့်သွင်းစဉ်းစား၍ n=10၊ 30၊ … အတွက် စတင်ခြင်းအား စမ်းသပ်ရွေးချယ်ခဲ့သည်။ 170 - စမ်းသပ်မှုစက်ဝန်း၏ စုစုပေါင်းလည်ပတ်ချိန် (n အားလုံးအတွက် ရွေးချယ်စရာအားလုံးအတွက်) သည် ပို၍ သို့မဟုတ် နည်းပါးကြောင်း ကျိုးကြောင်းဆီလျော်ပြီး လက်ဖက်ရည်သောက်ပွဲတစ်ခုအတွင်း (ပျမ်းမျှ 15 မိနစ်တွင်) ကိုက်ညီသောအခါ။

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

စမ်းသပ်မှုရလဒ်

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

မျှော်မှန်းထားသည့်အတိုင်း ရွေးချယ်စရာများ 3-5 သည် ကွန်ရက်အရွယ်အစားကြီးထွားမှုနှင့် ခွဲခြား၍မရသော ကွာခြားချက်အပေါ်တွင်မူတည်ခြင်းမရှိသည့် အဆက်မပြတ်နီးပါး "လုပ်ငန်းအရောင်းအ၀ယ်" အချိန်ကို ပြသသည်။
ရွေးချယ်မှု 2 သည် အဆက်မပြတ်ဖြစ်နေသော်လည်း အနည်းငယ်ပိုဆိုးသော စွမ်းဆောင်ရည်ကိုလည်း ပြသသည်၊ ရွေးချယ်စရာ 2-3 နှင့် နှိုင်းယှဉ်ပါက 5 ဆနီးပါး အတိအကျနီးပါးရှိသည်။ ၎င်းသည် သီအိုရီနှင့် ဆက်စပ်နေသောကြောင့် ၎င်းသည် ဝမ်းမြောက်နိုင်ရုံသာမက - ဤဗားရှင်းတွင် HBase သို့ I/O လည်ပတ်မှု အရေအတွက်သည် ၂ ဆ အတိအကျ ပိုများနေသည်။ ၎င်းသည် ကျွန်ုပ်တို့၏စမ်းသပ်ခုံတန်းသည် မူအရအားဖြင့် ကောင်းမွန်တိကျမှုရှိကြောင်း သွယ်ဝိုက်သက်သေပြနိုင်သည် ။
Option 1 သည် မျှော်လင့်ထားသည့်အတိုင်း အနှေးဆုံးဖြစ်လာပြီး တစ်ခုနှင့်တစ်ခု ကွန်ရက်အရွယ်အစားသို့ ပေါင်းထည့်ခြင်းအတွက် အသုံးပြုသည့်အချိန်အတွင်း တစ်ပြေးညီတိုးလာမှုကို သရုပ်ပြသည်။
အခု ဒုတိယ စမ်းသပ်မှု ရလဒ်ကို ကြည့်ရအောင်။

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

ကောင်းပြီ၊ နောက်ဆုံးဂရပ်သည် ဖယ်ရှားခြင်းစမ်းသပ်ခြင်း၏ ရလဒ်ဖြစ်သည်။

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

ရွေးချယ်စရာများ 1 နှင့် 2 သည် မျှော်လင့်ထားသည့်အတိုင်း၊ အချိန်အတိုင်းအတာတစ်ခုအတွင်း တိုးလာမှုကို သရုပ်ပြသည်။ တစ်ချိန်တည်းမှာပင်၊ ရွေးချယ်မှု 2 သည် ရွေးချယ်မှု 1 ထက် အမြဲနှေးကွေးနေသည် - အရေအတွက်ကော်လံကို "ထိန်းသိမ်းရန်" ထပ်လောင်း I/O လုပ်ဆောင်ချက်ကြောင့် ဖြစ်သည်။

စမ်းသပ်မှု၏အထွေထွေကောက်ချက်

• Options 3-5 သည် HBase ၏အားသာချက်ကိုအသုံးပြုသည့်အတွက် ပိုမိုထိရောက်မှုကိုပြသသည်။ ထို့အပြင်၊ ၎င်းတို့၏ စွမ်းဆောင်ရည်သည် တစ်ခုနှင့်တစ်ခု အဆက်မပြတ်အားဖြင့် ကွာခြားပြီး ကွန်ရက်အရွယ်အစားပေါ်တွင်မူတည်ခြင်းမရှိပေ။
• ရွေးချယ်စရာ 4 နှင့် 5 အကြားခြားနားချက်ကို မှတ်တမ်းတင်မထားပါ။ ဒါပေမယ့် ဒါက option 5 ကို အသုံးမပြုဘူးလို့ မဆိုလိုပါဘူး။ စမ်းသပ်ခုံတန်းလျား၏ စွမ်းဆောင်ရည်လက္ခဏာများကို ထည့်သွင်းစဉ်းစားကာ အသုံးပြုထားသော စမ်းသပ်မှုအခြေအနေသည် ၎င်းအား ရှာဖွေတွေ့ရှိရန် ခွင့်မပြုခဲ့ခြင်း ဖြစ်နိုင်သည်။
• ဒေတာဖြင့် "စီးပွားရေးလုပ်ငန်းဆောင်ရွက်မှုများ" လုပ်ဆောင်ရန် လိုအပ်သည့်အချိန်တိုးလာမှု၏ သဘောသဘာဝကို ယေဘုယျအားဖြင့် ရွေးချယ်စရာအားလုံးအတွက် ယခင်ရရှိထားသော သီအိုရီတွက်ချက်မှုများကို အတည်ပြုပါသည်။

epilogue

ကြမ်းတမ်းတဲ့ စမ်းသပ်မှုတွေကို ပကတိ အမှန်တရားအဖြစ် မခံယူသင့်ပါဘူး။ ရလဒ်များကို ထည့်သွင်းစဉ်းစား၍မရသော အချက်များစွာ ရှိသည် (ဤအတက်အကျများကို အထူးသဖြင့် ကွန်ရက်အရွယ်အစားသေးငယ်သော ဂရပ်များတွင် မြင်နိုင်သည်)။ ဥပမာအားဖြင့်၊ happybase ကသုံးတဲ့ အရှိန်အဟုန်၊ Python မှာ ကျွန်တော်ရေးထားတဲ့ logic ကို အကောင်အထည်ဖော်တဲ့ ပမာဏနဲ့ နည်းလမ်း (ကုဒ်ကို အစိတ်အပိုင်းအားလုံးရဲ့ လုပ်ဆောင်နိုင်စွမ်းတွေကို အကောင်းဆုံးနဲ့ ထိထိရောက်ရောက် ရေးထားတာလို့ မဆိုနိုင်ပါဘူး)၊ HBase caching ၏အင်္ဂါရပ်များ၊ ကျွန်ုပ်၏လက်ပ်တော့ရှိ Windows 10 ၏နောက်ခံလုပ်ဆောင်ချက်၊ စသည်တို့။ ယေဘူယျအားဖြင့်၊ သီအိုရီဆိုင်ရာ တွက်ချက်မှုများအားလုံးသည် ၎င်းတို့၏ တရားဝင်မှုကို လက်တွေ့ပြသခဲ့သည်ဟု ကျွန်ုပ်တို့ ယူဆနိုင်သည်။ ကောင်းပြီ၊ သို့မဟုတ် အနည်းဆုံးတော့ ထိုကဲ့သို့သော "ခေါင်းချင်းဆိုင်တိုက်ခိုက်ခြင်း" ဖြင့် ၎င်းတို့အား ချေပရန် မဖြစ်နိုင်ပေ။

နိဂုံးချုပ်အနေဖြင့်၊ HBase တွင် ဒေတာမော်ဒယ်များကို ဒီဇိုင်းဆွဲနေသူတစ်ဦးတိုင်းအတွက် အကြံပြုချက်များ- ဆက်စပ်ဒေတာဘေ့စ်များနှင့် လုပ်ဆောင်ခဲ့သည့် ယခင်အတွေ့အကြုံမှ စိတ္တဇဖြစ်ပြီး "အမိန့်တော်များ" ကို မှတ်သားပါ-

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

source: www.habr.com