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

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

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

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

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

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

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

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

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

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

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

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

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

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

ConfigurationCache သည် ကျွန်ုပ်တို့သည် မက်ထရစ်များ၊ host များ၊ data items များ၊ triggers များကို သိမ်းဆည်းသည့် အဓိက cache ဖြစ်သည်။ ကြိုတင်လုပ်ဆောင်ခြင်း၊ ဒေတာစုဆောင်းရန်၊ မည်သည့် hosts များမှ စုဆောင်းမည်၊ မည်သည့်ကြိမ်နှုန်းဖြင့် လုပ်ဆောင်ရန် လိုအပ်သည်များ။ ဒေတာဘေ့စ်သို့သွားကာ မလိုအပ်သောမေးခွန်းများဖန်တီးခြင်းမပြုရန် ဤအရာအားလုံးကို 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 သို့ ရေးပေးသည် - ဤသည်မှာ လုပ်ဆောင်ခြင်းလုပ်ငန်းစဉ်ပြီးဆုံးသည့်နေရာတွင်ဖြစ်သည်။

ဒေတာဘေ့စ်။ သိမ်းဆည်းခြင်း။

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

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

• shared_buffers;
• effective_cache_size;
• shared_pool

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

Database Performance အကြောင်း

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Partitioning က ပေးတဲ့အရာက table partitioning ဆိုတာ လူတိုင်းသိမယ်ထင်ပါတယ်။ များသောအားဖြင့် ၎င်းတို့သည် disk နှင့် span တောင်းဆိုမှုများတွင် သီးခြားဖိုင်များဖြစ်သည်။ ၎င်းသည် သာမာန် အပိုင်းခွဲခြင်း၏ တစ်စိတ်တစ်ပိုင်းဖြစ်လျှင် ၎င်းသည် အပိုင်းတစ်ခုအား ပိုကောင်းအောင် ရွေးချယ်သည်။

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

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

NoSQL အတွက် Elasticsearch

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

TimescaleDB Hypertables

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

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

TimescaleDB နှင့် PostgreSQL

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

TimescaleDB ကိုမည်သို့ထည့်သွင်းရမည်နည်း။ ရိုးရှင်းပါတယ်။

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

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

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

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

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

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

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

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

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

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

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

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

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

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

စွမ်းဆောင်ရည်စမ်းသပ်မှု။ PostgreSQL- NVP ၃၆ဝဝဝ

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

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

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

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

စွမ်းဆောင်ရည်စမ်းသပ်မှု။ PostgreSQL- NVP ၃၆ဝဝဝ

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

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

စွမ်းဆောင်ရည်စမ်းသပ်မှု။ PostgreSQL- NVP ၃၆ဝဝဝ

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

ခန့်မှန်းခြေအားဖြင့် 400 ဒေတာဒြပ်စင်, 280,ဝဝဝ အစပျိုးခဲ့သည်။ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ထည့်သွင်းမှုသည် (အယောက် 30 ရှိသည်) ၏ဝန်ထုပ်ဝန်ပိုးသည်အတော်လေးမြင့်မားနေပြီဖြစ်သည်။ ထို့နောက် ကျွန်ုပ်သည် အမျိုးမျိုးသော ကန့်သတ်ဘောင်များကို တိုးမြှင့်ထားသည်- မှတ်တမ်း နစ်မြုပ်သူများ၊ ကက်ရှ်... ဤဟာ့ဒ်ဝဲတွင်၊ မှတ်တမ်းနစ်မြုပ်သူများ၏ ဝန်သည် အများဆုံး “စင်ပေါ်၌” နီးပါး တိုးလာသည် - ထို့ကြောင့်၊ HistoryCache သည် အလွန်မြင့်မားသော ဝန်အဖြစ်သို့ ရောက်ရှိသွားသည်-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A: - ယေဘူယျအားဖြင့်၊ သင်သည် postgres များကိုလုံးဝဖယ်ရှားပစ်နိုင်သည်ဟူသောရလဒ်ထွက်ပေါ်လာသည်။

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

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

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

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

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