HighLoad++၊ Andrey Gushchin (Zabbix)- မြင့်မားသောစွမ်းဆောင်ရည်နှင့် မူရင်းအပိုင်းခွဲခြင်း။

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

HighLoad++ ဆိုက်ဘေးရီးယား 2019။ Tomsk ခန်းမ။ ဇွန်လ ၂၄ ရက် ၁၆း၀၀။ စိတ္တဇများနှင့် တင်ဆက်မှု. လာမည့် HighLoad++ ကွန်ဖရင့်ကို စိန့်ပီတာစဘတ်တွင် 6 ခုနှစ် ဧပြီလ 7 ရက်နေ့မှ 2020 ရက်နေ့အထိ ကျင်းပမည်ဖြစ်ပါသည်။ အသေးစိတ်နှင့်လက်မှတ်များ လင့်ခ်.

Andrey Gushchin (နောင် - AG) - ကျွန်ုပ်သည် ZABBIX နည်းပညာဆိုင်ရာပံ့ပိုးကူညီမှုအင်ဂျင်နီယာတစ်ဦး (ယခုနောက်ပိုင်းတွင် "Zabbix" ဟုရည်ညွှန်းသည်)၊ သင်တန်းဆရာဖြစ်သည်။ ကျွန်ုပ်သည် နည်းပညာဆိုင်ရာ ပံ့ပိုးကူညီမှုတွင် ၆ နှစ်ကျော် လုပ်ကိုင်ခဲ့ပြီး စွမ်းဆောင်ရည်ကို တိုက်ရိုက်ကြုံတွေ့ခဲ့ရသည်။ ပုံမှန် PostgreSQL 6 နှင့် နှိုင်းယှဉ်သည့်အခါ TimescaleDB ပေးစွမ်းနိုင်သော စွမ်းဆောင်ရည်အကြောင်း ယနေ့ ကျွန်ုပ်ပြောပါမည်။ ထို့အပြင်၊ အချို့သော နိဒါန်းအပိုင်း - ယေဘုယျအားဖြင့် ၎င်းသည် မည်သို့အလုပ်လုပ်ပုံအကြောင်း။

အဓိကစွမ်းဆောင်ရည်စိန်ခေါ်မှုများ- ဒေတာစုဆောင်းခြင်းမှ ဒေတာရှင်းလင်းခြင်းအထိ

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

ကောင်းမွန်သောစောင့်ကြည့်ရေးစနစ်သည် ဒေတာအားလုံးကို လျင်မြန်စွာနှင့် ချက်ခြင်းလက်ခံရရှိသင့်ပြီး၊ ၎င်းကို trigger expressions အရ လုပ်ဆောင်သင့်သည်၊ ဆိုလိုသည်မှာ အချို့သောစံနှုန်းများအတိုင်း လုပ်ဆောင်ခြင်း (၎င်းသည် မတူညီသောစနစ်များတွင် ကွဲပြားသည်) နှင့် ဤဒေတာကို အနာဂတ်တွင်အသုံးပြုနိုင်စေရန်အတွက် ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသင့်သည်။

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

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

caching ပြဿနာတွေကို ဘယ်လိုဖြေရှင်းမလဲ။

ယခု Zabbix အကြောင်း အထူးပြောပါမည်။ Zabbix တွင်၊ ပထမနှင့်ဒုတိယခေါ်ဆိုမှုများကို caching ဖြင့်ဖြေရှင်းသည်။

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

ပင်မနမူနာများအတွက် - ဂရပ်များ၊ အခြားအရာများအတွက် ဒေတာဘေ့စ်ဘက်တွင် သိမ်းဆည်းမှုအချို့လည်း ရှိပါသည်။

Zabbix ဆာဗာကိုယ်တိုင်က ဘေးဘက်တွင် သိမ်းဆည်းခြင်း- ကျွန်ုပ်တို့တွင် ConfigurationCache၊ ValueCache၊ HistoryCache၊ TrendsCache ရှိသည်။ အဲဒါဘာလဲ?

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

Zabbix တွင် သိမ်းဆည်းခြင်း။ ဒေတာစုဆောင်းခြင်း။

ဤသည်မှာ အလွန်ကြီးမားသော ပုံကြမ်းတစ်ခုဖြစ်သည်။

အစီအစဥ်ရှိ အဓိကအရာများမှာ ဤစုဝေးသူများဖြစ်သည်-

၎င်းတို့သည် စည်းဝေးပွဲ လုပ်ငန်းစဉ်များ ဖြစ်ကြပြီး၊ မတူညီသော စည်းဝေးပွဲ အမျိုးအစားများအတွက် တာဝန်ရှိသော အမျိုးမျိုးသော "မဲဆန္ဒရှင်" များဖြစ်သည်။ ၎င်းတို့သည် မတူညီသော ပရိုတိုကောများတွင် icmp၊ ipmi ဆိုင်ရာ အချက်အလက်များကို စုဆောင်းပြီး ၎င်းတို့အားလုံးကို ကြိုတင်လုပ်ဆောင်ခြင်းသို့ လွှဲပြောင်းပေးသည်။

Preprocessing HistoryCache

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

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

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

History syncer အလုပ်

Zabbix ရှိ အဓိကလုပ်ငန်းစဉ် (၎င်းသည် monolithic ဗိသုကာလက်ရာဖြစ်သောကြောင့်) သည် History syncer ဖြစ်သည်။ ဤသည်မှာ ဒေတာဒြပ်စင်တစ်ခုစီ၏ အက်တမ်လုပ်ဆောင်ခြင်းဆိုင်ရာ အဓိကလုပ်ငန်းစဉ်ဖြစ်ပြီး ဆိုလိုသည်မှာ တန်ဖိုးတစ်ခုစီဖြစ်သည်။

• တန်ဖိုးရောက်လာသည် (၎င်းကို HistoryCache မှယူသည်);
• Configuration syncer တွင် စစ်ဆေးမှုများ- တွက်ချက်ရန်အတွက် အစပျိုးမှုများ ရှိပါသလား - ၎င်းတို့ကို တွက်ချက်ပါသည်။
  တစ်ခုရှိလျှင်၊ ၎င်းသည် ဖြစ်ရပ်များကိုဖန်တီးသည်၊ ၎င်းသည် configuration လိုအပ်ပါက သတိပေးချက်တစ်ခုဖန်တီးရန်အတွက် escalation တစ်ခုဖန်တီးသည်။
• မှတ်တမ်းများ၊ အကယ်၍ သင်သည် နောက်ဆုံးနာရီအထိ ပေါင်းစည်းပါက၊ သမိုင်းဇယားကို ဝင်ရောက်ခြင်းမပြုရန် ValueCache မှ ဤတန်ဖိုးကို မှတ်ထားမည်ဖြစ်သည်။ ထို့ကြောင့်၊ ValueCache သည် အစပျိုးမှုများ၊ တွက်ချက်သည့်ဒြပ်စင်များ စသည်တို့ကို တွက်ချက်ရန် လိုအပ်သော ဒေတာများဖြင့် ပြည့်နေပါသည်။
• ထို့နောက် History syncer သည် အချက်အလက်အားလုံးကို ဒေတာဘေ့စ်သို့ ရေးသည်။
• ဒေတာဘေ့စ်သည် ၎င်းတို့ကို disk သို့ ရေးပေးသည် - ဤသည်မှာ လုပ်ဆောင်ခြင်းပြီးဆုံးသည့်နေရာတွင်ဖြစ်သည်။

ဒီထဲမှာ။ သိမ်းဆည်းခြင်း။

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

MySQL အတွက် Innodb_buffer_pool နှင့် configure လုပ်နိုင်သော အခြားသော မတူညီသော ကက်ရှ်အမြောက်အများ ရှိပါသည်။
ဒါပေမယ့် ဒါတွေက အဓိက ပါ

• shared_buffers;
• effective_cache_size;
• shared_pool

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

ဒေတာဘေ့စ်စွမ်းဆောင်ရည်အကြောင်း

ထို့ကြောင့်၊ Zabbix ဆာဗာသည် ဒေတာစုဆောင်းပြီး မှတ်တမ်းတင်ထားသော ပြိုင်ဆိုင်မှုရှိသော ပတ်ဝန်းကျင်တစ်ခု ရှိပါသည်။ ပြန်လည်စတင်သောအခါ၊ ValueCache ကိုဖြည့်ရန် မှတ်တမ်းမှလည်း ဖတ်ပါသည်။ ဤနေရာတွင် ဝဘ်အင်တာဖေ့စ်ကိုအခြေခံ၍ တည်ဆောက်ထားသည့် Zabbix API ကိုအသုံးပြုသည့် script များနှင့် အစီရင်ခံစာများပါရှိနိုင်သည်။ Zabbix API သည် DB သို့ ဝင်ရောက်ပြီး ဂရပ်ဖစ်များ၊ အစီရင်ခံစာများ သို့မဟုတ် ဖြစ်ရပ်များစာရင်း၊ လတ်တလော ပြဿနာအချို့ကို ရယူရန် လိုအပ်သောဒေတာကို လက်ခံရရှိပါသည်။

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

သမိုင်းကိုရှင်းလင်းခြင်း။ Zabbix တွင် အိမ်စောင့်ရှိသည်။

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

ကျွန်ုပ်တို့ အမြန်တွက်ချက်သည့် TrendCash ကို ကျွန်ုပ်မဖော်ပြခဲ့ပါ။ ဒေတာများ ဝင်လာသည်၊ ကျွန်ုပ်တို့ ၎င်းကို တစ်နာရီကြာ စုစည်းထားသည် (အများစုမှာ ၎င်းတို့သည် နောက်ဆုံးနာရီအတွက် ကိန်းဂဏာန်းများ)၊ ပျမ်းမျှ/အနိမ့်ဆုံး ပမာဏကို ပြောင်းလဲမှုဒိုင်းနမစ်ဇယား ("Trends") တွင် တစ်နာရီလျှင်တစ်ကြိမ် ချရေးပါ။ "Housekeeper" သည် အမြဲတမ်းထိရောက်မှုမရှိသော ပုံမှန်ရွေးချယ်မှုများကို အသုံးပြုကာ ဒေတာဘေ့စ်မှဒေတာများကို စတင်ပြီး ဖျက်ပါသည်။

ဒါက ထိရောက်မှုမရှိဘူးဆိုတာ ဘယ်လိုသိလဲ။ အတွင်းပိုင်း လုပ်ငန်းစဉ် စွမ်းဆောင်ရည် ဇယားများတွင် ဤပုံကို သင်မြင်နိုင်သည်-

သင်၏ History syncer သည် အမြဲအလုပ်များနေပါသည် (ဂရပ်အနီ)။ ပြီးတော့ အပေါ်က "အနီရောင်" ဂရပ်။ ၎င်းသည် DB မှ သတ်မှတ်ထားသည့် လိုင်းများအားလုံးကို ဖျက်ရန် စတင်ပြီး စောင့်ဆိုင်းနေသည့် "အိမ်ထိန်း" ဖြစ်သည်။

Item ID တစ်ချို့ကို ယူကြည့်ရအောင်၊ နောက်ဆုံး 5 ထောင်ကို ဖျက်ဖို့လိုတယ်။ ဟုတ်ပါတယ်၊ အညွှန်းကိန်းများအားဖြင့်။ သို့သော် အများအားဖြင့် dataset သည် အလွန်ကြီးမားသည် - ဒေတာဘေ့စ်သည် ၎င်းကို disk မှဖတ်ပြီး cache သို့တင်ထားဆဲဖြစ်ပြီး၊ ၎င်းသည် DB အတွက် အလွန်စျေးကြီးသောလုပ်ဆောင်မှုတစ်ခုဖြစ်သည်။ ၎င်း၏ အရွယ်အစားပေါ် မူတည်၍ ၎င်းသည် အချို့သော စွမ်းဆောင်ရည် ပြဿနာများကို ဖြစ်ပေါ်စေနိုင်သည်။

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

သင်ဘာဆက်လုပ်နိုင်မလဲ။ သင် ပိတ်လိုက်ပါပြီ၊ သင့်ဂရပ်ဖစ်များ ကျသွားပါပြီ... ဤကိစ္စတွင် နောက်ဆက်တွဲ ပြဿနာများ မည်သို့ရှိနိုင်မည်နည်း။ ဘာကူညီပေးနိုင်မလဲ။

ပိုင်းခြားခြင်း (အပိုင်းခွဲခြင်း)

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

သင်၏စနစ်ထည့်သွင်းမှုအပေါ်မူတည်၍ (တစ်နေ့လျှင် သင်ဖန်တီးသည့်ဒေတာမည်မျှ) အနိမ့်ဆုံးကို သတ်မှတ်ထားသည် - 1 ရက် / အပိုင်းခွဲ နှင့် "ခေတ်ရေစီးကြောင်းများ" အတွက် အပြောင်းအလဲများ ဒိုင်နနမစ် - 1 လ / အပိုင်းအသစ်အသစ်။ သင့်တွင် အလွန်ကြီးမားသော စနစ်ထည့်သွင်းပါက ၎င်းသည် ပြောင်းလဲနိုင်သည်။

တပ်ဆင်မှုအရွယ်အစားများအကြောင်း ချက်ချင်းပြောပြပါရစေ- တစ်စက္ကန့်လျှင် တန်ဖိုးအသစ် ၅ဝဝဝ အထိ (NVPS ဟုခေါ်သည်) – ၎င်းကို သေးငယ်သော “တပ်ဆင်မှု” အဖြစ် သတ်မှတ်ပါမည်။ ပျမ်းမျှ - တစ်စက္ကန့်လျှင် 5 မှ 5 သိန်းတန်ဖိုးများ။ ဒေတာဘေ့စ်၏ အလွန်ဂရုတစိုက်ဖွဲ့စည်းမှုလိုအပ်သော ကြီးမားပြီး အလွန်ကြီးမားသော တပ်ဆင်မှုများဖြစ်သည့် အထက်တွင်ရှိသည့် မည်သည့်အရာမဆို။

အလွန်ကြီးမားသော တပ်ဆင်မှုများတွင်၊ 1 ရက်သည် အကောင်းဆုံးမဖြစ်နိုင်ပါ။ တစ်နေ့လျှင် 40 gigabytes ရှိသော MySQL partitions များကို ကိုယ်တိုင်ကိုယ်ကျ မြင်ဖူးသည် (ထို့ထက်လည်း ရှိနိုင်သည်)။ ဤအရာသည် အလွန်ကြီးမားသော ဒေတာပမာဏဖြစ်ပြီး ပြဿနာအချို့ကို ဖြစ်ပေါ်စေနိုင်သည်။ လျှော့ချရန် လိုအပ်သည်။

အဘယ်ကြောင့် partitioning လိုအပ်သနည်း။

Partitioning က ဘာကိုပေးတယ်ဆိုတာ လူတိုင်းသိမယ်ထင်ပါတယ် - အဲဒါက table partitioning ဖြစ်ပါတယ်။ များသောအားဖြင့် ၎င်းတို့သည် disk နှင့် span queries များတွင် သီးခြားဖိုင်များဖြစ်သည်။ ပုံမှန် partitioning တွင်ပါဝင်ပါက၊ ၎င်းသည် partition တစ်ခုကို ပို၍အကောင်းဆုံးရွေးချယ်သည်။

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

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

NoSQL အတွက် Elasticsearch

မကြာသေးမီက 3.4 တွင် ကျွန်ုပ်တို့သည် NoSQL အတွက် ဖြေရှင်းချက်တစ်ခုကို အကောင်အထည်ဖော်ခဲ့သည်။ ကျွန်ုပ်တို့သည် Elasticsearch သို့ စာရေးနိုင်စွမ်းကို ပေါင်းထည့်ခဲ့သည်။ သီးခြားအမျိုးအစားအချို့ကို သင်ရေးနိုင်သည်- သင်ရွေးချယ်သည် - နံပါတ်များ သို့မဟုတ် ဆိုင်းဘုတ်အချို့ကို ရေးပါ။ ကျွန်ုပ်တို့တွင် စာတန်းစာသားပါရှိပြီး၊ သင်သည် Elasticsearch သို့ မှတ်တမ်းများရေးနိုင်သည်... ထို့ကြောင့်၊ ဝဘ်အင်တာဖေ့စ်သည် Elasticsearch ကိုလည်း ဝင်ရောက်အသုံးပြုနိုင်မည်ဖြစ်သည်။ ၎င်းသည် အချို့ကိစ္စများတွင် ကောင်းမွန်သော်လည်း ယခုအချိန်တွင် အသုံးပြုနိုင်ပါသည်။

TimescaleDB Hypertables

4.4.2 အတွက်၊ ကျွန်ုပ်တို့သည် TimescaleDB ကို အာရုံစိုက်ခဲ့သည်။ အဲဒါဘာလဲ? ၎င်းသည် Postgres အတွက် extension တစ်ခုဖြစ်ပြီး ဆိုလိုသည်မှာ ၎င်းတွင် မူရင်း PostgreSQL interface ရှိသည်။ ထို့အပြင်၊ ဤ extension သည် သင့်အား timeeries data နှင့် ပိုမိုထိရောက်စွာ လုပ်ဆောင်နိုင်ပြီး အလိုအလျောက် partitioning လုပ်နိုင်မည်ဖြစ်သည်။ ဘယ်လိုပုံလဲ-

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

TimescaleDB နှင့် PostgreSQL

TimescaleDB ထုတ်လုပ်သူများသည် အာမခံထားသည့်အတိုင်း၊ ၎င်းတို့သည် dataset ထည့်သွင်းမှု၏ အရွယ်အစား တိုးလာခြင်းဖြင့် ခန့်မှန်းခြေအားဖြင့် အဆက်မပြတ် စွမ်းဆောင်နိုင်စေမည့် အထူးသဖြင့် ထည့်သွင်းမှုများကို လုပ်ဆောင်ရန်အတွက် ပိုမိုမှန်ကန်သော အယ်လဂိုရီသမ်ကို အသုံးပြုကြသည်။ ဆိုလိုသည်မှာ၊ အတန်းပေါင်း သန်း 200 ပြီးနောက်၊ ပုံမှန် Postgres သည် အလွန်ပြင်းထန်စွာ ဆုတ်ယုတ်လာပြီး စွမ်းဆောင်မှု အစစ်အမှန်ကို သုညအထိ ဆုံးရှုံးသွားကာ Timescale သည် ဒေတာပမာဏများစွာဖြင့် ထည့်သွင်းမှုများကို တတ်နိုင်သမျှ ထိရောက်စွာ ထည့်သွင်းနိုင်စေပါသည်။

TimescaleDB ကို ဘယ်လို ထည့်သွင်းရမလဲ။ လွယ်ပါတယ်။

၎င်းကို ၎င်း၏စာရွက်စာတမ်းတွင်ဖော်ပြထားသည် - မည်သည့်အတွက်မဆို ပက်ကေ့ခ်ျများမှ သင်ထည့်သွင်းနိုင်သည်... ၎င်းသည် တရားဝင် Postgres ပက်ကေ့ခ်ျများပေါ်တွင်မူတည်ပါသည်။ ၎င်းကို သင်ကိုယ်တိုင် စုစည်းနိုင်သည်။ အဲဒါကို DB အတွက် compile လုပ်ရတာပါ။

Zabbix တွင်ကျွန်ုပ်တို့သည် Extention ကိုဖွင့်ရုံသာဖြစ်သည်။ Postgres မှာ Extention ကိုသုံးတဲ့သူတွေလို့ထင်ပါတယ်… Extention ကိုဖွင့်လိုက်ရုံပါပဲ၊ သင်အသုံးပြုတဲ့ Zabbix database အတွက် ဖန်တီးလိုက်ပါ။

ပြီးတော့ နောက်ဆုံးအဆင့်...

TimescaleDB မှတ်တမ်းဇယားများကို ရွှေ့ပြောင်းခြင်း။

သင်သည် hypertable ကိုဖန်တီးရန်လိုအပ်သည်။ ဤအတွက် အထူးလုပ်ဆောင်ချက်တစ်ခု ရှိသည် - hypertable ဖန်တီးပါ။ ၎င်းတွင်၊ ပထမ parameter သည်ဤ DB တွင်လိုအပ်သောဇယားဖြစ်သည် (သင် hypertable ကိုဖန်တီးရန်လိုအပ်သည်) ။

ဖန်တီးရန် အကွက်နှင့် chunk_time_interval (၎င်းသည် အသုံးပြုရန် အတုံးများ (အပိုင်းပိုင်းများ) ကြားကာလဖြစ်သည်)။ 86 သည် တစ်ရက်ဖြစ်သည်။

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

ငါ migrate_data ကို ကိုယ်တိုင်သုံးခဲ့တယ် - မင်းရဲ့ DB ဘယ်လောက်ကြီးလဲပေါ်မူတည်ပြီး အချိန်တော်တော်ကြာတယ်။ မိုင်းသည် တစ်တီရာဘိုက်ကျော် ရှိပြီး ဖန်တီးရန် တစ်နာရီကျော် ကြာသည်။ အချို့သောကိစ္စများတွင်၊ စမ်းသပ်သည့်အခါ၊ စာသား (history_text) နှင့် string (history_str) အတွက် သမိုင်းဒေတာကို ရွှေ့ပြောင်းရန် ဖျက်လိုက်သည် - ၎င်းတို့ကို ကျွန်ုပ် အမှန်တကယ် စိတ်မဝင်စားပါ။

ကျွန်ုပ်တို့၏ db_extention တွင်ကျွန်ုပ်တို့၏နောက်ဆုံးအပ်ဒိတ်ကိုပြုလုပ်သည်- DB သည် အထူးသဖြင့် ကျွန်ုပ်တို့၏ "Zabbix" သည် db_extention ရှိသည်ကိုနားလည်စေရန် timescaledb ကိုထည့်သွင်းပါသည်။ ၎င်းသည် TimescaleDB အတွက် လိုအပ်သော "အင်္ဂါရပ်များ" ကို အသုံးပြု၍ ၎င်းကို အသက်သွင်းပြီး DB သို့ မှန်ကန်သော syntax နှင့် queries ကို အသုံးပြုသည်။

ဆာဗာဖွဲ့စည်းပုံ

ဆာဗာနှစ်ခုကိုသုံးခဲ့တယ်။ ပထမဆုံး ဆာဗာသည် အလွန်သေးငယ်သော ပရိုဆက်ဆာ 20၊ RAM 16 ဂစ်ဂါဗိုက် ရှိသော virtual machine ဖြစ်သည်။ ၎င်းတွင် Postgres 10.8 ကို ကျွန်ုပ် configure လုပ်ခဲ့သည်-

လည်ပတ်မှုစနစ်သည် Debian ဖြစ်ပြီး၊ ဖိုင်စနစ်မှာ xfs ဖြစ်သည်။ ဤဒေတာဘေ့စ်ကိုအသုံးပြုရန်အတွက် အနည်းငယ်မျှသာဆက်တင်များကို Zabbix ကိုယ်တိုင်အသုံးပြုမည့်အရာအား နုတ်ထားသည်။ တူညီသောစက်တွင် Zabbix ဆာဗာ၊ PostgreSQL နှင့် load အေးဂျင့်များရှိသည်။

ရလဒ်အမျိုးမျိုးကို လျင်မြန်စွာထုတ်ပေးရန်အတွက် LoadableModule ကိုအသုံးပြုသည့် တက်ကြွသောအေးဂျင့် 50 ကိုအသုံးပြုခဲ့သည်။ သူတို့က စာကြောင်းတွေ၊ နံပါတ်တွေ ထုတ်ပေးတယ်။ DB ကို ဒေတာအများကြီးနဲ့ ဖြည့်ခဲ့တယ်။ ကနဦးဖွဲ့စည်းမှုတွင် host တစ်ခုလျှင် ဒေတာ 5 ပါဝင်ပြီး ခန့်မှန်းခြေအားဖြင့် ဒေတာပစ္စည်းတိုင်းတွင် အစပျိုးတစ်ခုပါရှိသည် - ၎င်းသည် အမှန်တကယ်ထည့်သွင်းမှုဖြစ်ရန်အတွက် ဖြစ်သည်။ တစ်ခါတစ်ရံတွင် ၎င်းကိုအသုံးပြုရန် ခလုတ်တစ်ခုထက်ပို၍ လိုအပ်ပါသည်။

အေးဂျင့် 50 (ပိုမိုထည့်ခြင်း) ကို အသုံးပြုရုံသာမက အပ်ဒိတ်ကာလနှင့် load ကို သူ့ကိုယ်သူ ထိန်းညှိပေးကာ dynamic data element များကို အသုံးပြုကာ အပ်ဒိတ်ကြားကာလကို 4 စက္ကန့်အထိ လျှော့ချခဲ့သည်။

စွမ်းဆောင်ရည်စမ်းသပ်မှု။ PostgreSQL- 36K NVPs

ပထမဆုံး စတင်ခြင်းဖြစ်ပြီး၊ ကျွန်ုပ်တွင် ပထမဆုံးတပ်ဆင်မှုမှာ ဤဟာ့ဒ်ဝဲရှိ သန့်ရှင်းသော PostreSQL 10 (တစ်စက္ကန့်လျှင် တန်ဖိုး ၃၅ဝဝဝ) ပေါ်တွင်ဖြစ်သည်။ ယေဘုယျအားဖြင့်၊ မျက်နှာပြင်ပေါ်တွင် သင်တွေ့မြင်ရသည့်အတိုင်း ဒေတာထည့်သွင်းခြင်းသည် တစ်စက္ကန့်၏အပိုင်းအစများ ကြာသည် - အရာအားလုံးသည် ကောင်းမွန်ပြီး မြန်ဆန်သည်၊ SSD disks (35 gigabyte) ဖြစ်သည်။ တစ်ခုတည်းသောအချက်မှာ 200 GB သည်အတော်လေးမြန်မြန်ပြည့်သည်။

ထိုကဲ့သို့ ဂရပ်ဖစ်များ အများအပြား ရှိပေလိမ့်မည်။ ၎င်းသည် Zabbix ဆာဗာစွမ်းဆောင်ရည်၏ စံဒိုင်ခွက်တစ်ခုဖြစ်သည်။

ပထမဂရပ်သည် တစ်စက္ကန့်လျှင် တန်ဖိုးအရေအတွက် (အပြာ၊ ဘယ်ဘက်ထိပ်)၊ ဤကိစ္စတွင် ၃၅ဝဝဝ တန်ဖိုးများဖြစ်သည်။ ဤ (ထိပ်ပိုင်းဗဟို) သည် တည်ဆောက်မှုလုပ်ငန်းစဉ်များ၏ တင်ခြင်းဖြစ်ပြီး၊ ဤ (ညာဘက်အပေါ်) သည် အတွင်းပိုင်းလုပ်ငန်းစဉ်များတင်ခြင်းဖြစ်သည်- မှတ်တမ်းစင့်ခ်လုပ်သူများနှင့် အိမ်စောင့်၊ ဤနေရာ (အောက်ခြေဗဟို) သည် အချိန်အတော်ကြာလည်ပတ်နေပါသည်။

ဤဂရပ် (အောက်ခြေဗဟို) သည် ValueCache ၏အသုံးပြုမှုကိုပြသသည် - အစပျိုးမှုများအတွက် ValueCache hit မည်မျှရှိသည် (တစ်စက္ကန့်လျှင်တန်ဖိုးထောင်ပေါင်းများစွာ) ကိုပြသသည်။ နောက်ထပ်အရေးကြီးသည့်ဂရပ်သည် ဒေတာဘေ့စ်ထဲသို့မထည့်မီ ကြားခံတစ်ခုဖြစ်သည့် HistoryCache ၏အသုံးပြုမှုကိုပြသသည့် စတုတ္ထတစ်ခု (အောက်ခြေဘယ်ဘက်) ဖြစ်သည်။

စွမ်းဆောင်ရည်စမ်းသပ်မှု။ PostgreSQL- 50K NVPs

ထို့နောက် တူညီသော ဟာ့ဒ်ဝဲတွင် ဝန်အား တစ်စက္ကန့်လျှင် 50 တန်ဘိုးအထိ တိုးမြှင့်ခဲ့သည်။ "Housekeeper" ဖြင့် တင်သည့်အခါ တွက်ချက်မှုဖြင့် 10 တန်ဘိုးကို 2-3 စက္ကန့်အတွင်း ရေးသားခဲ့သည်။ ၎င်းကို အောက်ပါ screenshot တွင် အမှန်တကယ်ပြသထားသည်။

"အိမ်ထိန်း" သည် လုပ်ငန်းကို စတင်နှောင့်ယှက်နေပြီဖြစ်သော်လည်း ယေဘူယျအားဖြင့် မှတ်တမ်း sinker trappers များ၏ဝန်သည် 60% (တတိယဂရပ်၊ အပေါ်ညာဘက်) တွင်ရှိနေဆဲဖြစ်သည်။ "Housekeeper" (အောက်ခြေဘယ်ဘက်) ၏လုပ်ဆောင်မှုအတွင်း HistoryCache သည် တက်တက်ကြွကြွ ဖြည့်စွက်နေပါသည်။ ၎င်းသည် ဂစ်ဂါဘိုက်တစ်ဝက်ခန့်ရှိပြီး 20% ပြည့်သွားသည်။

စွမ်းဆောင်ရည်စမ်းသပ်မှု။ PostgreSQL- 80K NVPs

အဲဒီနောက် တစ်စက္ကန့်ကို 80 တန်ဘိုးအထိ တိုးလာတယ်။

ဒေတာဒြပ်စင် 400, 280,ဝဝဝ အစပျိုးခဲ့သည်။ သင်မြင်သည့်အတိုင်း၊ မှတ်တမ်း sinkers (၎င်းတို့အထဲမှ 30 ရှိသည်) ကိုတင်ခြင်းဖြင့် ထည့်သွင်းမှုသည် အလွန်မြင့်မားနေပြီဖြစ်သည်။ ထို့နောက် ကျွန်ုပ်သည် အမျိုးမျိုးသော ကန့်သတ်ဘောင်များကို တိုးလာသည်- မှတ်တမ်း sinkers၊ cache... ဤ hardware တွင်၊ history sinkers များကို loading သည် အမြင့်ဆုံးအထိ တိုးလာသည်၊ "စင်သို့" နီးပါးအထိ တိုးလာသည် - ထို့ကြောင့် HistoryCache သည် အလွန်မြင့်မားသော load သို့ရောက်သွားသည်-

ဒီအချိန်တစ်လျှောက်လုံး ငါသည် စနစ်၏ ကန့်သတ်ချက်များအားလုံးကို စောင့်ကြည့်နေခဲ့ပြီး (ပရိုဆက်ဆာအသုံးပြုပုံ၊ RAM) သည် ဒစ်ခ်အသုံးပြုမှု အမြင့်ဆုံးဖြစ်ကြောင်း တွေ့ရှိခဲ့သည် - ဤ virtual machine တွင် ဤဒစ်၏ အမြင့်ဆုံးစွမ်းရည်ကို ငါရရှိခဲ့သည်။ “Postgres” သည် ထိုကဲ့သို့ပြင်းထန်မှုဖြင့် ဒေတာများကို အလွန်တက်ကြွစွာ စွန့်ပစ်ခြင်းကို စတင်ခဲ့ပြီး ဒစ်သည် စာရေးနိုင်၊ ဖတ်နိုင်တော့မည်မဟုတ်ပါ...

ပရိုဆက်ဆာ 48 ခုနှင့် RAM 128 ဂစ်ဂါဘိုက်ရှိသော အခြားဆာဗာတစ်ခုကို ကျွန်ုပ်ယူခဲ့သည်-

ကျွန်တော်လည်း ၎င်းကို "ချိန်ညှိသည်" - History syncer (60 pieces) ကို ထည့်သွင်းပြီး လက်ခံနိုင်သော စွမ်းဆောင်ရည်ကို ရရှိခဲ့သည်။ တကယ်တော့၊ ကျွန်ုပ်တို့သည် "စင်ပေါ်တွင်" မဟုတ်သော်လည်း၊ ၎င်းသည် ၎င်းနှင့်ပတ်သက်ပြီး တစ်စုံတစ်ရာလုပ်ဆောင်ရန် လိုအပ်နေပြီဖြစ်သော စွမ်းဆောင်ရည်၏ ကန့်သတ်ချက်ဖြစ်နိုင်သည်။

စွမ်းဆောင်ရည်စမ်းသပ်မှု။ TimescaleDB- 80K NVPs

ကျွန်ုပ်၏အဓိကရည်ရွယ်ချက်မှာ TimescaleDB ကိုအသုံးပြုရန်ဖြစ်သည်။ ဂရပ်တစ်ခုစီသည် ကျဆင်းမှုကို ပြသသည်-

ဤမအောင်မြင်မှုများသည် ဒေတာရွှေ့ပြောင်းခြင်းမျှသာဖြစ်သည်။ ထို့နောက်တွင်၊ Zabbix ဆာဗာရှိသမိုင်း sinker တင်သည့်ပရိုဖိုင်သည် သင်မြင်ရသည့်အတိုင်း ပြောင်းလဲသွားသည်။ ၎င်းသည် သင့်အား ဒေတာကို ၃ ဆနီးပါး ပိုမြန်စေပြီး HistoryCache ကို လျှော့သုံးနိုင်စေသည် - ထို့ကြောင့် သင့်တွင် ဒေတာများကို အချိန်မီ ပေးပို့နိုင်မည်ဖြစ်သည်။ တစ်ဖန် တစ်စက္ကန့်လျှင် တန်ဖိုး 3 သည် အလွန်မြင့်မားသောနှုန်းဖြစ်သည် (ဟုတ်ပါတယ်၊ Yandex အတွက်မဟုတ်ပါ)။ ယေဘူယျအားဖြင့်၊ ၎င်းသည် ဆာဗာတစ်ခုပါရှိ၍ အလွန်ကြီးမားသော တပ်ဆင်မှုတစ်ခုဖြစ်သည်။

PostgreSQL စွမ်းဆောင်ရည်စမ်းသပ်မှု- 120K NVPs

ထို့နောက် ကျွန်ုပ်သည် ဒေတာဒြပ်စင်များ၏ တန်ဖိုးကို သန်းဝက်သို့ တိုးမြှင့်ကာ တစ်စက္ကန့်လျှင် ခန့်မှန်းတန်ဖိုး ၁၂၅ဝဝဝ ကို ရခဲ့သည်။

ပြီးတော့ ဒီဂရပ်တွေကို ငါရခဲ့တယ်

မူအရ၊ ၎င်းသည် အလုပ်ချိန်ညှိမှုဖြစ်ပြီး၊ ၎င်းသည် အချိန်အတော်ကြာ အလုပ်လုပ်နိုင်သည်။ ဒါပေမယ့် ကျွန်တော့်မှာ 1,5 terabytes သာရှိတဲ့ disk တစ်ခုရှိတာကြောင့် ရက်အနည်းငယ်အတွင်းမှာပဲ သုံးခဲ့ပါတယ်။ အရေးကြီးဆုံးအချက်မှာ TimescaleDB တွင် အပိုင်းအသစ်များကို တစ်ချိန်တည်းတွင် ဖန်တီးခဲ့ခြင်းဖြစ်ပြီး၊ ၎င်းသည် MySQL အကြောင်း မပြောနိုင်သော စွမ်းဆောင်ရည်အတွက် လုံးဝသတိမထားမိပေ။

၎င်းသည် ပိတ်ဆို့ထည့်သွင်းခြင်းနှင့် စားပွဲများနှင့် လုံးဝအလုပ်လုပ်နိုင်သောကြောင့် အပိုင်းများကို ညအချိန်တွင် ဖန်တီးလေ့ရှိပြီး ဝန်ဆောင်မှုကို ပျက်စီးယိုယွင်းစေနိုင်သည်။ ဤကိစ္စတွင်၊ ဤကိစ္စမဟုတ်ပါ။ အဓိကတာဝန်မှာ TimescaleDB ၏စွမ်းရည်များကိုစမ်းသပ်ရန်ဖြစ်သည်။ အောက်ပါပုံအား ရရှိခဲ့သည်- တစ်စက္ကန့်လျှင် တန်ဖိုး ၁၂၀,ဝဝဝ။

"အသိုင်းအဝိုင်း" တွင်လည်း ဥပမာများ ရှိပါသည်။

အဆိုပါလူက TimescaleDB ကိုဖွင့်ထားပြီး io.weight အသုံးပြုမှုအပေါ်ဝန်က ပရိုဆက်ဆာပေါ်ကျဆင်းသွားသည် ။ TimescaleDB ၏ပါဝင်မှုကြောင့် အတွင်းပိုင်းလုပ်ငန်းစဉ်များ၏ အစိတ်အပိုင်းများအသုံးပြုမှုမှာလည်း လျော့နည်းသွားပါသည်။ ၎င်းတို့သည် သာမန် ပန်ကိတ်ဒစ်များ၊ ဆိုလိုသည်မှာ သာမန်ဒစ်များ (SSD မဟုတ်ဘဲ) ရှိ သာမန် virtual machine တစ်ခုဖြစ်သည်။

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

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

ပရိသတ်မေးခွန်းများ

ပရိသတ်ထံမှမေးခွန်း (ယခုနောက်ပိုင်းတွင် A ဟုရည်ညွှန်းသည်) - TimescaleDB သည်တပ်ဆင်ရန်အလွန်လွယ်ကူပြီး၎င်းသည်စွမ်းဆောင်ရည်မြှင့်တင်မှုကိုပေးပါက၎င်းကို Zabbix နှင့် Postgres ကိုထည့်သွင်းရန်အတွက်အကောင်းဆုံးအလေ့အကျင့်အဖြစ်အသုံးပြုသင့်သည်။ ပြီးတော့ ဒီဖြေရှင်းချက်အတွက် ချို့ယွင်းချက်တွေနဲ့ အားနည်းချက်တွေရှိသလား ဒါမှမဟုတ် Zabbix ကို ကိုယ်တိုင်ဖန်တီးဖို့ ဆုံးဖြတ်ရင်၊ Postgres ကို လုံခြုံစွာယူနိုင်တယ်၊ Timescale ကို အဲဒီနေရာမှာ ချက်ချင်းထည့်သွင်းနိုင်တယ်၊ အဲဒါကို အသုံးပြုပြီး ပြဿနာတွေကို မစဉ်းစားဘဲနဲ့ လုပ်လို့ရပါသလား။

AG- - ဟုတ်ကဲ့၊ TimescaleDB တိုးချဲ့မှုနဲ့အတူ Postgres ကိုသုံးဖို့ အကြံပြုချက်ကောင်းတစ်ခုလို့ ပြောချင်ပါတယ်။ ငါပြောခဲ့သည့်အတိုင်း၊ ဤ "အင်္ဂါရပ်" ကိုစမ်းသပ်သော်လည်းကောင်းပြန်လည်သုံးသပ်ချက်များစွာရှိသည်။ ဒါပေမယ့် တကယ်တမ်းတော့ စမ်းသပ်မှုတွေက ကောင်းမွန်တဲ့အဖြေတစ်ခု (TimescaleDB နဲ့) က တိုးတက်လာမယ်လို့ ကျွန်တော်ထင်ပါတယ်။ ဤတိုးချဲ့မှုသည် မည်သို့ပြောင်းလဲလာသည်ကို ကျွန်ုပ်တို့ စောင့်ကြည့်နေပြီး လိုအပ်သည်များကို ပြုပြင်ပေးမည်ဖြစ်သည်။

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

A: - အသိုင်းအဝိုင်းမှ နောက်ဆုံးဇယားများတွင် "အိမ်ထိန်း" ပါသော ဇယားတစ်ခု ရှိသည်-

သူအလုပ်ဆက်လုပ်သည်။ Housekeeper သည် TimescaleDB နှင့်ဘာလုပ်သနည်း။

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

A: - Timescale ရှိ ဖျက်ပစ်ခြင်း၏ စွမ်းဆောင်ရည်နှင့် ပတ်သက်၍ ကျွန်ုပ်တွင် အလားတူမေးခွန်းတစ်ခုရှိပါသည်။
A (ပရိသတ်ထံမှအဖြေ) - သင်ဇယားတစ်ခုမှဒေတာကိုဖျက်သောအခါ၊ သင်သည်ဖျက်ပစ်ခြင်းမှတစ်ဆင့်ပြုလုပ်ပါက၊ ထို့နောက်သင်ဇယားကိုဖြတ်သွားရန်လိုအပ်သည် - အနာဂတ်လေဟာနယ်အတွက်အရာအားလုံးကိုဖျက်ပစ်ပါ၊ သန့်ရှင်းပါ၊ အမှတ်အသားပြုပါ။ သင့်တွင်အပိုင်းများရှိနေသောကြောင့် "Timescale" တွင်၊ သင်ချနိုင်သည်။ အကြမ်းဖျင်းအားဖြင့်၊ သင်သည် ဒေတာကြီးကြီးမားမားရှိသော ဖိုင်ကို ပြောပါ- "ဖျက်မည်!"

"Timescale" သည် ထိုသို့သောအပိုင်းတစ်ခုမရှိတော့ကြောင်း ရိုးရှင်းစွာနားလည်သည်။ ၎င်းကို query planner တွင် ပေါင်းစည်းထားသောကြောင့်၊ ၎င်းသည် ရွေးချယ်ထားသော သို့မဟုတ် အခြားလုပ်ဆောင်မှုများတွင် သင့်အခြေအနေများကို ချိတ်ဆက်ထားပြီး ဤအပိုင်းမရှိတော့ကြောင်း ချက်ချင်းနားလည်သည် - "ငါ အဲဒီကို မသွားတော့ဘူး!" (ဒေတာမရှိပါ။) ဒါပဲ! ဆိုလိုသည်မှာ၊ ဇယားစကင်ကို binary ဖိုင်ကိုဖျက်ခြင်းဖြင့်အစားထိုးသည်၊ ထို့ကြောင့်၎င်းသည်မြန်ဆန်သည်။

A: - ကျွန်ုပ်တို့သည် SQL မဟုတ်သော ခေါင်းစဉ်နှင့် ထိတွေ့ပြီးဖြစ်သည်။ ငါနားလည်သလောက်၊ Zabbix သည် ဒေတာကို အမှန်ပြင်ရန်မလိုအပ်ပါ၊ ဤအရာအားလုံးသည် မှတ်တမ်းတစ်ခုကဲ့သို့ဖြစ်သည်။ ၎င်းတို့၏ဒေတာကို မပြောင်းလဲနိုင်သော အထူးပြု DBs များကို အသုံးပြုရန် ဖြစ်နိုင်ပါသလော၊ သို့သော် တစ်ချိန်တည်းတွင် သိမ်းဆည်း၊ စုပုံကာ ပိုမိုမြန်ဆန်စွာ ပြန်ပို့နိုင်သည် – ဥပမာ- Clickhouse၊ ဥပမာ Kafka ကဲ့သို့သော အရာတစ်ခုလား?... Kafka သည် မှတ်တမ်းတစ်ခုလည်းဖြစ်သည်။ ၎င်းတို့ကို တစ်နည်းနည်းဖြင့် ပေါင်းစပ်ရန် ဖြစ်နိုင်ပါသလား။

AG- - လွှင့်တင်ခြင်းကို သင်လုပ်ဆောင်နိုင်သည်။ ဗားရှင်း 3.4 ကတည်းက ကျွန်ုပ်တို့တွင် အချို့သော “အင်္ဂါရပ်များ” ရှိသည်- သင်သည် သမိုင်းဝင်ဖိုင်များ၊ အဖြစ်အပျက်များ၊ အခြားအရာအားလုံးကို ဖိုင်များသို့ ရေးနိုင်သည်။ ထို့နောက် အချို့သော handler ကို အသုံးပြု၍ ၎င်းတို့ကို အခြား DB သို့ ပေးပို့ပါ။ တကယ်တော့ လူတော်တော်များများက DB ကို တိုက်ရိုက်ပြန်ရေးပြီး ပြန်လုပ်ကြပါတယ်။ ပျံသန်းနေစဉ်တွင်၊ history sinkers များသည် ဤအရာအားလုံးကို ဖိုင်များသို့ရေးပြီး၊ ဤဖိုင်များကို လှည့်ခြင်းစသည်ဖြင့် ရေးပြီး Clickhouse သို့ လွှဲပြောင်းနိုင်ပါသည်။ အစီအစဥ်များအကြောင်း ကျွန်တော် ဘာမှ မပြောနိုင်သော်လည်း NoSQL ဖြေရှင်းချက် (ဥပမာ Clickhouse ကဲ့သို့) အတွက် နောက်ထပ် ပံ့ပိုးမှုများ ဆက်လက်ရှိနေဦးမည်ဖြစ်သည်။

A: - ယေဘုယျအားဖြင့်၊ Postgres ကို လုံးဝဖယ်ရှားပစ်ရန် ဖြစ်နိုင်ချေရှိသည်?

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

A: ဥပမာ- Clickhouse သို့ပြောင်းပါက အရာအားလုံးပိုမိုမြန်ဆန်မည်ကို ခန့်မှန်းနိုင်ပါသလား။

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

A: - ဒါဆို ငါတို့က တန်းတူရည်တူ တိုက်ပွဲအကြောင်း ပြောနေတာဘဲ၊ ဒီအမြန် BD တွေရဲ့ ကြီးမားတဲ့ အားသာချက်အကြောင်း မဟုတ်ဘူးလား။

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

A: - RRD အဟောင်းက ဘယ်ရောက်သွားတာလဲ။ ဘာက SQL databases ကိုပြောင်းခိုင်းတာလဲ။ အစပိုင်းတွင်၊ တိုင်းတာမှုအားလုံးကို RRD တွင်စုဆောင်းခဲ့သည်။

AG- - "Zabbix" RRD တွင်၊ အလွန်ရှေးကျသောဗားရှင်းဖြစ်နိုင်သည်။ SQL ဒေတာဘေ့စ်များ - ဂန္ထဝင်ချဉ်းကပ်မှုအမြဲရှိသည်။ ဂန္တဝင်ချဉ်းကပ်မှုမှာ MySQL၊ PostgreSQL (၎င်းတို့သည် အချိန်အတော်ကြာ တည်ရှိခဲ့သည်)။ ကျွန်ုပ်တို့တွင် SQL နှင့် RRD ဒေတာဘေ့စ်များအတွက် ဘုံအင်တာဖေ့စ်တစ်ခုရှိသည်၊ ၎င်းကို ကျွန်ုပ်တို့ လုံးဝအသုံးမပြုပါ။

ကြော်ငြာအချို့ 🙂

ကျွန်ုပ်တို့နှင့်အတူရှိနေသည့်အတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်ုပ်တို့၏ဆောင်းပါးများကို သင်နှစ်သက်ပါသလား။ ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အကြောင်းအရာတွေကို ကြည့်ချင်ပါသလား။ မှာယူမှုတစ်ခုပြုလုပ်ခြင်း သို့မဟုတ် သူငယ်ချင်းများကို အကြံပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား ပံ့ပိုးကူညီပါ၊ $4.99 မှ developer များအတွက် cloud VPS, မင်းအတွက် ငါတို့က တီထွင်ထားတဲ့ entry-level server တွေရဲ့ ထူးခြားတဲ့ analogue တစ်ခု။ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps သို့မဟုတ် $19 မှ ဆာဗာတစ်ခုမျှဝေပုံနှင့်ပတ်သက်သော အမှန်တရားတစ်ခုလုံး။ (RAID1 နှင့် RAID10၊ 24 cores အထိနှင့် 40GB DDR4 အထိ)။

အမ်စတာဒမ်ရှိ Equinix Tier IV ဒေတာစင်တာတွင် Dell R730xd သည် ၂ ဆ စျေးသက်သာသည်။ ဒီမှာသာ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ကို $199 မှ နယ်သာလန်မှာ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 မှ။ အကြောင်းဖတ်ပါ။ Infrastructure Corp ကို ဘယ်လိုတည်ဆောက်မလဲ။ တစ်ပြားတစ်ချပ်အတွက် ယူရို ၉၀၀၀ တန် Dell R730xd E5-2650 v4 ဆာဗာများကို အသုံးပြုခြင်း။

source: www.habr.com