ဧပြီလတွင်၊ Avito အင်ဂျင်နီယာများသည် ပင်မ ClickHouse developer Alexey Milovidov နှင့် Integros မှ Golang developer Kirill Shvakov တို့နှင့် အွန်လိုင်းအစည်းအဝေးများအတွက် စုဝေးခဲ့ကြသည်။ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်စီမံခန့်ခွဲမှုစနစ်ကို မည်သို့အသုံးပြုပုံနှင့် ကျွန်ုပ်တို့ကြုံတွေ့ရသည့်အခက်အခဲများကို ဆွေးနွေးခဲ့ပါသည်။
အစည်းအဝေးကို အခြေခံ၍ ကျွန်ုပ်တို့၏ အရန်သိမ်းမှုများ၊ ဒေတာပြန်လည်ထည့်သွင်းခြင်း၊ ပြင်ပအဘိဓာန်များ၊ Golang ဒရိုက်ဘာနှင့် ClickHouse ဗားရှင်းများကို မွမ်းမံခြင်းနှင့်ပတ်သက်သည့် ပရိသတ်၏မေးခွန်းများအတွက် ကျွမ်းကျင်သူများ၏ အဖြေများပါသည့် ဆောင်းပါးတစ်ပုဒ်ကို စုစည်းထားပါသည်။ Yandex DBMS နှင့် ၎င်း၏ ပစ္စုပ္ပန်နှင့် အနာဂတ်ကို စိတ်ဝင်စားသော developer များအတွက် ၎င်းသည် အသုံးဝင်နိုင်ပါသည်။ ပုံသေအားဖြင့်၊ အဖြေများသည် Alexey Milovidov မှမဟုတ်ပါက၊
သတိထားပါ၊ ဖြတ်တောက်မှုအောက်မှာ စာသားတွေအများကြီးရှိတယ်။ မေးခွန်းများပါသော အကြောင်းအရာသည် သင့်အား လမ်းညွှန်နိုင်ရန် ကူညီပေးလိမ့်မည်ဟု မျှော်လင့်ပါသည်။
အကြောင်းအရာ
စာသားမဖတ်ချင်ရင် စုဝေးမှုမှတ်တမ်းကို ကြည့်နိုင်ပါတယ်။ . အချိန်ကုဒ်များသည် ဗီဒီယိုအောက်တွင် ပထမမှတ်ချက်တွင် ရှိသည်။
ClickHouse ကို အဆက်မပြတ် အပ်ဒိတ်လုပ်ထားသော်လည်း ကျွန်ုပ်တို့၏ဒေတာသည် မဟုတ်ပါ။ အဲဒါနဲ့ပတ်သက်ပြီး ဘာလုပ်ရမလဲ။
ClickHouse ကို အဆက်မပြတ် အပ်ဒိတ်လုပ်နေပြီး နောက်ဆုံးအဆင့် စီမံဆောင်ရွက်ပြီးသော ကျွန်ုပ်တို့၏ဒေတာကို အပ်ဒိတ်မလုပ်ဘဲ အရန်မိတ္တူထဲတွင် ရှိနေပါသည်။
ကျွန်ုပ်တို့တွင် ပြဿနာအချို့ရှိခဲ့ပြီး ဒေတာ ပျောက်ဆုံးသွားသည်ဆိုပါစို့။ ပြန်လည်ရယူရန် ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့ပြီး၊ အရန်ဆာဗာများတွင် သိမ်းဆည်းထားသည့် အပိုင်းဟောင်းများသည် လက်ရှိအသုံးပြုနေသော ClickHouse ဗားရှင်းနှင့် အလွန်ကွာခြားကြောင်း တွေ့ရှိရပါသည်။ ဒီလိုအခြေအနေမှာ ဘာလုပ်ရမလဲ၊ ဖြစ်နိုင်ပါ့မလား။
သင်သည် ဖော်မတ်ဟောင်းတစ်ခုမှ ဒေတာကို အရန်သိမ်းဆည်းခြင်းမှ ပြန်လည်ရယူခဲ့သော်လည်း ၎င်းသည် ဗားရှင်းအသစ်သို့ မချိတ်ဆက်နိုင်သည့် အခြေအနေတစ်ခု မဖြစ်နိုင်ပေ။ ClickHouse ရှိ ဒေတာဖော်မတ်သည် အမြဲတမ်း နောက်ပြန်သဟဇာတ ဖြစ်နေကြောင်း ကျွန်ုပ်တို့ သေချာပါသည်။ အသုံးနည်းသော လုပ်ဆောင်ချက်အချို့၏ အမူအကျင့်များ ပြောင်းလဲသွားပါက လုပ်ဆောင်နိုင်စွမ်းတွင် နောက်ပြန်လိုက်ဖက်မှုထက် ၎င်းသည် ပိုမိုအရေးကြီးပါသည်။ ClickHouse ၏ ဗားရှင်းအသစ်သည် ဒစ်ခ်ပေါ်တွင် သိမ်းဆည်းထားသည့် ဒေတာကို အမြဲဖတ်ရှုနိုင်ရပါမည်။ ဒါက ဥပဒေ။
ClickHouse မှ ဒေတာကို အရန်သိမ်းဆည်းခြင်းအတွက် လက်ရှိ အကောင်းဆုံး အလေ့အကျင့်များကား အဘယ်နည်း။
ကျွန်ုပ်တို့သည် နောက်ဆုံးလုပ်ဆောင်မှုများကို အကောင်းဆုံးဖြစ်အောင်၊ ကြီးမားသော terabytes ဒေတာဘေ့စ်နှင့် အပ်ဒိတ်လုပ်ထားသည့် ဒေတာတို့ကို ထည့်သွင်းစဉ်းစားကာ နောက်ဆုံးသုံးရက်အတွင်း လုပ်ငန်းစဉ်များ ဖြစ်ပေါ်လာခြင်းမရှိကြောင်း ထည့်သွင်းစဉ်းစားကာ အရန်ကူးခြင်းကို မည်သို့ပြုလုပ်ရမည်နည်း။
ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဖြေရှင်းချက်ကို ဖန်တီးပြီး bash ပေါ်တွင်ရေးနိုင်သည်- ဤအရန်မိတ္တူများကို ဤကဲ့သို့သောနည်းလမ်းဖြင့် စုဆောင်းပါ။ ဘယ်အရာမှ ဖြတ်စရာ မလိုအပ်ဘဲ စက်ဘီးကို ဟိုးရှေးရှေးတုန်းက တီထွင်ခဲ့တာလား။
အကောင်းဆုံး အလေ့အကျင့်များဖြင့် စတင်ကြပါစို့။ ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များသည် မိတ္တူကူးခြင်းဆိုင်ရာမေးခွန်းများကို တုံ့ပြန်ရာတွင်၊ ဤပြဿနာကိုဖြေရှင်းပြီးဖြစ်သည့် Yandex.Cloud ဝန်ဆောင်မှုအကြောင်း သူတို့ကို သတိပေးရန် အမြဲအကြံပေးပါသည်။ ဒါကြောင့် ဖြစ်နိုင်ရင် သုံးပါ။
ClickHouse တွင် ရာနှုန်းပြည့် အရန်ကူးခြင်းအတွက် ပြီးပြည့်စုံသော ဖြေရှင်းချက်မရှိပါ။ သုံးလို့ရတဲ့ ကွက်လပ်တွေရှိတယ်။ ပြီးပြည့်စုံသောဖြေရှင်းချက်တစ်ခုရရန်၊ သင်သည် အနည်းငယ်ကို ကိုယ်တိုင်ပြုလုပ်ရန် သို့မဟုတ် ဇာတ်ညွှန်းပုံစံဖြင့် ထုပ်ပိုးမှုများကို ဖန်တီးရမည်ဖြစ်သည်။
ကျွန်ုပ်သည် ဒေတာပမာဏနှင့် အစုအဝေး၏အရွယ်အစားပေါ်မူတည်၍ အရိုးရှင်းဆုံးဖြေရှင်းနည်းများဖြင့် စတင်ပြီး အဆန်းပြားဆုံးအရာများဖြင့် အဆုံးသတ်ပါမည်။ အစုအဝေးကြီးလေ၊ ဖြေရှင်းချက်က ပိုရှုပ်ထွေးလေဖြစ်သည်။
ဒေတာပါသောဇယားသည် ဂစ်ဂါဘိုက်အနည်းငယ်သာ သိမ်းပိုက်ပါက၊ အရန်သိမ်းခြင်းကို ဤကဲ့သို့ လုပ်ဆောင်နိုင်သည်-
- ဇယားအဓိပ္ပါယ်ဆိုလိုသည်မှာ မက်တာဒေတာ − သိမ်းဆည်းပါ။ ဖန်တီးဇယားကိုပြသပါ။.
- ClickHouse client ကို အသုံးပြု၍ အမှိုက်ပုံးလုပ်ပါ ကို select * စားပွဲမှ ဖို. ပုံမှန်အားဖြင့် သင်သည် TabSeparated ဖော်မတ်ဖြင့် ဖိုင်တစ်ခုကို လက်ခံရရှိမည်ဖြစ်သည်။ ပိုမိုထိရောက်လိုပါက Native ဖော်မတ်ဖြင့် ပြုလုပ်နိုင်ပါသည်။
ဒေတာပမာဏ ပိုကြီးပါက၊ အရန်ကူးယူမှုသည် အချိန်ပိုကြာမည်ဖြစ်ပြီး နေရာများစွာ ယူမည်ဖြစ်သည်။ ၎င်းကို ကျိုးကြောင်းဆီလျော်သော အရန်သိမ်းခြင်းဟုခေါ်သည်၊ ၎င်းကို ClickHouse ဒေတာဖော်မတ်နှင့် ချိတ်ဆက်ထားခြင်းမရှိပါ။ အကယ်၍ ၎င်းသည် နောက်ဆုံးနည်းလမ်းအဖြစ် အရန်ကူးယူ၍ ပြန်လည်ရယူရန်အတွက် MySQL သို့ အပ်လုဒ်လုပ်နိုင်ပါသည်။
ပိုမိုအဆင့်မြင့်သောကိစ္စများအတွက်၊ ClickHouse သည် ဒေသတွင်းဖိုင်စနစ်ရှိ အခန်းကန့်များကို လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုဖန်တီးရန် built-in စွမ်းရည်ရှိသည်။ ဤအင်္ဂါရပ်ကို တောင်းဆိုမှုတစ်ခုအဖြစ် ရနိုင်ပါသည်။ ဇယားအေးခဲထားသော partition ကိုပြောင်းလဲပါ။. သို့မဟုတ်ရိုးရှင်းစွာ ဇယားအေးခဲခြင်းကိုပြောင်းလဲပါ။ - ဒါက စားပွဲတစ်ခုလုံးရဲ့ လျှပ်တစ်ပြက်ပုံပါ။
လျှပ်တစ်ပြက်ရိုက်ချက်အား shard တစ်ခုပေါ်ရှိ ဇယားတစ်ခုအတွက် အဆက်မပြတ်ဖန်တီးပေးမည်၊ ဆိုလိုသည်မှာ၊ ဤနည်းဖြင့် အစုအဖွဲ့တစ်ခုလုံး၏ တစ်သမတ်တည်းလျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုကို ဖန်တီးရန် မဖြစ်နိုင်ပါ။ သို့သော် အလုပ်အများစုအတွက် ယင်းကဲ့သို့ မလိုအပ်ဘဲ၊ shard တစ်ခုစီတွင် တောင်းဆိုမှုတစ်ခုကို လုပ်ဆောင်ရန်နှင့် ကိုက်ညီသော လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုရရှိရန် လုံလောက်ပါသည်။ ၎င်းကို hardlinks ပုံစံဖြင့် ဖန်တီးထားသောကြောင့် အပိုနေရာမယူပါ။ ထို့နောက် သင်သည် ဤလျှပ်တစ်ပြက်ရိုက်ချက်အား အရန်ဆာဗာသို့ သို့မဟုတ် အရန်ကူးယူရန်အတွက် သင်အသုံးပြုသည့် သိုလှောင်ခန်းသို့ ကူးယူပါ။
ထိုသို့သောအရန်ကူးယူခြင်းကိုပြန်လည်ရယူရန်အတော်လေးလွယ်ကူသည်။ ပထမဦးစွာ၊ ရှိပြီးသားဇယားအဓိပ္ပါယ်များကို အသုံးပြု၍ ဇယားများကိုဖန်တီးပါ။ ထို့နောက်၊ သိမ်းဆည်းထားသော အခန်းကန့်များ၏ ဓာတ်ပုံများကို ဤဇယားများအတွက် Directory-Detached သို့ ကူးယူပြီး မေးမြန်းမှုကို လုပ်ဆောင်ပါ။ partition ကိုပူးတွဲပါ။. ဤဖြေရှင်းချက်သည် အလွန်လေးနက်သော ဒေတာပမာဏများအတွက် အလွန်သင့်လျော်ပါသည်။
တစ်ခါတစ်ရံတွင် သင်သည် ဆာဗာတစ်ခုစီတွင် ဆယ်ဂဏန်း သို့မဟုတ် ရာနှင့်ချီသော terabytes နှင့် ဆာဗာရာပေါင်းများစွာရှိသည့် ကိစ္စများတွင် ပို၍ပင် အေးမြသောအရာတစ်ခုကို လိုအပ်သည်။ Yandex.Metrica မှ ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များထံမှ ကောက်ယူခဲ့သော အဖြေတစ်ခုရှိပါသည်။ လူတိုင်းကို အကြံပြုလိုတာ မဟုတ်ဘူး - အဲဒါကို ဖတ်ပြီး သင့်တော်သလား၊ မသင့်တော်ဘူးလားဆိုတာ ကိုယ်တိုင် ဆုံးဖြတ်ပါ။
ပထမဦးစွာ သင်သည် ကြီးမားသော disk စင်များဖြင့် ဆာဗာများစွာကို ဖန်တီးရန် လိုအပ်သည်။ ထို့နောက်၊ ဤဆာဗာများတွင် ClickHouse ဆာဗာအများအပြားကို မြှင့်တင်ပြီး တူညီသော shards များအတွက် အခြားပုံတူပုံတူအဖြစ် လုပ်ဆောင်နိုင်စေရန် ၎င်းတို့ကို စီစဉ်သတ်မှတ်ပါ။ ထို့နောက် လျှပ်တစ်ပြက်ရိုက်ချက်များ ဖန်တီးနိုင်စေမည့် ဤဆာဗာများရှိ ဖိုင်စနစ် သို့မဟုတ် ကိရိယာအချို့ကို အသုံးပြုပါ။ ဤနေရာတွင် ရွေးချယ်စရာနှစ်ခုရှိသည်။ ပထမရွေးချယ်မှုမှာ LVM လျှပ်တစ်ပြက်ရိုက်ချက်များဖြစ်ပြီး ဒုတိယရွေးချယ်မှုမှာ Linux ရှိ ZFS ဖြစ်သည်။
အဲဒီနောက်၊ နေ့တိုင်း လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခု ဖန်တီးဖို့လိုတယ်၊ အဲဒါက လိမ်ပြီး နေရာယူလိမ့်မယ်။ ထုံးစံအတိုင်း၊ ဒေတာတွေပြောင်းရင် အချိန်နဲ့အမျှ နေရာလွတ်တွေ တိုးလာမယ်။ ဤလျှပ်တစ်ပြက်ရိုက်ချက်သည် အချိန်မရွေး ထုတ်ယူနိုင်ပြီး ဒေတာကို ပြန်လည်ရယူနိုင်သည့် ထူးဆန်းသည့်ဖြေရှင်းချက်ဖြစ်သည်။ ထို့အပြင်၊ ၎င်းတို့သည် ခေါင်းဆောင်များဖြစ်လာရန် မကြိုးစားရန် ဤပုံတူများကို config တွင် ကန့်သတ်ရန် လိုအပ်ပါသည်။
ပုံတူများကို shafts များတွင် ထိန်းချုပ်ထားသော နောက်ကျကျန်နေမှုကို စုစည်းရန် ဖြစ်နိုင်ပါသလား။
ယခုနှစ်တွင် သင်သည် ClickHouse တွင် ရှပ်များပြုလုပ်ရန် စီစဉ်နေပါသည်။ ၎င်းတို့တွင် ပုံစံတူများ ထိန်းချုပ်ထားသော နောက်ကျကျန်နေမှုကို စုစည်းရန် ဖြစ်နိုင်ပါသလား။ ပြောင်းလဲမှုများနှင့် အခြားပြောင်းလဲမှုများဖြင့် အဆိုးမြင်အခြေအနေများမှ မိမိကိုယ်ကို ကာကွယ်ရန် ၎င်းကို ကျွန်ုပ်တို့ အသုံးပြုလိုပါသည်။
အပြောင်းအလဲအတွက် နောက်ကြောင်းပြန်လှည့်တာမျိုးတွေ လုပ်လို့ရပါသလား။ ဥပမာအားဖြင့်၊ ရှိပြီးသား shaft တစ်ခုတွင် အပြောင်းအလဲများကို သင်ဤအခိုက်အတန့်အထိ အသုံးချပြီး ဤအခိုက်အတန့်မှ အပြောင်းအလဲများကို ကျင့်သုံးတော့မည်လား။
အမိန့်တစ်ခုသည် ကျွန်ုပ်တို့၏အစုအဝေးသို့ ရောက်လာပြီး ၎င်းကို ဖြိုဖျက်ပါက၊ ကျွန်ုပ်တို့တွင် တစ်နာရီ နောက်ကျနေသော အခြေအနေနှင့် ပုံတူတစ်ခု ရှိသည်၊ ၎င်းကို လောလောဆယ်တွင် အသုံးပြုကြပါစို့ဟု ပြောနိုင်သော်လည်း၊ ကျွန်ုပ်တို့သည် ၎င်းကို နောက်ဆုံး ဆယ်မိနစ်အတွင်း အပြောင်းအလဲများကို ကျင့်သုံးမည်မဟုတ်ပါ။
ပထမဦးစွာ၊ ပုံတူများထိန်းချုပ်ထားသော နောက်ကျခြင်းအကြောင်း။ သုံးစွဲသူများထံမှ ထိုသို့သောတောင်းဆိုမှုတစ်ခုရှိခဲ့ပြီး Github တွင် ပြဿနာတစ်ခုဖန်တီးခဲ့သည်- "တစ်စုံတစ်ဦးသည် ၎င်းကိုလိုအပ်ပါက သဘောကျပါက နှလုံးသွင်းပါ။" မည်သူမျှ မပို့ဆောင်ခဲ့သဖြင့် ပြဿနာကို ပိတ်ခဲ့သည်။ သို့သော် ClickHouse ကို စနစ်ထည့်သွင်းခြင်းဖြင့် သင်သည် ဤအခွင့်အရေးကို ရရှိပြီးဖြစ်သည်။ မှန်သည်၊ ဗားရှင်း 20.3 မှစတင်သည်။
ClickHouse သည် နောက်ခံတွင် ဒေတာပေါင်းစည်းမှုကို အမြဲလုပ်ဆောင်သည်။ ပေါင်းစည်းမှုပြီးသွားသောအခါ၊ အချို့သောဒေတာအပိုင်းများကို ပိုကြီးသောအပိုင်းတစ်ခုဖြင့် အစားထိုးသည်။ တစ်ချိန်တည်းမှာပင်၊ ယခင်ရှိနေသည့် ဒေတာအပိုင်းအစများသည် ဒစ်ခ်ပေါ်တွင် အချိန်အတန်ကြာ ဆက်လက်တည်ရှိနေပါသည်။
ပထမဦးစွာ၊ ၎င်းတို့ကို ပိတ်ဆို့ခြင်းမပြုသည့် လုပ်ဆောင်ချက်ကို ပံ့ပိုးပေးရန်အတွက် ၎င်းတို့ကို အသုံးပြုသည့် ရွေးချယ်ထားသော စုံစမ်းမေးမြန်းမှုများ ရှိနေသရွေ့ ၎င်းတို့ကို ဆက်လက်သိမ်းဆည်းထားမည်ဖြစ်သည်။ ရွေးချယ်ထားသော မေးခွန်းများကို အပိုင်းဟောင်းများမှ အလွယ်တကူ ဖတ်နိုင်သည်။
ဒုတိယအနေဖြင့်၊ အချိန်အတိုင်းအတာတစ်ခုလည်းရှိသည် - ဒေတာအပိုင်းအစဟောင်းများကို disk ပေါ်တွင်ရှစ်မိနစ်ကြာအောင်ထားပါ။ ဤရှစ်မိနစ်ကို စိတ်ကြိုက်ပြင်ဆင်နိုင်ပြီး တစ်ရက်အဖြစ်ပင် ပြောင်းလဲနိုင်သည်။ ၎င်းသည် disk space ကိုကုန်ကျလိမ့်မည်- ဒေတာစီးဆင်းမှုပေါ် မူတည်၍ နောက်ဆုံးနေ့တွင်ဒေတာသည်နှစ်ဆမျှသာမဟုတ်ပါ၊ ၎င်းသည်ငါးဆပိုမိုဖြစ်လာနိုင်သည်။ သို့သော် ပြဿနာကြီးကြီးမားမားရှိပါက ClickHouse ဆာဗာကို ရပ်တန့်ပြီး အရာအားလုံးကို ခွဲထုတ်နိုင်သည်။
အခု အပြောင်းအလဲတွေကို ဘယ်လိုကာကွယ်မလဲဆိုတဲ့ မေးခွန်းပေါ်လာတယ်။ ClickHouse ၏ ဗားရှင်းအဟောင်းများတွင်၊ ပြောင်းလဲမှုသည် အပိုင်းပိုင်းများကို တိုက်ရိုက်ပြောင်းလဲစေသည့်နည်းဖြင့် ဤနေရာတွင် ပိုမိုနက်ရှိုင်းစွာကြည့်ရှုရန် တန်ဖိုးရှိသောကြောင့်ဖြစ်သည်။ ဖိုင်အချို့ပါရှိသည့် ဒေတာအပိုင်းတစ်ခုရှိပြီး၊ ဥပမာ၊ ကော်လံကို ပြောင်းပါ။. ထို့နောက် ဤကော်လံကို အပိုင်းအားလုံးမှ ရုပ်ပိုင်းအရ ဖယ်ရှားသည်။
ဗားရှင်း 20.3 မှစတင်၍ ပြောင်းလဲခြင်းယန္တရားသည် လုံးဝပြောင်းလဲသွားခဲ့ပြီး ယခုအခါ ဒေတာအပိုင်းအစများသည် အမြဲမပြောင်းလဲနိုင်တော့ပေ။ ၎င်းတို့သည် လုံးဝမပြောင်းလဲပါ - ယခု ပြောင်းလဲမှုများသည် ပေါင်းစည်းခြင်းကဲ့သို့ပင် များစွာလုပ်ဆောင်နေပါသည်။ တစ်နေရာတည်းမှာ အစားထိုးမယ့်အစား အသစ်တစ်ခုကို ဖန်တီးလိုက်ပါ။ အပိုင်းအသစ်တွင်၊ မပြောင်းလဲသောဖိုင်များသည် hardlink များဖြစ်လာပြီး ကော်လံတစ်ခုကို ဖျက်ပါက၊ ၎င်းသည် အပိုင်းအသစ်တွင် ပျောက်ဆုံးသွားမည်ဖြစ်သည်။ အပိုင်းဟောင်းကို ရှစ်မိနစ်အကြာတွင် မူရင်းအတိုင်း ဖျက်လိုက်မည်ဖြစ်ပြီး၊ ဤနေရာတွင် အထက်ဖော်ပြပါ ဆက်တင်များကို သင်ပြင်ဆင်နိုင်သည်။
ဗီဇပြောင်းလဲခြင်းကဲ့သို့သော ပြောင်းလဲမှုများနှင့် တူညီသည်။ သင်ဘယ်တော့လဲ။ ဖျက်ပစ်ပါ။ သို့မဟုတ် မွမ်းမံပြင်ဆင်ခြင်း။အပိုင်းကို မပြောင်းလဲဘဲ အသစ်တစ်ခုကို ဖန်တီးသည်။ ပြီးရင် အဟောင်းကို ဖျက်လိုက်ပါ။
ဇယားဖွဲ့စည်းပုံပြောင်းရင် ဘာဖြစ်မလဲ။
စနစ်ဟောင်းဖြင့် ပြုလုပ်ထားသည့် အရန်ကူးယူမှုကို မည်သို့ပြန်ယူရမည်နည်း။ ဒုတိယမေးခွန်းမှာ လျှပ်တစ်ပြက်ရိုက်ချက်များနှင့် ဖိုင်စနစ်ကိရိယာများအကြောင်းဖြစ်သည်။ Linux LVM တွင် ZFS အစား Btrfs သည် ဤနေရာတွင် ကောင်းမွန်ပါသလား။
မင်းလုပ်ရင် partition ကိုပူးတွဲပါ။ ကွဲပြားသောဖွဲ့စည်းပုံဖြင့် partitions များ, ထို့နောက် ClickHouse သည်မဖြစ်နိုင်သည်ကိုပြောပြလိမ့်မည်။ ဒါက ဖြေရှင်းချက်ပါ။ ပထမအချက်မှာ MergeTree အမျိုးအစား၏ ယာယီဇယားကို တည်ဆောက်ရန်၊ ဖိုင်တွဲကို အသုံးပြု၍ ထိုနေရာတွင် ဒေတာကို ပူးတွဲပါ၊ နှင့် ပြောင်းလဲမေးမြန်းမှုတစ်ခု ပြုလုပ်ရန်ဖြစ်သည်။ ထို့နောက် သင်သည် ဤဒေတာကို ကူးယူခြင်း သို့မဟုတ် လွှဲပြောင်းပြီး ထပ်မံ ပူးတွဲပါ သို့မဟုတ် တောင်းဆိုချက်ကို အသုံးပြုနိုင်သည်။ ဇယားရွှေ့ထားသော partition ကိုပြောင်းလဲပါ။.
ယခု ဒုတိယမေးခွန်းမှာ Btrfs ကို သုံးနိုင်မလား။ စတင်ရန်၊ သင့်တွင် LVM ရှိပါက LVM လျှပ်တစ်ပြက်ရိုက်ချက်များသည် လုံလောက်ပြီး၊ ဖိုင်စနစ်သည် ext4 ဖြစ်နိုင်သည်၊ အရေးမကြီးပါ။ Btrts ဖြင့်၊ အရာအားလုံးသည် ၎င်းကိုအသုံးပြုရာတွင် သင့်အတွေ့အကြုံပေါ်တွင် မူတည်ပါသည်။ ၎င်းသည် ရင့်ကျက်သော ဖိုင်စနစ်ဖြစ်သည်၊ သို့သော် အခြေအနေတစ်ခုတွင် အရာအားလုံး လက်တွေ့တွင် မည်သို့ဖြစ်မည်နှင့်ပတ်သက်၍ သံသယအချို့ရှိနေဆဲဖြစ်သည်။ သင့်တွင် Btrfs မရှိပါက ၎င်းကိုအသုံးပြုရန် ကျွန်ုပ်အကြံပြုမည်မဟုတ်ပါ။
ဒေတာပြန်လည်မျှဝေခြင်းတွင် လက်ရှိအကောင်းဆုံးအလေ့အကျင့်များကား အဘယ်နည်း။
ပြန်လည်ခွဲဝေခြင်းဆိုင်ရာ ပြဿနာသည် ရှုပ်ထွေးပြီး ဘက်စုံရှိသည်။ ဤနေရာတွင် ဖြစ်နိုင်ချေရှိသော အဖြေများစွာရှိပါသည်။ သင်သည် တစ်ဖက်မှသွား၍ ဤသို့ပြောနိုင်သည် - ClickHouse တွင် တပ်ဆင်ထားသော ပြန်လည်မျှဝေခြင်းအင်္ဂါရပ် မရှိပါ။ ဒါပေမယ့် ဒီအဖြေက ဘယ်သူနဲ့မှ အဆင်မပြေမှာကို ငါကြောက်တယ်။ ထို့ကြောင့်၊ သင်သည် တစ်ဖက်မှသွား၍ ClickHouse တွင် ဒေတာပြန်လည် သိမ်းဆည်းရန် နည်းလမ်းများစွာ ရှိသည်ဟု ပြောနိုင်သည်။
အစုအဝေးသည် နေရာလွတ်ကုန်သွားပါက သို့မဟုတ် ၎င်းသည် ဝန်ကိုမကိုင်တွယ်နိုင်ပါက၊ သင်သည် ဆာဗာအသစ်များကို ထည့်သွင်းပါ။ သို့သော် ဤဆာဗာများသည် ပုံသေအားဖြင့် ဗလာဖြစ်နေသည်၊ ၎င်းတို့တွင် ဒေတာမရှိ၊ ဝန်မရှိပါ။ ဒေတာကို ပိုမိုကြီးမားသော အစုအဝေးအသစ်တွင် အညီအမျှ ပျံ့နှံ့စေရန်အတွက် သင်သည် ဒေတာကို ပြန်လည်စီစဉ်ရန် လိုအပ်ပါသည်။
၎င်းကိုလုပ်ဆောင်နိုင်သည့် ပထမဆုံးနည်းလမ်းမှာ တောင်းဆိုချက်တစ်ခုအသုံးပြု၍ အပိုင်းခွဲများကို ဆာဗာအသစ်များသို့ ကူးယူခြင်းဖြစ်သည်။ Table fetch partition ကိုပြောင်းပါ။. ဥပမာအားဖြင့်၊ သင်သည် လအလိုက် အပိုင်းခွဲများ ရှိပြီး၊ သင်သည် 2017 ခုနှစ်၏ ပထမလကို ယူ၍ ဆာဗာအသစ်သို့ ကူးယူပြီး တတိယလကို အခြားဆာဗာအသစ်အချို့သို့ ကူးယူပါ။ အနည်းနှင့်အများပင် ဖြစ်လာသည်အထိ သင်ဤသို့လုပ်ပါ။
ရိုက်ကူးနေစဉ်အတွင်း မပြောင်းလဲသော အခန်းကန့်များအတွက်သာ လွှဲပြောင်းနိုင်သည်။ အသစ်သောအပိုင်းများအတွက်၊ ၎င်းတို့၏လွှဲပြောင်းမှုသည် atomic မဟုတ်သောကြောင့် အသံသွင်းခြင်းကို ပိတ်ရပါမည်။ မဟုတ်ပါက၊ သင်သည် ဒေတာတွင် ထပ်တူများ သို့မဟုတ် ကွာဟမှုများဖြင့် အဆုံးသတ်သွားပါမည်။ သို့သော် ဤနည်းလမ်းသည် လက်တွေ့ကျပြီး ထိရောက်မှုရှိသည်။ အဆင်သင့်လုပ်ထားသော ချုံ့ထားသောအပိုင်းများကို ကွန်ရက်ပေါ်တွင် ပို့လွှတ်သည်၊ ဆိုလိုသည်မှာ ဒေတာကို ချုံ့ထားခြင်း သို့မဟုတ် ပြန်လည်ကုဒ်လုပ်ထားခြင်း မရှိပါ။
ဤနည်းလမ်းတွင် အားနည်းချက်တစ်ခုရှိသည်၊ ၎င်းသည် ဤ sharding scheme ကိုသင်ကတိကဝတ်ပြုသည်ဖြစ်စေ၊ သင့်တွင် sharding သော့ရှိမရှိအပေါ်တွင်မူတည်သည်။ မက်ထရစ်များဆိုင်ရာ ကိစ္စအတွက် သင့်ဥပမာတွင်၊ sharding key သည် လမ်းကြောင်း၏ hash ဖြစ်သည်။ ဖြန့်ဝေထားသောဇယားကို သင်ရွေးချယ်သောအခါ၊ ၎င်းသည် အစုအဝေးရှိ shards များအားလုံးသို့ တစ်ပြိုင်နက် ရောက်သွားပြီး ထိုနေရာမှ ဒေတာကို ရယူသည်။
ဆိုလိုသည်မှာ မည်သည့် shard တွင် ဒေတာ အဆုံးသတ်ခဲ့သည်မှာ သင့်အတွက် အမှန်တကယ် အရေးမကြီးကြောင်း ဆိုလိုသည်။ အဓိကအချက်မှာ လမ်းတစ်ခုတစ်လျှောက်ရှိ data များသည် shard တစ်ခုပေါ်တွင်အဆုံးသတ်သော်လည်း မည်သည့်အရာသည် အရေးမကြီးပါ။ ဤကိစ္စတွင်၊ အဆင်သင့်လုပ်ထားသော partitions များကို လွှဲပြောင်းခြင်းသည် ပြီးပြည့်စုံသည်၊ အဘယ်ကြောင့်ဆိုသော် ရွေးချယ်ထားသော queries ဖြင့် သင်သည် ပြန်လည်မမျှဝေမီ သို့မဟုတ် အပြီးတွင်ဖြစ်စေ ဒေတာအပြည့်အစုံကို သင်ရရှိနိုင်မည်ဖြစ်သောကြောင့် အစီအစဉ်သည် အမှန်တကယ် အရေးမကြီးပါ။
ဒါပေမယ့် ပိုရှုပ်ထွေးတဲ့ ကိစ္စတွေလည်း ရှိတယ်။ အပလီကေးရှင်းယုတ္တိအဆင့်တွင် သင်သည် အထူးခွဲဝေပေးသည့်အစီအစဉ်ကို အားကိုးပါက၊ ဤကလိုင်းယင့်သည် ထိုကဲ့သို့သော shard ပေါ်တွင်တည်ရှိပြီး တောင်းဆိုချက်အား ဖြန့်ဝေထားသောဇယားသို့မဟုတ်ဘဲ ထိုနေရာသို့ တိုက်ရိုက်ပေးပို့နိုင်သည်။ သို့မဟုတ် သင်သည် ClickHouse ၏ လတ်တလောဗားရှင်းကို အသုံးပြုနေပြီး ဆက်တင်ကို ဖွင့်ထားသည်။ အသုံးမပြုသော shards များကို ကျော်သွားခြင်းကို အကောင်းဆုံးဖြစ်အောင်လုပ်ပါ။. ဤကိစ္စတွင်၊ ရွေးချယ်ထားသော စုံစမ်းမှုအတွင်း၊ ခွဲခြမ်းစိတ်ဖြာမည့် ကဏ္ဍရှိ စကားရပ်ကို ခွဲခြမ်းစိပ်ဖြာသည့် အစီအစဉ်အရ မည်သည့် shards များကို အသုံးပြုရန် လိုအပ်သည်ကို တွက်ချက်မည်ဖြစ်သည်။ ဤ sharding scheme အရ ဒေတာကို အတိအကျ ပိုင်းခြားထားသောကြောင့် ၎င်းသည် အလုပ်လုပ်ပါသည်။ ၎င်းတို့ကို ကိုယ်တိုင်ပြန်စီစဉ်ပါက စာပေးစာယူသည် ပြောင်းလဲနိုင်သည်။
ဒါကြောင့် ဒီနည်းလမ်းက နံပါတ်တစ်ပါ။ ပြီးတော့ နည်းလမ်းက သင့်တော်သလား၊ ဒါမှမဟုတ် ဆက်လျှောက်ရအောင်၊ မင်းရဲ့အဖြေကို ငါစောင့်နေတယ်။
Avito ၏ဦးဆောင်စနစ်စီမံခန့်ခွဲသူ Vladimir Kolobaev: Alexey၊ သင်ဖော်ပြခဲ့သောနည်းလမ်းသည် စာဖတ်ခြင်းအပါအဝင် ဝန်ကိုဖြန့်ကြက်ရန် လိုအပ်သောအခါတွင် ကောင်းစွာအလုပ်မလုပ်ပါ။ ကျွန်ုပ်တို့သည် လစဉ်ပြုလုပ်ထားသော partition တစ်ခုကိုယူနိုင်ပြီး ယခင်လက အခြား node တစ်ခုသို့ ယူနိုင်သော်လည်း ဤဒေတာအတွက် တောင်းဆိုမှုတစ်ခုရောက်လာသောအခါတွင် ၎င်းကိုသာ တင်ပါမည်။ သို့သော် ကျွန်ုပ်တို့သည် အစုအဝေးတစ်ခုလုံးကို တင်လိုသည်၊ အကြောင်းမှာ၊ မဟုတ်ပါက၊ အချိန်အတိုင်းအတာတစ်ခုအထိ စာဖတ်ခြင်းဝန်တစ်ခုလုံးကို အပိုင်းနှစ်ပိုင်းဖြင့် လုပ်ဆောင်သွားမည်ဖြစ်သည်။
Alexey Milovidov ဤနေရာတွင် အဖြေက ထူးဆန်းသည် - ဟုတ်တယ်၊ ဆိုးတယ်၊ ဒါပေမယ့် အလုပ်ဖြစ်နိုင်တယ်။ လုပ်နည်းကို အတိအကျ ရှင်းပြပါ့မယ်။ သင့်ဒေတာနောက်ကွယ်တွင် ပါလာသည့် load scenario ကို ကြည့်ရကျိုးနပ်ပါသည်။ ၎င်းသည် ဒေတာကို စောင့်ကြည့်နေပါက၊ တောင်းဆိုချက်အများစုသည် ဒေတာအသစ်အတွက်ဖြစ်ကြောင်း ကျွန်ုပ်တို့ သေချာပေါက်နီးပါးပြောနိုင်ပါသည်။
သင်သည် ဆာဗာအသစ်များကို ထည့်သွင်းပြီး အပိုင်းဟောင်းများကို ရွှေ့ပြောင်းထားသော်လည်း အသစ်သောဒေတာကို မှတ်တမ်းတင်ပုံကိုလည်း ပြောင်းလဲခဲ့သည်။ နှင့် လတ်ဆတ်သော ဒေတာများကို အစုအဝေးတစ်ခုလုံး ပျံ့နှံ့သွားမည်ဖြစ်သည်။ ထို့ကြောင့်၊ ငါးမိနစ်ခန့်အကြာတွင်၊ နောက်ဆုံးငါးမိနစ်အတွက် တောင်းဆိုမှုများသည် အစုအဝေးကို အညီအမျှ သယ်ဆောင်လာမည်ဖြစ်ပြီး တစ်ရက်အကြာတွင်၊ XNUMX နာရီတောင်းဆိုမှုများသည် အစုကို အညီအမျှ သယ်ဆောင်လာမည်ဖြစ်သည်။ ကံမကောင်းစွာပဲ၊ ယခင်လအတွက် တောင်းဆိုချက်များသည် အစုလိုက်ဆာဗာများ၏ အစိတ်အပိုင်းများသို့သာ ရောက်သွားပါမည်။
သို့သော် မကြာခဏ သင့်တွင် ဖေဖော်ဝါရီ 2019 အတွက် အထူးတောင်းဆိုမှုများ ရှိမည်မဟုတ်ပါ။ ဖြစ်နိုင်ချေများသောအားဖြင့်၊ တောင်းဆိုမှုများသည် 2019 သို့ရောက်သွားပါက၊ ၎င်းတို့သည် 2019 တစ်ခုလုံးအတွက်ဖြစ်သည် - အချိန်အတိုင်းအတာတစ်ခုအထိ၊ သေးငယ်သောအတိုင်းအတာအတွက်မဟုတ်ပေ။ ထိုတောင်းဆိုချက်များသည် အစုအဝေးကို အညီအမျှ တင်နိုင်မည်ဖြစ်သည်။ သို့သော် ယေဘူယျအားဖြင့်၊ ဤသည်မှာ ဒေတာကို လုံးလုံးလျားလျား မဖြန့်ကျက်ဘဲ သီးသန့်ဖြေရှင်းချက်ဖြစ်သည်ဟူသော သင်၏မှတ်ချက်သည် လုံးဝမှန်ကန်ပါသည်။
မေးခွန်းကို ဖြေဖို့ နောက်ထပ် အချက်လေးတွေ ရှိပါသေးတယ်။ ၎င်းတို့ထဲမှ တစ်ခုမှာ ပြန်လည်ခွဲထုတ်ခြင်းသည် နာကျင်မှုကို သက်သာစေရန်အတွက် ခွဲခြမ်းစိပ်ဖြာခြင်း အစီအစဉ်ကို ကနဦး ဒီဇိုင်းရေးဆွဲနည်း အကြောင်းဖြစ်သည်။ ဒါက အမြဲတမ်း မဖြစ်နိုင်ပါဘူး။
ဥပမာအားဖြင့်၊ သင့်တွင်စောင့်ကြည့်ရေးဒေတာရှိသည်။ အကြောင်းရင်း သုံးခုကြောင့် စောင့်ကြည့်လေ့လာခြင်း ဒေတာ ကြီးထွားလာသည်။ ပထမအချက်မှာ သမိုင်းအချက်အလက် စုဆောင်းခြင်း ဖြစ်သည်။ ဒုတိယအချက်က ယာဉ်ကြော ပိတ်ဆို့မှု ကြီးထွားလာခြင်း ဖြစ်သည်။ တတိယအချက်မှာ စောင့်ကြည့်ရမည့်အရာ အရေအတွက် တိုးလာခြင်းဖြစ်သည်။ သိမ်းဆည်းရန် လိုအပ်သော အသေးစားဝန်ဆောင်မှုများနှင့် တိုင်းတာမှုအသစ်များ ရှိပါသည်။
ယင်းတို့အနက် အကြီးမားဆုံး တိုးလာမှုသည် ဖြစ်နိုင်ခြေရှိသော တတိယအကြောင်းရင်း - စောင့်ကြည့်အသုံးပြုမှု တိုးလာခြင်းဖြစ်သည်။ ဤကိစ္စတွင်၊ ဝန်၏သဘောသဘာဝ၊ အဓိကရွေးချယ်ထားသောမေးခွန်းများကား အဘယ်နည်း။ အခြေခံရွေးချယ်ထားသော မေးခွန်းများသည် အချို့သော မက်ထရစ်များ၏ အမျိုးအစားခွဲများအပေါ် အခြေခံ၍ ဖြစ်နိုင်ချေများပါသည်။
ဥပမာအားဖြင့်၊ အချို့သောဝန်ဆောင်မှုဖြင့် ဆာဗာများတွင် CPU အသုံးပြုမှု။ ဤဒေတာကို သင်ရရှိသည့် သော့အချို့ရှိနေကြောင်း တွေ့ရှိရပါသည်။ ထို့အပြင် ဤဒေတာအတွက် တောင်းဆိုချက်သည် အလွန်ရိုးရှင်းပြီး မီလီစက္ကန့် ဆယ်ဂဏန်းအတွင်း အပြီးသတ်နိုင်ဖွယ်ရှိသည်။ ဝန်ဆောင်မှုများနှင့် ဒက်ရှ်ဘုတ်များကို စောင့်ကြည့်ရန်အတွက် အသုံးပြုသည်။ ဒါကို မှန်မှန်ကန်ကန် နားလည်ဖို့ မျှော်လင့်ပါတယ်။
ဗလာဒီမာ Kolobaev အမှန်မှာ ကျွန်ုပ်တို့သည် လက်ရှိအခြေအနေနှင့် သမိုင်းဆိုင်ရာ အချက်အလက်များကို အချိန်နှင့်တပြေးညီ နှိုင်းယှဉ်ထားသောကြောင့် ကျွန်ုပ်တို့သည် သမိုင်းဆိုင်ရာ အချက်အလက်များကို မကြာခဏ အသနားခံလေ့ရှိပါသည်။ ပြီးတော့ ဒေတာအများအပြားကို မြန်မြန်ဆန်ဆန်ဝင်ရောက်နိုင်ဖို့က ကျွန်ုပ်တို့အတွက် အရေးကြီးပါတယ်၊ ClickHouse က ဒါကို အကောင်းဆုံးလုပ်ဆောင်ပါတယ်။
သင်လုံးဝမှန်ပါသည်၊ မည်သည့်စောင့်ကြည့်ရေးစနစ်ကဲ့သို့မဆို နောက်ဆုံးနေ့တွင် ဖတ်ရန်တောင်းဆိုချက်အများစုကို ကျွန်ုပ်တို့ တွေ့ကြုံခံစားရပါသည်။ သို့သော် တစ်ချိန်တည်းတွင်၊ သမိုင်းဆိုင်ရာ အချက်အလက် ဝန်ထုပ်ဝန်ပိုးသည် အလွန်ကြီးမားသည်။ အခြေခံအားဖြင့် ၎င်းသည် စက္ကန့်သုံးဆယ်ကြာတိုင်း လည်ပတ်နေသည့် အချက်ပေးစနစ်တစ်ခုမှဖြစ်ပြီး ClickHouse အား “ပြီးခဲ့သော ခြောက်ပတ်အတွက် ဒေတာကို ကျွန်ုပ်အား ပေးပါ။ အခု သူတို့ဆီက ရွေ့လျားနေတဲ့ ပျမ်းမျှပမာဏကို ဖန်တီးပြီး လက်ရှိတန်ဖိုးကို သမိုင်းတန်ဖိုးနဲ့ နှိုင်းယှဉ်ကြည့်ရအောင်။”
ယခုလို မကြာသေးမီက တောင်းဆိုမှုများအတွက် ကျွန်ုပ်တို့တွင် ဒေတာနှစ်ရက်သာ သိမ်းဆည်းထားသည့် အခြားဇယားသေးသေးလေး ရှိပြီး အဓိက တောင်းဆိုချက်များမှာ ၎င်းတွင် ပါဝင်ပါသည်။ ကျွန်ုပ်တို့သည် ကြီးမားသော သမိုင်းဝင်မေးခွန်းများကို ခွဲခြမ်းစိပ်စိပ်ထားသော စားပွဲကြီးဆီသို့သာ ပေးပို့ပါသည်။
Alexey Milovidov ကံမကောင်းစွာပဲ၊ ၎င်းသည် သင့်အခြေအနေအတွက် အသုံးချရန် ညံ့ဖျင်းပုံပေါ်သော်လည်း အသုံးပြုရန်မလိုအပ်သော်လည်း ကျွန်ုပ်၏သူငယ်ချင်းများ၏ ဝန်ဆောင်မှုတွင် အသုံးပြုသည့် ဆိုးရွားပြီး ရှုပ်ထွေးသော ခွဲခြမ်းစိပ်ဖြာမှုအစီအစဉ်နှစ်ခု၏ ဖော်ပြချက်ကို ကျွန်ုပ်ပြောပြပါမည်။
Yandex.Metrica ဖြစ်ရပ်များနှင့်အတူ အဓိကအစုအဝေးတစ်ခု ရှိပါသည်။ အစီအစဉ်များသည် စာမျက်နှာကြည့်ရှုမှု၊ ကလစ်များနှင့် ပြောင်းလဲမှုများဖြစ်သည်။ တောင်းဆိုမှုအများစုသည် သီးခြားဝဘ်ဆိုဒ်တစ်ခုသို့ သွားကြသည်။ သင်သည် Yandex.Metrica ဝန်ဆောင်မှုကိုဖွင့်ပြီး၊ သင့်တွင် ဝဘ်ဆိုက်တစ်ခုရှိသည် - avito.ru၊ အစီရင်ခံစာကိုသွားပါ၊ သင့်ဝဘ်ဆိုဒ်အတွက် တောင်းဆိုချက်တစ်ခု ပြုလုပ်ထားသည်။
သို့သော် အတွင်းပိုင်းလေ့လာသုံးသပ်သူများမှ ပြုလုပ်သော အခြားတောင်းဆိုချက်များ - ခွဲခြမ်းစိတ်ဖြာမှုနှင့် ကမ္ဘာလုံးဆိုင်ရာ တောင်းဆိုမှုများ ရှိပါသည်။ အခြေအနေတွင်၊ အတွင်းပိုင်းလေ့လာသုံးသပ်သူများသည် Yandex ဝန်ဆောင်မှုများအတွက်သာ တောင်းဆိုမှုများကို ပြုလုပ်ကြောင်း ကျွန်ုပ်သတိပြုမိပါသည်။ မည်သို့ပင်ဆိုစေကာမူ Yandex ဝန်ဆောင်မှုများသည် ဒေတာအားလုံး၏ သိသိသာသာဝေစုကို သိမ်းပိုက်ထားသည်။ ၎င်းတို့သည် သီးခြားကောင်တာများအတွက်မဟုတ်ဘဲ ပိုမိုကျယ်ပြန့်သော စစ်ထုတ်ခြင်းအတွက် တောင်းဆိုချက်များဖြစ်သည်။
ကောင်တာတစ်ခုတည်းအတွက်သာမက ကမ္ဘာလုံးဆိုင်ရာမေးခွန်းများပါ အရာအားလုံးကို ထိရောက်စွာအလုပ်လုပ်နိုင်စေရန် ဒေတာကို မည်သို့စုစည်းမည်နည်း။ နောက်အခက်အခဲတစ်ခုကတော့ မက်ထရစ်အစုအဝေးအတွက် ClickHouse မှာ တောင်းဆိုချက်အရေအတွက်ဟာ တစ်စက္ကန့်ကို ထောင်ပေါင်းများစွာ ရှိနေပါတယ်။ တစ်ချိန်တည်းမှာပင်၊ ClickHouse ဆာဗာတစ်ခုသည် အသေးအဖွဲမဟုတ်သော တောင်းဆိုချက်များကို ကိုင်တွယ်ဖြေရှင်းနိုင်မည်မဟုတ်ပေ၊ ဥပမာအားဖြင့် တစ်စက္ကန့်လျှင် ထောင်ပေါင်းများစွာ။
အစုအဝေးအရွယ်အစားသည် ခြောက်ရာရှိသော ဆာဗာများဖြစ်သည်။ အကယ်၍ သင်သည် ဤအစုအဝေးပေါ်မှ ဖြန့်ဝေထားသော ဇယားတစ်ခုကို ဆွဲထုတ်ပြီး ထိုနေရာတွင် တောင်းဆိုချက်ပေါင်း ထောင်ပေါင်းများစွာ ပေးပို့ပါက၊ ၎င်းတို့ကို ဆာဗာတစ်ခုသို့ ပေးပို့ခြင်းထက် ပိုဆိုးသွားပါမည်။ အခြားတစ်ဖက်တွင်၊ ဒေတာကို အညီအမျှ ဖြန့်ကျက်ပြီး ဆာဗာအားလုံးထံမှ တောင်းဆိုမှုအား ချက်ချင်းပယ်ဖျက်လိုက်ပါသည်။
Diametrically ဆန့်ကျင်ဘက်ဖြစ်သော ရွေးချယ်ခွင့်တစ်ခုရှိသည်။ ကျွန်ုပ်တို့သည် ဝဘ်ဆိုက်များတစ်လျှောက် ဒေတာများကို မျှဝေပြီး ဆိုက်တစ်ခုအတွက် တောင်းဆိုမှုတစ်ခုသည် shard တစ်ခုသို့ ရောက်သွားပါက စိတ်ကူးကြည့်ပါ။ ယခုအခါ အစုအဖွဲ့သည် တစ်စက္ကန့်လျှင် တောင်းဆိုချက်ပေါင်း တစ်သောင်းကို ကိုင်တွယ်နိုင်မည်ဖြစ်ပြီး၊ သို့သော် တောင်းဆိုချက်တစ်ခုတွင် မည်သည့်တောင်းဆိုမှုမဆို နှေးကွေးလွန်းသည်။ ဖြတ်သန်းမှု သတ်မှတ်ချက်အရ ၎င်းသည် အတိုင်းအတာ ချဲ့ထွင်တော့မည် မဟုတ်ပါ။ အထူးသဖြင့် ၎င်းသည် avito.ru ဆိုက်ဖြစ်ပါက။ Avito သည် RuNet တွင် အလည်အပတ် အများဆုံး ဆိုက်များထဲမှ တစ်ခုဟု ဆိုပါက လျှို့ဝှက်ချက်ကို ထုတ်ဖော်မည် မဟုတ်ပေ။ ၎င်းကို အကြမ်းထည်တစ်ခုပေါ်တွင် လုပ်ဆောင်ခြင်းသည် ရူးသွပ်မှုဖြစ်သည်။
ထို့ကြောင့် ခွဲခြမ်းစိပ်ဖြာခြင်းအစီအစဉ်ကို ပိုမိုလိမ္မာပါးနပ်စွာ ရေးဆွဲထားသည်။ အစုအဝေးတစ်ခုလုံးကို အလွှာများဟုခေါ်သော အစုအဝေးများစွာဖြင့် ပိုင်းခြားထားသည်။ အစုအဝေးတစ်ခုစီတွင် တစ်ဒါဇင်မှ ဒါဇင်များစွာသော shard များပါရှိသည်။ စုစုပေါင်း အစုအဝေး သုံးဆယ့်ကိုးခု ရှိတယ်။
ဒါတွေအားလုံးက ဘယ်လိုအတိုင်းအတာရှိလဲ။ အစုအဖွဲ့အရေအတွက်က မပြောင်းလဲပါဘူး - လွန်ခဲ့တဲ့နှစ်အနည်းငယ်က သုံးဆယ့်ကိုးနှစ်လောက်ကအတိုင်းပဲ ကျန်နေပါသေးတယ်။ သို့သော် ၎င်းတို့တစ်ခုစီအတွင်းတွင် ကျွန်ုပ်တို့သည် ဒေတာစုဆောင်းခြင်းဖြင့် shards အရေအတွက်ကို တဖြည်းဖြည်း တိုးလာပါသည်။ ခွဲခြမ်းစိပ်ဖြာခြင်းအစီအစဉ်တစ်ခုလုံးသည် ဤကဲ့သို့ဖြစ်သည်- ဤအစုအဝေးများကို ဝဘ်ဆိုဒ်များအဖြစ် ပိုင်းခြားထားပြီး မည်သည့်ဝဘ်ဆိုက်တွင် မည်သည့်အစုအဖွဲ့ရှိသည်ကို နားလည်ရန်အတွက် MySQL တွင် သီးခြား metabase ကို အသုံးပြုပါသည်။ ဆိုက်တစ်ခု - အစုအဖွဲ့တစ်ခုတွင်။ ၎င်းအတွင်းတွင်၊ ဧည့်သည် ID များနှင့်အညီ sharding ဖြစ်ပေါ်သည်။
မှတ်တမ်းတင်သည့်အခါ၊ ၎င်းတို့ကို ဧည့်သည် ID ၏ အကြွင်းဖြင့် ပိုင်းခြားပါသည်။ ဒါပေမယ့် shard အသစ်တစ်ခုထပ်ထည့်တဲ့အခါ၊ sharding scheme ကပြောင်းသွားပြီး၊ ဆက်ပြီးခွဲသွားပေမယ့် ကျန်ရှိတဲ့အပိုင်းကို အခြားနံပါတ်နဲ့ ခွဲပါတယ်။ ဆိုလိုသည်မှာ ဧည့်သည်တစ်ဦးသည် ဆာဗာများစွာပေါ်တွင် တည်ရှိနေပြီးဖြစ်ပြီး ၎င်းကို သင်အားကိုး၍မရပါ။ ဒေတာကို ပိုမိုကောင်းမွန်စွာ ချုံ့နိုင်စေရန် တစ်ခုတည်းကိုသာ လုပ်ဆောင်ပါသည်။ တောင်းဆိုမှုများပြုလုပ်သောအခါ၊ ကျွန်ုပ်တို့သည် အစုအဝေးကိုကြည့်ရှုပြီး ဆာဗာများစွာကို ဝင်ရောက်ကြည့်ရှုသည့် Distributed table သို့သွားပါ။ ဒါက မိုက်မဲတဲ့ အစီအစဥ်ပါပဲ။
ဒါပေမယ့် ဒီအစီအစဥ်ကို စွန့်လွှတ်တယ်လို့ မပြောရင် ငါ့ဇာတ်လမ်းက ပြီးပြည့်စုံမှာ မဟုတ်ပါဘူး။ အစီအစဥ်အသစ်တွင်၊ ကျွန်ုပ်တို့သည် အရာအားလုံးကို ပြောင်းလဲခဲ့ပြီး clickhouse-copier ကို အသုံးပြု၍ ဒေတာအားလုံးကို ကူးယူပါသည်။
အစီအစဥ်အသစ်တွင်၊ ဆိုက်အားလုံးကို အကြီးနှင့် အသေး အမျိုးအစား နှစ်မျိုးခွဲထားသည်။ သတ်မှတ်ချက်ကို မည်သို့ရွေးချယ်ခဲ့သည်ကို ကျွန်ုပ်မသိပါ၊ သို့သော် ရလဒ်မှာ ဆိုဒ်ကြီးများကို အစုလိုက်တစ်ခုတွင် မှတ်တမ်းတင်ထားပြီး၊ တစ်ခုစီတွင် ပုံတူသုံးမျိုးပါသော shard 120 ခုပါရှိသည် - ဆိုလိုသည်မှာ 360 ဆာဗာများဖြစ်သည်။ sharding အစီအစဉ်သည် မည်သည့်တောင်းဆိုမှုမဆို shards များအားလုံးသို့ တစ်ပြိုင်နက် ရောက်သွားစေရန်ဖြစ်သည်။ Yandex.Metrica တွင် Avito.ru အတွက် အစီရင်ခံစာစာမျက်နှာကို ယခုဖွင့်ပါက တောင်းဆိုချက်သည် ဆာဗာ 120 သို့သွားပါမည်။ RuNet တွင် ဆိုဒ်ကြီးအနည်းငယ်ရှိသည်။ တောင်းဆိုချက်တွေက တစ်စက္ကန့်ကို တစ်ထောင်မဟုတ်ပေမယ့် တစ်ရာထက်နည်းတယ်။ ဤအရာအားလုံးကို ဆာဗာ 120 ဖြင့် လုပ်ဆောင်ပေးသော Distributed table မှ တိတ်တဆိတ် ဝါးစားလိုက်ပါသည်။
ဒုတိယအစုသည် သေးငယ်သောဆိုဒ်များအတွက်ဖြစ်သည်။ ဤသည်မှာ site ID ကိုအခြေခံ၍ ခွဲခြမ်းစိပ်ဖြာခြင်းအစီအစဉ်ဖြစ်ပြီး တောင်းဆိုမှုတစ်ခုစီသည် shard တစ်ခုစီသို့သွားပါသည်။
ClickHouse တွင် clickhouse-copier utility ရှိသည်။ သူ့အကြောင်း ပြောပြနိုင်မလား။
ဒီဖြေရှင်းချက်က ပိုခက်ပြီး အတန်ငယ် အကျိုးနည်းတယ်လို့ ချက်ချင်းပြောမယ်။ အားသာချက်ကတော့ သင်သတ်မှတ်ထားတဲ့ ပုံစံအတိုင်း ဒေတာတွေကို လုံးလုံးလျားလျား လိမ်းပေးတာပါပဲ။ ဒါပေမယ့် utility ရဲ့ အားနည်းချက်ကတော့ လုံးဝ rehard မဖြစ်တာဘဲ။ ၎င်းသည် cluster schema တစ်ခုမှ data ကို အခြားသော cluster schema သို့ ကူးယူသည်။
ဆိုလိုသည်မှာ ၎င်းကိုလုပ်ဆောင်ရန်အတွက် သင့်တွင် အစုနှစ်ခုရှိရပါမည်။ ၎င်းတို့ကို တူညီသောဆာဗာများတွင် ထားရှိနိုင်သော်လည်း၊ မည်သို့ပင်ဆိုစေကာမူ ဒေတာများကို တိုးမြင့်ရွှေ့မည်မဟုတ်သော်လည်း ကူးယူသွားမည်ဖြစ်သည်။
ဥပမာအားဖြင့်၊ ဆာဗာ လေးခုရှိခဲ့သည်၊ ယခုအခါ ရှစ်ခုရှိသည်။ သင်သည် ဆာဗာအားလုံးတွင် ဖြန့်ဝေထားသော ဇယားအသစ်ကို ဖန်တီးပြီး၊ ဒေသဆိုင်ရာ ဇယားအသစ်များနှင့် clickhouse-copier ကိုဖွင့်ပြီး ၎င်းတွင် ၎င်းသည် ၎င်းမှဖတ်သင့်သည့် အလုပ်အစီအစဉ်ကို ညွှန်ပြကာ၊ sharding scheme အသစ်ကို လက်ခံပြီး ထိုနေရာတွင် ဒေတာကို လွှဲပြောင်းပါ။ ဆာဗာဟောင်းများတွင် ဒေတာဟောင်းများသည် ၎င်းတို့တွင် ရှိနေရမည်ဖြစ်သောကြောင့် ဒေတာဟောင်းများ၏ ထက်ဝက်သည် ၎င်းတို့အပေါ်တွင် ရှိနေမည်ဖြစ်၍ ယခုထက် တစ်ဆခွဲ ပိုနေရာယူရန် လိုအပ်မည်ဖြစ်သည်။ ဒေတာကို ပြန်လည်မျှဝေရန် လိုအပ်ပြီး နေရာလွတ်ရှိမည်ဟု ကြိုတွေးထားလျှင် ဤနည်းလမ်းသည် သင့်လျော်ပါသည်။
clickhouse-copier အတွင်းမှာ ဘယ်လိုအလုပ်လုပ်သလဲ။ ၎င်းသည် အလုပ်အားလုံးကို shard တစ်ခုပေါ်ရှိ ဇယားတစ်ခု၏ partition တစ်ခု၏ အပိုင်းတစ်ခုကို စီမံဆောင်ရွက်ရန်အတွက် အလုပ်များအားလုံးကို အပိုင်းတစ်ခုအဖြစ် ခွဲထားသည်။ ဤလုပ်ဆောင်စရာများအားလုံးကို အပြိုင်လုပ်ဆောင်နိုင်ပြီး၊ clickhouse-copier သည် မတူညီသောစက်များတွင် လုပ်ဆောင်နိုင်သည်၊ သို့သော် partition တစ်ခုအတွက် ၎င်းလုပ်ဆောင်သည့်အရာသည် insert select တစ်ခုထက်မပိုပါ။ ဒေတာကို ဖတ်ပြီး၊ ချုံ့လိုက်သည်၊ ပြန်ခွဲသည်၊ ထို့နောက် ထပ်ကာထပ်ကာ ချုံ့သည်၊ တစ်နေရာရာကို ရေးပြီး ပြန်စီထားသည်။ ဒါက ပိုပြင်းထန်တဲ့ ဆုံးဖြတ်ချက်ပါ။
သင့်တွင် ပြန်လည်စတင်ခြင်းဟုခေါ်သော ရှေ့ပြေးအရာတစ်ခု ရှိခဲ့သည်။ သူမနဲ့ ဘာဆိုင်လဲ။
2017 တွင်၊ သင့်တွင် ပြန်လည်ဆန်းသစ်ခြင်းဟုခေါ်သော ရှေ့ပြေးအရာတစ်ခု ရှိခဲ့သည်။ ClickHouse တွင်ရွေးချယ်စရာတစ်ခုရှိသည်။ ကျွန်တော်နားလည်သလောက်တော့ ပျက်မသွားပါဘူး။ ဘာကြောင့် ဒီလိုဖြစ်သွားတာလဲ ပြောပြနိုင်မလား။ အလွန်သက်ဆိုင်ပုံရသည်။
ပြဿနာတစ်ရပ်လုံးမှာ ဒေတာများကို ပြန်လည်သိမ်းဆည်းရန် လိုအပ်ပါက ယင်းကို အက်တမ်နည်းအရ လုပ်ဆောင်ရန်အတွက် အလွန်ရှုပ်ထွေးသော ထပ်တူပြုမှု လိုအပ်ပါသည်။ ဤထပ်တူပြုခြင်းလုပ်ဆောင်ပုံကို ကျွန်ုပ်တို့ စတင်ကြည့်ရှုသောအခါတွင် အခြေခံပြဿနာများရှိကြောင်း သိသာထင်ရှားလာပါသည်။ ဤအခြေခံပြဿနာများသည် သီအိုရီပိုင်းသာမကဘဲ ရိုးရှင်းစွာရှင်းပြနိုင်သော အရာတစ်ခု၏ပုံစံဖြင့် လက်တွေ့တွင် ချက်ချင်းဆိုသလို ၎င်းတို့ကိုယ်မိမိ ပြသလာသည် - ဘာမှအလုပ်မဖြစ်ပါ။
နှေးကွေးသောဒစ်များသို့မရွှေ့မီ ဒေတာအပိုင်းအားလုံးကို ပေါင်းစည်းရန် ဖြစ်နိုင်ပါသလား။
ပေါင်းစည်းခြင်း၏အကြောင်းအရာတွင် နှေးကွေးသောဒစ်ခ်ရွေးချယ်မှုသို့ ရွှေ့ခြင်းဖြင့် TTL အကြောင်းမေးခွန်း။ နှေးကွေးသောဒစ်များသို့မရွှေ့မီ အစိတ်အပိုင်းအားလုံးကို cron မှတစ်ဆင့် ပေါင်းစည်းရန် နည်းလမ်းရှိပါသလား။
မေးခွန်း၏အဖြေမှာ အပိုင်းအားလုံးကို မလွှဲပြောင်းမီ တစ်နည်းနည်းနှင့် အလိုအလျောက် ကော်သွားအောင် ပြုလုပ်နိုင်ပါမည်လား။ ဒါကို မလိုအပ်ဘူးလို့ ထင်ပါတယ်။ အစိတ်အပိုင်းအားလုံးကို တစ်ခုတည်းအဖြစ် ပေါင်းစည်းရန် မလိုအပ်သော်လည်း ၎င်းတို့ကို နှေးကွေးသော disks များထံ အလိုအလျောက် လွှဲပြောင်းပေးမည်ဟူသောအချက်ကို ရိုးရိုးလေးသာ အားကိုးပါ။
အပြောင်းအရွှေ့စည်းမျဉ်းများအတွက် စံသတ်မှတ်ချက်နှစ်ခုရှိသည်။ ပထမတစ်ခုက ဖြည့်ထားတဲ့အတိုင်းပါပဲ။ လက်ရှိသိုလှောင်မှုအဆင့်တွင် နေရာလွတ်အချို့ရာခိုင်နှုန်းထက်နည်းပါက၊ ကျွန်ုပ်တို့သည် အပိုင်းတစ်ခုကို ရွေးချယ်ပြီး ၎င်းကို နှေးကွေးသောသိုလှောင်မှုသို့ ရွှေ့ပါ။ သို့မဟုတ်၊ မနှေးသော်လည်း၊ သင် configure လုပ်ထားသည့်အတိုင်း၊ နောက်တစ်ခု။
ဒုတိယစံသတ်မှတ်ချက်မှာ အရွယ်အစားဖြစ်သည်။ ကြီးမားသောအပိုင်းများကို ရွှေ့ခြင်းအကြောင်းဖြစ်သည်။ အမြန်ဒစ်ပေါ်ရှိ နေရာလွတ်များအလိုက် တံခါးခုံကို ချိန်ညှိနိုင်ပြီး ဒေတာကို အလိုအလျောက် လွှဲပြောင်းပေးမည်ဖြစ်သည်။
လိုက်ဖက်ညီမှုကို ကြိုတင်စစ်ဆေးရန် နည်းလမ်းမရှိပါက ClickHouse ၏ ဗားရှင်းအသစ်များသို့ မည်သို့ပြောင်းရွှေ့ရမည်နည်း။
ဤအကြောင်းအရာကို ပုံမှန်ဆွေးနွေးသည်။ အကောင့်အမျိုးမျိုးကိုဗားရှင်းထည့်သွင်းခြင်းနှင့်နေဆဲဖြစ်သည်။ ဗားရှင်း 19.11 မှ 19.16 သို့ အဆင့်မြှင့်တင်ရန်နှင့် ဥပမာ 19.16 မှ 20.3 သို့ အဆင့်မြှင့်တင်ရန် မည်မျှ အန္တရာယ်ကင်းသနည်း။ Sandbox တွင် လိုက်ဖက်ညီမှုကို ကြိုတင်စစ်ဆေးနိုင်ခြင်းမရှိဘဲ ဗားရှင်းအသစ်များသို့ ပြောင်းရွှေ့ရန် အကောင်းဆုံးနည်းလမ်းမှာ အဘယ်နည်း။
ဤနေရာတွင် "ရွှေ" စည်းမျဉ်းများစွာရှိသည်။ ပထမ- . ၎င်းသည် ကြီးမားသော်လည်း နောက်ပြန်မလိုက်နိုင်သော ပြောင်းလဲမှုများအကြောင်း သီးခြားစာပိုဒ်များရှိပါသည်။ ဒီအချက်တွေကို အနီရောင်အလံအဖြစ် မသတ်မှတ်ပါနဲ့။ ၎င်းတို့သည် အများအားဖြင့် သင်အသုံးမပြုနိုင်သော အနားသတ်လုပ်ဆောင်ချက်အချို့ပါ၀င်သည့် အသေးအဖွဲများဖြစ်သည်။
ဒုတိယအနေဖြင့်၊ sandbox တွင် လိုက်ဖက်ညီမှုကို စစ်ဆေးရန် နည်းလမ်းမရှိသဖြင့် ထုတ်လုပ်မှုတွင် ချက်ချင်းမွမ်းမံလိုပါက၊ ၎င်းကို သင်လုပ်ဆောင်ရန် မလိုအပ်ကြောင်း အကြံပြုချက်ဖြစ်သည်။ ပထမဆုံး sandbox တစ်ခုကို ဖန်တီးပြီး စမ်းသပ်ပါ။ စမ်းသပ်မှုပတ်ဝန်းကျင်မရှိပါက သင့်တွင် အလွန်ကြီးမားသောကုမ္ပဏီတစ်ခုမှ မရှိနိုင်ချေ၊ ဆိုလိုသည်မှာ သင်သည် ဒေတာအချို့ကို သင့်လက်ပ်တော့သို့ ကူးယူနိုင်ပြီး ၎င်းတွင် အရာအားလုံးမှန်ကန်ကြောင်း သေချာပါစေ။ သင့်စက်ပေါ်တွင် ပုံတူအများအပြားကို စက်တွင်း၌ပင် သင်တင်နိုင်သည်။ သို့မဟုတ် သင်သည် အနီးအနားတစ်နေရာ၌ ဗားရှင်းအသစ်တစ်ခုကို ကောက်ယူပြီး ထိုနေရာတွင် ဒေတာအချို့ကို အပ်လုဒ်လုပ်နိုင်သည် - ဆိုလိုသည်မှာ၊ တီထွင်ထားသော စမ်းသပ်မှုပတ်ဝန်းကျင်ကို ဖန်တီးပါ။
ထုတ်လုပ်မှုတွင် bugs ဖမ်းမိခြင်းနှင့် နောက်ဆက်တွဲ အမြန်ပြင်ဆင်မှုများကြောင့် ဗားရှင်းထွက်ပြီး တစ်ပတ်အကြာတွင် နောက်ထပ်စည်းမျဉ်းတစ်ခု အပ်ဒိတ်မလုပ်ရပါ။ စိတ်ရှုပ်မခံရအောင် ClickHouse ဗားရှင်းများ၏ နံပါတ်များကို တွက်ကြည့်ရအောင်။
ဗားရှင်း 20.3.4 ရှိပါတယ်။ နံပါတ် 20 သည် ထုတ်လုပ်သည့်နှစ် - 2020 ကို ညွှန်ပြပါသည်။ အတွင်း၌ရှိသော အရာများကို ရှုမြင်ပါက ၎င်းသည် အရေးမကြီးပါ၊ ထို့ကြောင့် ၎င်းကို ကျွန်ုပ်တို့ ဂရုမစိုက်ပါ။ နောက်တစ်ခု - 20.3 ။ ကျွန်ုပ်တို့သည် ဒုတိယနံပါတ်ကို တိုးမြှင့်သည် - ဤကိစ္စတွင် 3 - ကျွန်ုပ်တို့သည် လုပ်ဆောင်ချက်အသစ်များဖြင့် ထုတ်ဝေမှုအား ထုတ်ပြန်သည့်အခါတိုင်း၊ ကျွန်ုပ်တို့သည် ClickHouse တွင် အင်္ဂါရပ်အချို့ကို ထည့်လိုပါက ဤနံပါတ်ကို တိုးမြှင့်ရပါမည်။ ဆိုလိုသည်မှာ၊ ဗားရှင်း 20.4 ClickHouse တွင် ပို၍ပင် ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ တတိယဂဏန်းမှာ 20.3.4 ဖြစ်သည်။ ဤတွင် 4 သည် ကျွန်ုပ်တို့သည် စွမ်းဆောင်ချက်အသစ်များမထည့်ဘဲ ချို့ယွင်းချက်အချို့ကို ပြင်ဆင်ထားသည့် patch ထုတ်ဝေမှုအရေအတွက်ဖြစ်သည်။ 4 ဆိုလိုတာက လေးကြိမ်လုပ်တယ်။
ဒါက ကြောက်စရာကောင်းတဲ့ အရာလို့ မထင်ပါနဲ့။ အများအားဖြင့် အသုံးပြုသူသည် နောက်ဆုံးထွက်ဗားရှင်းကို ထည့်သွင်းနိုင်ပြီး တစ်နှစ်လျှင် uptime တွင် ပြဿနာတစ်စုံတစ်ရာမရှိဘဲ လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ သို့သော် ကျွန်ုပ်တို့၏တရုတ်ရဲဘော်များထည့်ထားသည့် ဘစ်မြေပုံများလုပ်ဆောင်ခြင်းအတွက် လုပ်ဆောင်ချက်အချို့တွင် မှားယွင်းသောအကြောင်းပြချက်များကိုဖြတ်သန်းသည့်အခါ ဆာဗာသည် ပျက်သွားသည်ကို စိတ်ကူးကြည့်ပါ။ ဒါကိုပြင်ဖို့ ကျွန်တော်တို့မှာ တာဝန်ရှိတယ်။ ကျွန်ုပ်တို့သည် patch ဗားရှင်းအသစ်ကို ထုတ်ပြန်မည်ဖြစ်ပြီး ClickHouse ပိုမိုတည်ငြိမ်လာမည်ဖြစ်သည်။
အကယ်၍ သင့်တွင် ClickHouse ကို ထုတ်လုပ်မှုတွင် လုပ်ဆောင်နေပါက၊ ClickHouse ၏ ဗားရှင်းအသစ်သည် ထပ်လောင်းအင်္ဂါရပ်များ ထွက်ပေါ်လာသည် - ဥပမာ၊ 20.4.1 သည် ပထမဆုံးဖြစ်ပြီး၊ ၎င်းကို ပထမဆုံးနေ့တွင် ထုတ်လုပ်ရန် အလျင်စလိုမလုပ်ပါနှင့်။ ဘာကြောင့်တောင် လိုအပ်တာလဲ။ အကယ်၍ သင်သည် ClickHouse ကို အသုံးမပြုရသေးပါက ၎င်းကို သင်ထည့်သွင်းနိုင်ပြီး အရာအားလုံး အဆင်ပြေသွားမည်ဖြစ်သည်။ သို့သော် ClickHouse သည် တည်ငြိမ်စွာအလုပ်လုပ်နေပြီဖြစ်ပါက ကျွန်ုပ်တို့ဖြေရှင်းနေသည့်ပြဿနာများကို သိရှိနိုင်ရန် ဖာထေးမှုများနှင့် အပ်ဒိတ်များကို စောင့်ကြည့်ပါ။
Kirill Shvakov- စာမေးပွဲပတ်ဝန်းကျင်အကြောင်း နည်းနည်းထည့်ချင်ပါတယ်။ လူတိုင်းသည် စမ်းသပ်ပတ်ဝန်းကျင်များကို အလွန်ကြောက်ကြပြီး သင့်တွင် အလွန်ကြီးမားသော ClickHouse အစုအဝေးတစ်ခုရှိလျှင် စမ်းသပ်ပတ်ဝန်းကျင်သည် မနည်း သို့မဟုတ် အနည်းဆုံး ဆယ်ဆ ပိုသေးငယ်သင့်သည်ဟု ယုံကြည်ကြသည်။ အဲဒါ လုံးဝမကြိုက်ဘူး။
ငါ မင်းကို ငါ့ရဲ့ ဥပမာကနေ ပြောပြနိုင်တယ်။ ငါ့မှာ ပရောဂျက်တစ်ခုရှိပြီး ClickHouse ရှိတယ်။ ကျွန်ုပ်တို့၏စမ်းသပ်မှုပတ်ဝန်းကျင်သည် သူ့အတွက်သာဖြစ်သည် - ဤအရာအားလုံးသည် လုံးဝအသုံးပြုနိုင်သည့် ယူရိုနှစ်ဆယ်တန် Hetzner ရှိ အသေးစား virtual machine တစ်ခုဖြစ်သည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ ကျွန်ုပ်တို့တွင် Ansible တွင် အလိုအလျောက်စနစ် အပြည့်အဝရှိသည်၊ ထို့ကြောင့် မူအရ၊ ၎င်းသည် ဟာ့ဒ်ဝဲဆာဗာများသို့ သွားရမည့်နေရာ သို့မဟုတ် virtual machines များတွင် ဖြန့်ကျက်ထားရုံဖြင့် မထူးခြားပါ။
ဘာတွေလုပ်ဆောင်နိုင်မလဲ။ သင့်အိမ်တွင် အစုအဝေးငယ်တစ်ခုကို ဖြန့်ကျက်နည်းနှင့်ပတ်သက်သည့် ClickHouse စာရွက်စာတမ်းတွင် ဥပမာတစ်ခုပေးခြင်းဖြင့် Docker၊ LXC တွင် Ansible playbook ကိုဖန်တီးနိုင်သည်၊ အကြောင်းမှာ မတူညီသောလူများတွင် မတူညီသောနေရာချထားမှုများရှိသောကြောင့်ဖြစ်သည်။ ဒါကအများကြီးရိုးရှင်းပါလိမ့်မယ်။ ငါးမိနစ်အတွင်း အစုအဖွဲ့တစ်ခုကို သင်ယူ၍ အသုံးချသည့်အခါ၊ တစ်ခုခုကို ဖော်ထုတ်ရန် ကြိုးစားရန် ပိုမိုလွယ်ကူသည်။ သင်မစမ်းသပ်ရသေးသော ထုတ်လုပ်မှုဗားရှင်းသို့ ကူးပြောင်းခြင်းသည် မည်သည့်နေရာသို့ မရောက်နိုင်သောကြောင့် ၎င်းသည် ပို၍အဆင်ပြေပါသည်။ တစ်ခါတလေ အလုပ်ဖြစ်တတ်သလို တစ်ခါတလေလည်း မလုပ်တတ်ပါဘူး။ ထို့ကြောင့် အောင်မြင်မှုကို မျှော်လင့်ခြင်းသည် မကောင်းပါ။
Maxim Kotyakov၊ အကြီးတန်း backend အင်ဂျင်နီယာ Avito ကုမ္ပဏီကြီးတွေရဲ့ ရင်ဆိုင်နေရတဲ့ ပြဿနာပေါင်းစုံကနေ စမ်းသပ်မှုပတ်ဝန်းကျင်အကြောင်း နည်းနည်းထပ်ပြောမယ်။ ကျွန်ုပ်တို့တွင် ပြည့်စုံသော ClickHouse လက်ခံမှုအစုအဝေးတစ်ခုရှိသည်။ ဒေတာအစီအစဉ်များနှင့် ဆက်တင်များနှင့်ပတ်သက်၍၊ ၎င်းသည် ထုတ်လုပ်မှု၏အတိအကျမိတ္တူဖြစ်သည်။ ဤအစုအဝေးကို အရင်းအမြစ် အနည်းဆုံးဖြင့် မျှမျှတတ အကျုံးဝင်သော ကွန်တိန်နာများတွင် အသုံးပြုထားသည်။ ကျွန်ုပ်တို့သည် ထိုနေရာတွင် ထုတ်လုပ်မှုဒေတာ၏ အချို့သောရာခိုင်နှုန်းကို ရေးပေးသည်၊ ကံကောင်းစွာပင် Kafka တွင် စီးကြောင်းကို ပုံတူပွားရန် ဖြစ်နိုင်သည်။ ရှိရှိသမျှ အရာအားလုံးကို ထပ်တူကျစေပြီး အတိုင်းအတာ- စွမ်းရည်နှင့် စီးဆင်းမှု နှစ်မျိုးလုံးနှင့် သီအိုရီအရ၊ အခြားအရာအားလုံးသည် တန်းတူဖြစ်ပြီး၊ ၎င်းသည် မက်ထရစ်များဆိုင်ရာ ထုတ်လုပ်မှုကဲ့သို့ ပြုမူသင့်သည်။ ပေါက်ကွဲနိုင်ချေရှိသော အရာအားလုံးကို ဤစရပ်တွင် ဦးစွာလှိမ့်ပြီး အဆင်သင့်မဖြစ်မီအထိ ရက်အတော်ကြာအောင် ထိုနေရာတွင် ထားခဲ့ပါ။ သို့သော် သဘာဝအတိုင်း၊ ဤဖြေရှင်းချက်သည် စျေးကြီးသည်၊ ခက်ခဲပြီး သုညမဟုတ်သော ပံ့ပိုးမှုစရိတ်များရှိသည်။
Alexey Milovidov Yandex.Metrica မှကျွန်ုပ်တို့၏သူငယ်ချင်းများ၏စမ်းသပ်မှုပတ်ဝန်းကျင်သည်သင့်အားပြောပြပါမည်။ အစုအဝေးတစ်ခုတွင် ထူးဆန်းသောဆာဗာ 600 ရှိသည်၊ နောက်တစ်ခုတွင် 360 ရှိပြီး တတိယနှင့် အစုအဝေးများစွာရှိသည်။ ၎င်းတို့အနက်မှ တစ်ခုအတွက် စမ်းသပ်မှုပတ်ဝန်းကျင်သည် တစ်ခုစီတွင် ပုံစံတူနှစ်ခုပါသည့် ရိုးရှင်းသော အပိုင်းနှစ်ပိုင်းဖြစ်သည်။ ဘာကြောင့် ကြိုးနှစ်ချောင်း ဒါမှ မင်းတစ်ယောက်တည်းမဟုတ်ဘူး။ ပုံတူတွေလည်း ရှိသင့်ပါတယ်။ သင်တတ်နိုင်သော အနည်းဆုံးပမာဏတစ်ခုမျှသာ။
ဤစမ်းသပ်မှုပတ်ဝန်းကျင်တွင် သင့်မေးမြန်းချက်များသည် အလုပ်ဖြစ်မဖြစ်နှင့် ကြီးကြီးမားမားတစ်စုံတစ်ရာ ပျက်သွားခြင်းရှိမရှိ စစ်ဆေးနိုင်စေပါသည်။ သို့သော် အရာရာတိုင်း အလုပ်လုပ်သောအခါတွင် လုံးဝကွဲပြားသော သဘောသဘာဝအရ ပြဿနာများ ပေါ်ပေါက်တတ်သော်လည်း ဝန်တွင် အနည်းငယ်သော အပြောင်းအလဲများရှိသည်။
ဥပမာတစ်ခုပေးပါရစေ။ ClickHouse ဗားရှင်းအသစ်ကို ထည့်သွင်းရန် ဆုံးဖြတ်ခဲ့သည်။ ၎င်းကို စမ်းသပ်မှုပတ်ဝန်းကျင်တွင် ပို့စ်တင်ထားပြီး၊ အလိုအလျောက်စမ်းသပ်မှုများကို Yandex.Metrica ကိုယ်တိုင် ပြီးမြောက်ခဲ့ပြီး၊ ပိုက်လိုင်းတစ်ခုလုံးကို လည်ပတ်နေသည့် ဗားရှင်းဟောင်းနှင့် အသစ်တွင် ဒေတာကို နှိုင်းယှဉ်ပေးပါသည်။ ကျွန်ုပ်တို့၏ CI ၏ စိမ်းလန်းသော စမ်းသပ်မှုများ။ မဟုတ်ရင် ဒီဗားရှင်းကို ကျွန်တော်တို့တောင် အဆိုပြုမှာ မဟုတ်ဘူး။
အားလုံးအဆင်ပြေတယ်။ ကျွန်ုပ်တို့သည် ထုတ်လုပ်ရေးသို့ စတင်ရောက်ရှိနေပြီဖြစ်သည်။ ဂရပ်များပေါ်ရှိ load သည် အဆများစွာ တိုးလာကြောင်း သတင်းတစ်ခု ရရှိခဲ့ပါသည်။ ကျွန်ုပ်တို့သည် ဗားရှင်းကို ပြန်ဖွင့်နေပါသည်။ ဂရပ်ကိုကြည့်၍ မြင်သည်- လွှင့်တင်စဉ်အတွင်း ဝန်သည် အမှန်တကယ် အကြိမ်များစွာ တိုးလာပြီး ၎င်းတို့ ထုတ်သည့်အခါတွင် ပြန်လျော့သွားပါသည်။ ထို့နောက် ကျွန်ုပ်တို့သည် ဗားရှင်းကို ပြန်လည်စတင်ခဲ့သည်။ ဝန်သည် ထိုနည်းအတိုင်း တိုး၍ ထိုနည်းအတိုင်း ပြန်ကျလေ၏။ ထို့ကြောင့် နိဂုံးချုပ်ချက်မှာ ဤအရာဖြစ်သည်- အဆင်အပြင်ကြောင့် ဝန်တိုးလာသည်၊ အံ့သြစရာမရှိပါ။
ထို့နောက် ဗားရှင်းအသစ်ကို ထည့်သွင်းရန် လုပ်ဖော်ကိုင်ဖက်များအား စည်းရုံးရန် ခက်ခဲသည်။ ငါပြောတယ်- "အဆင်ပြေပါတယ်၊ လှည့်လိုက်ပါ။ သင့်လက်ချောင်းများကို ဖြတ်ထားပါ၊ အရာအားလုံး အဆင်ပြေသွားပါမည်။ ယခု ဂရပ်ဖစ်ပေါ်တွင် ဝန်တိုးလာသော်လည်း အရာအားလုံး အဆင်ပြေပါသည်။ ဟိုမှာထိုင်။" ယေဘူယျအားဖြင့်၊ ငါတို့က ဒါကိုလုပ်တယ်၊ ဒါပဲ - ဗားရှင်းကို ထုတ်လုပ်ဖို့အတွက် ထုတ်ထားတာ။ ဒါပေမယ့် အပြင်အဆင်တိုင်းလိုလိုမှာ အလားတူပြဿနာတွေ ပေါ်လာပါတယ်။
Kill query သည် queries ကိုသတ်ပစ်ရန် ရည်မှန်းထားသော်လည်း ထိုသို့မဖြစ်ပါ။ အဘယ်ကြောင့်?
အသုံးပြုသူတစ်ဦး၊ လေ့လာဆန်းစစ်သူအချို့သည် ကျွန်ုပ်ထံလာပြီး ကျွန်ုပ်၏ ClickHouse အစုအဝေးကို ထည့်သွင်းရန် တောင်းဆိုချက်တစ်ခုကို ဖန်တီးခဲ့သည်။ မည်သည့်ပုံစံတူ သို့မဟုတ် shard တောင်းဆိုမှုသို့သွားသည်ပေါ်မူတည်၍ အချို့သော node သို့မဟုတ် cluster တစ်ခုလုံး။ ဤဆာဗာရှိ CPU အရင်းအမြစ်များအားလုံးသည် စင်တစ်ခုထဲတွင် ရှိနေသည်ကို ကျွန်ုပ်မြင်ရပြီး အရာအားလုံးသည် အနီရောင်ဖြစ်သည်။ တစ်ချိန်တည်းတွင်၊ ClickHouse ကိုယ်တိုင်က တောင်းဆိုမှုများကို တုံ့ပြန်သည်။ ပြီးတော့ ငါရေးတယ်- "ကျေးဇူးပြုပြီး လုပ်ငန်းစဉ်စာရင်းကို ပြပါ၊ ဒီရူးသွပ်မှုကို ဖြစ်ပေါ်စေတဲ့ ဘယ်တောင်းဆိုချက်လဲ။"
ဒီတောင်းဆိုချက်ကို တွေ့ပြီး သတ်ပစ်ဖို့ ရေးလိုက်တယ်။ ပြီးတော့ ဘာမှမဖြစ်ဘူးဆိုတာ ငါမြင်တယ်။ ကျွန်ုပ်၏ဆာဗာသည် စင်တစ်ခုတွင် ရှိနေသည်၊ ထို့နောက် ClickHouse သည် ကျွန်ုပ်အား အမိန့်အချို့ပေးသည်၊ ဆာဗာသည် အသက်ရှင်နေသေးကြောင်းပြသပြီး အရာအားလုံးသည် ကောင်းမွန်ပါသည်။ သို့သော် ကျွန်ုပ်တွင် အသုံးပြုသူ တောင်းဆိုချက်များအားလုံးတွင် ပျက်စီးယိုယွင်းသွားသည်၊ ClickHouse တွင် မှတ်တမ်းများ ပျက်ယွင်းခြင်းမှ အစပြုကာ ကျွန်ုပ်၏ သတ်ပစ်ရန် တောင်းဆိုချက်သည် အလုပ်မဖြစ်ပါ။ အဘယ်ကြောင့်? kill query သည် queries ကိုသတ်ပစ်မည်ဟုထင်ခဲ့သည်၊ သို့သော်မဖြစ်ပါ။
အခု ထူးထူးခြားခြား အဖြေတစ်ခု ပေါ်လာလိမ့်မယ်။ ဆိုလိုသည်မှာ kill query သည် queries ကိုသတ်ခြင်းမဟုတ်ပါ။
Kill query သည် "ဤမေးခွန်းကို သတ်ပစ်ချင်သည်" ဟု ခေါ်သည့် အကွက်ငယ်ကို စစ်ဆေးသည်။ ပိတ်ဆို့ခြင်းတစ်ခုစီကို လုပ်ဆောင်သည့်အခါ တောင်းဆိုချက်သည် ဤအလံကို ကြည့်ရှုသည်။ သတ်မှတ်ပါက၊ တောင်းဆိုချက် အလုပ်မလုပ်တော့ပါ။ တောင်းဆိုချက်အား မည်သူမျှ မသတ်ခဲ့ကြောင်း ပေါ်ထွက်ခဲ့ပြီး၊ သူကိုယ်တိုင် အရာအားလုံးကို စစ်ဆေးပြီး ရပ်တန့်ရမည်ဖြစ်သည်။ တောင်းဆိုချက်သည် အချက်အလက်တုံးများကို လုပ်ဆောင်နေသည့် အခြေအနေတွင်ရှိသည့် ကိစ္စတိုင်းတွင် ၎င်းသည် လုပ်ဆောင်သင့်သည်။ ၎င်းသည် လာမည့်ဒေတာဘလောက်ကို လုပ်ဆောင်မည်၊ အလံကိုစစ်ဆေးပြီး ရပ်သွားမည်ဖြစ်သည်။
လုပ်ဆောင်ချက်အချို့တွင် တောင်းဆိုမှုကို ပိတ်ဆို့ထားသည့်ကိစ္စများတွင် ၎င်းသည် အလုပ်မဖြစ်ပါ။ မှန်ပါတယ်၊ ဒါက သင့်ကိစ္စမဟုတ်ဘူး၊ ဘာကြောင့်လဲဆိုတော့ သင့်အနေနဲ့ ဆာဗာရင်းမြစ်တွေ အများကြီးကို အသုံးပြုထားလို့ပါပဲ။ ပြင်ပအမျိုးအစားခွဲခြင်းနှင့် အခြားအသေးစိတ်အချက်အချို့တွင် ၎င်းသည် အလုပ်မဖြစ်နိုင်ပါ။ ဒါပေမယ့် ယေဘုယျအားဖြင့်တော့ ဒါဟာ မဖြစ်သင့်ပါဘူး၊ ဒါဟာ bug တစ်ခုပါ။ ကျွန်ုပ်အကြံပြုနိုင်သည့်တစ်ခုတည်းသောအရာမှာ ClickHouse ကိုမွမ်းမံရန်ဖြစ်သည်။
Read load အောက်တွင် တုံ့ပြန်မှုအချိန်ကို မည်သို့တွက်ချက်မည်နည်း။
ပစ္စည်း အစုအဝေးများကို သိမ်းဆည်းသည့် စားပွဲတစ်ခု ရှိသည် - ကောင်တာအမျိုးမျိုး။ လိုင်းအရေအတွက်က သန်းတစ်ရာနီးပါးရှိတယ်။ အကယ်၍ သင်သည် 1K ပစ္စည်းများအတွက် 1K RPS လောင်းပါက ခန့်မှန်းနိုင်သော တုံ့ပြန်မှုအချိန်ကို တွက်ချက်နိုင်ပါသလား။
အကြောင်းအရင်းကို သုံးသပ်ကြည့်လျှင် စာရေးရာတွင် ပြဿနာမရှိသောကြောင့် - တစ်ထောင်၊ တစ်သိန်းပင်၊ တစ်ခါတစ်ရံတွင် အတန်းပေါင်း သန်းပေါင်းများစွာ ထည့်သွင်းနိုင်သည်။
စာဖတ်ခြင်းတောင်းဆိုမှုများသည် အလွန်ကွဲပြားပါသည်။ ရွေးချယ်ထားသော 1 တွင်၊ ClickHouse သည် တစ်စက္ကန့်လျှင် သောင်းနှင့်ချီသော တောင်းဆိုမှုများကို လုပ်ဆောင်နိုင်သည်၊ ထို့ကြောင့် သော့တစ်ခုအတွက် တောင်းဆိုမှုများပင် ရင်းမြစ်အချို့ လိုအပ်နေပြီဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် ထိုသို့သောအချက်ပြမေးခွန်းများသည် အချို့သောသော့တန်ဖိုးဒေတာဘေ့စ်များထက် ပို၍ခက်ခဲလိမ့်မည်၊ အကြောင်းမှာ စာဖတ်တိုင်းအတွက် ဒေတာဘလောက်တစ်ခုကို အညွှန်းဖြင့်ဖတ်ရန် လိုအပ်သောကြောင့်ဖြစ်သည်။ ကျွန်ုပ်တို့၏အညွှန်းကိန်းသည် မှတ်တမ်းတစ်ခုစီမဟုတ်သော်လည်း အပိုင်းအခြားတစ်ခုစီကို ဖော်ပြသည်။ ဆိုလိုသည်မှာ၊ သင်သည် အကွာအဝေးတစ်ခုလုံးကို ဖတ်ရမည်ဖြစ်ပြီး၊ ၎င်းသည် ပုံသေအားဖြင့် 8192 လိုင်းဖြစ်သည်။ 64 KB မှ 1 MB မှ compressed data block ကို decompress လုပ်ရပါမည်။ ပုံမှန်အားဖြင့်၊ ထိုသို့သော ပစ်မှတ်ထားသော မေးခွန်းများသည် ပြီးမြောက်ရန် မီလီစက္ကန့်အနည်းငယ် ကြာသည်။ ဒါပေမယ့် ဒါက အရိုးရှင်းဆုံး ရွေးချယ်မှုပါ။
ရိုးရှင်းသောဂဏန်းသင်္ချာကို စမ်းကြည့်ရအောင်။ မီလီစက္ကန့်အနည်းငယ်ကို ထောင်ဂဏန်းနဲ့ မြှောက်ရင် စက္ကန့်အနည်းငယ် ရနိုင်ပါတယ်။ တစ်စက္ကန့်လျှင် တောင်းဆိုချက်တစ်ထောင်ကို အမှီလိုက်ရန် မဖြစ်နိုင်သကဲ့သို့၊ ကျွန်ုပ်တို့တွင် ပရိုဆက်ဆာ core များစွာရှိသောကြောင့် ဖြစ်နိုင်သည်။ ထို့ကြောင့်၊ မူအရ၊ ClickHouse သည် တစ်ခါတစ်ရံတွင် 1000 RPS ကို ထိန်းထားနိုင်သော်လည်း တိုတောင်းသောတောင်းဆိုမှုများအတွက်၊ အထူးသဖြင့် ပစ်မှတ်ထားသောအရာများဖြစ်သည်။
အကယ်၍ သင်သည် ClickHouse အစုအဝေးတစ်ခုကို ရိုးရှင်းသောတောင်းဆိုမှုအရေအတွက်ဖြင့် အတိုင်းအတာတစ်ခုပြုလုပ်ရန် လိုအပ်ပါက၊ ကျွန်ုပ်သည် အရိုးရှင်းဆုံးအချက်ကို အကြံပြုလိုသည် - ပုံတူအရေအတွက်ကို တိုးမြှင့်ပြီး ကျပန်းပုံစံတူသို့ တောင်းဆိုချက်များကို ပေးပို့ပါ။ ပုံတူတစ်ခုသည် တစ်စက္ကန့်လျှင် တောင်းဆိုချက်ငါးရာရရှိပါက၊ လုံးဝလက်တွေ့ကျသော ပုံစံတူသုံးမျိုးသည် တစ်စက္ကန့်လျှင် တစ်ထောင်ခွဲခန့် ကိုင်တွယ်မည်ဖြစ်သည်။
တစ်ခါတစ်ရံတွင်၊ သင်သည် အမှတ်အများဆုံးဖတ်ရှုခြင်းအတွက် ClickHouse ကို configure လုပ်နိုင်ပါသည်။ ဒီအတွက် ဘာလိုအပ်လဲ။ ပထမအချက်မှာ အညွှန်းကိန်း၏ အသေးစိပ်ကို လျှော့ချရန်ဖြစ်သည်။ ဤကိစ္စတွင်၊ ၎င်းကို တစ်ခုသို့ မလျှော့ချသင့်သော်လည်း အညွှန်းကိန်းတွင် ထည့်သွင်းသည့်အရေအတွက်သည် ဆာဗာတစ်ခုလျှင် သန်းပေါင်းများစွာ သို့မဟုတ် သန်းဆယ်ဂဏန်းအထိ ရှိလိမ့်မည်ကို အခြေခံ၍ ဖြစ်သည်။ ဇယားတွင် အတန်းပေါင်း သန်းတစ်ရာရှိလျှင် အသေးစိတ်အား 64 ဟု သတ်မှတ်နိုင်သည်။
compressed block ၏ အရွယ်အစားကို လျှော့ချနိုင်သည်။ ဒီအတွက် ဆက်တင်တွေရှိတယ်။ min compress block အရွယ်အစား, အမြင့်ဆုံး compress block အရွယ်အစား. ၎င်းတို့ကို လျှော့ချနိုင်သည်၊ ဒေတာဖြင့် ထပ်ဖြည့်နိုင်သည်၊ ထို့နောက် ပစ်မှတ်ထားသော မေးခွန်းများသည် ပိုမိုမြန်ဆန်လာမည်ဖြစ်သည်။ သို့သော်၊ ClickHouse သည် သော့တန်ဖိုးဒေတာဘေ့စ်မဟုတ်ပါ။ သေးငယ်သောတောင်းဆိုမှုများသည် load antipattern တစ်ခုဖြစ်သည်။
Kirill Shvakov- သာမန်အကောင့်တွေရှိရင် အကြံဉာဏ်ပေးမယ်။ ClickHouse ကောင်တာတစ်မျိုးမျိုးကို သိမ်းဆည်းသည့်အခါ ဤသည်မှာ မျှတသောစံအခြေအနေတစ်ခုဖြစ်သည်။ ကျွန်တော့်မှာ အသုံးပြုသူရှိပါတယ်၊ သူက အဲဒီလို နိုင်ငံမျိုးက နေပြီး တတိယနယ်ပယ်က တစ်ခုခုကို တိုးမြင့်ဖို့ လိုပါတယ်။ MySQL ကိုယူပါ၊ ထူးခြားသောသော့တစ်ခုပြုလုပ်ပါ - MySQL တွင်၎င်းသည်ပွားနေသောသော့ဖြစ်ပြီး PostgreSQL တွင်၎င်းသည်ပဋိပက္ခဖြစ်သည် - နှင့်အပေါင်းလက္ခဏာကိုထည့်ပါ။ ဒါကအများကြီးပိုကောင်းအလုပ်လုပ်ပါလိမ့်မယ်။
သင့်တွင်ဒေတာများစွာမရှိသောအခါ ClickHouse ကိုအသုံးပြုရာတွင်အချက်များစွာမရှိပါ။ ပုံမှန်ဒေတာဘေ့စ်တွေရှိကြပြီး ဒါကို ကောင်းကောင်းလုပ်တယ်။
ကက်ရှ်တွင် ဒေတာများ ပိုမိုရှိနေစေရန် ClickHouse တွင် အဘယ်အရာကို ပြင်ဆင်နိုင်သနည်း။
အခြေအနေတစ်ခုကို စိတ်ကူးကြည့်ကြပါစို့ - ဆာဗာများတွင် RAM 256 GB ရှိပြီး နေ့စဉ်လုပ်ရိုးလုပ်စဉ် ClickHouse တွင် 60-80 GB ခန့်ကြာမြင့်ပြီး - 130 အထိ အမြင့်ဆုံးဖြစ်သည်။ သို့မှသာ ဒေတာပိုမိုရရှိနိုင်ပြီး ကက်ရှ်တွင် ပိုများလာနိုင်သည်နှင့်အညီ၊ disk သို့ ခရီးစဉ် အနည်းငယ်သာ ရှိပါသလား။
ပုံမှန်အားဖြင့်၊ လည်ပတ်မှုစနစ်၏ စာမျက်နှာ ကက်ရှ်သည် ၎င်းကို ကောင်းမွန်စွာ လုပ်ဆောင်သည်။ အပေါ်ကိုဖွင့်လိုက်ရင် ကက်ရှ် (သို့) ဖရီးကိုကြည့်ပါ - ကက်ရှ် ဘယ်လောက်ပါလဲ ဆိုတာကိုလည်း ပြောပါတယ် - ထို့နောက် အခမဲ့ မမ်မိုရီအားလုံးကို ကက်ရှ်အတွက် သုံးကြောင်း သတိပြုမိပါလိမ့်မည်။ ဤဒေတာကိုဖတ်သောအခါ၊ ၎င်းကို disk မှမဟုတ်ဘဲ RAM မှဖတ်လိမ့်မည်။ တစ်ချိန်တည်းမှာပင်၊ ကက်ရှ်သည် ကက်ရှ်ချုံ့ထားသော ဒေတာဖြစ်သောကြောင့် ထိရောက်စွာအသုံးပြုကြောင်း ကျွန်ုပ်ပြောနိုင်သည်။
သို့ရာတွင်၊ သင်သည် အချို့သော ရိုးရှင်းသောမေးခွန်းများကို ပို၍မြန်ဆန်စေလိုလျှင် ClickHouse အတွင်းရှိ ချုံ့ထားသောဒေတာတွင် ကက်ရှ်တစ်ခုကို ဖွင့်နိုင်သည်။ အဲ့ဒါကိုခေါ်တယ် ချုံ့မထားသော cache. config.xml configuration ဖိုင်တွင်၊ ချုံ့မထားသော cache အရွယ်အစားကို သင်လိုအပ်သည့်တန်ဖိုးအဖြစ် သတ်မှတ်ပါ - အခမဲ့ RAM ၏ ထက်ဝက်ထက် မပိုစေရဟု အကြံပြုထားသောကြောင့် ကျန်သည် စာမျက်နှာ cache အောက်တွင် ရှိနေမည်ဖြစ်သည်။
ထို့အပြင်၊ တောင်းဆိုမှုအဆင့်ဆက်တင်နှစ်ခုရှိသည်။ ပထမအဆင့်သတ်မှတ်ချက် - ချုံ့မထားသော cache ကိုသုံးပါ။ - ၎င်း၏အသုံးပြုမှုပါဝင်သည်။ ဒေတာအားလုံးကို ဖတ်နိုင်ပြီး ကက်ရှ်ကို ဖယ်ရှားနိုင်သည့် လေးလံသော တောင်းဆိုချက်များမှအပ၊ ၎င်းကို ဖွင့်ရန် အကြံပြုထားသည်။ ဒုတိယဆက်တင်သည် ကက်ရှ်ကိုအသုံးပြုရန် အများဆုံး လိုင်းအရေအတွက်နှင့်တူသည်။ ၎င်းသည် ကြီးမားသောမေးခွန်းများကို ကက်ရှ်ကိုကျော်သွားစေရန် အလိုအလျောက်ကန့်သတ်ပေးသည်။
RAM တွင် သိုလှောင်မှုအတွက် storage_configuration ကို မည်သို့ configure လုပ်ရမည်နည်း။
ClickHouse စာရွက်စာတမ်းအသစ်တွင် ဆက်စပ်ကဏ္ဍကို ကျွန်ုပ်ဖတ်ပါသည်။ . ဖော်ပြချက်တွင် မြန်ဆန်သော SSD ပါသော ဥပမာတစ်ခုပါရှိသည်။
တူညီသောအရာကို volume hot memory ဖြင့်မည်ကဲ့သို့ configure လုပ်နိုင်မည်ကို ကျွန်ုပ်တွေးမိပါသည်။ နောက်ထပ်မေးခွန်းတစ်ခု။ ရွေးချယ်မှုသည် ဤဒေတာအဖွဲ့အစည်းနှင့် မည်သို့အလုပ်လုပ်သနည်း၊ ၎င်းသည် အစုံလိုက်တစ်ခုလုံး သို့မဟုတ် ဒစ်ခ်ပေါ်ရှိတစ်ခုတည်းကိုသာ ဖတ်မည်ဖြစ်ပြီး၊ ဤဒေတာကို မမ်မိုရီတွင် ချုံ့ထားပါသလား။ ပြီးတော့ prewhere section က ဒီလို data အဖွဲ့အစည်းနဲ့ ဘယ်လိုအလုပ်လုပ်သလဲ။
ဤဆက်တင်သည် ဒေတာအပိုင်းများကို သိမ်းဆည်းခြင်းအပေါ် သက်ရောက်မှုရှိပြီး ၎င်းတို့၏ဖော်မတ်သည် မည်သည့်နည်းနှင့်မျှ ပြောင်းလဲခြင်းမရှိပါ။
အနီးကပ်ကြည့်ကြပါစို့။
RAM တွင် ဒေတာသိုလှောင်မှုကို သင်သတ်မှတ်နိုင်သည်။ disk အတွက် configure လုပ်ထားသမျှသည် ၎င်း၏လမ်းကြောင်းဖြစ်သည်။ သင်သည် ဖိုင်စနစ်ရှိ လမ်းကြောင်းအချို့တွင် တပ်ဆင်ထားသည့် tmpfs အပိုင်းတစ်ခုကို ဖန်တီးသည်။ အပူဆုံး partition အတွက် ဒေတာကို သိမ်းဆည်းရန် ဤလမ်းကြောင်းကို သင်သတ်မှတ်သည်၊ ဒေတာအပိုင်းအစများ ရောက်ရှိလာပြီး ထိုနေရာတွင် ရေးထားသည်၊ အရာအားလုံး အဆင်ပြေပါသည်။
ဒါပေမယ့် ယုံကြည်စိတ်ချရမှုနည်းတာကြောင့် ဒါကိုလုပ်ဖို့ မအကြံပြုလိုပါဘူး၊ အကယ်၍ သင့်မှာ မတူညီတဲ့ဒေတာစင်တာတွေမှာ အနည်းဆုံး ပုံတူသုံးမျိုးရှိတယ်ဆိုရင် ဖြစ်နိုင်ချေရှိပါတယ်။ တစ်ခုခုဖြစ်သွားပါက ဒေတာကို ပြန်လည်ရယူပါမည်။ ဆာဗာရုတ်တရက်ပိတ်သွားပြီး ပြန်ဖွင့်တာကို စိတ်ကူးကြည့်ကြပါစို့။ အခန်းကန့်ကို ထပ်မံတပ်ဆင်ထားသော်လည်း ထိုနေရာတွင် ဘာမှမရှိပေ။ ClickHouse ဆာဗာ စတင်သောအခါ၊ ZooKeeper မက်တာဒေတာအရ ၎င်းတို့သည် ထိုနေရာတွင် ရှိနေသင့်သော်လည်း ၎င်းတွင် ဤအပိုင်းများ မပါရှိသည်ကို မြင်တွေ့ရသည်။ မည်သည့်ပုံတူများပါရှိသည်ကို ကြည့်ရှုကာ တောင်းဆိုပြီး ဒေါင်းလုဒ်လုပ်ပါ။ ဤနည်းဖြင့် ဒေတာများကို ပြန်လည်ရရှိမည်ဖြစ်သည်။
ဤသဘောအရ၊ RAM တွင် ဒေတာသိမ်းဆည်းခြင်းသည် ၎င်းကို disk တွင် သိမ်းဆည်းခြင်းနှင့် အခြေခံအားဖြင့် ကွဲပြားခြင်းမရှိပေ။ အကြောင်းမှာ ဒေတာကို disk သို့ စာရေးသောအခါ၊ ၎င်းသည် စာမျက်နှာ cache တွင် ပထမဆုံးအဆုံးသတ်ပြီး နောက်ပိုင်းတွင် ရုပ်ပိုင်းဆိုင်ရာအရ ရေးသားခြင်းဖြစ်သည်။ ၎င်းသည် file system mounting option ပေါ်တွင်မူတည်သည်။ သို့သော် ကိစ္စရပ်တွင်၊ ClickHouse ထည့်သွင်းသည့်အခါတွင် sync မလုပ်ကြောင်း ကျွန်ုပ်ပြောပါမည်။
ဤကိစ္စတွင်၊ RAM အတွင်းရှိဒေတာကို disk ပေါ်ရှိကဲ့သို့တူညီသောပုံစံဖြင့်သိမ်းဆည်းထားသည်။ တူညီသောနည်းဖြင့် ရွေးချယ်ထားသော query သည် ဖတ်ရန် လိုအပ်သည့် အပိုင်းများကို ရွေးသည်၊ အပိုင်းပိုင်းများရှိ လိုအပ်သော ဒေတာအပိုင်းအခြားများကို ရွေးကာ ၎င်းတို့ကို ဖတ်သည်။ ဒေတာသည် RAM တွင်ဖြစ်စေ၊ ဒစ်ခ်ပေါ်တွင်ဖြစ်စေ ဒေတာကို RAM တွင်ဖြစ်စေ မသက်ဆိုင်ဘဲ Prewhere သည် အတိအကျတူညီပါသည်။
Low Cardinality သည် မည်သည့်ထူးခြားသောတန်ဖိုးများအထိ ထိရောက်မှုရှိသနည်း။
Low Cardinality ကို ပါးပါးနပ်နပ် ဒီဇိုင်းထုတ်ထားပါတယ်။ ၎င်းသည် ဒေတာအဘိဓာန်များကို စုစည်းထားသော်လည်း ၎င်းတို့သည် ဒေသန္တရဖြစ်သည်။ ပထမအချက်၊ အပိုင်းတစ်ခုစီအတွက် မတူညီသော အဘိဓာန်များ ရှိပြီး ဒုတိယအချက်မှာ အပိုင်းတစ်ခုအတွင်း၌ပင် ၎င်းတို့သည် အပိုင်းတစ်ခုစီအတွက် ကွဲပြားနိုင်သည်။ ထူးခြားသောတန်ဖိုးများအရေအတွက်—တစ်သန်း—တစ်သန်းသို့ရောက်ရှိသောအခါ၊ အဘိဓာန်ကို ရိုးရိုးရှင်းရှင်းဖယ်ထားပြီး အသစ်တစ်ခုကို ဖန်တီးလိုက်သည်ဟု ကျွန်တော်ထင်သည်။
အဖြေသည် ယေဘူယျအားဖြင့်- ဒေသန္တရအကွာအဝေးတစ်ခုစီအတွက် - ဆိုပါစို့ - တစ်ရက်ချင်းစီအတွက် - တစ်သန်းသောထူးခြားသောတန်ဖိုးများ Low Cardinality သည် ထိရောက်သည်။ နောက်ပိုင်းတွင် အဘိဓာန်များစွာကို တစ်ခုတည်းတင်မဟုတ်ဘဲ မတူညီသော အဘိဓာန်များစွာကို အသုံးပြုမည့် ရိုးရှင်းသော နောက်ပြန်ဆုတ်မှုတစ်ခု ရှိလိမ့်မည်။ ၎င်းသည် ပုံမှန်စာကြောင်းကော်လံတစ်ခုနှင့် ခန့်မှန်းခြေအားဖြင့် အတူတူပင်ဖြစ်ပြီး ထိရောက်မှုအနည်းငယ်ရှိနိုင်သည်၊ သို့သော် ပြင်းထန်သောစွမ်းဆောင်ရည်ကျဆင်းခြင်းရှိမည်မဟုတ်ပါ။
အတန်းငါးဘီလီယံရှိသော ဇယားတစ်ခုကို စာသားအပြည့်အစုံရှာဖွေခြင်းအတွက် အကောင်းဆုံးအလေ့အကျင့်များကား အဘယ်နည်း။
အဖြေအမျိုးမျိုးရှိပါတယ်။ ပထမတစ်ချက်မှာ ClickHouse သည် full-text search engine မဟုတ်ပါ။ ဒီအတွက် အထူးစနစ်တွေရှိတယ် ဥပမာ၊ и . သို့သော်၊ Elasticsearch မှ ClickHouse သို့ ပြောင်းနေသည်ဟု လူအများက တိုး၍တိုး၍ပြောနေပါသည်။
ဘာကြောင့် ဒီလိုဖြစ်တာလဲ။ Elasticsearch သည် အညွှန်းကိန်းများတည်ဆောက်မှုမှစတင်ကာ အချို့သော volumes များတွင် ဝန်ကိုကိုင်တွယ်ဖြေရှင်းခြင်းမပြုတော့သည့်အချက်ကို ၎င်းတို့ကရှင်းပြသည်။ အညွှန်းများသည် ရှုပ်ထွေးလွန်းပြီး အကယ်၍ သင်သည် ဒေတာကို ClickHouse သို့ လွှဲပြောင်းမည်ဆိုပါက၊ ၎င်းတို့ကို အသံအတိုးအကျယ်အရ အဆများစွာ ပိုမိုထိရောက်စွာ သိမ်းဆည်းထားကြောင်း ထင်ရှားစေသည်။ တစ်ချိန်တည်းမှာပင်၊ morphology ကိုထည့်သွင်းစဉ်းစားကာ ဒေတာထုထည်တစ်ခုလုံးရှိ စကားစုအချို့ကို ရှာဖွေရန် လိုအပ်သော်လည်း ရှာဖွေမှုမေးခွန်းများသည် မကြာခဏဆိုသလို ထိုသို့မဟုတ်ပေ။ ဥပမာ၊ ပြီးခဲ့သော နာရီအနည်းငယ်အတွင်း မှတ်တမ်းများတွင် ဘိုက်များ၏ နောက်ဆက်တွဲအချို့ကို ရှာပါ။
ဤကိစ္စတွင်၊ သင်သည် ရက်စွဲနှင့် အချိန်ဖြစ်မည့် ပထမဆုံးအကွက်ဖြစ်သည့် ClickHouse တွင် အညွှန်းတစ်ခုဖန်တီးပါ။ နှင့် အကြီးဆုံးဒေတာဖြတ်တောက်မှုသည် ရက်စွဲအကွာအဝေးအပေါ် အခြေခံမည်ဖြစ်သည်။ ရွေးချယ်ထားသော ရက်စွဲအပိုင်းအခြားအတွင်း စည်းကမ်းအတိုင်း၊ ၎င်းသည် brute force method ကို အသုံးပြု၍ပင် စာသားအပြည့်အစုံရှာဖွေမှုကို လုပ်ဆောင်နိုင်နေပြီဖြစ်သည်။ ClickHouse ရှိကဲ့သို့အော်ပရေတာသည် သင်ရှာတွေ့နိုင်သော အထိရောက်ဆုံးအော်ပရေတာကဲ့သို့ဖြစ်သည်။ ပိုကောင်းတာတွေ့ရင် ပြောပြပါ။
သို့သော်၊ အပြည့်အဝစကင်န်ကဲ့သို့ဖြစ်သည်။ ပြီးပြည့်စုံသောစကင်န်ဖတ်ခြင်းသည် CPU တွင်သာမက disk တွင်လည်းနှေးကွေးနိုင်သည်။ အကယ်၍ သင့်တွင် တစ်နေ့လျှင် ဒေတာ terabyte ရုတ်တရက်ရှိပြီး နေ့ဘက်တွင် စကားလုံးတစ်လုံးကို ရှာဖွေပါက terabyte ကို စကင်န်ဖတ်ရပါမည်။ ၎င်းသည် ပုံမှန် hard drives များတွင် ဖြစ်နိုင်ပြီး အဆုံးတွင် ၎င်းတို့သည် ဤဆာဗာကို SSH မှတစ်ဆင့် သင်ဝင်ရောက်ကြည့်ရှုနိုင်မည်မဟုတ်သည့်နည်းဖြင့် ၎င်းတို့ကို တင်ဆောင်မည်ဖြစ်သည်။
ဤကိစ္စတွင်၊ ငါသည်နောက်ထပ်လှည့်ကွက်အနည်းငယ်ကိုကမ်းလှမ်းရန်အဆင်သင့်ဖြစ်သည်။ ၎င်းသည် စမ်းသပ်ခြင်းဖြစ်သည်- ၎င်းသည် အလုပ်ဖြစ်နိုင်သည်၊ ၎င်းသည် မဖြစ်နိုင်ပါ။ ClickHouse တွင် trigram Bloom စစ်ထုတ်မှုများပုံစံဖြင့် စာသားအပြည့်အစုံ အညွှန်းများရှိသည်။ Arenadata ရှိ ကျွန်ုပ်တို့၏လုပ်ဖော်ကိုင်ဖက်များသည် ဤအညွှန်းကိန်းများကို စမ်းသုံးထားပြီးဖြစ်ပြီး ၎င်းတို့သည် ရည်ရွယ်ထားသည့်အတိုင်း မကြာခဏလုပ်ဆောင်ပါသည်။
၎င်းတို့ကို မှန်ကန်စွာအသုံးပြုရန်အတွက် ၎င်းတို့လုပ်ဆောင်ပုံ- trigram Bloom filter သည် မည်ကဲ့သို့အလုပ်လုပ်ပုံနှင့် ၎င်း၏အရွယ်အစားကို ရွေးချယ်ရမည်ကို ကောင်းစွာနားလည်ထားသင့်သည်။ ဒေတာတွင် တွေ့ရခဲသော ရှားပါးသော စကားစုများ၊ စာကြောင်းခွဲများ ဆိုင်ရာ စုံစမ်းမေးမြန်းမှုများကို ၎င်းတို့က ကူညီပေးလိမ့်မည်ဟု ကျွန်ုပ်ပြောနိုင်သည်။ ဤကိစ္စတွင်၊ အမျိုးအစားခွဲများကို အညွှန်းများဖြင့် ရွေးမည်ဖြစ်ပြီး ဒေတာနည်းသည်ကို ဖတ်မည်ဖြစ်သည်။
မကြာသေးမီက၊ ClickHouse သည် စာသားအပြည့်အစုံရှာဖွေမှုအတွက် ပိုမိုအဆင့်မြင့်သည့်လုပ်ဆောင်ချက်များကို ထည့်သွင်းထားသည်။ ၎င်းသည် ပထမဦးစွာ၊ UTF-8 သို့မဟုတ် ASCII အတွက်သာ ပံ့ပိုးမှုဖြင့် စာလုံးအကြီးအသေး၊ အသေးအမွှား အာရုံမခံသော ရွေးစရာများ အပါအဝင် pass တစ်ခုတွင် တန်းခွဲစာတန်းများ တစ်စုတစ်စည်းတည်း ရှာဖွေခြင်း ဖြစ်သည်။ သင်လိုအပ်သော အထိရောက်ဆုံးကို ရွေးချယ်ပါ။
ဖြတ်သန်းခွင့်တစ်ခုတွင် ပုံမှန်အသုံးအနှုန်းများစွာကို ရှာဖွေမှုလည်း ပေါ်လာသည်။ စာတန်းခွဲတစ်ခုကဲ့သို့ X သို့မဟုတ် အခြားစာတန်းခွဲများကဲ့သို့ X ရေးရန် မလိုအပ်ပါ။ သင်ချက်ချင်းရေးပြီး အရာအားလုံးကို တတ်နိုင်သမျှ ထိရောက်အောင် ပြီးပါပြီ။
တတိယ၊ ယခု regexps အတွက် ခန့်မှန်းခြေ ရှာဖွေမှု နှင့် substrings များအတွက် အနီးစပ်ဆုံး ရှာဖွေမှု တစ်ခု ရှိပါသည်။ အကယ်၍ တစ်စုံတစ်ယောက်က စာလုံးပေါင်းမှားပါက၊ ၎င်းသည် အများဆုံးကိုက်ညီမှုကို ရှာဖွေမည်ဖြစ်သည်။
အသုံးပြုသူအများအပြားအတွက် ClickHouse သို့ဝင်ရောက်ခွင့်ကို စုစည်းရန် အကောင်းဆုံးနည်းလမ်းမှာ အဘယ်နည်း။
စားသုံးသူများနှင့် လေ့လာသုံးသပ်သူ အများအပြားအတွက် ဝင်ခွင့်ကို မည်ကဲ့သို့ စုစည်းရန် အကောင်းဆုံးနည်းကို ကျွန်ုပ်တို့အား ပြောပြပါ။ တန်းစီဇယားကို ဘယ်လိုဖွဲ့စည်းမလဲ၊ အမြင့်ဆုံး တစ်ပြိုင်တည်းမေးမြန်းချက်များကို ဦးစားပေးလုပ်ဆောင်ပြီး မည်သည့်ကိရိယာများဖြင့် ပြုလုပ်မည်နည်း။
အစုအဝေးသည် အလုံအလောက်ကြီးပါက၊ ဆန်းစစ်လေ့လာသူများအတွက် ဝင်ခွင့်အမှတ်ဖြစ်လာမည့် နောက်ထပ်ဆာဗာနှစ်ခုကို မြှင့်တင်ရန် ကောင်းသောအဖြေတစ်ခုဖြစ်သည်။ ဆိုလိုသည်မှာ၊ ခွဲခြမ်းစိတ်ဖြာသူအား သီးခြား shards များကို ဝင်ရောက်ခွင့်မပြုပါနှင့်၊ သို့သော် ဒေတာမပါဘဲ ဆာဗာနှစ်ခုကို ဖန်တီးပြီး ၎င်းတို့တွင် ဝင်ရောက်ခွင့်များကို စီစဉ်သတ်မှတ်ပါ။ ဤကိစ္စတွင်၊ ဖြန့်ဝေတောင်းဆိုမှုများအတွက် အသုံးပြုသူဆက်တင်များကို အဝေးထိန်းဆာဗာများသို့ လွှဲပြောင်းပေးပါသည်။ ဆိုလိုသည်မှာ သင်သည် ဤဆာဗာနှစ်ခုရှိ အရာအားလုံးကို ပြင်ဆင်သတ်မှတ်ပြီး ဆက်တင်များသည် အစုအဝေးတစ်ခုလုံးအပေါ် သက်ရောက်မှုရှိသည်။
မူအရ၊ ဤဆာဗာများတွင် ဒေတာမရှိသော်လည်း ၎င်းတို့တွင်ရှိသော RAM ပမာဏသည် တောင်းဆိုမှုများကို လုပ်ဆောင်ရန်အတွက် အလွန်အရေးကြီးပါသည်။ ပြင်ပ စုစည်းမှု သို့မဟုတ် ပြင်ပ အမျိုးအစားခွဲခြင်းကို ဖွင့်ထားလျှင် ယာယီဒေတာအတွက် ဒစ်ကိုလည်း အသုံးပြုနိုင်သည်။
ဖြစ်နိုင်သည့် ကန့်သတ်ချက်အားလုံးနှင့် ဆက်စပ်နေသည့် ဆက်တင်များကို ကြည့်ရှုရန် အရေးကြီးသည်။ အကယ်၍ ကျွန်ုပ်သည် ယခု Yandex.Metrica အစုအဝေးသို့ သွားပြီး ဆန်းစစ်သူတစ်ဦးအနေဖြင့် တောင်းဆိုချက်တစ်ခုမေးပါ။ hits များမှ count ကိုရွေးချယ်ပါ။သို့ဆိုလျှင် ကျွန်ုပ်သည် တောင်းဆိုချက်ကို မလုပ်ဆောင်နိုင်သော ခြွင်းချက်တစ်ခု ချက်ချင်းပေးပါမည်။ ကျွန်ုပ်စကင်ဖတ်ခွင့်ပြုသည့် အများဆုံးအတန်းအရေအတွက်သည် ဘီလီယံတစ်ရာဖြစ်ပြီး၊ အစုအဝေးပေါ်ရှိ ဇယားတစ်ခုတွင် ၎င်းတို့အနက်မှ ထရီလီယံငါးဆယ်ရှိသည်။ ဒါက ပထမဆုံး ကန့်သတ်ချက်ပါ။
အတန်းကန့်သတ်ချက်ကို ဖယ်ရှားပြီး query ကို ထပ်မံလုပ်ဆောင်သည်ဟု ဆိုကြပါစို့။ ထို့နောက် အောက်ပါခြွင်းချက်- setting ကိုဖွင့်ထားသည်ကိုတွေ့ရပါမည်။ ရက်စွဲအလိုက် အင်အားအညွှန်းကိန်း. ရက်အပိုင်းအခြားကို မသတ်မှတ်ထားပါက မေးခွန်းကို ပြီးအောင် မလုပ်နိုင်ပါ။ ၎င်းကို ကိုယ်တိုင်သတ်မှတ်ရန် အကဲခတ်သူများအပေါ် သင် အားကိုးနေစရာ မလိုပါ။ ပုံမှန်ဖြစ်ရပ်တစ်ခုသည် ရက်သတ္တပတ်များကြားတွင် အဖြစ်အပျက်ရက်စွဲကို ရေးထားသော ရက်စွဲအပိုင်းအခြားတစ်ခုဖြစ်သည်။ ထို့နောက် ၎င်းတို့သည် မှားယွင်းသောနေရာတွင် ကွင်းပိတ်တစ်ခုကို ရိုးရိုးရှင်းရှင်းသတ်မှတ်ခဲ့ပြီး ၎င်းအစား သို့မဟုတ် - သို့မဟုတ် URL တူညီမှုအဖြစ် ပြောင်းလဲသွားခဲ့သည်။ ကန့်သတ်ချက်မရှိပါက၊ ၎င်းသည် URL ကော်လံကို ကူးယူနိုင်ပြီး အရင်းအမြစ်များစွာကို ဖြုန်းတီးနေမည်ဖြစ်သည်။
ထို့အပြင် ClickHouse တွင် ဦးစားပေးဆက်တင် နှစ်ခုရှိသည်။ ကံမကောင်းစွာပဲ၊ သူတို့ဟာ အလွန်ရှေးကျပါတယ်။ တစ်ခုက ရိုးရိုးရှင်းရှင်းပဲ ခေါ်တယ်။ ဦးစားပေး. အကယ်၍ ဦးစားပေး ≠ 0 နှင့် အချို့သော ဦးစားပေး တောင်းဆိုမှုများကို လုပ်ဆောင်နေသော်လည်း ဦးစားပေးတန်ဖိုးထက် နည်းသော တောင်းဆိုချက်တစ်ခု၊ ဆိုလိုသည်မှာ ပိုမိုသော ဦးစားပေးမှုကို လုပ်ဆောင်နေပါက၊ ဦးစားပေးတန်ဖိုး ပိုကြီးသော တောင်းဆိုချက်တစ်ခု၊ ဆိုလိုသည်မှာ ဦးစားပေးမှု နိမ့်သည် ၊ သည် ရိုးရှင်းစွာ ရပ်ဆိုင်းထားပြီး ဤကာလအတွင်း လုံးဝ အလုပ်မလုပ်ပါ။
၎င်းသည် အလွန်ရိုင်းစိုင်းသော ဆက်တင်ဖြစ်ပြီး အစုအဝေးတွင် အဆက်မပြတ် ဝန်ရှိနေသော ကိစ္စများအတွက် မသင့်လျော်ပါ။ သို့သော် သင့်တွင် အရေးကြီးသော တိုတောင်းသော၊ ကျယ်လောင်သော တောင်းဆိုမှုများ ရှိပြီး၊ အစုအဝေးသည် အများအားဖြင့် အလုပ်မလုပ်ပါက၊ ဤစနစ်ထည့်သွင်းမှုသည် သင့်လျော်ပါသည်။
နောက်ဦးစားပေးဆက်တင်ကို ခေါ်သည်။ OS thread ဦးစားပေး. ၎င်းသည် Linux scheduler အတွက် တောင်းဆိုမှု လုပ်ငန်းစဉ်အားလုံးအတွက် ကောင်းမွန်သောတန်ဖိုးကို ရိုးရိုးရှင်းရှင်း သတ်မှတ်ပေးသည်။ ၎င်းသည် ဤမျှလောက် အလုပ်လုပ်သော်လည်း ၎င်းသည် အလုပ်လုပ်ဆဲဖြစ်သည်။ အနိမ့်ဆုံး ကောင်းမွန်သောတန်ဖိုးကို သင်သတ်မှတ်ပါက - ၎င်းသည် တန်ဖိုးအကြီးဆုံးဖြစ်ပြီး ထို့ကြောင့် အနိမ့်ဆုံးဦးစားပေးဖြစ်သည် - နှင့် မြင့်မားသောဦးစားပေးတောင်းဆိုမှုများအတွက် -19 ကိုသတ်မှတ်ထားပါက CPU သည် ဦးစားပေးအဆင့်မြင့်တောင်းဆိုမှုများထက် လေးဆခန့်နည်းပါးသော ဦးစားပေးတောင်းဆိုမှုများကို စားသုံးမည်ဖြစ်ပါသည်။
အမြင့်ဆုံး တောင်းဆိုချက် အကောင်အထည်ဖော်ချိန်ကို သင်လည်း စီစဉ်သတ်မှတ်ရန် လိုအပ်သည် - ဆိုပါစို့၊ ငါးမိနစ်။ query execute ၏ အနိမ့်ဆုံးအမြန်နှုန်းသည် အအေးဆုံးအရာဖြစ်သည်။ ဤဆက်တင်သည် အချိန်ကြာမြင့်နေပြီဖြစ်ပြီး ClickHouse နှေးကွေးခြင်းမရှိကြောင်း အခိုင်အမာဆိုရုံသာမက ၎င်းအား အတင်းအကြပ်ပြုလုပ်ရန် လိုအပ်ပါသည်။
သင် configure ကို မြင်ယောင်ကြည့်ပါ- အချို့သော query သည် တစ်စက္ကန့်လျှင် အတန်းတစ်သန်းအောက်သာ လုပ်ဆောင်ပါက၊ သင်သည် ၎င်းကို မလုပ်နိုင်ပါ။ ဒါက ကျွန်တော်တို့ရဲ့ နာမည်ကောင်း၊ ကျွန်တော်တို့ရဲ့ ကောင်းမွန်တဲ့ ဒေတာဘေ့စ်ကို အရှက်ကွဲစေတယ်။ ဒါကိုပဲ တားမြစ်လိုက်ရအောင်။ တကယ်တော့ setting နှစ်ခုရှိပါတယ်။ တစ်ခုခေါ်တယ်။ min ကွပ်မျက်မှုမြန်နှုန်း - တစ်စက္ကန့်ကို မျဉ်းကြောင်းများအတိုင်းဖြစ်ပြီး ဒုတိယအား မိနစ်အား စစ်ဆေးခြင်းအမြန်နှုန်းကို မစစ်ဆေးမီ အချိန်ကုန်ခြင်းဟုခေါ်သည် - ပုံမှန်အားဖြင့် ဆယ့်ငါးစက္ကန့်။ ဆိုလိုသည်မှာ၊ ဆယ့်ငါးစက္ကန့်ဖြစ်နိုင်သည်၊ ထို့နောက်၊ နှေးနေပါက၊ ခြွင်းချက်တစ်ခုချလိုက်ပြီး တောင်းဆိုမှုကို ပယ်ဖျက်လိုက်ပါ။
ခွဲတမ်းကိုလည်း သတ်မှတ်ရန် လိုအပ်သည်။ ClickHouse တွင် အရင်းအမြစ်သုံးစွဲမှုကို ရေတွက်သည့် ပါ၀င်သော ခွဲတမ်းအင်္ဂါရပ် ရှိသည်။ သို့သော် ကံမကောင်းစွာဖြင့်၊ CPU၊ disks ကဲ့သို့သော ဟာ့ဒ်ဝဲအရင်းအမြစ်များ မဟုတ်ဘဲ ယုတ္တိတန်သော အရာများဖြစ်သည် - လုပ်ဆောင်ပြီးသော တောင်းဆိုမှုများ၊ လိုင်းများနှင့် ဘိုက်များ ဖတ်ရှုသည့် အရေအတွက်။ ဥပမာ၊ ငါးမိနစ်အတွင်း အများဆုံး တောင်းဆိုချက် တစ်ရာနှင့် တစ်နာရီလျှင် တောင်းဆိုချက် တစ်ထောင်ကို သင် configure လုပ်နိုင်သည်။
အဘယ်ကြောင့် အရေးကြီးသနည်း။ အဘယ်ကြောင့်ဆိုသော် အချို့သော ခွဲခြမ်းစိတ်ဖြာမှုဆိုင်ရာ မေးမြန်းချက်များကို ClickHouse ကလိုင်းယင့်ထံမှ တိုက်ရိုက်လုပ်ဆောင်ပေးမည်ဖြစ်သည်။ ပြီးတော့ အားလုံးအဆင်ပြေသွားမှာပါ။ ဒါပေမယ့် သင့်ကုမ္ပဏီမှာ အဆင့်မြင့်သုံးသပ်သူတွေရှိရင်၊ သူတို့က ဇာတ်ညွှန်းရေးပြီး ဇာတ်ညွှန်းမှာ အမှားအယွင်းရှိနိုင်ပါတယ်။ ပြီးတော့ ဒီအမှားက တောင်းဆိုမှုကို အဆုံးမဲ့ ကွင်းဆက်တစ်ခုထဲမှာ လုပ်ဆောင်စေပါလိမ့်မယ်။ ဒါက ကျွန်တော်တို့ကို ကာကွယ်ဖို့ လိုတယ်။
တစ်ခုသော query ၏ရလဒ်များကို client ဆယ်ယောက်အား ပေးနိုင်ပါသလား။
ကျွန်ုပ်တို့တွင် အလွန်ကြီးမားသော တောင်းဆိုမှုများဖြင့် အချိန်နှင့်တပြေးညီ ဝင်ရောက်လိုသော သုံးစွဲသူများစွာရှိသည်။ တောင်းဆိုချက်သည် ကြီးမားပြီး မူအရအားဖြင့် လျင်မြန်စွာ အကောင်အထည်ဖော်နိုင်သော်လည်း တစ်ချိန်တည်းတွင် ထိုသို့သော တောင်းဆိုမှုများ အများအပြားရှိနေခြင်းကြောင့် အလွန်နာကျင်စေသည်။ ဆက်တိုက် ဆယ်ကြိမ်၊ တစ်ကြိမ် ရောက်ရှိလာပြီး ရလဒ်ကို ဖောက်သည် ဆယ်ဦးကို ပေးသည့် တူညီသော တောင်းဆိုချက်ကို အကောင်အထည်ဖော်ရန် ဖြစ်နိုင်ပါသလား။
ပြဿနာမှာ ကျွန်ုပ်တို့တွင် အလယ်အလတ်ဒေတာ၏ cache သို့မဟုတ် cache ၏ရလဒ်များမရှိပါ။ လည်ပတ်မှုစနစ်၏ စာမျက်နှာ ကက်ရှ်တစ်ခု ရှိပြီး၊ ၎င်းသည် သင့်အား ဒစ်ခ်မှ ဒေတာများကို ထပ်မံဖတ်ရှုခြင်းမှ တားဆီးနိုင်သော်လည်း၊ ကံမကောင်းစွာဖြင့်၊ ဒေတာကို ဖိသိပ်ထားဆဲ၊ ဖယ်ထုတ်ထားပြီး ပြန်လည်လုပ်ဆောင်နေမည်ဖြစ်သည်။
အလယ်အလတ်ဒေတာကို ကက်ရှ်လုပ်ခြင်းဖြင့်ဖြစ်စေ သို့မဟုတ် အလားတူမေးခွန်းမျိုးများကို တန်းစီပြီး ရလဒ် ကက်ရှ်တစ်ခုထည့်ခြင်းဖြင့် ၎င်းကို တစ်နည်းနည်းဖြင့် ရှောင်ရှားလိုပါသည်။ တောင်းဆိုချက် ကက်ရှ်တစ်ခုကို ပေါင်းထည့်သည့် ဖွံ့ဖြိုးတိုးတက်မှုတွင် လောလောဆယ်တွင် ဆွဲယူတောင်းဆိုချက်တစ်ခု ရှိသည်၊ သို့သော် ကဏ္ဍများအတွင်းနှင့် ပါဝင်ရန် ကဏ္ဍခွဲများအတွက်သာ - ဆိုလိုသည်မှာ၊ ဖြေရှင်းချက် မပြည့်စုံပါ။
ဒါပေမယ့်လည်း ဒီလိုအခြေအနေမျိုး ကြုံနေရပါတယ်။ အထူးသဖြင့် Canonical ဥပမာတစ်ခုသည် paginated queries ဖြစ်သည်။ အစီရင်ခံစာတစ်ခုရှိပြီး၊ ၎င်းတွင်စာမျက်နှာများစွာပါရှိပြီးကန့်သတ်ချက် 10 အတွက်တောင်းဆိုမှုတစ်ခုရှိသည်။ ထို့နောက်တူညီသောအရာဖြစ်သော်လည်းကန့်သတ် 10,10 ဖြစ်သည်။ ပြီးရင် နောက်တစ်မျက်နှာ။ ပြီးတော့ မေးစရာက၊ ဘာကြောင့် ဒါတွေအားလုံးကို အချိန်တိုင်း ရေတွက်တာလဲ။ ယခုမူကား ဖြေရှင်းနည်းမရှိ၊ ရှောင်ရန်နည်းလမ်းမရှိပေ။
ClickHouse ဘေးတွင် ဘေးတွဲကားအဖြစ် ထည့်ထားသော အခြားဖြေရှင်းချက်တစ်ခုရှိသည်။ .
Kirill Shvakov- ClickHouse Proxy တွင် built-in နှုန်းကန့်သတ်ချက်နှင့် built-in ရလဒ်များ cache ရှိသည်။ အလားတူပြဿနာကို ဖြေရှင်းနေသောကြောင့် ထိုနေရာတွင် ဆက်တင်များစွာကို ပြုလုပ်ထားပါသည်။ Proxy သည် ၎င်းတို့ကို တန်းစီစောင့်ဆိုင်းပြီး တောင်းဆိုချက် cache သက်တမ်းမည်မျှကြာအောင် ချိန်ညှိခြင်းဖြင့် တောင်းဆိုမှုများကို ကန့်သတ်ခွင့်ပြုသည်။ တောင်းဆိုချက်များသည် အမှန်တကယ်တူညီပါက၊ Proxy သည် ၎င်းတို့ကို အကြိမ်များစွာ ပေးပို့မည်ဖြစ်ပြီး၊ သို့သော် ClickHouse သို့ တစ်ကြိမ်သာသွားပါမည်။
Nginx သည် အခမဲ့ဗားရှင်းတွင် ကက်ရှ်တစ်ခုလည်း ရှိပြီး ၎င်းသည်လည်း အလုပ်ဖြစ်ပါမည်။ Nginx တွင် တောင်းဆိုချက်များ တစ်ချိန်တည်းရောက်လာပါက၊ တစ်ခုပြီးမြောက်သည်အထိ အခြားသူများကို နှေးကွေးစေမည့် ဆက်တင်များပင်ရှိသည်။ သို့သော်၎င်းသည် ClickHouse Proxy တွင်တပ်ဆင်မှုပိုမိုကောင်းမွန်သည်။ ဤတောင်းဆိုမှုများအတွက် အထူးသဖြင့် ClickHouse အတွက် အထူးပြုလုပ်ထားသောကြောင့် ၎င်းသည် ပိုမိုသင့်လျော်ပါသည်။ ကောင်းပြီ၊ တပ်ဆင်ရန်လွယ်ကူသည်။
တပြိုင်နက်တည်း လုပ်ဆောင်မှုများနှင့် ရုပ်လုံးပေါ်လာသော အမြင်များကော။
replay engine နှင့် လုပ်ဆောင်မှုများသည် အညီအညွတ်ဖြစ်နေသည် - ပထမဦးစွာ ဒေတာကို ရေးသားပြီးနောက် ပြိုကျသွားသည်။ ပေါင်းစပ်အချို့ပါရှိသော တက်ဘလက်တစ်ခုသည် ဆိုင်းဘုတ်အောက်တွင် ရှိနေပါက၊ ထပ်တူများကို ၎င်းထံသို့ စာရေးပါမည်။ ရှုပ်ထွေးသောယုတ္တိမရှိပါက၊ ဒေတာကို ထပ်ပွားပါမည်။ ၎င်းနှင့်ပတ်သက်၍ သင်ဘာလုပ်နိုင်သနည်း။
ပြတ်ပြတ်သားသား ပြိုကျသည့် လုပ်ဆောင်ချက်အတွင်း အချို့သော matviews အတန်းပေါ်တွင် ထင်ရှားသော အဖြေတစ်ခု ရှိပါသည်။ ငွေရောင်ကျည်ဆန်များ သို့မဟုတ် အလားတူလုပ်ဆောင်နိုင်စွမ်းကို အကောင်အထည်ဖော်ရန် အစီအစဉ်များ ရှိပါသလား။
ပုံတူပွားခြင်းအလုပ်လုပ်ပုံကို နားလည်ရကျိုးနပ်သည်။ အခုပြောပြမယ့်အရာက မေးခွန်းနဲ့မသက်ဆိုင်ပေမယ့် မှတ်သားထားသင့်တဲ့ကိစ္စပါ။
ပုံတူဇယားတစ်ခုသို့ ထည့်သွင်းသောအခါ၊ ထည့်သွင်းထားသော ဘလောက်တစ်ခုလုံး၏ ထပ်ပွားမှုရှိသည်။ တူညီသောအစီအစဥ်တွင် တူညီသောအတန်းအရေအတွက်များပါရှိသော တူညီသောဘလောက်ကို ပြန်လည်ထည့်သွင်းပါက ဒေတာကို ပွားနေပါသည်။ ထည့်သွင်းရန်အတွက် "Ok" ကို သင်လက်ခံရရှိလိမ့်မည်၊ သို့သော် အမှန်တကယ်တွင် ဒေတာပက်ကေ့ချ်တစ်ခုအား ရေးသားမည်ဖြစ်ပြီး ၎င်းကို ထပ်ပွားမည်မဟုတ်ပါ။
ဒါက သေချာဘို့လိုတယ်။ ထည့်သွင်းစဉ် "Ok" ကို လက်ခံရရှိပါက၊ သင်၏ဒေတာကို ထည့်သွင်းလိုက်ပါပြီ။ ClickHouse မှ အမှားအယွင်းတစ်ခုကို လက်ခံရရှိပါက ၎င်းတို့ကို ထည့်သွင်းခြင်းမပြုဘဲ ထည့်သွင်းမှုကို ထပ်လုပ်ရန် လိုအပ်သည်ဟု ဆိုလိုသည်။ သို့သော် ထည့်သွင်းစဉ်အတွင်း ချိတ်ဆက်မှု ပျက်သွားပါက၊ ဒေတာ ထည့်သွင်းခြင်း ရှိ၊ မရှိကို သင်မသိရပါ။ တစ်ခုတည်းသောနည်းလမ်းမှာ ထည့်သွင်းမှုကို ထပ်မံပြုလုပ်ရန်ဖြစ်သည်။ အကယ်၍ ဒေတာကို အမှန်တကယ် ထည့်သွင်းပြီး ၎င်းကို ပြန်လည်ထည့်သွင်းပါက၊ ပိတ်ဆို့ခြင်း ထပ်ပွားခြင်း ရှိပါသည်။ ထပ်တူများကို ရှောင်ရှားရန် ဤအရာသည် လိုအပ်ပါသည်။
ထို့အပြင် ရုပ်လုံးပေါ်လာသော အမြင်များအတွက် ၎င်းသည် မည်ကဲ့သို့ အလုပ်လုပ်ပုံလည်း အရေးကြီးပါသည်။ အကယ်၍ ဒေတာကို ပင်မဇယားတွင် ထည့်သွင်းသည့်အခါ၊ ၎င်းသည် ရုပ်လုံးပေါ်လာသည့် မြင်ကွင်းသို့ ရောက်သွားမည်မဟုတ်ပေ။
ယခုမေးခွန်းနှင့်ပတ်သက်။ လိုင်းတစ်ခုချင်းစီ၏ ထပ်တူများကို မှတ်တမ်းတင်နေသောကြောင့် သင့်အခြေအနေမှာ ပိုမိုရှုပ်ထွေးပါသည်။ ဆိုလိုသည်မှာ၊ ၎င်းသည် ထပ်ပွားထားသည့် pack တစ်ခုလုံးမဟုတ်သော်လည်း သီးခြားမျဉ်းများဖြစ်ပြီး ၎င်းတို့သည် နောက်ခံတွင် ပြိုကျသွားသည်။ အမှန်မှာ၊ ဒေတာသည် ပင်မဇယားတွင် ပြိုကျသွားလိမ့်မည်၊ သို့သော် မပြိုကျသေးသော ဒေတာများသည် ရုပ်လုံးပေါ်လာသော မြင်ကွင်းသို့ ရောက်သွားမည်ဖြစ်ပြီး ပေါင်းစည်းလိုက်သည့်အတောအတွင်း ရုပ်လုံးပေါ်လာသော အမြင်များတွင် မည်သည့်အရာမျှ ဖြစ်လာမည်မဟုတ်ပေ။ အဘယ်ကြောင့်ဆိုသော် ရုပ်လုံးပေါ်လာသော မြင်ကွင်းသည် ထည့်သွင်းမှု အစပျိုးခြင်းထက် မပိုပါ။ အခြားလုပ်ဆောင်မှုများအတွင်း ၎င်းအတွက် နောက်ထပ်ဘာမျှမဖြစ်ပါ။
ပြီးတော့ ငါ မင်းကို ဒီမှာ ပျော်ရွှင်အောင် မလုပ်နိုင်ဘူး။ ဤကိစ္စအတွက် တိကျသောအဖြေကို သင်ရှာရန်သာလိုသည်။ ဥပမာအားဖြင့်၊ ၎င်းကို ရုပ်လုံးပေါ်လာသော မြင်ကွင်းတွင် ပြန်လည်ပြသရန် ဖြစ်နိုင်ပါသလော၊ နှင့် ထပ်တူပွားခြင်းနည်းလမ်းသည် တူညီသောနည်းလမ်းဖြင့် အလုပ်လုပ်နိုင်သည်။ ဒါပေမယ့် ကံမကောင်းတာက အမြဲတမ်းတော့ မဟုတ်ပါဘူး။ ပေါင်းလိုက်လျှင် အလုပ်မဖြစ်ပါ။
Kirill Shvakov- ဟိုနေ့တုန်းကလည်း ချိုင်းထောက်တွေ ဆောက်တယ်။ ကြော်ငြာထင်မြင်ယူဆမှုများ ရှိနေသည်နှင့် ကျွန်ုပ်တို့ အချိန်နှင့်တပြေးညီ ပြသနိုင်သည့် ဒေတာအချို့ရှိသည် - ၎င်းတို့သည် အထင်အမြင်များသာဖြစ်သည်။ ၎င်းတို့သည် ထပ်တူခဲသော်လည်း ထိုသို့ဖြစ်လာပါက၊ မည်သို့ပင်ဖြစ်စေ ကျွန်ုပ်တို့သည် ၎င်းတို့ကို နောက်ပိုင်းတွင် ပြိုကျမည်ဖြစ်သည်။ ကလစ်များနှင့် ဤဇာတ်လမ်းတစ်ခုလုံးကို ထပ်ပွား၍မရသော အရာများရှိသည်။ ဒါပေမယ့် ချက်ချင်းနီးပါး သူတို့ကို ပြချင်ခဲ့တယ်။
ရုပ်လုံးပေါ်လာသော အမြင်များကို မည်သို့ဖန်တီးခဲ့သနည်း။ ၎င်းကို တိုက်ရိုက်ရေးသားခဲ့သည့် မြင်ကွင်းများ ရှိခဲ့သည် - ၎င်းကို ဒေတာအကြမ်းအဖြစ် ရေးသားကာ အမြင်များထံ ရေးသားခဲ့သည်။ အဲဒီမှာ တစ်ချိန်ချိန်မှာ ဒေတာက သိပ်မမှန်ဘူး၊ ထပ်တူဖြစ်သွားတာ။ ပြီးတော့ ဇယားရဲ့ ဒုတိယအပိုင်းတစ်ခု ရှိတယ်၊ အဲဒါတွေက ရုပ်လုံးပေါ်လာတဲ့ အမြင်တွေနဲ့ အတိအကျ အတူတူပါပဲ၊ ဆိုလိုသည်မှာ ၎င်းတို့သည် ဖွဲ့စည်းတည်ဆောက်ပုံတွင် လုံးဝတူညီပါသည်။ တစ်ချိန်က ကျွန်ုပ်တို့သည် ဒေတာကို ပြန်လည်တွက်ချက်ပြီး ထပ်တူမကျဘဲ ဒေတာများကို ရေတွက်ကာ ထိုဇယားများသို့ စာရေးပါ။
ကျွန်ုပ်တို့သည် API ကိုဖြတ်သွားသည် - ၎င်းသည် ClickHouse တွင် ကိုယ်တိုင်လုပ်ဆောင်မည်မဟုတ်ပါ။ API သည် မှန်ကန်သောဒေတာကို တွက်ချက်ပြီးဖြစ်ကြောင်း အာမခံသည့် ဇယားတွင် နောက်ဆုံးထည့်သည့်ရက်စွဲကို ကျွန်ုပ်ရရှိသည့်အခါတွင်၊ ၎င်းသည် ဇယားတစ်ခုနှင့် အခြားဇယားတစ်ခုသို့ တောင်းဆိုချက်တစ်ခု ပြုလုပ်သည်။ တောင်းဆိုချက်တစ်ခုမှ အချိန်အတိုင်းအတာတစ်ခုအထိ ရွေးချယ်ပြီး အခြားတစ်ခုမှ မတွက်ချက်ရသေးသည့်အရာကို ရရှိသည်။ ၎င်းသည် ClickHouse တစ်ခုတည်းမှတဆင့်အလုပ်လုပ်သည်မဟုတ်။
အကယ်၍ သင့်တွင် API အမျိုးအစားအချို့ရှိလျှင် - လေ့လာသုံးသပ်သူများအတွက်၊ အသုံးပြုသူများအတွက် - ထို့နောက်မူအရ၊ ၎င်းသည် ရွေးချယ်မှုတစ်ခုဖြစ်သည်။ မင်းအမြဲရေတွက်တယ်၊ အမြဲရေတွက်တယ်။ ၎င်းကို တစ်နေ့တစ်ကြိမ် သို့မဟုတ် အခြားအချိန်များတွင် ပြုလုပ်နိုင်သည်။ သင် မလိုအပ်သော အပိုင်းအခြားကို သင်ကိုယ်တိုင် ရွေးချယ်ပြီး မစိုးရိမ်ရပါ။
ClickHouse တွင် မှတ်တမ်းများစွာရှိသည်။ ဆာဗာတွင် ဖြစ်ပျက်သမျှအားလုံးကို တစ်ချက်ချင်း မည်သို့မြင်နိုင်မည်နည်း။
ClickHouse တွင် မတူညီသော မှတ်တမ်းများ အလွန်များပြားပြီး ဤအရေအတွက်သည် တိုးများလာသည်။ ဗားရှင်းအသစ်များတွင်၊ အချို့ကို မူရင်းအတိုင်းဖွင့်ထားသော်လည်း ဗားရှင်းအဟောင်းများတွင် အပ်ဒိတ်လုပ်သည့်အခါတွင် ၎င်းတို့ကို ဖွင့်ထားရပါမည်။ သို့သော် ၎င်းတို့ထဲမှ ပိုများလာပါသည်။ အဆုံးစွန်အားဖြင့်၊ ကျွန်ုပ်သည် ကျွန်ုပ်၏ဆာဗာတွင် ယခုဖြစ်ပျက်နေသည့်အရာကို မြင်လိုသည်၊ အကျဉ်းချုပ် ဒက်ရှ်ဘုတ်တစ်မျိုးမျိုးတွင် ဖြစ်နိုင်သည်။
သင့်တွင် ဤမှတ်တမ်းများကို အဆင်သင့်လုပ်ထားသော ထုတ်ကုန်အဖြစ် ပြသမည့် အသင့်လုပ် ဒက်ရှ်ဘုတ်များ၏ လုပ်ဆောင်ချက်အချို့ကို ပံ့ပိုးပေးသော သင်၏ ClickHouse အဖွဲ့တွင် သို့မဟုတ် သင့်သူငယ်ချင်းများအဖွဲ့တွင် ရှိပါသလား။ အဆုံးစွန်အားဖြင့် ClickHouse ရှိ မှတ်တမ်းများကို ကြည့်ရုံဖြင့် အလွန်ကောင်းမွန်ပါသည်။ ဒါပေမယ့် ဒက်ရှ်ဘုတ်ပုံစံနဲ့ ပြင်ဆင်ထားပြီးသားဆိုရင်တော့ အရမ်းကောင်းပါတယ်။ ကန်တော့မယ်။
စံချိန်စံညွှန်းမမီသော်လည်း ဒက်ရှ်ဘုတ်များရှိသည်။ ကျွန်ုပ်တို့၏ကုမ္ပဏီတွင် အသင်းပေါင်း 60 ခန့်က ClickHouse ကိုအသုံးပြုကြပြီး အထူးဆန်းဆုံးအချက်မှာ ၎င်းတို့အများစုတွင် ၎င်းတို့ကိုယ်တိုင်ပြုလုပ်ထားသည့် ဒက်ရှ်ဘုတ်များရှိပြီး အနည်းငယ်ကွဲပြားသည့်အရာများရှိသည်။ အချို့အဖွဲ့များသည် အတွင်းပိုင်း Yandex.Cloud တပ်ဆင်ခြင်းကို အသုံးပြုသည်။ လိုအပ်သည့် အစီရင်ခံစာများ အားလုံးမဟုတ်သော်လည်း အဆင်သင့်လုပ်ထားသော အစီရင်ခံစာအချို့ရှိသည်။ တခြားသူတွေလည်း ရှိကြတယ်။
Metrica မှ ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များသည် Grafana တွင် ၎င်းတို့၏ကိုယ်ပိုင် ဒက်ရှ်ဘုတ်ရှိပြီး ၎င်းတို့၏အစုအဝေးအတွက် ကျွန်ုပ်၏ကိုယ်ပိုင်ရှိသည်။ serif cache အတွက် cache hit လိုမျိုး အရာတွေကို ကြည့်နေတယ်။ ပို၍ပင်ခက်ခဲသည်မှာ ကျွန်ုပ်တို့သည် မတူညီသောကိရိယာများကို အသုံးပြုနေခြင်းဖြစ်သည်။ Graphite-web ဟုခေါ်သော အလွန်ရှေးကျသော ကိရိယာကို အသုံးပြု၍ ကျွန်ုပ်၏ ဒက်ရှ်ဘုတ်ကို ဖန်တီးခဲ့သည်။ သူက လုံးဝရုပ်ဆိုးတယ်။ Grafana က ပိုအဆင်ပြေပြီး လှပနေပေမယ့်လည်း ဒီနည်းကို ကျွန်တော်သုံးနေတုန်းပါပဲ။
ဒက်ရှ်ဘုတ်များတွင် အခြေခံအချက်မှာ အတူတူပင်ဖြစ်သည်။ ၎င်းတို့သည် အစုအဝေးအတွက် စနစ်မက်ထရစ်များဖြစ်သည်- CPU၊ memory၊ disk၊ network အခြားအရာများ - တစ်ပြိုင်နက်တည်း တောင်းဆိုချက်အရေအတွက်၊ တစ်ပြိုင်နက်တည်း ပေါင်းစည်းမှုအရေအတွက်၊ တစ်စက္ကန့်လျှင် တောင်းဆိုချက်အရေအတွက်၊ MergeTree ဇယားကန့်ကွက်များ အတွက် အများဆုံး အပိုင်းအရေအတွက်၊ ကူးယူမှု နောက်ကျခြင်း၊ ထပ်တူပြုခြင်း တန်းစီခြင်း အရွယ်အစား၊ တစ်စက္ကန့်လျှင် ထည့်သွင်းထားသော အတန်းအရေအတွက်၊ တစ်စက္ကန့်လျှင် ထည့်သွင်းထားသော ဘလောက်များ အရေအတွက်။ ဤအရာသည် မှတ်တမ်းများမှမဟုတ်ဘဲ မက်ထရစ်များမှ ရရှိသော အရာများဖြစ်သည်။
ဗလာဒီမာ Kolobaev Alexey နည်းနည်းပြင်ပေးချင်ပါတယ်။ Grafana ရှိတယ်။ Grafana တွင် ClickHouse ဖြစ်သည့် ဒေတာအရင်းအမြစ်တစ်ခုရှိသည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်သည် Grafana မှ ClickHouse သို့ တိုက်ရိုက်တောင်းဆိုမှုများ ပြုလုပ်နိုင်သည်။ ClickHouse တွင် မှတ်တမ်းများပါရှိသော ဇယားတစ်ခုရှိပြီး လူတိုင်းအတွက် အတူတူပင်ဖြစ်ပါသည်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်သည် ဤမှတ်တမ်းဇယားကို Grafana တွင်ဝင်ရောက်ကြည့်ရှုလိုပြီး ကျွန်ုပ်၏ဆာဗာမှတောင်းဆိုမှုများကို ကြည့်ရှုလိုပါသည်။ ဤကဲ့သို့သော ဒက်ရှ်ဘုတ်တစ်ခုရှိလျှင် ကောင်းပေလိမ့်မည်။
ငါကိုယ်တိုင် စက်ဘီးစီးခဲ့တယ်။ ဒါပေမယ့် ကျွန်တော့်မှာ မေးစရာတစ်ခုရှိတယ် - အဲဒါတွေအားလုံးက စံသတ်မှတ်ထားပြီး Grafana ကို လူတိုင်းအသုံးပြုတယ်ဆိုရင် ဘာကြောင့် Yandex မှာ ဒီလိုတရားဝင် ဒက်ရှ်ဘုတ် မရှိတာလဲ။
Kirill Shvakov- တကယ်တော့၊ ClickHouse သို့သွားသောဒေတာအရင်းအမြစ်သည် Altinity ကိုယခုအသုံးပြုနိုင်သည်။ ပြီးတော့ ဘယ်နေရာကို တူးရမလဲ၊ ဘယ်သူက တွန်းရမလဲဆိုတဲ့ အားနည်းချက်ကို ပေးချင်တာပါ။ Yandex သည် ClickHouse ကိုပြုလုပ်နေဆဲဖြစ်ပြီး ၎င်းနှင့်ပတ် ၀ န်းကျင်ဇာတ်လမ်းမဟုတ်သောကြောင့် ၎င်းတို့ကို သင်မေးနိုင်သည်။ Altinity သည် လက်ရှိ ClickHouse ကို အရောင်းမြှင့်တင်နေသည့် အဓိက ကုမ္ပဏီဖြစ်သည်။ သူတို့သည် သူ့ကို မစွန့်ဘဲ ထောက်ပံ့ကြလိမ့်မည်။ အခြေခံအားဖြင့် Grafana ဝဘ်ဆိုက်သို့ ဒက်ရှ်ဘုတ်တစ်ခုကို အပ်လုဒ်လုပ်ရန် သင်သည် ၎င်းကို မှတ်ပုံတင်ပြီး အပ်လုဒ်လုပ်ရန်သာ လိုအပ်သောကြောင့် - အထူးပြဿနာများမရှိပါ။
Alexey Milovidov ပြီးခဲ့သောနှစ်တွင် ClickHouse သည် query profileing စွမ်းရည်များစွာကို ထည့်သွင်းခဲ့သည်။ အရင်းအမြစ်အသုံးပြုမှုတွင် တောင်းဆိုမှုတစ်ခုစီအတွက် မက်ထရစ်များရှိသည်။ မကြာသေးမီကပင်၊ စုံစမ်းမေးမြန်းမှုတစ်ခုသည် မီလီစက္ကန့်တိုင်း သုံးစွဲနေသည့်နေရာကို ကြည့်ရန် အောက်ခြေအဆင့် စုံစမ်းမှု ပရိုဖိုင်းကို ထည့်ပေးခဲ့သည်။ ဒါပေမယ့် ဒီလုပ်ဆောင်ချက်ကိုသုံးဖို့အတွက်၊ ငါအမြဲမေ့နေတဲ့ console client ကိုဖွင့်ပြီး တောင်းဆိုချက်တစ်ခုကို ရိုက်ထည့်ရပါမယ်။ တစ်နေရာရာမှာ သိမ်းဆည်းပြီး အတိအကျ နေရာကို မေ့နေခဲ့တယ်။
ဤသည်မှာ သင်၏လေးလံသောမေးခွန်းများကို query class ဖြင့်အုပ်စုဖွဲ့ထားသော tool တစ်ခုရှိချင်ပါသည်။ တစ်ချက်နှိပ်လိုက်တာနဲ့ အဲဒါက လေးလံတယ်လို့ ပြောလိမ့်မယ်။ ယခုတွင် ထိုကဲ့သို့ ဖြေရှင်းချက် မရှိပါ။ ပြီးတော့ လူတွေက ကျွန်တော့်ကို “ပြောပါ Grafana အတွက် အဆင်သင့်လုပ်ထားတဲ့ ဒက်ရှ်ဘုတ်တွေ ရှိလား” လို့ မေးတဲ့အခါ “Grafana ဝဘ်ဆိုက်ကို သွားပါ၊ “ဒိုင်ခွက်များ” အသိုက်အဝန်းတစ်ခု ရှိပြီး ဒက်ရှ်ဘုတ်တစ်ခု ရှိပါတယ်၊ Dimka မှ Kostyan မှ dashboard တစ်ခုရှိသည်။ ဘာလဲမသိဘူး၊ ငါကိုယ်တိုင်မသုံးဖူးဘူး"
ဆာဗာသည် OOM သို့မတိုက်မိစေရန် ပေါင်းစည်းခြင်းကို မည်ကဲ့သို့ လွှမ်းမိုးနိုင်မည်နည်း။
ငါ့မှာ ဇယားတစ်ခုရှိတယ်၊ ဇယားမှာ အပိုင်းတစ်ခုပဲရှိတယ်၊ အဲဒါက ReplaceingMergeTree။ အချက်အလက်တွေ ရေးနေတာ လေးနှစ်ရှိပြီ။ ပြောင်းလဲမှုတစ်ခုပြုလုပ်ရန်နှင့် ဒေတာအချို့ကို ဖျက်ပစ်ရန် လိုအပ်ပါသည်။
ကျွန်တော် ဒါကိုလုပ်ခဲ့ပြီး ဒီတောင်းဆိုမှုကို လုပ်ဆောင်နေချိန်မှာ၊ အစုအဝေးရှိ ဆာဗာအားလုံးရှိ မမ်မိုရီအားလုံးကို သုံးစွဲခဲ့ပြီး အစုအဝေးရှိ ဆာဗာများအားလုံး OOM သို့သွားခဲ့သည်။ ထို့နောက် သူတို့အားလုံး အတူတကွထကြပြီး၊ ဤတူညီသောလည်ပတ်ဆောင်ရွက်မှု၊ ဤဒေတာပိတ်ဆို့ခြင်းကို စတင်ကာ OOM သို့ ထပ်မံဝင်ရောက်ခဲ့ကြသည်။ ထို့နောက် သူတို့သည် တစ်ဖန်ထ၍ လဲကျပြန်သည်။ ပြီးတော့ ဒီအရာက ရပ်တန့်မသွားဘူး။
နောက်တော့ ဒါက ယောက်ျားလေးတွေ ပြင်ပေးတဲ့ bug ပဲဆိုတာ သိလာရတယ်။ ဒါက အရမ်းမိုက်တယ်၊ ကျေးဇူးအများကြီးတင်ပါတယ်။ ဒါပေမယ့် အကြွင်းအကျန်တွေ ကျန်ခဲ့ပါတယ်။ ယခုလည်း ဇယားတွင် ပေါင်းစည်းမှု တစ်မျိုးမျိုး ပြုလုပ်ရန် စဉ်းစားသောအခါတွင် မေးခွန်းတစ်ခု ရှိသည် - ဤပေါင်းစည်းမှုများကို အဘယ်ကြောင့် တစ်နည်းတစ်ဖုံ လွှမ်းမိုးနိုင်သနည်း။ ဥပမာအားဖြင့်၊ ၎င်းတို့ကို လိုအပ်သော RAM ပမာဏဖြင့် ကန့်သတ်ထားပါ သို့မဟုတ် မူအားဖြင့် ဤဇယားကို လုပ်ဆောင်မည့် ပမာဏဖြင့် ကန့်သတ်ပါ။
ကျွန်ုပ်တွင် "မက်ထရစ်များ" ဟုခေါ်သော ဇယားတစ်ခုရှိသည်၊ ကျေးဇူးပြု၍ ကျွန်ုပ်အတွက် ၎င်းကို စာတွဲနှစ်ခုဖြင့် လုပ်ဆောင်ပါ။ အပြိုင် ဆယ်ခု သို့မဟုတ် ငါးခု ပေါင်းစပ်ဖန်တီးရန် မလိုအပ်ပါ၊ ၎င်းကို နှစ်ပိုင်းလုပ်ပါ။ နှစ်ယောက်အတွက် လုံလောက်တဲ့ Memory ရှိတယ်လို့ ထင်ပါတယ်၊ ဒါပေမယ့် ဆယ်ခုကို လုပ်ဆောင်ဖို့ မလုံလောက်ပါဘူး။ ဘာကြောင့် အကြောက်တရားတွေ ရှိနေတာလဲ။ ဘာကြောင့်လဲဆိုတော့ ဇယားက ကြီးထွားလာပြီး တစ်နေ့ကျရင် မူအရတော့ bug တစ်ခုကြောင့်မဟုတ်တော့ဘဲ ဒေတာတွေ အများကြီးပြောင်းလဲသွားတဲ့အတွက် ဒေတာပမာဏက လုံလောက်တဲ့ Memory မလုံလောက်လို့၊ ဆာဗာ။ ထို့နောက် ပေါင်းစည်းလိုက်သောအခါ ဆာဗာသည် OOM သို့ ပျက်သွားလိမ့်မည်။ ထို့အပြင်၊ ကျွန်ုပ်သည် ဗီဇပြောင်းလဲခြင်းကို ပယ်ဖျက်နိုင်သော်လည်း Merji မရှိတော့ပါ။
ပေါင်းစည်းလိုက်သောအခါတွင် ဆာဗာသည် OOM ထဲသို့ ကျလိမ့်မည်မဟုတ်ကြောင်း သင်သိသည်၊ အဘယ်ကြောင့်ဆိုသော် ပေါင်းစည်းသောအခါတွင် RAM ပမာဏသည် ဒေတာအကွာအဝေးတစ်ခုအတွက်သာ အသုံးပြုသောကြောင့်ဖြစ်သည်။ ဒါကြောင့် ဒေတာပမာဏ ဘယ်လိုပဲ ဖြစ်ဖြစ် အားလုံး အဆင်ပြေသွားမှာပါ။
ဗလာဒီမာ Kolobaev ဒဏ်ငွေ။ ဤတွင် အခိုက်အတန့်မှာ bug ကိုပြင်ပြီးသောအခါ၊ ကျွန်ုပ်ကိုယ်တိုင်အတွက် ဗားရှင်းအသစ်ကို ဒေါင်းလုဒ်လုပ်ပြီး၊ အခြားစားပွဲတစ်ခု၊ အပိုင်းများစွာရှိသည့် သေးငယ်သောတစ်ခုတွင် အလားတူလုပ်ဆောင်ချက်ကို လုပ်ဆောင်ခဲ့သည်။ ပေါင်းစည်းစဉ်တွင်၊ ဆာဗာတွင် RAM 100 GB ခန့်ကို လောင်ကျွမ်းစေခဲ့သည်။ ကျွန်ုပ်တွင် သိမ်းပိုက်မှု 150၊ ထမင်းစား 100 နှင့် 50 GB ဝင်းဒိုးတစ်ခု ကျန်နေသောကြောင့် ကျွန်ုပ်သည် OOM ထဲသို့ မကျရောက်ခဲ့ပါ။
အကယ်၍ ၎င်းသည် 100 GB RAM ကို အမှန်တကယ်သုံးစွဲပါက OOM ထဲသို့ လောလောဆယ် ကျွန်ုပ်အား မည်သည့်အရာက ကာကွယ်ပေးသနည်း။ ပေါင်းစပ်ထားသော RAM ရုတ်တရက်ကုန်သွားပါက ဘာလုပ်ရမလဲ။
Alexey Milovidov ပေါင်းစည်းရန်အတွက် သီးသန့် RAM သုံးစွဲမှုသည် အကန့်အသတ်မရှိသော ပြဿနာတစ်ခုဖြစ်သည်။ ဒုတိယပြဿနာမှာ အချို့သော ပေါင်းစပ်မှုကို သတ်မှတ်ပေးထားပါက၊ ၎င်းကို ပွားခြင်းမှတ်တမ်းတွင် မှတ်တမ်းတင်ထားသောကြောင့် ၎င်းကို အကောင်အထည်ဖော်ရမည်ဖြစ်သည်။ ပုံတူပွားခြင်းမှတ်တမ်းသည် ပုံတူကို တသမတ်တည်းဖြစ်စေရန် လိုအပ်သည့် လုပ်ဆောင်ချက်များဖြစ်သည်။ ဤပုံတူပွားခြင်းမှတ်တမ်းကို ပြန်ပြောင်းမည့် လူကိုယ်တိုင် ခြယ်လှယ်မှုများ မပြုလုပ်ပါက၊ ပေါင်းစည်းခြင်းကို တစ်နည်းမဟုတ်တစ်နည်း လုပ်ဆောင်ရမည်ဖြစ်ပါသည်။
ဟုတ်ပါတယ်၊၊ OOM ကိုကာကွယ်ပေးမယ့် RAM ကန့်သတ်ချက်ရှိဖို့ မလိုအပ်ပါဘူး။ ပေါင်းစည်းမှုကို ပြီးမြောက်အောင် မကူညီနိုင်ပေ၊ ၎င်းသည် နောက်တစ်ကြိမ် စတင်မည်၊ အတိုင်းအတာတစ်ခုအထိ ရောက်ရှိမည်၊ ခြွင်းချက်တစ်ခုအား ပစ်ချပြီးနောက် ပြန်လည်စတင်ပါ - ဤအရာမှ မည်သည့်အရာမှ ကောင်းမွန်လာမည်မဟုတ်ပါ။ သို့သော်မူအရ၊ ဤကန့်သတ်ချက်ကိုမိတ်ဆက်ရန် အသုံးဝင်မည်ဖြစ်သည်။
ClickHouse အတွက် Golang ဒရိုက်ဘာကို ဘယ်လိုဖန်တီးမလဲ။
Kirill Shvakov မှရေးသားခဲ့သော Golang ယာဉ်မောင်းကို ClickHouse အဖွဲ့မှတရားဝင်ပံ့ပိုးပေးနေပြီဖြစ်သည်။ သူ သူက အခု ကြီးပြီး အစစ်အမှန်။
မှတ်စုလေးတစ်ခု။ အကန့်အသတ်မရှိသော ပုံမှန်ပုံစံများ၏ အံ့သြဖွယ်ကောင်းပြီး ချစ်လှစွာသော သိုလှောင်ရုံတစ်ခု ရှိသည် - ၎င်းသည် Vertica ဖြစ်သည်။ ၎င်းတို့တွင် Vertica developer များက ပံ့ပိုးထားသည့် ၎င်းတို့၏ တရားဝင် python driver လည်းရှိသည်။ သိုလှောင်မှုဗားရှင်းများနှင့် ဒရိုက်ဘာဗားရှင်းများ သိသိသာသာ ကွဲပြားသွားကာ တစ်ချိန်ချိန်တွင် ဒရိုင်ဘာ အလုပ်မလုပ်တော့ကြောင်း အကြိမ်များစွာ ဖြစ်ပွားခဲ့သည်။ ဒုတိယအချက်။ ဤတရားဝင်ယာဉ်မောင်းအတွက် ပံ့ပိုးကူညီမှုသည် “နို့သီးခေါင်း” စနစ်ဖြင့် လုပ်ဆောင်သည် - သင်သည် ၎င်းတို့ကို ပြဿနာတစ်ခုရေးပြီး ၎င်းသည် အမြဲတမ်း တွဲနေပါသည်။
ငါ့မှာ မေးခွန်းနှစ်ခုရှိတယ်။ ယခု Kirill ၏ Golang ဒရိုက်ဘာသည် ClickHouse နှင့် Golang မှ ဆက်သွယ်ရန် မူရင်းနည်းလမ်းနီးပါးဖြစ်သည်။ တစ်စုံတစ်ယောက်သည် ၎င်းကိုနှစ်သက်သောကြောင့် http interface မှတစ်ဆင့် ဆက်သွယ်ခြင်းမပြုပါက၊ ဒီဒရိုင်ဘာရဲ့ ဖွံ့ဖြိုးတိုးတက်မှုက ဘယ်လို ဆက်သွားမလဲ။ repository ကိုယ်တိုင်က ပျက်စီးနေတဲ့ အပြောင်းအလဲတွေနဲ့ ထပ်တူပြုမှာလား။ ပြဿနာတစ်ရပ်ကို ထည့်သွင်းစဉ်းစားရန် လုပ်ငန်းစဉ်သည် အဘယ်နည်း။
Kirill Shvakov- ပထမအချက်က အရာအားလုံးကို ဗျူရိုကရေစီစနစ်တကျ စီမံထားခြင်း။ ဤအချက်ကို မဆွေးနွေးခဲ့၍ ကျွန်ုပ်မှာ အဖြေမရှိပါ။
ပြဿနာနှင့်ပတ်သက်သောမေးခွန်းကိုဖြေဆိုရန် ယာဉ်မောင်း၏သမိုင်းကြောင်း အနည်းငယ်လိုအပ်ပါသည်။ ဒေတာတွေ အများကြီးရှိတဲ့ ကုမ္ပဏီတစ်ခုမှာ ကျွန်တော် အလုပ်လုပ်ခဲ့တယ်။ ၎င်းသည် တစ်နေရာရာတွင် သိမ်းဆည်းထားရန် လိုအပ်သော ပွဲအမြောက်အမြားရှိသော ကြော်ငြာလှည့်ကွက်တစ်ခုဖြစ်သည်။ တစ်ချိန်ချိန်တွင် ClickHouse ပေါ်လာသည်။ အဲဒါကို ဒေတာတွေနဲ့ ဖြည့်ပြီး အစပိုင်းမှာတော့ အားလုံးအဆင်ပြေပေမယ့် ClickHouse ပျက်သွားတယ်။ အဲဒီအချိန်မှာ ကျွန်တော်တို့က အဲဒါကို မလိုအပ်ဘူးလို့ ဆုံးဖြတ်လိုက်တယ်။
တစ်နှစ်အကြာတွင်၊ ကျွန်ုပ်တို့သည် ClickHouse ကိုအသုံးပြုရန် စိတ်ကူးကို ပြန်ရောက်လာပြီး ထိုနေရာတွင် ဒေတာကို တစ်နည်းနည်းဖြင့် ရေးသားရန် လိုအပ်ပါသည်။ မိတ်ဆက်စာမှာ ဤအရာဖြစ်သည်- ဟာ့ဒ်ဝဲသည် အလွန်အားနည်းသည်၊ အရင်းအမြစ်အနည်းငယ်ရှိသည်။ သို့သော် ကျွန်ုပ်တို့သည် ဤနည်းအတိုင်း အမြဲလုပ်ဆောင်ခဲ့ပြီး ထို့ကြောင့် ကျွန်ုပ်တို့သည် မူလပရိုတိုကောကို ဦးတည်ထားသည်။
ကျွန်တော်တို့ Go မှာ အလုပ်လုပ်ကတည်းက Go driver လိုတယ်ဆိုတာ ရှင်းပါတယ်။ အချိန်ပြည့်နီးပါး လုပ်ခဲ့တယ် - အဲဒါက ငါ့အလုပ်ပဲ။ ကျွန်ုပ်တို့သည် ၎င်းကို တစ်စုံတစ်ရာသောအချက်သို့ ယူဆောင်လာခဲ့ပြီး မူအရ ကျွန်ုပ်တို့မှလွဲ၍ အခြားမည်သူမျှ ၎င်းကို အသုံးပြုမည်ဟု မည်သူမျှ မယူဆပါ။ ထို့နောက် CloudFlare သည် တူညီသောပြဿနာတစ်ခုဖြင့် ရောက်ရှိလာပြီး ၎င်းတို့နှင့် တူညီသောအလုပ်များ ရှိသောကြောင့် အချိန်အတော်ကြာ ကျွန်ုပ်တို့သည် အလွန်ချောမွေ့စွာ လုပ်ဆောင်ခဲ့ပါသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ဤအရာကို ClickHouse တွင်သာမက ယာဉ်မောင်းတွင်ပါ ပြုလုပ်ခဲ့သည်။
တစ်ချိန်ချိန်တွင်၊ ကျွန်ုပ်သည် ClickHouse နှင့်အလုပ်အနည်းငယ်ပြောင်းလဲသွားသောကြောင့်ကျွန်ုပ်၏လုပ်ဆောင်ချက်သည်အနည်းငယ်ပြောင်းလဲသွားသောကြောင့်ဖြစ်သည်။ ထို့ကြောင့် ပြဿနာများကို မပိတ်ပါ။ အခါအားလျော်စွာ၊ ၎င်းတို့ကိုယ်တိုင် တစ်ခုခုလိုအပ်နေသူများသည် သိုလှောင်ရုံသို့ အပ်နှံကြသည်။ ထို့နောက် ဆွဲထုတ်ရန် တောင်းဆိုချက်ကို ကြည့်လိုက်ရာ တစ်ခါတစ်ရံတွင် ကျွန်ုပ်ကိုယ်တိုင် တစ်ခုခုကိုပင် တည်းဖြတ်ခဲ့သော်လည်း၊ ထိုသို့ဖြစ်ခဲပါသည်။
ဒရိုင်ဘာကို ပြန်သွားချင်တယ်။ လွန်ခဲ့သောနှစ်ပေါင်းများစွာက ဤအရာအားလုံးစတင်သောအခါတွင် ClickHouse သည် ကွဲပြားခြားနားပြီး ကွဲပြားခြားနားသောစွမ်းရည်များဖြင့်လည်း လုပ်ဆောင်ခဲ့သည်။ ယခု ကျွန်ုပ်တို့သည် ယာဉ်မောင်းကို ကောင်းစွာအလုပ်လုပ်နိုင်စေရန် မည်သို့ပြန်လည်ဖန်တီးရမည်ကို ကျွန်ုပ်တို့ နားလည်သဘောပေါက်ထားပါသည်။ ထိုသို့ဖြစ်လာပါက၊ စုဆောင်းထားသော ချိုင်းထောက်များကြောင့် ဗားရှင်း 2 သည် မည်သည့်အခြေအနေတွင်မဆို တွဲသုံးနိုင်မည်မဟုတ်ပေ။
ဒီကိစ္စကို ဘယ်လိုစီစဉ်ရမှန်းမသိဘူး။ ငါ့မှာ အချိန်သိပ်မရှိဘူး။ တစ်ချို့လူတွေက ကားမောင်းတာကို ပြီးသွားရင် ငါ သူတို့ကို ကူညီပြီး ဘာလုပ်ရမယ်ဆိုတာ ပြောပြပေးနိုင်ပါတယ်။ သို့သော် ပရောဂျက်ဖွံ့ဖြိုးတိုးတက်ရေးတွင် Yandex ၏ တက်ကြွစွာပါဝင်မှုကို မဆွေးနွေးရသေးပါ။
Alexey Milovidov တကယ်တော့ ဒီယာဉ်မောင်းတွေနဲ့ ပတ်သက်ပြီး ဗျူရိုကရေစီ မရှိသေးပါ။ တစ်ခုတည်းသောအချက်မှာ ၎င်းတို့ကို တရားဝင်အဖွဲ့အစည်းတစ်ခုထံ တင်ပြရခြင်းဖြစ်သည်၊ ဆိုလိုသည်မှာ ဤယာဉ်မောင်းအား Go အတွက် တရားဝင်ပုံသေဖြေရှင်းချက်အဖြစ် အသိအမှတ်ပြုထားသည်။ အခြားယာဉ်မောင်းအချို့ရှိသော်လည်း သီးခြားစီလာကြသည်။
ဤဒရိုင်ဘာများအတွက် ကျွန်ုပ်တို့တွင် အတွင်းပိုင်း ဖွံ့ဖြိုးတိုးတက်မှု မရှိပါ။ မေးခွန်းမှာ ဤအထူးယာဉ်မောင်းအတွက်မဟုတ်ဘဲ၊ ရပ်ရွာယာဉ်မောင်းများအားလုံး ဖွံ့ဖြိုးတိုးတက်မှုအတွက်၊ သို့မဟုတ် ပြင်ပမှတစ်စုံတစ်ဦးကို ရှာဖွေနိုင်မလား။
lazy_load ဆက်တင်ကို ဖွင့်ထားခြင်းဖြင့် ပြန်လည်စတင်ပြီးနောက် ပြင်ပအဘိဓာန်သည် မဖွင့်နိုင်ပါ။ ဘာလုပ်မလဲ?
ကျွန်ုပ်တို့တွင် lazy_load ဆက်တင်ကို ဖွင့်ထားပြီး ဆာဗာကို ပြန်လည်စတင်ပြီးနောက်၊ အဘိဓာန်သည် ၎င်း၏ကိုယ်ပိုင်တွင် ဖွင့်မည်မဟုတ်ပါ။ အသုံးပြုသူသည် ဤအဘိဓာန်ကို ဝင်ရောက်ကြည့်ရှုပြီးမှသာ ၎င်းကို မြှင့်တင်မည်ဖြစ်သည်။ ၎င်းကို ကျွန်ုပ်ပထမအကြိမ်ဝင်ရောက်သည့်အခါတွင် အမှားအယွင်းတစ်ခု ဖြစ်ပေါ်စေပါသည်။ ClickHouse သုံးပြီး အဘိဓာန်များကို တနည်းနည်းနဲ့ အလိုအလျောက် တင်နိုင်သလား သို့မဟုတ် အသုံးပြုသူများ အမှားများမခံရစေရန် ၎င်းတို့၏ အဆင်သင့်ကို သင်ကိုယ်တိုင် အမြဲထိန်းချုပ်ရန် လိုအပ်ပါသလား။
ကျွန်ုပ်တို့တွင် ClickHouse ၏ ဗားရှင်းဟောင်းတစ်ခု ရှိကောင်းရှိနိုင်သည်၊ ထို့ကြောင့် အဘိဓာန်သည် အလိုအလျောက် မတင်နိုင်သေးပါ။ ဤသို့ဖြစ်နိုင်ပါသလား။
ပထမဦးစွာ၊ query ကိုအသုံးပြု၍ အဘိဓာန်များကို အတင်းအကြပ်တင်နိုင်သည်။ စနစ် အဘိဓာန်များကို ပြန်လည်စတင်ပါ။. ဒုတိယအချက်မှာ အမှားနှင့်ပတ်သက်၍ - အဘိဓာန်ကို တင်ထားပြီးဖြစ်ပါက၊ မေးမြန်းချက်များသည် ဒေါင်းလုဒ်လုပ်ထားသည့် ဒေတာအပေါ် အခြေခံ၍ အလုပ်လုပ်မည်ဖြစ်သည်။ အကယ်၍ အဘိဓာန်ကို မတင်ရသေးပါက၊ တောင်းဆိုမှုအတွင်း တိုက်ရိုက်တင်ပေးပါမည်။
လေးလံသော အဘိဓာန်များအတွက် ၎င်းသည် အလွန်အဆင်ပြေမည်မဟုတ်ပါ။ ဥပမာအားဖြင့်၊ သင်သည် MySQL မှ အတန်းတစ်သန်းကို ဆွဲထုတ်ရန် လိုအပ်သည်။ တစ်စုံတစ်ဦးသည် ရိုးရှင်းသောရွေးချယ်မှုတစ်ခုကို ပြုလုပ်သော်လည်း ဤရွေးချယ်မှုသည် အတန်းတစ်သန်းကို စောင့်မည်ဖြစ်သည်။ ဤနေရာတွင် ဖြေရှင်းချက်နှစ်ခုရှိသည်။ ပထမတစ်ခုကတော့ lazy_load ကိုပိတ်လိုက်ပါ။ ဒုတိယအနေနဲ့၊ server တက်လာတဲ့အခါ၊ load မတင်ခင် လုပ်ပါ။ စနစ်အဘိဓာန်ကို ပြန်လည်စတင်ပါ။ သို့မဟုတ် အဘိဓာန်ကို အသုံးပြုသည့် စုံစမ်းမှုတစ်ခု ပြုလုပ်ပါ။ ထို့နောက် အဘိဓာန်ကို တင်ပေးပါမည်။ ClickHouse သည် ၎င်းတို့ကို အလိုအလျောက် မတင်နိုင်သောကြောင့် lazy_load ဆက်တင်ကို ဖွင့်ထားခြင်းဖြင့် အဘိဓာန်များရရှိနိုင်မှုကို ထိန်းချုပ်ရန် လိုအပ်ပါသည်။
နောက်ဆုံးမေးခွန်း၏အဖြေမှာ ဗားရှင်းဟောင်းသည်ဖြစ်စေ သို့မဟုတ် အမှားရှာရန် လိုအပ်သည်။
အနည်းဆုံးတစ်ခု error တစ်ခုပျက်သွားပါက system reload dictionaries များထဲမှ တစ်ခုမှ အဘိဓာန်များကို မတင်နိုင်ခြင်း နှင့် မည်ကဲ့သို့လုပ်ဆောင်ရမည်နည်း။
စနစ်ပြန်လည်စတင်သည့် အဘိဓာန်များနှင့်ပတ်သက်သည့် နောက်ထပ်မေးခွန်းတစ်ခုရှိသည်။ ကျွန်ုပ်တို့တွင် အဘိဓာန်နှစ်ခု ရှိသည် - တစ်ခုသည် မတင်ရသေးပါ၊ ဒုတိယတစ်ခုသည် တင်နေပါသည်။ ဤကိစ္စတွင်၊ System reload အဘိဓာန်များသည် မည်သည့် အဘိဓာန်ကိုမျှ မတင်ဘဲ၊ စနစ်ပြန်တင်သည့် အဘိဓာန်ကို အသုံးပြု၍ သီးခြားတစ်ခုကို ၎င်း၏အမည်ဖြင့် ညွှန်ပြရန် လိုအပ်ပါသည်။ ၎င်းသည် ClickHouse ဗားရှင်းနှင့်လည်း သက်ဆိုင်ပါသလား။
မင်းကိုပျော်စေချင်တယ်။ ဒီအမူအကျင့်က ပြောင်းလဲသွားတယ်။ ဆိုလိုသည်မှာ သင် ClickHouse ကို မွမ်းမံပါက ၎င်းသည်လည်း ပြောင်းလဲသွားမည်ဖြစ်သည်။ မင်းရဲ့ လက်ရှိအပြုအမူကို မကျေနပ်ရင် စနစ် အဘိဓာန်များကို ပြန်လည်စတင်ပါ။၊ အပ်ဒိတ်လုပ်ပြီး ပိုကောင်းအောင် ပြောင်းလဲမယ်လို့ မျှော်လင့်ကြပါစို့။
ClickHouse config တွင်အသေးစိတ်အချက်အလက်များကို configure လုပ်ရန်နည်းလမ်းရှိပါသလား၊ သို့သော်အမှားအယွင်းများရှိပါက၎င်းတို့ကိုမပြသပါ။
နောက်မေးခွန်းတစ်ခုကတော့ အဘိဓာန်နဲ့ပတ်သက်တဲ့ အမှားအယွင်းတွေအကြောင်း၊ အတိအကျပြောရရင် အသေးစိတ်ပါပဲ။ အဘိဓာန်အတွက် ClickHouse config တွင် ချိတ်ဆက်မှုအသေးစိတ်အချက်အလက်များကို ကျွန်ုပ်တို့သတ်မှတ်ထားပြီး အမှားအယွင်းရှိပါက၊ ဤအသေးစိတ်အချက်အလက်များနှင့် စကားဝှက်ကို ကျွန်ုပ်တို့ လက်ခံရရှိမည်ဖြစ်သည်။
ODBC ဒရိုက်ဘာ config တွင်အသေးစိတ်အချက်များထည့်ခြင်းဖြင့်ဤအမှားကိုဖြေရှင်းခဲ့သည်။ ClickHouse config တွင်အသေးစိတ်အချက်အလက်များကို configure လုပ်ရန်နည်းလမ်းရှိပါသလား၊ သို့သော်အမှားများရှိပါကဤအသေးစိတ်အချက်အလက်များကိုမပြပါ။
ဤနေရာတွင် တကယ့်အဖြေမှာ odbc.ini တွင် ဤအထောက်အထားများကို သတ်မှတ်ရန်ဖြစ်ပြီး ClickHouse ကိုယ်တိုင်က ODBC Data Source Name ကိုသာ သတ်မှတ်ပေးသည်။ အခြားသော အဘိဓာန်ရင်းမြစ်များအတွက် ၎င်းသည် ဖြစ်ပေါ်မည်မဟုတ်ပါ - MySQL ပါသော အဘိဓာန်အတွက်ရော အခြားသူများအတွက်ပါ အမှားအယွင်း မက်ဆေ့ချ်ကို လက်ခံရရှိသောအခါ စကားဝှက်ကို မမြင်ရပါ။ ODBC အတွက်၊ ငါလည်းကြည့်မယ် - အဲဒါရှိရင်၊ မင်းဖယ်ဖို့ပဲလိုတယ်။
အပိုဆု- စုဝေးမှုများမှ Zoom အတွက် နောက်ခံများ
ပုံပေါ်တွင် နှိပ်ခြင်းဖြင့်၊ စုဝေးမှုများမှ ဘောနပ်စ်နောက်ခံများကို အမြဲဆုံးဖတ်သူများအတွက် ဖွင့်ပါမည်။ ကျွန်ုပ်တို့သည် Avito နည်းပညာ mascots များနှင့်အတူ မီးငြိမ်းသတ်ခြင်း၊ စနစ်စီမံခန့်ခွဲသူ၏အခန်း သို့မဟုတ် ကျောင်းဟောင်းကွန်ပြူတာကလပ်မှ လုပ်ဖော်ကိုင်ဖက်များနှင့် ဆွေးနွေးကြပြီး ဂရပ်ဖီတီနောက်ခံပုံနှင့် တံတားအောက်တွင် နေ့စဉ်အစည်းအဝေးများ ပြုလုပ်ကြသည်။
source: www.habr.com