HBase ကိုအသုံးပြုခြင်း၏သီအိုရီနှင့်အလေ့အကျင့်

မင်္ဂလာနေ့လည်ခင်းပါ ကျွန်ုပ်၏အမည်မှာ Danil Lipovoy ဖြစ်ပြီး၊ Sbertech ရှိ ကျွန်ုပ်တို့၏အဖွဲ့သည် လုပ်ငန်းလည်ပတ်ဒေတာအတွက် သိုလှောင်မှုအဖြစ် HBase ကို စတင်အသုံးပြုခဲ့သည်။ ၎င်းကိုလေ့လာစဉ်တွင်၊ ကျွန်တော်စနစ်တကျဖော်ပြလိုသောအတွေ့အကြုံများစုဆောင်းခဲ့သည် (များစွာသောများအတွက်အသုံးဝင်လိမ့်မည်ဟုမျှော်လင့်ပါတယ်) ။ အောက်ဖော်ပြပါ စမ်းသပ်မှုအားလုံးကို HBase ဗားရှင်း 1.2.0-cdh5.14.2 နှင့် 2.0.0-cdh6.0.0-beta1 တို့ဖြင့် လုပ်ဆောင်ခဲ့သည်။

1. အထွေထွေဗိသုကာ
2. ဒေတာကို HBASE သို့ရေးသားခြင်း။
3. HBASE မှဒေတာကိုဖတ်ခြင်း။
4. ဒေတာသိမ်းဆည်းခြင်း
5. ဒေတာအတွဲလိုက် MultiGet/MultiPut လုပ်ဆောင်ခြင်း။
6. ဇယားများကို ဒေသများအဖြစ် ပိုင်းခြားခြင်း (splitting) ဗျူဟာ
7. အမှားခံနိုင်ရည်ရှိမှု၊ စုစည်းမှုနှင့် ဒေတာနေရာဒေသ
8. ဆက်တင်များနှင့် စွမ်းဆောင်ရည်
9. စိတ်ဖိစီးမှုစမ်းသပ်ခြင်း။
10. တွေ့ရှိချက်များ

1. အထွေထွေဗိသုကာ

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

2. အချက်အလက်ကို HBASE သို့ ရေးပါ။

အရင်ဆုံး put(rowkey) ကိုသုံးပြီး table တစ်ခုမှာ key-value object တစ်ခုကို ရေးကြည့်ရအောင်။ client သည် hbase:meta table ကို သိမ်းဆည်းထားသည့် Root Region Server (RRS) သည် မည်သည့်နေရာတွင် ရှိနေသည်ကို ရှာဖွေရမည်ဖြစ်သည်။ ဤအချက်အလက်ကို ZooKeeper မှရရှိသည်။ ထို့နောက် ၎င်းသည် RRS ကိုဝင်ရောက်ပြီး hbase:meta table ကိုဖတ်ကာ၊ ၎င်းသည် RegionServer (RS) သည် စိတ်ဝင်စားသောဇယားရှိ ပေးထားသော rowkey အတွက် ဒေတာသိမ်းဆည်းရန် တာဝန်ရှိသည်ဟူသော အချက်အလက်ကို ထုတ်ယူသည်။ အနာဂတ်အသုံးပြုမှုအတွက်၊ မက်တာဇယားကို client မှ ကက်ရှ်လုပ်ထားသောကြောင့် နောက်ဆက်တွဲခေါ်ဆိုမှုများသည် RS သို့ တိုက်ရိုက်ပိုမြန်ပါသည်။

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

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

“Delete” လုပ်ဆောင်ချက်ကို လုပ်ဆောင်သောအခါ၊ ဒေတာများကို ရုပ်ပိုင်းဆိုင်ရာ ဖျက်ပစ်မည်မဟုတ်ပါ။ ၎င်းတို့ကို ဖျက်လိုက်ခြင်းအဖြစ် ရိုးရှင်းစွာ မှတ်သားထားပြီး အပိုဒ် 7 တွင် အသေးစိတ်ဖော်ပြထားသည့် အဓိကကျစ်လစ်သိပ်သည်းသည့်လုပ်ဆောင်ချက်ကို ခေါ်သည့်အချိန်တွင် ၎င်းကိုယ်တိုင် ဖျက်ဆီးခြင်း ဖြစ်ပေါ်ပါသည်။

HFile ဖော်မတ်ရှိ ဖိုင်များကို HDFS တွင် စုဆောင်းထားပြီး သေးငယ်သောကျစ်လျစ်သော လုပ်ငန်းစဉ်ကို အခါအားလျော်စွာ စတင်လုပ်ဆောင်ပြီး မည်သည့်အရာမှ မဖျက်ဘဲ ပိုကြီးသောဖိုင်များအဖြစ်သို့ ရိုးရှင်းစွာ ပေါင်းစည်းသည်။ အချိန်ကြာလာသည်နှင့်အမျှ၊ ၎င်းသည် ဒေတာကိုဖတ်သည့်အခါမှသာ ပေါ်လာသည့် ပြဿနာတစ်ခုအဖြစ်သို့ ပြောင်းလဲသွားသည် (ကျွန်ုပ်တို့ ၎င်းကို နောက်အနည်းငယ်ကြာသောအခါ ပြန်လာခဲ့ပါမည်)။

အထက်တွင်ဖော်ပြထားသော loading လုပ်ငန်းစဉ်အပြင်၊ ဤဒေတာဘေ့စ်၏အပြင်းထန်ဆုံးအခြမ်းဖြစ်သည့် BulkLoad ဖြစ်နိုင်သည်။ ကျွန်ုပ်တို့သည် HFiles ကို သီးခြားဖန်တီးပြီး ၎င်းတို့ကို ဒစ်ခ်ပေါ်တွင် ထားရှိရခြင်းမှာ ကျွန်ုပ်တို့အား စုံလင်စွာ အတိုင်းအတာနှင့် အလွန်သင့်လျော်သော အမြန်နှုန်းများကို ရရှိစေသည့်အချက်တွင် အကျုံးဝင်ပါသည်။ အမှန်တော့၊ ဤနေရာတွင် ကန့်သတ်ချက်သည် HBase မဟုတ်ဘဲ ဟာ့ဒ်ဝဲ၏ စွမ်းဆောင်ရည်များဖြစ်သည်။ အောက်တွင် 16 RegionServers နှင့် 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase ဗားရှင်း 1.2.0-cdh5.14.2 ပါဝင်သော အစုအဝေးတစ်ခုပေါ်ရှိ boot ရလဒ်များ။

ဇယားရှိ partitions (ဒေသများ) နှင့် Spark executors များ အရေအတွက်ကို တိုးမြှင့်ခြင်းဖြင့် ကျွန်ုပ်တို့သည် ဒေါင်းလုဒ်အမြန်နှုန်း တိုးလာသည်ကို ဤနေရာတွင် သင်တွေ့မြင်နိုင်ပါသည်။ ထို့အပြင်၊ အမြန်နှုန်းသည် ရိုက်ကူးသည့် အသံအတိုးအကျယ်ပေါ်မူတည်သည်။ ကြီးမားသော ဘလောက်များသည် MB/sec တိုးလာသည်၊ အချိန်ယူနစ်အလိုက် ထည့်သွင်းထားသော မှတ်တမ်းအရေအတွက်တွင် သေးငယ်သော အတုံးငယ်များ၊ အခြားအရာအားလုံးသည် တန်းတူဖြစ်သည်။

တစ်ချိန်တည်းတွင် ဇယားနှစ်ခုသို့ စတင်တင်နိုင်ပြီး အမြန်နှုန်းကို နှစ်ဆရနိုင်သည်။ အောက်တွင် 10 KB တုံးများကို ဇယားနှစ်ခုသို့ တစ်ပြိုင်နက် ရေးသားခြင်းသည် တစ်ခုစီတွင် 600 MB/sec ခန့် (စုစုပေါင်း 1275 MB/sec) ဖြင့် ဖြစ်ပေါ်သည်ကို သင်တွေ့မြင်နိုင်သည် အမှတ် ၁၁)၊

သို့သော် 50 KB မှတ်တမ်းများပါရှိသော ဒုတိယအပြေးသည် ဒေါင်းလုဒ်အမြန်နှုန်းသည် အနည်းငယ်ကြီးထွားလာသည်ကို ပြသသည်၊ ၎င်းသည် ကန့်သတ်တန်ဖိုးများဆီသို့ ချဉ်းကပ်လာနေကြောင်း ဖော်ပြသည်။ တစ်ချိန်တည်းမှာပင်၊ HBASE ကိုယ်တိုင်က လက်တွေ့တွင် ဖန်တီးထားသော load မရှိကြောင်း မှတ်သားထားရန်လိုသည်၊ လိုအပ်သည်မှာ hbase:meta မှ ဒေတာကို ဦးစွာပေးရန်နှင့် HFiles ကိုစီတန်းပြီးနောက် BlockCache ဒေတာကို ပြန်လည်သတ်မှတ်ပြီး သိမ်းဆည်းပါ။ ဗလာမဟုတ်ပါက MemStore သည် disk သို့ ကြားခံဖြစ်သည်။

3. HBASE မှဒေတာကိုဖတ်ခြင်း။

အကယ်၍ client တွင် hbase:meta မှ အချက်အလက်အားလုံးရှိနေပြီဟု ကျွန်ုပ်တို့ယူဆပါက တောင်းဆိုချက်သည် လိုအပ်သောသော့ကို သိမ်းဆည်းထားသည့် RS သို့ တိုက်ရိုက်သွားမည်ဖြစ်သည်။ ပထမဦးစွာ၊ ရှာဖွေမှုကို MemCache တွင်လုပ်ဆောင်သည်။ ထိုနေရာတွင် ဒေတာရှိသည်ဖြစ်စေ မရှိသည်ဖြစ်စေ ရှာဖွေမှုကို BlockCache ကြားခံတွင် လုပ်ဆောင်ပြီး လိုအပ်ပါက HFiles တွင် လုပ်ဆောင်ပါသည်။ ဖိုင်တွင် ဒေတာကို တွေ့ရှိပါက၊ ၎င်းကို BlockCache တွင် ထားရှိမည်ဖြစ်ပြီး နောက်တောင်းဆိုမှုတွင် ပိုမိုမြန်ဆန်စွာ ပြန်ပို့ပေးပါမည်။ Bloom filter ကိုအသုံးပြုခြင်းကြောင့် HFile တွင်ရှာဖွေခြင်းသည် အတော်လေးမြန်သည်။ ဒေတာအနည်းငယ်ကို ဖတ်ပြီးသည်နှင့် ဤဖိုင်တွင် လိုအပ်သောသော့ပါရှိမရှိ ချက်ချင်းဆုံးဖြတ်ပြီး မဟုတ်ပါက နောက်တစ်ခုသို့ ဆက်သွားပါ။

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

4. ဒေတာသိမ်းဆည်းခြင်း

MemStore နှင့် BlockCache ကြားခံများသည် ခွဲဝေချထားပေးသည့် on-heap RS memory ၏ 80% အထိ သိမ်းပိုက်ထားသည် (ကျန်သောအရာများကို RS ဝန်ဆောင်မှုလုပ်ငန်းများအတွက် သီးသန့်ထားပါသည်)။ ပုံမှန်အသုံးပြုမှုမုဒ်သည် လုပ်ငန်းစဉ်များရေးသားပြီး တူညီသောဒေတာကိုချက်ချင်းဖတ်ခြင်းမျိုးဖြစ်ပါက BlockCache ကိုလျှော့ချပြီး MemStore ကိုတိုးမြှင့်ခြင်းသည် အဓိပ္ပာယ်ရှိသောကြောင့်ဖြစ်သည်။ ဒေတာစာရေးခြင်းသည် စာဖတ်ရန်အတွက် ကက်ရှ်ထဲသို့ မဝင်သောအခါ၊ BlockCache ကို မကြာခဏ အသုံးပြုမှု နည်းပါးသွားပါမည်။ BlockCache ကြားခံတွင် အပိုင်းနှစ်ပိုင်း ပါဝင်သည်- LruBlockCache (ပုံတွင် အမြဲရှိနေသည်) နှင့် BucketCache (များသောအားဖြင့် အစုအဝေး သို့မဟုတ် SSD ပေါ်တွင်)။ ဖတ်ရှုရန် တောင်းဆိုမှုများ အများအပြားရှိနေချိန်တွင် BucketCache ကို အသုံးပြုသင့်ပြီး ၎င်းတို့သည် အမှိုက်စုဆောင်းသူ၏ တက်ကြွစွာလုပ်ဆောင်မှုကို ဖြစ်စေသည့် LruBlockCache နှင့် မကိုက်ညီပါ။ တစ်ချိန်တည်းမှာပင်၊ read cache ကိုအသုံးပြုခြင်းမှ စွမ်းဆောင်ရည်မြင့်မားလာမည်ဟု သင်မမျှော်လင့်သင့်သော်လည်း အပိုဒ် 8 တွင် ဤအရာကို ပြန်သွားပါမည်။

RS တစ်ခုလုံးအတွက် BlockCache တစ်ခုရှိပြီး ဇယားတစ်ခုစီအတွက် MemStore တစ်ခု (Column Family တစ်ခုစီအတွက် တစ်ခု) ရှိပါသည်။

ဘယ်လို ဖော်ပြခဲ့သည်။ သီအိုရီအရ၊ စာရေးသည့်အခါ၊ ဒေတာသည် ကက်ရှ်ထဲသို့ မဝင်ဘဲ အမှန်ပင်၊ ဇယားအတွက် CACHE_DATA_ON_WRITE နှင့် RS အတွက် "Cache DATA on Write" တို့ကို false ဟု သတ်မှတ်ထားသည်။ သို့သော် လက်တွေ့တွင်၊ ကျွန်ုပ်တို့ MemStore တွင် ဒေတာကို ရေးလိုက်လျှင် ၎င်းကို ဒစ်ခ်တွင် လွှင့်ပစ်ပါ (ထို့ကြောင့် ၎င်းကို ရှင်းလင်းခြင်း) ပြီးနောက် ရရှိလာသော ဖိုင်ကို ဖျက်ပစ်ပြီးနောက် ရယူရန် တောင်းဆိုမှုကို လုပ်ဆောင်ခြင်းဖြင့် ကျွန်ုပ်တို့သည် ဒေတာကို အောင်မြင်စွာ ရရှိမည်ဖြစ်သည်။ ထို့အပြင် သင်သည် BlockCache ကို လုံးဝပိတ်ပြီး ဒေတာအသစ်ဖြင့် ဇယားကိုဖြည့်ပြီးပါက MemStore ကို disk သို့ ပြန်လည်သတ်မှတ်ပါ၊ ၎င်းတို့ကို ဖျက်ပြီး အခြား session တစ်ခုမှ တောင်းဆိုပါက ၎င်းတို့ကို တစ်နေရာမှ ပြန်လည်ရယူမည်ဖြစ်သည်။ ထို့ကြောင့် HBase သည် ဒေတာများကိုသာမက လျှို့ဝှက်ဆန်းကြယ်သော အရာများကိုပါ သိမ်းဆည်းထားသည်။

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

Read on "Cache DATA" parameter ကို false ဟု သတ်မှတ်ထားသည်။ သင့်တွင်အကြံဥာဏ်များရှိပါက comment တွင်ဆွေးနွေးရန်ကြိုဆိုပါသည်။

5. Batch data processing MultiGet/MultiPut

တောင်းဆိုချက်တစ်ခုတည်းကို လုပ်ဆောင်ခြင်း (Get/Put/Delete) သည် အလွန်စျေးကြီးသော လုပ်ဆောင်ချက်ဖြစ်ပြီး၊ ဖြစ်နိုင်လျှင် ၎င်းတို့ကို စာရင်း သို့မဟုတ် စာရင်းတစ်ခုအဖြစ် ပေါင်းစပ်ထားသင့်ပြီး သိသာထင်ရှားသော စွမ်းဆောင်ရည်ကို မြှင့်တင်နိုင်မည်ဖြစ်သည်။ အထူးသဖြင့် စာရေးခြင်းလုပ်ငန်းအတွက် ဤသည်မှာ မှန်သော်လည်း ဖတ်သည့်အခါတွင် အောက်ပါအခက်အခဲများရှိသည်။ အောက်ဖော်ပြပါဂရပ်သည် MemStore မှမှတ်တမ်းပေါင်း 50 ကိုဖတ်ရန်အချိန်ကိုပြသသည်။ စာဖတ်ခြင်းကို စာတွဲတစ်ခုတွင် လုပ်ဆောင်ခဲ့ပြီး အလျားလိုက်ဝင်ရိုးသည် တောင်းဆိုချက်ရှိ သော့အရေအတွက်ကို ပြသသည်။ တောင်းဆိုချက်တစ်ခုတွင် သော့တစ်ထောင်အထိ တိုးလာသောအခါ၊ လုပ်ဆောင်ချိန်သည် ကျဆင်းသွားသည်ကို ဤနေရာတွင် သင်တွေ့မြင်နိုင်ပါသည်။ အရှိန်တိုးလာသည်။ သို့သော်၊ MSLAB မုဒ်ကို ပုံသေဖြင့်ဖွင့်ထားခြင်းဖြင့်၊ ဤအဆင့်သတ်မှတ်ပြီးနောက် စွမ်းဆောင်ရည်ကျဆင်းမှုစတင်လာပြီး မှတ်တမ်းရှိဒေတာပမာဏပိုကြီးလေ၊ လည်ပတ်ချိန်ပိုကြာလေဖြစ်သည်။

စမ်းသပ်မှုများကို virtual machine၊ 8 cores၊ ဗားရှင်း HBase 2.0.0-cdh6.0.0-beta1 တွင် ပြုလုပ်ခဲ့သည်။

MSLAB မုဒ်သည် မျိုးဆက်သစ်နှင့် အဟောင်းဒေတာ ရောနှောခြင်းကြောင့် ဖြစ်ပေါ်လာသည့် အစုအပုံလိုက် အကွဲအပြဲများကို လျှော့ချရန် ဒီဇိုင်းထုတ်ထားသည်။ ဖြေရှင်းနည်းတစ်ခုအနေဖြင့် MSLAB ကိုဖွင့်ထားသောအခါ၊ ဒေတာကို သေးငယ်သောဆဲလ်များ (အတုံးများ) အဖြစ်ထားရှိကာ အတုံးအခဲများဖြင့် လုပ်ဆောင်သည်။ ရလဒ်အနေဖြင့် တောင်းဆိုထားသောဒေတာပက်ကေ့ချ်ရှိ ပမာဏသည် ခွဲဝေချထားပေးသည့်အရွယ်အစားထက်ကျော်လွန်သောအခါ၊ စွမ်းဆောင်ရည် သိသိသာသာကျဆင်းသွားပါသည်။ တစ်ဖက်တွင်၊ ဤမုဒ်ကို ပိတ်ခြင်းသည်လည်း အကြံပြုလိုမည်မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် ပြင်းထန်သောဒေတာလုပ်ဆောင်မှုအခိုက်အတန့်တွင် GC ကြောင့် ရပ်တန့်သွားမည်ဖြစ်သည်။ ကောင်းမွန်သောဖြေရှင်းချက်မှာ စာဖတ်ခြင်းနှင့် တစ်ချိန်တည်းတွင် ထည့်သွင်းရေးသားခြင်းတွင် ဆဲလ်ထုထည်ပမာဏကို တိုးမြှင့်ရန်ဖြစ်သည်။ မှတ်တမ်းတင်ပြီးနောက်၊ MemStore ကို disk သို့ပြန်လည်သတ်မှတ်ပေးသော flush command ကို run ပါက သို့မဟုတ် BulkLoad ကိုအသုံးပြု၍ load လုပ်ပါက ပြဿနာမဖြစ်ပေါ်ကြောင်း သတိပြုသင့်ပါသည်။ အောက်ဖော်ပြပါဇယားသည် ပိုမိုကြီးမားသော (နှင့်တူညီသောပမာဏ) ဒေတာအတွက် MemStore မှမေးမြန်းချက်များသည် နှေးကွေးမှုဖြစ်စေသည်ဟု ဖော်ပြသည်။ သို့သော်လည်း၊ chunksize ကို တိုးမြှင့်ခြင်းဖြင့် ကျွန်ုပ်တို့သည် လုပ်ဆောင်ချိန်ကို ပုံမှန်အတိုင်း ပြန်ပေးပါသည်။

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

6. ဇယားများကို ဒေသများအဖြစ် ပိုင်းခြားခြင်း (splitting)၊

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

ဥပမာအားဖြင့်၊ ရှည်လျားသောတန်ဖိုးများ၊ အများစုမှာ ဂဏန်းတစ်ခုတည်းဖြင့် စတင်ပါက၊ ၎င်းသည် နောက်ပိုင်းတွင် loaded data များကို သိသိသာသာနှေးကွေးသွားစေပြီး ဥပမာ-

1000001
1000002
...
1100003

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

HexStringSplit – သော့ကို "00000000" => "FFFFFFFF" အကွာအဝေးရှိ ဆဋ္ဌမကိန်းဂဏန်းဝှက်ထားသော စာကြောင်းအဖြစ်သို့ ပြောင်းပြီး ဘယ်ဘက်တွင် သုညဖြင့် ကွက်လပ်ထိုးပါ။

UniformSplit – အကွာအဝေး "00" => "FF" အတွင်းရှိ သော့ကို ဘိုက်အခင်းအကျင်းအဖြစ်သို့ အပိုင်းအခြား "XNUMX" => "FF" နှင့် ညာဘက်တွင် သုညဖြင့် ကွက်လပ်ထည့်သည်။

ထို့အပြင်၊ သင်သည် ပိုင်းခြားခြင်းနှင့် အလိုအလျောက်ခွဲခြမ်းခြင်းအတွက် သော့တွဲများကို သတ်မှတ်နိုင်သည်။ သို့သော်၊ အရိုးရှင်းဆုံးနှင့် အထိရောက်ဆုံး ချဉ်းကပ်နည်းများထဲမှ တစ်ခုမှာ UniformSplit နှင့် hash ပေါင်းစပ်ခြင်းကို အသုံးပြုခြင်းဖြစ်သည်၊ ဥပမာ CRC32(rowkey) လုပ်ဆောင်ချက်နှင့် rowkey ကိုယ်တိုင်က သော့ကိုလည်ပတ်ခြင်းမှ အထင်ရှားဆုံး bytes အတွဲများ-

hash + rowkey

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

7. အမှားခံနိုင်ရည်နှင့် ဒေတာနေရာဒေသ

သော့အတွဲတစ်ခုစီအတွက် ဒေသတစ်ခုကသာ တာဝန်ရှိသောကြောင့် RS ပျက်စီးခြင်း သို့မဟုတ် ဖျက်သိမ်းခြင်းဆိုင်ရာ ပြဿနာများအတွက် ဖြေရှင်းချက်မှာ လိုအပ်သောဒေတာအားလုံးကို HDFS တွင် သိမ်းဆည်းထားခြင်းဖြစ်သည်။ RS ပြုတ်ကျသောအခါ ZooKeeper node ပေါ်ရှိ နှလုံးခုန်သံမရှိသဖြင့် ၎င်းကို master မှ သိရှိသည်။ ထို့နောက် ၎င်းသည် ဝန်ဆောင်မှုပေးသည့်ဒေသအား အခြား RS သို့ ပေးအပ်ပြီး HFiles များကို ဖြန့်ဝေထားသော ဖိုင်စနစ်တွင် သိမ်းဆည်းထားသောကြောင့်၊ ပိုင်ရှင်အသစ်က ၎င်းတို့ကို ဖတ်ပြီး ဒေတာကို ဆက်လက်လုပ်ဆောင်နေပါသည်။ သို့သော်၊ အချို့သောဒေတာများသည် MemStore တွင်ရှိနေနိုင်ပြီး HFiles သို့ဝင်ရောက်ရန်အချိန်မရှိသောကြောင့် HDFS တွင်သိမ်းဆည်းထားသည့် WAL ကို လုပ်ဆောင်ချက်များ၏သမိုင်းကြောင်းကိုပြန်လည်ရယူရန်အသုံးပြုပါသည်။ အပြောင်းအလဲများကို အသုံးချပြီးနောက်၊ RS သည် တောင်းဆိုမှုများကို တုံ့ပြန်နိုင်သော်လည်း ရွေ့လျားမှုသည် ဒေတာအချို့နှင့် ၎င်းတို့ကို ဝန်ဆောင်မှုပေးသည့် လုပ်ငန်းစဉ်များသည် မတူညီသော node များပေါ်တွင် အဆုံးသတ်သွားသည်ဟူသော အချက်ကို ဦးတည်စေသည်။ နေရာဒေသ ကျဆင်းလာသည်။

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

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

စမ်းသပ်မှုကို DataNodes 3 ခုနှင့် 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads) တွင် လုပ်ဆောင်ခဲ့သည်။ HBase ဗားရှင်း 1.2.0-cdh5.14.2

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

ထို့အပြင်၊ အဓိကကျုံ့မှုသည် MemStore ၏အခြေအနေကိုမထိခိုက်စေပါ၊ ၎င်းကို disk သို့ထုတ်ပြီးကျစ်လစ်စေရန်၊ flush (connection.getAdmin()flush(TableName.valueOf(tblName))) ကိုအသုံးပြုရန်လိုအပ်ပါသည်။

8. ဆက်တင်များနှင့် စွမ်းဆောင်ရည်

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

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

-ထား
-ရယူပါ။
- Get+Put

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

- BlockCache = ဖွင့် သို့မဟုတ် ပိတ်သည်။
- BlockSize = 65 KB သို့မဟုတ် 16 KB
- အပိုင်းများ = 1၊ 5 သို့မဟုတ် 30
— MSLAB = ဖွင့်ထားသည် သို့မဟုတ် ပိတ်ထားသည်။

ထို့ကြောင့် ဘလောက်သည် ဤကဲ့သို့ ဖြစ်သည်-

a MSLAB မုဒ်ကို ဖွင့်/ပိတ်ထားသည်။
ခ အောက်ဖော်ပြပါ ကန့်သတ်ချက်များသတ်မှတ်ထားသည့် ဇယားတစ်ခုကို ဖန်တီးထားသည်- BlockCache = true/none၊ BlockSize = 65/16 Kb၊ Partition = 1/5/30။
ဂ။ Compression ကို GZ ဟု သတ်မှတ်ခဲ့သည်။
ဃ။ 10 threads သည် 1/10 put/get/get+put operations များကို 100/1000/10000 bytes မှတ်တမ်းများနှင့်အတူ ဤဇယားတွင် 50/000 put/get/get+put operations များကို တပြိုင်နက်တည်း စတင်ခဲ့ပြီး၊ ဆက်တိုက်မေးမြန်းချက် XNUMX (ကျပန်းသော့များ) ကို လုပ်ဆောင်ပါသည်။
င အမှတ် ဃ ကို သုံးကြိမ် ထပ်ခါတလဲလဲ လုပ်တယ်။
f လိုင်းအားလုံး၏ လည်ပတ်ချိန်ကို ပျမ်းမျှအားဖြင့် တွက်ချက်ထားသည်။

ဖြစ်နိုင်သော ပေါင်းစပ်မှုအားလုံးကို စမ်းသပ်ခဲ့သည်။ မှတ်တမ်းအရွယ်အစား တိုးလာသည်နှင့်အမျှ မြန်နှုန်း ကျဆင်းသွားမည် သို့မဟုတ် ကက်ရှ်ကို ပိတ်ခြင်းသည် နှေးကွေးစေသည်ဟု ခန့်မှန်းနိုင်သည်။ သို့သော်လည်း ပန်းတိုင်သည် အတိုင်းအတာတစ်ခုစီ၏ သြဇာလွှမ်းမိုးမှု၏ ဒီဂရီနှင့် အရေးပါမှုကို နားလည်ရန်ဖြစ်သည်၊ ထို့ကြောင့် စုဆောင်းထားသောဒေတာကို linear regression function ၏ ထည့်သွင်းမှုထဲသို့ ဖြည့်သွင်းပြီး t-statistics ကို အသုံးပြု၍ အရေးပါမှုကို အကဲဖြတ်ရန် ဖြစ်နိုင်သည်။ အောက်ဖော်ပြပါများသည် Put လုပ်ဆောင်ချက်များကို လုပ်ဆောင်နေသည့် တုံးများ၏ ရလဒ်များဖြစ်သည်။ ပေါင်းစပ်မှုအစုံအလင် 2*2*3*2*3 = 144 ရွေးချယ်မှုများ + 72 tk။ တချို့က နှစ်ကြိမ်လုပ်တယ်။ ထို့ကြောင့် စုစုပေါင်း 216 ပြေးသည်။

စမ်းသပ်ခြင်းကို DataNodes 3 ခုနှင့် 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads) ပါ၀င်သည့် အသေးစား အစုအဝေးတွင် ပြုလုပ်ခဲ့သည်။ HBase ဗားရှင်း 1.2.0-cdh5.14.2။

3.7 စက္ကန့်အတွင်း အမြင့်ဆုံးထည့်သွင်းမှုအမြန်နှုန်းကို MSLAB မုဒ်ပိတ်လိုက်ခြင်းဖြင့် BlockCache ကိုဖွင့်ထားခြင်းဖြင့် ဇယားတစ်ခုပေါ်တွင် BlockSize = 16၊ 100 bytes မှတ်တမ်းများ၊ တစ်ထုပ်လျှင် 10 ပိုင်းရှိသည်။
အနိမ့်ဆုံးထည့်သွင်းမှုအမြန်နှုန်း 82.8 စက္ကန့်ကို MSLAB မုဒ်ကိုဖွင့်ထားခြင်းဖြင့်၊ အပိုင်းတစ်ခုပါရှိသော ဇယားတစ်ခုပေါ်တွင် BlockCache ကိုဖွင့်ထားခြင်းဖြင့်၊ BlockSize = 16၊ 10000 bytes၊ 1 တစ်ခုစီ၏ မှတ်တမ်းများ။

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

သို့သော် partitions အရေအတွက်တိုးလာခြင်းသည် စွမ်းဆောင်ရည်ကျဆင်းခြင်းသို့ ဦးတည်စေသည်ဟူသောအချက်သည် အနည်းငယ်မျှော်လင့်မထားသောအချက်ဖြစ်သည် (BulkLoad ဖြင့် partition အရေအတွက်တိုးခြင်း၏ အပြုသဘောဆောင်သောအကျိုးသက်ရောက်မှုကို ကျွန်ုပ်တို့တွေ့မြင်နေရပြီဖြစ်သည်)။ ပထမဦးစွာ၊ လုပ်ဆောင်ခြင်းအတွက်၊ တစ်ခုအစား ဒေသ 30 သို့ တောင်းဆိုမှုများပြုလုပ်ရန် လိုအပ်ပြီး ဒေတာပမာဏသည် အမြတ်ထွက်စေမည့် ထိုကဲ့သို့မဟုတ်ပေ။ ဒုတိယအနေဖြင့်၊ စုစုပေါင်းလည်ပတ်ချိန်ကို အနှေးဆုံး RS မှဆုံးဖြတ်ပြီး DataNodes အရေအတွက်သည် RSs အရေအတွက်ထက်နည်းသောကြောင့်၊ အချို့သောဒေသများတွင် နေရာဒေသမရှိပေ။ ကောင်းပြီ၊ ထိပ်ဆုံးငါးခုကိုကြည့်ရအောင်။

ယခု Get blocks ကိုလုပ်ဆောင်ခြင်း၏ရလဒ်များကိုအကဲဖြတ်ကြပါစို့။

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

နောက်ဆုံးတော့၊ ပထမဆုံး get လုပ်ပြီး တင်ထားတဲ့ block ရဲ့ model ကို ကြည့်ကြရအောင်။

သတ်မှတ်ချက်များအားလုံးသည် ဤနေရာတွင် သိသာထင်ရှားပါသည်။ ခေါင်းဆောင်များ၏ ရလဒ်များ၊

9. Load စမ်းသပ်ခြင်း။

ကောင်းပြီ၊ နောက်ဆုံးတွင် ကျွန်ုပ်တို့သည် ပိုမိုသင့်လျော်သောဝန်ကို စတင်လိုက်မည်ဖြစ်သော်လည်း သင့်တွင် နှိုင်းယှဉ်စရာတစ်ခုရှိသည့်အခါ ၎င်းသည် အမြဲတမ်း ပို၍ စိတ်ဝင်စားစရာကောင်းပါသည်။ Cassandra ၏ အဓိက developer ဖြစ်သော DataStax ၏ ဝဘ်ဆိုဒ်တွင် ရှိပါသည်။ ရလဒ်များကို HBase ဗားရှင်း 0.98.6-1 အပါအဝင် NoSQL သိုလှောင်မှုအများအပြား၏ NT။ Loading ကို 40 threads၊ data size 100 bytes၊ SSD disks များဖြင့် လုပ်ဆောင်သည်။ Read-Modify-Write လုပ်ဆောင်ချက်များကို စမ်းသပ်ခြင်း၏ရလဒ်သည် အောက်ပါရလဒ်များကို ပြသခဲ့သည်။

ကျွန်ုပ်နားလည်သလောက်၊ စာဖတ်ခြင်းကို 100 မှတ်တမ်းတုံးများနှင့် HBase node 16 ခုအတွက် DataStax စမ်းသပ်မှုသည် တစ်စက္ကန့်လျှင် 10 လုပ်ဆောင်ချက်ကို ပြသခဲ့သည်။

ကျွန်ုပ်တို့၏အစုအဝေးတွင် node 16 ခုလည်းရှိသည့်အတွက်ကံကောင်းသော်လည်း DataStax စမ်းသပ်မှုတွင် 64 ခုသာရှိသော်လည်း၊ ၎င်းတို့တွင် SSD drive များရှိပြီး၊ ကျွန်ုပ်တို့တွင် HDD များရှိနေသော်လည်း၊ ၎င်းတို့တွင် SSD drive များပါရှိသည်။ သို့မဟုတ် ၎င်းထက်ပိုသော ဗားရှင်းအသစ်သည် ဝန်ချနေစဉ်အတွင်း HBase နှင့် CPU အသုံးချမှု သိသိသာသာ တိုးမလာပါ (အမြင်အားဖြင့် 4-5 ရာခိုင်နှုန်း)။ သို့သော်၊ ဤဖွဲ့စည်းပုံကို စတင်အသုံးပြုရန် ကြိုးစားကြပါစို့။ ပုံသေ ဇယားဆက်တင်များ၊ စာဖတ်ခြင်းကို သော့အကွာအဝေး 10 မှ 0 သန်းအထိ ကျပန်းလုပ်ဆောင်သည် (ဆိုလိုသည်မှာ အချိန်တိုင်းတွင် မရှိမဖြစ်လိုအပ်သည်)။ ဇယားတွင် မှတ်တမ်းပေါင်း သန်း ၅၀ ပါ၀င်ပြီး အပိုင်း ၆၄ ခု ခွဲထားသည်။ သော့များကို crc50 ကို အသုံးပြု၍ ဖျက်ထားသည်။ ဇယားဆက်တင်များသည် မူရင်းဖြစ်သည်၊ MSLAB ကို ဖွင့်ထားသည်။ စာတွဲ 50 ကို စတင်လိုက်ခြင်းဖြင့် စာတွဲတစ်ခုစီသည် ကျပန်းသော့ 64 ခုကို ဖတ်ပြီး ထုတ်လုပ်လိုက်သော 32 bytes များကို ဤသော့များထံ ချက်ချင်းပြန်ရေးပေးသည်။

Stand- 16 DataNode နှင့် 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads)။ HBase ဗားရှင်း 1.2.0-cdh5.14.2။

ပျမ်းမျှရလဒ်သည် DataStax စမ်းသပ်မှုထက် သိသိသာသာ ကောင်းမွန်သော တစ်စက္ကန့်လျှင် လုပ်ဆောင်ချက် 40 နှင့် နီးစပ်ပါသည်။ သို့သော်၊ စမ်းသပ်မှုရည်ရွယ်ချက်အတွက် သင်သည် အခြေအနေများကို အနည်းငယ်ပြောင်းလဲနိုင်သည်။ အလုပ်အားလုံးကို စားပွဲတစ်ခုတည်းတွင်သာမက ထူးခြားသောသော့များဖြင့်သာ လုပ်ဆောင်နိုင်မည်မဟုတ်ပေ။ ပင်မဝန်ကိုထုတ်ပေးသည့် "ပူ"သော့အချို့ရှိနေသည်ဟု ယူဆကြပါစို့။ ထို့ကြောင့်၊ ပိုကြီးသောမှတ်တမ်းများ (10 KB) ဖြင့် 100 အတွဲလိုက်၊ မတူညီသောဇယား 4 ခုတွင် နှင့် တောင်းဆိုထားသောသော့များ၏အကွာအဝေးကို 50 အထိ ကန့်သတ်ဖန်တီးလိုက်ကြပါစို့။ အောက်တွင်ဖော်ပြထားသောဂရပ်သည် စာတွဲ 40 ၏စတင်ခြင်းကိုပြသသည်၊ စာတွဲတစ်ခုစီသည်ဖတ်သည် သော့ 100 အစုံရှိပြီး ဤသော့များပေါ်တွင် ကျပန်း 10 KB ကို ချက်ချင်းရေးပါ။

Stand- 16 DataNode နှင့် 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads)။ HBase ဗားရှင်း 1.2.0-cdh5.14.2။

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

စာဖတ်ခြင်းနှင့်ချက်ချင်းရေးသားခြင်းသည် HBase အတွက်အခက်ခဲဆုံးအလုပ်အခြေအနေများထဲမှတစ်ခုဖြစ်သည်။ အကယ်၍ သင်သည် သေးငယ်သော ထည့်သွင်းတောင်းဆိုမှုများသာ ပြုလုပ်ခဲ့သည်၊ ဥပမာအားဖြင့် 100 bytes၊ ၎င်းတို့ကို 10-50 အပိုင်းပိုင်းများအဖြစ် ပေါင်းစပ်ပါက၊ သင်သည် တစ်စက္ကန့်လျှင် လုပ်ဆောင်ချက်ပေါင်း ရာနှင့်ချီရနိုင်ပြီး၊ အခြေအနေသည် ဖတ်ရှုရန်သာ တောင်းဆိုမှုများနှင့် ဆင်တူပါသည်။ 50 blocks မှ တောင်းဆိုမှုများကြောင့် DataStax မှရရှိသော ရလဒ်များထက် များစွာသာလွန်ကောင်းမွန်ကြောင်း သတိပြုသင့်ပါသည်။

Stand- 16 DataNode နှင့် 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads)။ HBase ဗားရှင်း 1.2.0-cdh5.14.2။

၈

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

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

source: www.habr.com