ClickHouse ကို ထိရောက်စွာအသုံးပြုခြင်း။ Alexey Milovidov (Yandex)

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

အားလုံးမင်္ဂလာပါ! ကျွန်တော့်နာမည် Alexey ပါ၊ ClickHouse ပါ။

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

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

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

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

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

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

ပုံမှန်စွမ်းဆောင်ရည်က ဘယ်လိုရှိမလဲဆိုတာ ကြည့်လိုက်ရအောင်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် Yandex.Metrica ဒေတာမှ ဇယားတစ်ခုရှိသည်။ hits။ 105 ကော်လံအချို့။ 700 bytes ကို ချုံ့မထားပါ။ ကျွန်ုပ်တို့သည် အတန်းတစ်သန်း၏ အစီအစဥ်များတွင် နည်းလမ်းကောင်းဖြင့် ထည့်သွင်းပါမည်။

ကျွန်ုပ်တို့သည် MergeTree ကို ဇယားထဲသို့ထည့်လိုက်သည်၊ ၎င်းသည် တစ်စက္ကန့်လျှင် အတန်းတစ်သန်းခွဲထွက်သည်။ မိုက်တယ်။ ပုံတူဇယားတစ်ခုတွင် ၎င်းသည် တစ်စက္ကန့်လျှင် အတန်း 400 ခန့် အနည်းငယ်သေးငယ်မည်ဖြစ်သည်။

အကယ်၍ သင်သည် quorum ထည့်သွင်းမှုကို ဖွင့်ပါက၊ သင်သည် အနည်းငယ်နည်းသော်လည်း သင့်တင့်လျောက်ပတ်သော စွမ်းဆောင်ရည်ရှိနေဆဲဖြစ်ပြီး၊ တစ်စက္ကန့်လျှင် ဝေါဟာရ 250 ရရှိမည်ဖြစ်သည်။ Quorum ထည့်သွင်းခြင်းသည် ClickHouse* တွင် စာရွက်စာတမ်းမရှိသော အင်္ဂါရပ်တစ်ခုဖြစ်သည်။

* 2020 ခုနှစ်အထိ၊ မှတ်တမ်းတင်ထားပြီးသား.

မကောင်းတာလုပ်ရင် ဘာဖြစ်မလဲ။ ကျွန်ုပ်တို့သည် MergeTree ဇယားတွင် အတန်းတစ်တန်းကို ထည့်သွင်းပြီး တစ်စက္ကန့်လျှင် အတန်း 59 တန်းရရှိမည်ဖြစ်သည်။ အဲဒါက အဆ 10 ပိုနှေးတယ်။ ReplicatedMergeTree တွင် - တစ်စက္ကန့်လျှင် 000 တန်း။ အကယ်၍ quorum ကိုဖွင့်ပါက၊ တစ်စက္ကန့်လျှင် 6 လိုင်းထွက်သည်။ ကျွန်တော့်အမြင်အရတော့ ဒါက လုံးဝအမိုက်စားပါပဲ။ ဒီလိုမျိုး နှေးကွေးအောင် ဘယ်လိုလုပ်ရမလဲ။ ClickHouse နှေးကွေးမနေသင့်ဘူးဆိုတဲ့ တီရှပ်ပေါ်မှာတောင် ရေးထားတယ်။ သို့သော် တစ်ခါတစ်ရံတွင် ဖြစ်တတ်ပါသည်။

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

နည်းပညာဆိုင်ရာရှုထောင့်မှကြည့်လျှင် အချက်မှာ ClickHouse တွင် ထည့်သွင်းသည့်အခါ ဒေတာသည် မည်သည့် memtable တွင်မှ အဆုံးမရှိပေ။ ကျွန်ုပ်တို့တွင် MergeTree အစစ်အမှန် မှတ်တမ်းဖွဲ့စည်းပုံပင် မရှိသော်လည်း MergeTree တစ်ခုမျှသာ ဖြစ်သောကြောင့်၊ မှတ်တမ်းတစ်ခု သို့မဟုတ် memTable မရှိပါ။ ကျွန်ုပ်တို့သည် ကော်လံများတွင် စီစဉ်ပြီးသော ဖိုင်စနစ်သို့ ဒေတာများကို ချက်ချင်းရေးပါ။ အကယ်၍ သင့်တွင် ကော်လံ 100 ရှိပါက၊ ဖိုင် 200 ကျော်ကို သီးခြား directory တစ်ခုသို့ ရေးသားရန် လိုအပ်မည်ဖြစ်ပါသည်။ ဤအရာအားလုံးသည် အလွန်ခက်ခဲသည်။

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

Method 1. ဒါက အလွယ်ဆုံးနည်းလမ်းပါ။ ဖြန့်ဝေထားသော တန်းစီခြင်းကို အသုံးပြုပါ။ ဥပမာအားဖြင့် Kafka။ သင်သည် Kafka မှဒေတာကိုရိုးရှင်းစွာထုတ်ယူပြီးတစ်စက္ကန့်လျှင်တစ်ကြိမ်ပြုလုပ်သည်။ ပြီးတော့ အရာအားလုံး အဆင်ပြေသွားမှာပါ၊ မင်း မှတ်တမ်းတင်ပါ၊ အရာအားလုံး အဆင်ပြေမှာပါ။

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

Method 2. ဤသည်ကျောင်းမှအခြားရွေးချယ်စရာဖြစ်ပြီးတစ်ချိန်တည်းမှာအလွန်ရိုးရှင်းပါသည်။ သင့်တွင် သင့်မှတ်တမ်းများကိုထုတ်ပေးသည့် ဆာဗာမျိုးရှိပါသလား။ ၎င်းသည် သင်၏မှတ်တမ်းများကို ဖိုင်တစ်ခုသို့ ရေးပေးသည်။ ဥပမာအားဖြင့်၊ တစ်စက္ကန့်လျှင် တစ်ကြိမ်၊ ဤဖိုင်ကို အမည်ပြောင်းပြီး အသစ်တစ်ခုကို ဖြတ်လိုက်ပါ။ cron သို့မဟုတ် အချို့ daemon မှတစ်ဆင့် သီးခြား script တစ်ခုသည် ရှေးအကျဆုံးဖိုင်ကိုယူ၍ ClickHouse သို့ရေးသားသည်။ မှတ်တမ်းတွေကို တစ်စက္ကန့်မှာ တစ်ကြိမ် မှတ်တမ်းတင်ရင် အားလုံး အဆင်ပြေသွားမှာပါ။

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

နည်းလမ်း 3။ ယာယီဖိုင်များ လုံးဝမလိုအပ်သော အခြားစိတ်ဝင်စားဖွယ်နည်းလမ်းတစ်ခုရှိပါသည်။ ဥပမာအားဖြင့်၊ သင့်တွင် ဒေတာကိုထုတ်ပေးသည့် ကြော်ငြာ spinner သို့မဟုတ် အခြားစိတ်ဝင်စားဖွယ်ရာ daemon အချို့ရှိသည်။ ပြီးတော့ RAM ထဲမှာ၊ ကြားခံထဲမှာ ဒေတာအမြောက်အများကို စုဆောင်းနိုင်ပါတယ်။ အချိန်အလုံအလောက်ကုန်သွားသောအခါ၊ သင်သည် ဤကြားခံကိုဘေးဖယ်ထားကာ အသစ်တစ်ခုဖန်တီးကာ သီးခြားစာတွဲတစ်ခုတွင် စုဆောင်းထားပြီးဖြစ်သည့်အရာကို ClickHouse ထဲသို့ထည့်ပါ။

အခြားတစ်ဖက်တွင်၊ ဒေတာသည် kill -9 နှင့်အတူပျောက်ကွယ်သွားသည်။ သင့်ဆာဗာ ပျက်သွားပါက ဤဒေတာ ဆုံးရှုံးသွားပါမည်။ နောက်ပြဿနာတစ်ခုကတော့ Database မှာ စာမရေးနိုင်ရင် RAM ထဲမှာ Data တွေစုပုံလာမယ်။ RAM က ကုန်သွားလိမ့်မယ် ဒါမှမဟုတ် ဒေတာတွေ ဆုံးရှုံးသွားလိမ့်မယ်။

Method 4. နောက်ထပ်စိတ်ဝင်စားစရာကောင်းတဲ့နည်းလမ်း။ သင့်တွင် ဆာဗာ လုပ်ငန်းစဉ်မျိုး ရှိပါသလား။ ၎င်းသည် ClickHouse သို့ချက်ချင်းဒေတာပေးပို့နိုင်သော်လည်း၎င်းကိုချိတ်ဆက်မှုတစ်ခုတည်းဖြင့်ပြုလုပ်ပါ။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် လွှဲပြောင်း-ကုဒ်နံပါတ်ဖြင့် http တောင်းဆိုချက်ကို ပေးပို့ခဲ့သည်- ထည့်သွင်းမှုဖြင့် အပိုင်းပိုင်းထားသည်။ ၎င်းသည် အပိုင်းများကို ရှားပါးလွန်းသည်မဟုတ်ပါ၊ ဤဒေတာကို ဘောင်သွင်းရန်အတွက် ထိပ်တွင်ရှိနေသော်လည်း စာကြောင်းတစ်ခုစီကို သင်ပေးပို့နိုင်ပါသည်။

သို့သော်၊ ဤကိစ္စတွင်၊ ဒေတာကို ClickHouse သို့ချက်ချင်းပေးပို့လိမ့်မည်။ ပြီးလျှင် ClickHouse သည် ၎င်းတို့ကိုယ်တိုင် ကြားခံပေးလိမ့်မည်။

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

Method 5. ဒါကလည်း စိတ်ဝင်စားစရာကောင်းတဲ့ နည်းလမ်းတစ်ခုပါ။ ၎င်းသည် data batch အတွက် community-developed server တစ်မျိုးဖြစ်သည်။ ကျွန်တော် ကိုယ်တိုင် မကြည့်ရသေးတဲ့အတွက် ဘာမှ အာမမခံနိုင်ပါဘူး။ သို့သော် ClickHouse ကိုယ်တိုင်အတွက် အာမခံချက်ပေးမထားပါ။ ၎င်းသည် open source လည်းဖြစ်သည်၊ သို့သော် အခြားတစ်ဖက်တွင်၊ သင်သည် ကျွန်ုပ်တို့ပေးဆောင်ရန်ကြိုးစားသော အရည်အသွေးစံနှုန်းအချို့ကို အသုံးပြုနိုင်သည်။ ဤအရာအတွက် - ငါမသိပါ၊ GitHub သို့သွားပါ၊ ကုဒ်ကိုကြည့်ပါ။ သာမာန် တစ်ခုခု ရေးဖြစ်နိုင်တယ်။

* 2020 တွင် ထည့်သွင်းစဉ်းစားသင့်သည်။ KittenHouse.

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

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

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

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

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

* 2020 တွင် အလားတူ ပံ့ပိုးမှု ပေါ်လာပါသည်။ ယုန် MQ.

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

* လောလောဆယ်တွင်၊ ပြဿနာကို လုံးလုံးဖြေရှင်းပြီးဖြစ်သည်၊ VALUES တွင် ဖော်ပြချက်များကို အသုံးပြုသည့်အခါ စွမ်းဆောင်ရည်ဆုတ်ယုတ်မှုမရှိတော့ပါ။

နောက်ဥပမာတစ်ခုကတော့ partitions အစုအစည်းတစ်ခုပိုင်တဲ့ batch တစ်ခုမှာ data တွေရတဲ့အခါ ပြဿနာအချို့ရှိလာနိုင်ပါတယ်။ ပုံမှန်အားဖြင့်၊ ClickHouse အခန်းကန့်များသည် လအလိုက်ဖြစ်သည်။ အကယ်၍ သင်သည် အတန်းတစ်သန်း၏အသုတ်ကို ထည့်သွင်းပြီး နှစ်အတော်ကြာ ဒေတာရှိနေပါက၊ ထို့နောက် သင့်တွင် အခန်းကန့်ပေါင်း ဒါဇင်များစွာရှိမည်ဖြစ်သည်။ ၎င်းသည် အတွင်းဘက်တွင် အမြဲတမ်း ပထမပိုင်းများကို ပိုင်းခြားထားသောကြောင့် အဆများစွာ သေးငယ်သော အတွဲများ ရှိလိမ့်မည်ဟူသောအချက်နှင့် ညီမျှသည်။

* မကြာသေးမီက၊ စမ်းသပ်မှုမုဒ်တွင်၊ ClickHouse သည် ပြဿနာကို လုံးဝဖြေရှင်းနိုင်လုနီးပါးဖြစ်သော write-ahead log ဖြင့် RAM ရှိ အတုံးအခဲများနှင့် အတုံးများပုံစံများအတွက် ပံ့ပိုးမှုထပ်ဖြည့်ထားသည်။

အခု ပြဿနာရဲ့ ဒုတိယအမျိုးအစားဖြစ်တဲ့ data typing ကို ကြည့်ရအောင်။

ဒေတာစာရိုက်ခြင်းသည် တင်းကျပ်သော သို့မဟုတ် စာတန်းဖြစ်နိုင်သည်။ String သည် ၎င်းကိုယူကာ သင်၏အကွက်များအားလုံးသည် အမျိုးအစား string ဖြစ်ကြောင်းကြေငြာသောအခါဖြစ်သည်။ ဒီလိုကစားကြတယ်။ ဒီလိုလုပ်ဖို့ မလိုဘူး။

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

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် IP လိပ်စာတစ်ခုရှိသည်။ ကိစ္စတစ်ခုတွင်၊ ကျွန်ုပ်တို့ ၎င်းကို ကြိုးတစ်ချောင်းအဖြစ် သိမ်းဆည်းထားသည်။ ဥပမာ၊ 192.168.1.1။ အခြားအခြေအနေတွင်၊ ၎င်းသည် UInt32* အမျိုးအစားများစွာဖြစ်လိမ့်မည်။ 32 bits သည် IPv4 လိပ်စာတစ်ခုအတွက် လုံလောက်သည်။

ပထမဦးစွာ ထူးဆန်းသည်မှာ၊ ဒေတာများကို အနီးစပ်ဆုံး တူညီစွာ ချုံ့သွားပါမည်။ ခြားနားချက်တစ်ခုရှိလိမ့်မည်၊ သို့သော်ထိုမျှလောက်မကြီးပါ။ ထို့ကြောင့် disk I/O တွင် အထူးပြဿနာမရှိပါ။

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

၎င်းတို့ကို နံပါတ်များအဖြစ် သိမ်းဆည်းထားပါက ထူးခြားသော IP လိပ်စာများ၏ အရေအတွက်ကို ရေတွက်ကြည့်ကြပါစို့။ ၎င်းသည် တစ်စက္ကန့်လျှင် လိုင်း ၁၃၇ သန်းအထိ အလုပ်လုပ်သည်။ အကယ်၍ မျဉ်းကြောင်းများ တူညီပါက တစ်စက္ကန့်လျှင် လိုင်း ၃၇ သန်း ရှိသည်။ ဒီတိုက်ဆိုင်မှုက ဘာကြောင့်ဖြစ်တာလဲတော့ မသိဘူး။ ဒီတောင်းဆိုချက်တွေကို ငါကိုယ်တိုင်လုပ်တယ်။ ဒါပေမယ့် ၄ ဆလောက် နှေးနေပါသေးတယ်။

အကယ်၍ သင်သည် disk space ခြားနားချက်ကို တွက်ချက်ပါက ခြားနားချက်လည်း ရှိပါသည်။ ထူးခြားသော IP လိပ်စာများစွာရှိသောကြောင့် ကွာခြားချက်မှာ လေးပုံတစ်ပုံခန့်ဖြစ်သည်။ အဓိပ္ပါယ်အမျိုးမျိုးရှိသည့် မျဉ်းကြောင်းများပါရှိလျှင် အဘိဓာန်အရ ၎င်းတို့ကို ခန့်မှန်းခြေအားဖြင့် တူညီသော volume အဖြစ် အလွယ်တကူ ချုံ့နိုင်မည်ဖြစ်သည်။

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

မတူညီတဲ့ ကိစ္စတွေကို ကြည့်ရအောင်။

1. သင့်တွင် မတူညီသော ထူးခြားသောတန်ဖိုးများ အနည်းငယ်ရှိသောအခါ ကိစ္စတစ်ခု။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် မည်သည့် DBMS အတွက်မဆို သင်သိနိုင်ပြီး အသုံးပြုနိုင်သည့် ရိုးရှင်းသော အလေ့အကျင့်ကို ကျွန်ုပ်တို့ အသုံးပြုပါသည်။ ဤအရာအားလုံးသည် ClickHouse အတွက်သာမက အဓိပ္ပါယ်ရှိသည်။ ဒေတာဘေ့စ်တွင် ကိန်းဂဏာန်းအချက်အလတ်များကို ရေးပါ။ ထို့အပြင် သင်သည် ကြိုးတန်းများအဖြစ်သို့ ပြောင်းနိုင်ပြီး သင့်အပလီကေးရှင်း၏ ဘေးဘက်တွင် ပြန်နိုင်သည်။

ဥပမာ သင့်တွင် ဒေသတစ်ခုရှိသည်။ ပြီးတော့ ကြိုးတစ်ချောင်းအနေနဲ့ သိမ်းဖို့ သင်ကြိုးစားနေတယ်။ ၎င်းကို မော်စကိုနှင့် မော်စကိုဒေသတို့၌ ရေးသားမည်ဖြစ်သည်။ "မော်စကို" ဟုပြောသည်ကိုမြင်သောအခါ၊ ၎င်းသည်ဘာမှမရှိသော်လည်း၊ မော်စကိုရောက်သောအခါ၊ တစ်နည်းနည်းဖြင့်လုံးဝဝမ်းနည်းစရာဖြစ်လာသည်။ ဒါက ဘိုက်ဘယ်လောက်လဲ။

ယင်းအစား၊ ကျွန်ုပ်တို့သည် Ulnt32 နှင့် 250 နံပါတ်ကို ရိုးရိုးရှင်းရှင်း ရေးမှတ်ထားသည်။ ကျွန်ုပ်တို့တွင် Yandex တွင် 250 ရှိသည်၊ သို့သော် သင့်တွင် ကွဲပြားနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ ClickHouse သည် geobase နှင့်အလုပ်လုပ်ရန် built-in စွမ်းရည်ရှိသည်ဟုငါပြောလိမ့်မည်။ မော်စကို၊ မော်စကိုဒေသ နှင့် သင်လိုအပ်သမျှအရာအားလုံး ပါ၀င်မည့် အထက်တန်းပုံတစ်ခုအပါအဝင် ဒေသများပါရှိသော လမ်းညွှန်တစ်ခုကို သင်ရိုးရှင်းစွာရေးပါ။ တောင်းဆိုမှုအဆင့်တွင်သင် convert နိုင်သည်။

ဒုတိယရွေးချယ်မှုမှာ ခန့်မှန်းခြေအားဖြင့် တူညီသော်လည်း ClickHouse အတွင်းရှိ ပံ့ပိုးမှုဖြင့်။ ၎င်းသည် Enum ဒေတာအမျိုးအစားဖြစ်သည်။ သင် Enum တွင် သင်လိုအပ်သော တန်ဖိုးများအားလုံးကို ရိုးရှင်းစွာရေးပါ။ ဥပမာအားဖြင့်၊ စက်ပစ္စည်းအမျိုးအစားနှင့် စားပွဲတင်၊ မိုဘိုင်း၊ တက်ဘလက်၊ တီဗီ။ စုစုပေါင်းရွေးချယ်စရာ 4 ခုရှိသည်။

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

* ClickHouse ၏နောက်ဆုံးထွက်ဗားရှင်းများတွင် ALTER ကို လုံးဝပိတ်ဆို့ခြင်းမပြုပါ။

ClickHouse အတွက် အလွန်ထူးခြားသော နောက်ထပ်ရွေးချယ်စရာတစ်ခုမှာ ပြင်ပအဘိဓာန်များကို ချိတ်ဆက်ခြင်းပင်ဖြစ်သည်။ သင်သည် ClickHouse တွင် နံပါတ်များရေးနိုင်ပြီး သင့်အတွက် အဆင်ပြေသည့် မည်သည့်စနစ်တွင်မဆို သင့်လမ်းညွှန်များကို သိမ်းဆည်းနိုင်သည်။ ဥပမာအားဖြင့်၊ သင်သည် MySQL၊ Mongo၊ Postgres ကိုသုံးနိုင်သည်။ http မှတစ်ဆင့် ဤဒေတာကို ပေးပို့မည့် သင်၏ကိုယ်ပိုင် microservice ကိုပင် ဖန်တီးနိုင်သည်။ ClickHouse အဆင့်တွင် သင်သည် ဤဒေတာကို နံပါတ်များမှ စာကြောင်းများအဖြစ်သို့ ပြောင်းလဲပေးမည့် လုပ်ဆောင်ချက်တစ်ခုကို ရေးပါ။

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

ဒါက ဥပမာတစ်ခုပါ။ Yandex.Direct ရှိပါတယ်။ ကြော်ငြာကုမ္ပဏီတစ်ခုနှင့် နဖူးစည်းများရှိသည်။ ကြော်ငြာကုမ္ပဏီပေါင်း သန်းဆယ်ဂဏန်းလောက်ရှိမယ်ထင်တယ်။ ၎င်းတို့သည် RAM တွင်အကြမ်းဖျင်းအားဖြင့်ကိုက်ညီသည်။ ဘီလီယံချီတဲ့ နဖူးစည်းတွေရှိတယ်၊ အဲဒါတွေက အဆင်မပြေဘူး။ ကျွန်ုပ်တို့သည် MySQL မှ သိမ်းဆည်းထားသော အဘိဓာန်ကို အသုံးပြုပါသည်။

တစ်ခုတည်းသောပြဿနာမှာ ကက်ရှ်အဘိဓာန်သည် 100% နီးနီးဖြစ်လျှင် hit rate သည် ကောင်းမွန်ပါသည်။ ၎င်းသည် သေးငယ်ပါက၊ data batch တစ်ခုစီအတွက် queries များကို လုပ်ဆောင်သောအခါ၊ သင်သည် အမှန်တကယ်တွင် ပျောက်ဆုံးနေသောသော့များကိုယူ၍ MySQL မှဒေတာကို ရယူရမည်ဖြစ်သည်။ ClickHouse အကြောင်း၊ ကျွန်ုပ်အာမခံနိုင်ဆဲဖြစ်သည် - ဟုတ်ကဲ့၊ နှေးကွေးမည်မဟုတ်ပါ၊ အခြားစနစ်များအကြောင်း ကျွန်ုပ်ပြောမည်မဟုတ်ပါ။

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

သင့်စာကြောင်းများအတွက် identifiers များကို မည်သည့်နေရာတွင် ရယူရမည်ကို မသိသည့်အခါ နောက်တစ်နည်း။ ရိုးရှင်းစွာ hash နိုင်သည်။ ထို့အပြင်၊ အရိုးရှင်းဆုံးရွေးချယ်မှုသည် 64-bit hash ကိုယူရန်ဖြစ်သည်။

တစ်ခုတည်းသောပြဿနာမှာ hash သည် 64-bit ဖြစ်ပါက၊ သင်သည် collision များသေချာပေါက်နီးပါးဖြစ်လိမ့်မည်။ အဘယ်ကြောင့်ဆိုသော် ထိုနေရာတွင် လိုင်းတစ်ဘီလီယံရှိနေပါက ဖြစ်နိုင်ခြေသည် သိသာထင်ရှားနေပြီဖြစ်သည်။

ကြော်ငြာကုမ္ပဏီများ၏အမည်များကို ဤနည်းဖြင့် ဖျက်ခြင်းသည် အလွန်ကောင်းမည်မဟုတ်ပေ။ မတူကွဲပြားသော ကုမ္ပဏီများ၏ ကြော်ငြာကမ်ပိန်းများ ရောထွေးနေပါက၊ နားမလည်နိုင်သော အရာတစ်ခု ဖြစ်လာလိမ့်မည်။

ရိုးရှင်းတဲ့လှည့်ကွက်တစ်ခုရှိပါတယ်။ မှန်ပါသည်၊ ၎င်းသည် လေးနက်သောဒေတာအတွက်လည်း မသင့်လျော်သော်လည်း တစ်စုံတစ်ရာသည် အလွန်လေးနက်ခြင်းမရှိပါက၊ client identifier ကို အဘိဓာန်ကီးထဲသို့ ထည့်လိုက်ရုံပါပဲ။ ထို့နောက် သင့်တွင် တိုက်မိမှုများ ရှိလိမ့်မည်၊ သို့သော် client တစ်ခုအတွင်းသာ ဖြစ်သည်။ Yandex.Metrica ရှိ လင့်ခ်မြေပုံများအတွက် ဤနည်းလမ်းကို ကျွန်ုပ်တို့ အသုံးပြုပါသည်။ ကျွန်ုပ်တို့တွင် URL များရှိပြီး၊ hash များကို သိမ်းဆည်းပါသည်။ ပြီးတော့ တိုက်မိတာတွေလည်း ရှိတယ်ဆိုတာ ကျွန်တော်တို့ သိပါတယ်။ သို့သော် စာမျက်နှာကိုပြသသည့်အခါ၊ သုံးစွဲသူတစ်ဦး၏ စာမျက်နှာတစ်ခုတွင် အချို့သော URL များသည် အတူတကွ ကပ်နေပြီး ယင်းကို လျစ်လျူရှုထားနိုင်သည်ကို သတိပြုမိမည်ဖြစ်သည်။

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

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

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

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

အကယ်၍ ဒေတာကို နေရာတွင် သိမ်းဆည်းထားပါက ၎င်းကို ဖိုင်စနစ်မှ လိုအပ်သော အစီအစဥ်အတိုင်း ဖတ်ရှုနိုင်ပြီး အရာအားလုံး အဆင်ပြေပါသည်။

သင့်တွင် URL များ သို့မဟုတ် အခြားရှုပ်ထွေးသော ရှည်လျားသောစာကြောင်းအချို့ရှိပါက၊ ထုတ်ယူမှုအချို့ကို ကြိုတင်တွက်ချက်ပြီး သီးခြားကော်လံတစ်ခုတွင် ရေးနိုင်သည်ကို ထည့်သွင်းစဉ်းစားသင့်သည်။

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

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

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

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

ဒစ်ခ်ပေါ်ရှိ ဒေတာပမာဏကိုကြည့်လျှင် URL သည် 126 megabytes ဖြစ်ပြီး domain သည် 5 megabytes သာရှိသည်။ 25 ဆပိုနည်းတယ်။ မည်သို့ပင်ဆိုစေကာမူ၊ တောင်းဆိုမှုသည် ၄ ​​ဆပိုမိုမြန်ဆန်သည်။ ဒါ​ပေမယ့်​ Data က ပူ​နေလို့ပါ။ အေးနေပါက၊ disk I/O ကြောင့် 4 ဆ ပိုမြန်နိုင်သည် ။

စကားမစပ်၊ ဒိုမိန်းတစ်ခုသည် URL တစ်ခုထက်မည်မျှသေးငယ်သည်ကို ခန့်မှန်းပါက၊ ၎င်းသည် 4 ဆခန့် သေးငယ်သွားပါသည်။ သို့သော် အကြောင်းအမျိုးမျိုးကြောင့် ဒေတာသည် ဒစ်ခ်ပေါ်တွင် 25 ဆ ပိုနည်းပါသည်။ အဘယ်ကြောင့်? နှိမ်ခြင်းကြောင့်။ URL ကို ချုံ့ထားပြီး၊ ဒိုမိန်းကို ချုံ့ထားသည်။ သို့သော် မကြာခဏ URL တွင် အမှိုက်များစွာပါရှိသည်။

အမှန်တော့၊ လိုချင်သောတန်ဖိုးများ သို့မဟုတ် သင့်လျော်သော အထူးပြုလုပ်ထားသော မှန်ကန်သောဒေတာအမျိုးအစားများကို အသုံးပြုရန် ပေးဆောင်ရမည်ဖြစ်ပါသည်။ IPv4 တွင်ရှိနေပါက UInt32* ကို သိမ်းဆည်းပါ။ IPv6 ဖြစ်ပါက FixedString(16) သည် IPv6 လိပ်စာသည် 128 bits ဖြစ်သောကြောင့်၊ ဆိုလိုသည်မှာ binary ဖော်မတ်ဖြင့် တိုက်ရိုက်သိမ်းဆည်းထားသည်။

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

* ယခု ClickHouse တွင် သီးခြား IPv4၊ IPv6 ဒေတာအမျိုးအစားများ ကိန်းဂဏန်းများကဲ့သို့ ထိရောက်စွာ သိမ်းဆည်းထားသော်လည်း ၎င်းတို့ကို စာကြောင်းများကဲ့သို့ အဆင်ပြေစွာ ကိုယ်စားပြုပါသည်။

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

ဥပမာ၊ browser ဗားရှင်း။ လက်ညိုးထိုးမပြချင်သော အနီးနားဌာနအချို့တွင်၊ ဘရောက်ဆာဗားရှင်းကို ဤကဲ့သို့ သိမ်းဆည်းထားသည်၊ ဆိုလိုသည်မှာ စာကြောင်း- 12.3 ဖြစ်သည်။ ထို့နောက် အစီရင်ခံစာတစ်ခုပြုလုပ်ရန်၊ ၎င်းတို့သည် ဤစာကြောင်းကိုယူ၍ ၎င်းကို ခင်းကျင်းတစ်ခုအဖြစ် ပိုင်းခြားကာ array ၏ပထမဒြပ်စင်သို့ ရောက်ရှိလာသည်။ ထုံးစံအတိုင်း အရာအားလုံး နှေးကွေးသွားသည် ။ ဘာလို့ဒီလိုလုပ်တာလဲလို့မေးတယ်။ အချိန်မတန်မီ ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ခြင်းကို မကြိုက်ကြောင်း သူတို့က ကျွန်ုပ်ကို ပြောခဲ့သည်။ ပြီးတော့ အချိန်မတန်ခင် အဆိုးမြင်တာကို မကြိုက်ဘူး။

ထို့ကြောင့် ဤကိစ္စတွင် ကော်လံ 4 ခု ခွဲခြင်းသည် ပိုမှန်လိမ့်မည်။ ဤနေရာတွင် ClickHouse ဖြစ်သောကြောင့် မကြောက်ပါနှင့်။ ClickHouse သည် columnar database တစ်ခုဖြစ်သည်။ ကော်လံလေးတွေ ပိုသပ်ရပ်လေလေ ပိုကောင်းလေပါပဲ။ BrowserVersion 5 ခုရှိမည်ဖြစ်ပြီး ကော်လံ 5 ခုလုပ်ပါ။ ဒါကအဆင်ပြေပါတယ်။

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

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

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

* ယခု ClickHouse တွင် ဒေတာအမျိုးအစားတစ်ခုရှိသည်။ ကာဒီနယ်နည်း အားစိုက်ထုတ်မှုနည်း၍ ကြိုးများကို ထိထိရောက်ရောက် သိမ်းဆည်းနိုင်စေပါသည်။

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

ဤတွင် ဇယားတစ်ထောင်ကိုတွေ့မြင်ရပြီး ကျန်တစ်ထောင်ကိုမည်သူသိနိုင်သည်ကို ပိုင်းခြား၍ မှတ်တမ်းတင်ထားသည်။

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

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

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

သို့မဟုတ် ဥပမာ၊ microsharding၊ ဒါပေမယ့် နောက်ပိုင်းမှာ အဲဒါကို ပိုလုပ်ပါ။

ClickHouse တွင် ၎င်းကိုလုပ်ဆောင်ရန်မလိုအပ်ပါ၊ အဘယ်ကြောင့်ဆိုသော်၊ ပထမဦးစွာ၊ အဓိကသော့ကို အစုလိုက်အပြုံလိုက် ပြုလုပ်ထားသောကြောင့် ဒေတာကို အဓိကသော့ဖြင့် စီစစ်ထားပါသည်။

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

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

ClickHouse တွင် Alter သည် ကော်လံပေါင်းထည့်/ချပေးလျှင် အခမဲ့ဖြစ်သည်။

စားပွဲအသေးလေးများ မပြုလုပ်သင့်ပါ အဘယ်ကြောင့်ဆိုသော် သင့်တွင် စားပွဲတစ်ခုတွင် အတန်း 10 တန်း သို့မဟုတ် 10 တန်းရှိပါက ၎င်းသည် အရေးမကြီးပါ။ ClickHouse သည် latency မဟုတ်ဘဲ throughput ကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ပေးသည့် စနစ်ဖြစ်သောကြောင့် လိုင်း 000 ခုကို လုပ်ဆောင်ရန် အဓိပ္ပါယ်မရှိပေ။

စားပွဲကြီးတစ်လုံးကို သုံးတာမှန်တယ်။ ပုံစံဟောင်းများကို ဖယ်ရှားလိုက်ပါ၊ အရာအားလုံး အဆင်ပြေသွားမှာပါ။

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

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

* ယခု ClickHouse လည်းရှိနေပြီဖြစ်သည်။ ဇယားလုပ်ဆောင်ချက်ထည့်သွင်းခြင်း။.

နောက်တစ်မျိုးကတော့ microsharding ဖြစ်ပါတယ်။ ဥပမာအားဖြင့်၊ သင်သည် ဒေတာကို မျှဝေရန် လိုအပ်ပြီး သင့်တွင် ဆာဗာ ၅ ခု ရှိပြီး မနက်ဖြန်တွင် ဆာဗာ ၆ ခု ရှိမည်ဖြစ်သည်။ ပြီးတော့ ဒီဒေတာကို ဘယ်လိုပြန်ချိန်ညှိရမလဲဆိုတာကို သင်စဉ်းစားပါ။ ၎င်းအစား သင်သည် 5 shards ထဲသို့မချိုးဘဲ 6 shards သို့မချိုးပါ။ ထို့နောက် သင်သည် ဤ microshards တစ်ခုစီကို သီးခြားဆာဗာတစ်ခုသို့ မြေပုံဆွဲပါ။ ဥပမာ၊ ဆာဗာတစ်ခုတွင် ClickHouse 5 ကို သင်ရလိမ့်မည်။ သီးခြားဆိပ်ကမ်းများ သို့မဟုတ် သီးခြားဒေတာဘေ့စ်များတွင် သီးခြားဖြစ်ရပ်များကို ခွဲခြားပါ။

ဒါပေမယ့် ClickHouse မှာ ဒါက သိပ်မကောင်းဘူး။ အဘယ်ကြောင့်ဆိုသော် ClickHouse instance တစ်ခုသည် တောင်းဆိုချက်တစ်ခုကို လုပ်ဆောင်ရန် ရရှိနိုင်သော ဆာဗာရင်းမြစ်အားလုံးကို အသုံးပြုရန် ကြိုးစားသောကြောင့်ဖြစ်သည်။ ဆိုလိုသည်မှာ သင့်တွင် ဆာဗာတစ်မျိုးမျိုးရှိပြီး၊ ဥပမာအားဖြင့်၊ ပရိုဆက်ဆာ 56 cores ရှိသည်။ သင်သည် တစ်စက္ကန့်ကြာသော query တစ်ခုကို လုပ်ဆောင်နေပြီး ၎င်းသည် 56 cores ကို အသုံးပြုမည်ဖြစ်သည်။ အကယ်၍ သင်သည် ဆာဗာတစ်ခုတွင် ClickHouse 200 ကို ထိုနေရာတွင် ထားရှိပါက 10 threads စတင်လိမ့်မည်ဖြစ်သည်။ ယေဘူယျအားဖြင့် အရာအားလုံးသည် အလွန်ဆိုးရွားနေပေလိမ့်မည်။

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

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

အခြား antipattern ဆိုပေမယ့်လည်း antipattern လို့ ခေါ်လို့မရပါဘူး။ ၎င်းသည် ကြိုတင်စုစည်းမှု ပမာဏများစွာဖြစ်သည်။

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

သို့သော် ကျွန်ုပ်တို့သည် ဤကဲ့သို့သောဒေတာကို စုစည်းပြီး ဤကဲ့သို့သောဒေတာကို စုစည်းမည်ဟု သင်ထင်သည့်အချိန်များရှိသည်။ အချို့သောအိမ်နီးချင်းဌာနများတွင်၊ ကျွန်ုပ်သည်လည်းမည်သည်ကိုမပြောလိုပါ၊ ၎င်းတို့သည်အဓိကသော့ဖြင့်အကျဉ်းချုပ်ရန် SummingMergeTree ဇယားများကိုအသုံးပြုပြီးကော်လံ 20 ခန့်ကိုမူလကီးအဖြစ်အသုံးပြုသည်။ အခြေအနေအရ၊ လျှို့ဝှက်ရန်အတွက် ကော်လံအချို့၏အမည်များကို ကျွန်ုပ်ပြောင်းလိုက်သော်လည်း၊ ဤသည်မှာ တော်တော်များပါသည်။

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

ပြီးတော့ အဲဒါနဲ့ပတ်သက်ပြီး ဘာထူးခြားလဲ။ တကယ်တော့ ဒီလူတွေဟာ အနီးနားဌာနက တခါတရံ သွားပြီး ပင်မသော့ထဲကို နောက်ထပ်ကော်လံတစ်ခု ထပ်ထည့်ခိုင်းတာ ဖြစ်တယ်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် ဤကဲ့သို့သောဒေတာများကို စုစည်းထားသော်လည်း ယခုအခါ အနည်းငယ်ပိုလိုပါသည်။ သို့သော် ClickHouse တွင် ပြောင်းလဲနိုင်သော အဓိကသော့တစ်ခု မရှိပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် C++ တွင် အချို့သော Script များကို ရေးရပါမည်။ C++ မှာရှိရင်တောင် Script တွေကို ကျွန်တော်မကြိုက်ဘူး။

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

နောက်ထပ်စိတ်ဝင်စားစရာကိစ္စမှာ အကန့်အသတ်မရှိသော ကွင်းဆက်ရှိ စုံစမ်းမှုများဖြစ်သည်။ တစ်ခါတရံမှာ ကျွန်တော်ဟာ ထုတ်လုပ်မှုဆာဗာကိုသွားပြီး အဲဒီ့မှာ show processlist ကို ကြည့်တယ်။ ပြီးတော့ ကြောက်စရာကောင်းတဲ့ အရာတစ်ခု ဖြစ်ပျက်နေတာကို သိလိုက်တိုင်း။

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

အဆုံးမရှိသော ကွင်းဆက်ထဲတွင် ဤကဲ့သို့သော မေးခွန်းများစွာသည် အဘယ်ကြောင့် ဆိုးရွားနေရသနည်း။ အကယ်၍ အညွှန်းတစ်ခုကို အသုံးမပြုပါက၊ တူညီသောဒေတာကို သင်ဖြတ်သန်းမှုများစွာရှိလိမ့်မည်။ အကယ်၍ အညွှန်းကိုအသုံးပြုပါက၊ ဥပမာ၊ သင့်တွင် ru အတွက် အဓိကသော့တစ်ခုရှိပြီး url = တစ်ခုခုကို ထိုနေရာတွင် ရေးပါ။ ဇယားမှ URL တစ်ခုသာဖတ်ပါက အရာအားလုံးအဆင်ပြေမည်ဟု သင်ထင်သည်။ ဒါပေမယ့် တကယ်တော့ မဟုတ်ဘူး။ အဘယ်ကြောင့်ဆိုသော် ClickHouse သည် အရာအားလုံးကို အသုတ်လိုက်လုပ်သောကြောင့်ဖြစ်သည်။

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

အပိုဆုအနေဖြင့် ClickHouse တွင် megabytes နှင့် IN section သို့ megabytes ရာပေါင်းများစွာကိုပင် လွှဲပြောင်းရန် မကြောက်သင့်ကြောင်း မှတ်သားနိုင်ပါသည်။ ကျွန်ုပ်တို့သည် MySQL တွင် တန်ဖိုးများစွာကို IN ကဏ္ဍသို့ လွှဲပြောင်းပါက ဥပမာအားဖြင့်၊ အချို့သော နံပါတ်များ၏ 100 megabytes ကို ထိုနေရာတွင် လွှဲပြောင်းပေးမည်ဆိုပါက MySQL သည် memory 10 gigabyte ကိုစားပြီး အခြားဘာမှမဖြစ်နိုင်ကြောင်း ကျွန်ုပ်တို့၏အလေ့အကျင့်မှ ကျွန်ုပ်မှတ်မိပါသည်။ ညံ့ဖျင်းစွာအလုပ်လုပ်သည်။

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

ဒါပေမယ့် အခက်အခဲတွေတော့ရှိတယ်။ ဥပမာအားဖြင့်၊ subquery တစ်ခုဖြင့် IN သည် အညွှန်းကိန်းကို အသုံးမပြုပါ။ ဒါပေမယ့် ဒါက ကျွန်တော်တို့ရဲ့ ပြဿနာဖြစ်ပြီး အဲဒါကို ပြင်ဖို့လိုတယ်။ ဒီမှာ အခြေခံ ဘာမှ မရှိပါဘူး။ ပြင်ပေးပါ့မယ်*။

နောက်စိတ်ဝင်စားစရာကောင်းတာက သင့်မှာ အလွန်ရှည်လျားတဲ့ တောင်းဆိုချက်တစ်ခုရှိပြီး ဖြန့်ဝေတောင်းဆိုမှု လုပ်ငန်းစဉ်ကို လုပ်ဆောင်နေဆဲဖြစ်ပါက၊ အလွန်ရှည်လျားတဲ့ တောင်းဆိုချက်ကို ချုံ့ခြင်းမပြုဘဲ ဆာဗာတစ်ခုစီထံ ပေးပို့ပါလိမ့်မယ်။ ဥပမာအားဖြင့်၊ 100 megabytes နှင့် 500 servers။ ထို့ကြောင့် သင်သည် ကွန်ရက်ပေါ်တွင် 50 ဂစ်ဂါဘိုက် လွှဲပြောင်းပေးမည်ဖြစ်သည်။ ၎င်းကိုကူးစက်ပြီးနောက်အရာအားလုံးအောင်မြင်စွာပြီးမြောက်လိမ့်မည်။

* သုံးနေပြီ၊ အားလုံးက ကတိအတိုင်း ပြင်ပြီးပြီ။

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

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

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

အခု နောက်ထပ် စိတ်ဝင်စားစရာတစ်ခု။ ၎င်းသည် လက်ဖြင့် ကူးယူခြင်း ဖြစ်သည်။

ClickHouse တွင် built-in ကူးယူပံ့ပိုးမှုပါရှိသော်လည်း၊ လူများသည် ClickHouse ကိုကိုယ်တိုင်ပုံတူပွားသည့်ကိစ္စများစွာကိုကျွန်ုပ်သိသည်။

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

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

တကယ်တော့၊ ClickHouse တွင်တည်ဆောက်ထားသောပုံတူကူးယူခြင်းကိုအသုံးပြုရန်ပိုမိုလွယ်ကူသည်။ သို့သော် ၎င်းအတွက် သင်သည် ZooKeeper ကို အသုံးပြုရန် လိုအပ်သောကြောင့် တားမြစ်ခြင်းအချို့ရှိနိုင်သည်။ ZooKeeper အကြောင်း မကောင်းတာ ဘာမှ မပြောပါဘူး၊ မူအရတော့ စနစ်က အလုပ်လုပ်ပါတယ်၊ ဒါပေမယ့် လူတွေက java-phobia ကြောင့် အဲဒါကို မသုံးဖြစ်တာ၊ ClickHouse က C++ နဲ့ရေးထားတဲ့ ကောင်းမွန်တဲ့ စနစ်ဖြစ်လို့ပါ၊ ဘာကြောင့်လဲဆိုတော့ သင်သုံးနိုင်တဲ့၊ အားလုံးအဆင်ပြေပါလိမ့်မယ်။ ZooKeeper သည် java တွင်ရှိသည်။ တစ်နည်းနည်းနဲ့ သင်တောင် မကြည့်ချင်ပေမယ့်၊ ထို့နောက် manual replication ကို သုံးနိုင်ပါတယ်။

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

အကယ်၍ သင်သည် primitive table engines ကိုအသုံးပြုပါက နောက်ထပ်ပြဿနာများ ဖြစ်ပေါ်လာနိုင်သည်။ ClickHouse သည် မတူညီသော စားပွဲအင်ဂျင်များ အစုအဝေးရှိသော တည်ဆောက်သူဖြစ်သည်။ စာရွက်စာတမ်းများတွင် ရေးထားသည့်အတိုင်း လေးနက်သောကိစ္စများအားလုံးအတွက်၊ MergeTree မိသားစုမှ ဇယားများကို အသုံးပြုပါ။ ကျန်တာအားလုံး - ဒါကဒါကြောင့်၊ တစ်ဦးချင်းစီကိစ္စများအတွက်သို့မဟုတ်စမ်းသပ်မှုများအတွက်။

MergeTree ဇယားတွင်၊ သင့်တွင် မည်သည့်ရက်စွဲနှင့် အချိန်ရှိရန် မလိုအပ်ပါ။ သင်အသုံးပြုနိုင်သေးသည်။ ရက်စွဲနှင့်အချိန်မရှိပါက default 2000 ဟုရေးပါ။ ၎င်းသည် အလုပ်လုပ်နိုင်ပြီး အရင်းအမြစ်များ မလိုအပ်ပါ။

ဆာဗာ၏ ဗားရှင်းအသစ်တွင်၊ partition key မပါဘဲ သင့်တွင် စိတ်ကြိုက်ခွဲဝေခြင်းကိုပင် သတ်မှတ်နိုင်သည်။ အတူတူပဲဖြစ်လိမ့်မယ်။

အခြားတစ်ဖက်တွင်၊ သင်သည် primitive table engines ကိုသုံးနိုင်သည်။ ဥပမာအားဖြင့်၊ ဒေတာကို တစ်ကြိမ်ဖြည့်ပြီး ကြည့်ရှုပါ၊ လှည့်၍ ဖျက်ပါ။ Log ကိုသုံးနိုင်သည်။

သို့မဟုတ် ကြားခံလုပ်ဆောင်ခြင်းအတွက် သေးငယ်သော volumes များကို သိမ်းဆည်းခြင်းသည် StripeLog သို့မဟုတ် TinyLog ဖြစ်သည်။

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

ClickHouse သည် ပြန်လည်ပြင်ဆင်ထားသော ဒေတာကို အမှန်တကယ် မကြိုက်ပါ။

ဒါကတော့ သာမာန် ဥပမာတစ်ခုပါ။ ဤသည်မှာ များပြားလှသော URL များဖြစ်သည်။ မင်း သူတို့ကို နောက်စားပွဲမှာ ထားလိုက်ပါ။ ထို့နောက် ၎င်းတို့နှင့် JOIN လုပ်ရန် ဆုံးဖြတ်လိုက်သော်လည်း ClickHouse သည် Hash JOIN ကိုသာ ပံ့ပိုးပေးသောကြောင့် စည်းကမ်းအတိုင်း အလုပ်မဖြစ်ပါ။ ချိတ်ဆက်ရန် လိုအပ်သော ဒေတာများစွာအတွက် RAM မလုံလောက်ပါက JOIN အလုပ်မလုပ်ပါ*။

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

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

နောက်ထပ် ဥပမာနှစ်ခု၊ ဒါပေမယ့် အဲဒါတွေက ဆန့်ကျင်ဘက်ပုံစံ ဟုတ်မဟုတ် သံသယဖြစ်နေပြီ။

ClickHouse တွင် လူသိများသော ချို့ယွင်းချက်တစ်ခုရှိသည်။ အပ်ဒိတ်လုပ်နည်းမသိပါ။ အချို့သောနည်းလမ်းများတွင်၊ ဤသည်ပင်ကောင်းသည်။ သင့်တွင် အရေးကြီးသောဒေတာအချို့ ဥပမာ၊ စာရင်းကိုင်ခြင်းရှိပါက၊ အပ်ဒိတ်များမရှိသောကြောင့် ၎င်းကို မည်သူမျှ ပေးပို့နိုင်မည်မဟုတ်ပါ။

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

သို့သော် နောက်ခံတွင်ကဲ့သို့ အပ်ဒိတ်များကို ခွင့်ပြုနိုင်သည့် အထူးနည်းလမ်းအချို့ရှိသည်။ ဥပမာ၊ ReplaceMergeTree ကဲ့သို့ ဇယားများ။ နောက်ခံပေါင်းစည်းမှုများအတွင်း ၎င်းတို့သည် အပ်ဒိတ်များပြုလုပ်သည်။ optimize table ကို အသုံးပြု၍ ၎င်းကို သင် ဖိအားပေးနိုင်သည်။ သို့သော် ၎င်းသည် partition ကို လုံးဝ overwrite လုပ်သောကြောင့် ၎င်းကို မကြာခဏ မလုပ်ပါနှင့်။

ClickHouse တွင်ဖြန့်ဝေထားသော JOIN များကို query planner မှလည်း ကိုင်တွယ်မှု ညံ့ဖျင်းပါသည်။

ဆိုးပေမယ့် တစ်ခါတလေ Ok တယ်။

Select* ကို အသုံးပြု၍ ဒေတာပြန်ဖတ်ရန် ClickHouse ကို အသုံးပြုခြင်း။

ခက်ခဲသောတွက်ချက်မှုများအတွက် ClickHouse ကိုအသုံးပြုရန် ကျွန်ုပ်အကြံပြုမည်မဟုတ်ပါ။ သို့သော် ကျွန်ုပ်တို့သည် ဤအကြံပြုချက်မှ ဝေးကွာနေပြီဖြစ်သောကြောင့် ၎င်းသည် လုံးဝမမှန်ပါ။ ကျွန်ုပ်တို့သည် ClickHouse - Catboost တွင် စက်သင်ယူမှုပုံစံများကို အသုံးချနိုင်သည့် စွမ်းရည်ကို မကြာသေးမီက ထည့်သွင်းခဲ့သည်။ “ကြောက်စရာကောင်းလိုက်တာ” လို့ တွေးလိုက်မိလို့ စိတ်အနှောင့်အယှက်ဖြစ်မိပါတယ်။ ဒါက ဘိုက်တစ်ဘိုက်မှာ အကြိမ်ဘယ်လောက် ထွက်လာတယ်။ ဘိုက်ပေါ်မှာ နာရီတွေကို ဖြုန်းတီးရတာကို ငါတကယ်မုန်းတယ်။

သို့သော် မကြောက်ပါနှင့်၊ ClickHouse ကို install လုပ်ပါ၊ အားလုံးအဆင်ပြေပါမည်။ တစ်ခုခုဆိုရင် ကျွန်တော်တို့မှာ အသိုင်းအဝိုင်းရှိတယ်။ စကားမစပ်၊ အသိုင်းအဝိုင်းက သင်ပါပဲ။ သင့်တွင် ပြဿနာတစ်စုံတစ်ရာရှိပါက အနည်းဆုံး ကျွန်ုပ်တို့၏ chat သို့သွားနိုင်ပြီး ၎င်းတို့သည် သင့်အား ကူညီလိမ့်မည်ဟု မျှော်လင့်ပါသည်။

မေးခွန်းများကို

အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ ClickHouse ပျက်ကျခြင်းနှင့် ပတ်သက်၍ မည်သည့်နေရာတွင် တိုင်ကြားနိုင်သနည်း။

သင်သည် ကျွန်ုပ်အား ကိုယ်တိုင်ကိုယ်ကျ တိုင်ကြားနိုင်ပါသည်။

မကြာသေးမီက ကျွန်ုပ်သည် ClickHouse ကို စတင်အသုံးပြုခဲ့သည်။ ငါချက်ချင်း cli interface ကိုချပစ်လိုက်တယ်။

ဘာရမှတ်လဲ။

ခဏကြာတော့ ဆာဗာကို ရွေးချယ်မှုလေးတစ်ခုနဲ့ ပျက်သွားတယ်။

မင်းမှာ အရည်အချင်းရှိတယ်။

GitHub bug ကိုဖွင့်ထားသော်လည်း လျစ်လျူရှုထားသည်။

ငါတို့တွေ့လိမ့်မယ်

Alexey သည် အစီရင်ခံစာကို တက်ရောက်ရန် လှည့်ဖြားခဲ့ပြီး အထဲမှာ ဒေတာကို သင်မည်ကဲ့သို့ ဝင်ရောက်သည်ကို ပြောပြမည်ဟု ကတိပေးခဲ့သည်။

အလွန်ရိုးရှင်းပါသည်။

ဒါကို မနေ့က သဘောပေါက်တယ်။ ပိုတိကျပါတယ်။

အဲဒီမှာ ကြောက်စရာကောင်းတဲ့ လှည့်ကွက်တွေ မရှိဘူး။ block-by-block compression ပဲရှိတယ်။ မူရင်းမှာ LZ4 ဖြစ်ပြီး၊ သင်သည် ZSTD* ကို ဖွင့်နိုင်သည်။ 64 ကီလိုဘိုက်မှ 1 မီဂါဘိုက်အထိ ပိတ်ဆို့သည်။

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

ဘလောက်များသည် ဒေတာအကြမ်းမျှသာလား။

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

ရှင်းပါပြီ။

Alexey၊ IPs များပေါ်တွင် uniqExact နှင့်ပါသော ဥပမာတစ်ခု၊ ဆိုလိုသည်မှာ uniqExact သည် ကိန်းဂဏန်းများထက် စာကြောင်းများဖြင့် တွက်ချက်ရန် အချိန်ပိုကြာသည်ဟူသော အချက်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏နားရွက်ကို အတုအယောင်သုံး၍ စစ်ကြောသည့်အချိန်တွင် ပစ်လိုက်လျှင်ကော။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့၏ disk တွင် ၎င်းသည် အလွန်ကွဲပြားခြင်းမရှိဟု သင်ပြောခဲ့ပုံရသည်။ အကယ်၍ ကျွန်ုပ်တို့သည် ဒစ်ခ်မှ စာကြောင်းများကို ဖတ်ပြီး ကာစ်လုပ်ပါက၊ ကျွန်ုပ်တို့၏ စုစည်းမှုများ ပိုမိုမြန်ဆန်မည်လော ဒါမှမဟုတ် ဒီမှာ နည်းနည်းလေး အမြတ်ကျန်သေးလား။ ဒါကို သင်စမ်းသပ်ဖူးတယ်လို့ ထင်ရပေမယ့် အကြောင်းတစ်ခုခုကြောင့် စံသတ်မှတ်ချက်မှာ မဖော်ပြခဲ့ပါဘူး။

မသွင်းဘဲနဲ့ထက် ပိုနှေးမယ်ထင်တယ်။ ဤကိစ္စတွင်၊ IP လိပ်စာကို စာကြောင်းမှ ခွဲခြမ်းစိတ်ဖြာရပါမည်။ ဟုတ်ပါတယ်၊ ClickHouse မှာ၊ ကျွန်ုပ်တို့ရဲ့ IP လိပ်စာခွဲခြမ်းစိတ်ဖြာမှုကိုလည်း အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ထားပါတယ်။ ကျွန်တော်တို့ အရမ်းကြိုးစားခဲ့ပေမယ့် အဲဒီမှာ နံပါတ်တစ်သောင်းပုံစံနဲ့ ရေးထားတယ်။ သိပ်အဆင်မပြေဘူး။ အခြားတစ်ဖက်တွင်၊ uniqExact လုပ်ဆောင်ချက်သည် strings များဖြစ်သောကြောင့် strings များသာမက algorithm ၏ ကွဲပြားသော အထူးပြုချက်တစ်ခုကို ရွေးချယ်ထားသောကြောင့်လည်း လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ ကြိုးများကို ရိုးရှင်းစွာ ကွဲပြားစွာ လုပ်ဆောင်ပါသည်။

ကျွန်ုပ်တို့သည် ပို၍ပင်နဂိုဒေတာအမျိုးအစားကို ယူလျှင်ကော။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင်ရှိသော user id ကိုရေးချပါ၊ ၎င်းကိုစာကြောင်းတစ်ခုအနေဖြင့်ရေးပါ၊ ထို့နောက်၎င်းကိုမွှေပါ၊ ၎င်းသည် ပို၍ ပျော်စရာကောင်းမည်၊ မဟုတ်ဘူးလား။

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

Alexey၊ အစီရင်ခံစာအတွက် ကျေးဇူးအများကြီးတင်ပါတယ်။ ပြီးတော့ ClickHouse အတွက် အရမ်းကျေးဇူးတင်ပါတယ်။ အစီအစဉ်နဲ့ ပတ်သက်ပြီး မေးစရာရှိတယ်။ အဘိဓာန်များကို ပြီးပြည့်စုံစွာ အပ်ဒိတ်လုပ်ရန် အင်္ဂါရပ်တစ်ခုအတွက် အစီအစဉ်ရှိပါသလား။

အဲဒါက တစ်စိတ်တစ်ပိုင်း ပြန်ဖွင့်တာလား။

ဟုတ်ကဲ့ဟုတ်ကဲ့။ အဲဒီမှာ MySQL အကွက်ကို သတ်မှတ်နိုင်မှုလိုပဲ၊ ဆိုလိုသည်မှာ အဘိဓာန်သည် အလွန်ကြီးပါက ဤဒေတာကိုသာ တင်ဆောင်ပြီးနောက် အပ်ဒိတ်လုပ်ပါ။

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

မထင်ပါဘူး။

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

ဟုတ်ကဲ့၊ ဒါပေမယ့် ကံမကောင်းစွာပဲ၊ C++ မှာ မဟုတ်ပါဘူး။

သင့်လုပ်ဖော်ကိုင်ဖက်များသည် C++ တွင် မည်သို့ရေးရမည်ကို သိပါသလား။

ငါတစ်ယောက်ယောက်ကိုရှာမယ်။

ကောင်းတယ်*။

* အစီရင်ခံစာပြီးနောက်နှစ်လအကြာတွင်အင်္ဂါရပ်ကိုထည့်သွင်းခဲ့သည် - မေးခွန်းရေးသားသူက၎င်းကိုတီထွင်ပြီးသူ၏ပေးပို့ခဲ့သည်။ တောင်းခံပါ.

Thank you!

မင်္ဂလာပါ! အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ ClickHouse သည် ၎င်းအတွက်ရနိုင်သောအရင်းအမြစ်အားလုံးကို စားသုံးရာတွင် အလွန်ကောင်းမွန်ကြောင်း သင်ဖော်ပြခဲ့သည်။ Luxoft ရဲ့ဘေးနားက စပီကာက Russian Post အတွက် သူ့ရဲ့ဖြေရှင်းချက်အကြောင်း ပြောပြခဲ့ပါတယ်။ သူတို့က ClickHouse ကိုတကယ်ကြိုက်တယ်လို့ပြောခဲ့ပေမယ့် CPU အားလုံးကိုစားနေတာကြောင့် သူတို့ရဲ့အဓိကပြိုင်ဘက်အစား အတိအကျမသုံးခဲ့ပါဘူး။ ပြီးတော့ သူတို့ဟာ သူတို့ရဲ့ ဗိသုကာလက်ရာနဲ့ သူတို့ရဲ့ ZooKeeper မှာ dockers တွေနဲ့ ချိတ်ဆက်လို့မရပါဘူး။ ClickHouse မှာ ရနိုင်တဲ့ အရာအားလုံးကို မစားသုံးမိအောင် တစ်နည်းနည်းနဲ့ ကန့်သတ်ဖို့ ဖြစ်နိုင်ပါသလား။

ဟုတ်တယ်၊ ဖြစ်နိုင်တယ်၊ အရမ်းလွယ်တယ်။ core တွေနည်းနည်းသုံးချင်ရင်တော့ ရေးလိုက်ရုံပါပဲ။ set max_threads = 1. ဒါပဲ၊ အဲဒါက core တစ်ခုထဲမှာ တောင်းဆိုမှုကို လုပ်ဆောင်ပါလိမ့်မယ်။ ထို့အပြင်၊ သင်သည် မတူညီသော သုံးစွဲသူများအတွက် မတူညီသော ဆက်တင်များကို သတ်မှတ်နိုင်သည်။ ဒီတော့ ပြဿနာမရှိပါဘူး။ Luxoft မှ သင်၏လုပ်ဖော်ကိုင်ဖက်များအား စာရွက်စာတမ်းတွင် ဤဆက်တင်ကိုမတွေ့ရခြင်းသည် အဆင်မပြေကြောင်း ပြောပြပါ။

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

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

* ClickHouse ၏နောက်ဆုံးထွက်ဗားရှင်းများတွင်၊ "လိုက်လျောညီထွေရှိသောအညွှန်းကိန်းအသေးစိတ်" ကိုဖွင့်ထားပြီး၊ အများစုအတွက်ရှည်လျားသောအတန်းများကိုသိမ်းဆည်းခြင်းပြဿနာကိုဖယ်ရှားပေးသည်။

ကီလိုဘိုက်က ပုံမှန်လား။

Нормально။

မင်္ဂလာပါ! အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ ဒီအကြောင်းကို chat မှာ မေးထားပြီးသားဖြစ်ပေမယ့် အဖြေရရင် မမှတ်မိပါဘူး။ CTE ၏ပုံစံဖြင့် WITH ကဏ္ဍကို တစ်နည်းနည်းဖြင့် ချဲ့ထွင်ရန် အစီအစဉ်ရှိပါသလား။

မရသေး။ ကျွန်ုပ်တို့၏ WITH အပိုင်းသည် အနည်းငယ် သိမ်ဖျင်းသည်။ ဒါဟာ ကျွန်တော်တို့အတွက် သေးငယ်တဲ့ အင်္ဂါရပ်တစ်ခုလိုပါပဲ။

ကျွန်တော်နားလည်ပါတယ်။ ကျေးဇူးတင်ပါသည်!

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

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

* ကီးဘုတ်ပေါ်ရှိခလုတ်များကိုနှိပ်ပြီးအရာရာကိုလုပ်ဆောင်ပါ။

၎င်းသည် စနစ်၏စွမ်းဆောင်ရည်ကို တစ်နည်းနည်းဖြင့် သက်ရောက်မှုရှိနိုင်မလား။ ထည့်သွင်းမှုသည် ယခုကဲ့သို့ မြန်ဆန်မည်လား။

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

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

ဟုတ်ပါတယ်။

မေးခွန်းတစ်ခု။ အကယ်၍ ကျွန်ုပ်တို့သည် မည်သည့်အဓိကသော့ကိုမျှ မရွေးချယ်နိုင်ပါက၊ "ရက်စွဲ" အကွက်အရ ၎င်းကို နောက်ခံတွင် ပိုမိုစနစ်ကျစွာ လိုက်လျောညီထွေဖြစ်စေရန်အတွက် ဤဒေတာကို ပြန်လည်စီခြယ်မှုနည်းပါးစေရန်အတွက် "ရက်စွဲ" အကွက်အတိုင်း တိတိကျကျလုပ်ဆောင်ခြင်းသည် မှန်ကန်ပါသလား။ သင့်တွင် range queries များမရှိသည့်အပြင် ပင်မကီးကိုပင် မရွေးချယ်နိုင်ပါက၊ ၎င်းသည် အဓိကကီးတွင် ရက်စွဲတစ်ခုထည့်ရန် ထိုက်တန်ပါသလား။

ဟုတ်ပါတယ်။

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

OK အရမ်းကျေးဇူးတင်ပါတယ်!

source: www.habr.com