စွမ်းဆောင်ရည်မြင့်မားပြီး မူရင်းအပိုင်းခွဲခြင်း- TimescaleDB ပံ့ပိုးမှုဖြင့် Zabbix

Zabbix သည် စောင့်ကြည့်ရေးစနစ်တစ်ခုဖြစ်သည်။ အခြားစနစ်များကဲ့သို့ပင်၊ ၎င်းသည် စောင့်ကြည့်စစ်ဆေးရေးစနစ်အားလုံး၏ အဓိကပြဿနာသုံးခုဖြစ်သည့် ဒေတာစုဆောင်းခြင်းနှင့် လုပ်ဆောင်ခြင်း၊ မှတ်တမ်းသိမ်းဆည်းခြင်းနှင့် ၎င်းကို သန့်ရှင်းရေးလုပ်ခြင်းတို့နှင့် ရင်ဆိုင်နေရသည်။

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

Zabbix တွင် စုဆောင်းမှုနှင့် သိုလှောင်မှုအတွင်း နှောင့်နှေးမှုပြဿနာများကို ကက်ရှ်များ သိမ်းဆည်းခြင်းဖြင့် ဖြေရှင်းနိုင်သည်- ကက်ရှ်အမျိုးအစားများစွာ၊ ဒေတာဘေ့စ်တွင် ကက်ရှ်လုပ်ခြင်း။ တတိယပြဿနာကိုဖြေရှင်းရန်၊ caching သည်မသင့်လျော်သောကြောင့် Zabbix သည် TimescaleDB ကိုအသုံးပြုခဲ့သည်။ သူ့အကြောင်းပြောပြမယ်။ Andrey Gushchin - နည်းပညာပံ့ပိုးမှုအင်ဂျင်နီယာ Zabbix SIA. Andrey သည် Zabbix ကို 6 နှစ်ကျော် ပံ့ပိုးခဲ့ပြီး စွမ်းဆောင်ရည်နှင့် တိုက်ရိုက်အတွေ့အကြုံရှိသည်။

TimescaleDB မည်ကဲ့သို့အလုပ်လုပ်သနည်း၊ ပုံမှန် PostgreSQL နှင့်နှိုင်းယှဉ်ပါကမည်သည့်စွမ်းဆောင်ရည်ကိုပေးစွမ်းနိုင်သနည်း။ Zabbix သည် TimescaleDB ဒေတာဘေ့စ်အတွက် မည်သည့်အခန်းကဏ္ဍမှ ပါဝင်သနည်း။ အစမှစတင်၍ PostgreSQL မှမည်သို့ရွှေ့ပြောင်းရသနည်း၊ မည်သည့်ဖွဲ့စည်းမှုပုံစံသည် ပိုမိုကောင်းမွန်သောစွမ်းဆောင်ရည်ရှိသနည်း။ ဖြတ်တောက်မှုအောက်တွင် ဤအရာအားလုံးကို အကြောင်းပြုပါ။

ကုန်ထုတ်စွမ်းအား စိန်ခေါ်မှုများ

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

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

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

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

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

Zabbix တွင် သိမ်းဆည်းခြင်း။

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

Zabbix ဆာဗာ၏ဘေးတွင် Caching သည်-

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache။

သူတို့ကိုအသေးစိတ်သုံးသပ်ကြည့်ရအောင်။

ConfigurationCache

ဤသည်မှာ ကျွန်ုပ်တို့သည် မက်ထရစ်များ၊ ဟို့စ်များ၊ ဒေတာပစ္စည်းများ၊ အစပျိုးမှုများ - ကြိုတင်လုပ်ဆောင်ခြင်းအတွက် ကျွန်ုပ်တို့လိုအပ်သမျှနှင့် ဒေတာစုဆောင်းခြင်းအတွက် ကျွန်ုပ်တို့သိမ်းဆည်းသည့် အဓိက cache ဖြစ်သည်။

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

ဒေတာစုဆောင်းခြင်း။

ပုံကြမ်းသည် အလွန်ကြီးမားသော်လည်း ၎င်းတွင် အဓိကအရာဖြစ်သည်။ ရွေးချယ်သူများ. ၎င်းတို့သည် အမျိုးမျိုးသော "မဲဆန္ဒရှင်များ" - စုဝေးခြင်းလုပ်ငန်းစဉ်များဖြစ်သည်။ ကွဲပြားသော စည်းဝေးပွဲ အမျိုးအစားများအတွက် ၎င်းတို့တွင် တာဝန်ရှိသည်- SNMP၊ IPMI မှတဆင့် ဒေတာများကို စုဆောင်းပြီး ၎င်းတို့အားလုံးကို PreProcessing သို့ လွှဲပြောင်းပါ။

စုဆောင်းသူများသည် လိမ္မော်ရောင်ဖြင့် ကွပ်ထားသည်။

Zabbix သည် စစ်ဆေးမှုများ ပေါင်းစည်းရန် လိုအပ်သည့် ပေါင်းစည်းမှုကို တွက်ချက်ထားသည်။ ၎င်းတို့ရှိပါက ကျွန်ုပ်တို့သည် ၎င်းတို့အတွက် ဒေတာကို ValueCache မှ တိုက်ရိုက်ရယူပါသည်။

Preprocessing HistoryCache

စုဆောင်းသူအားလုံး အလုပ်လက်ခံရန် ConfigurationCache ကို အသုံးပြုသည်။ ထို့နောက် ၎င်းတို့အား PreProcessing သို့ လွှဲပြောင်းပေးသည်။

PreProcessing သည် PreProcessing အဆင့်များကို လက်ခံရရှိရန် ConfigurationCache ကိုအသုံးပြုသည်။ ၎င်းသည် ဤဒေတာကို နည်းလမ်းအမျိုးမျိုးဖြင့် လုပ်ဆောင်သည်။

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

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

ValueCache၊ မှတ်တမ်းနှင့် ခေတ်ရေစီးကြောင်း ကက်ရှ်

History syncer သည် ဒေတာဒြပ်စင်တစ်ခုစီကို အက်တမ်ဖြင့် လုပ်ဆောင်ပေးသည့် အဓိက လုပ်ငန်းစဉ်ဖြစ်သည်၊ ဆိုလိုသည်မှာ တန်ဖိုးတစ်ခုစီဖြစ်သည်။

History syncer သည် HistoryCache မှတန်ဖိုးများကိုယူကာ တွက်ချက်မှုများအတွက် triggers များရှိနေခြင်းအတွက် Configuration ကိုစစ်ဆေးသည်။ သူတို့ရှိလျှင် တွက်ချက်သည်။

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

History syncer သည် အချက်အလက်အားလုံးကို ဒေတာဘေ့စ်သို့ ရေးပြီး disk သို့ စာရေးသည်။ လုပ်ဆောင်ခြင်း လုပ်ငန်းစဉ်သည် ဤနေရာတွင် အဆုံးသတ်ပါသည်။

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

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

• Innodb_buffer_pool MySQL ဘက်တွင်၊
• shared_buffers PostgreSQL ဘက်တွင်၊
• effective_cache_size Oracle ဘက်မှာ;
• shared_pool DB2 ဘက်မှာ။

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

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

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

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

နေရာထိုင်ခင်းထိန်းသိမ်းရေး

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

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

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

အနီရောင်ဂရပ်သည် History syncer သည် အဆက်မပြတ် အလုပ်ရှုပ်နေကြောင်း ပြသသည်။ ထိပ်ရှိ လိမ္မော်ရောင်ဂရပ်သည် အဆက်မပြတ်လည်ပတ်နေသည့် အိမ်စောင့်ဖြစ်သည်။ သူသတ်မှတ်ထားသည့် အတန်းအားလုံးကို ဖျက်ရန် ဒေတာဘေ့စ်ကို စောင့်နေသည်။

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

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

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

Partitioning - partitioning သို့မဟုတ် partitioning

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

ပုံမှန်အားဖြင့်၊ partitions များကို တစ်ရက်အတွင်း ဖန်တီးထားသည့် data ပမာဏ "setup" ပေါ်မူတည်၍ configure လုပ်ပါသည်။ စည်းကမ်းအတိုင်း၊ Partitioning ကို တစ်ရက်တည်းထုတ်ပေးသည်၊ ဤသည်အနည်းဆုံးဖြစ်သည်။ အသုတ်အသစ်၏ ခေတ်ရေစီးကြောင်းများအတွက် - 1 လ။

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

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

Partitioning က ဘာပေးလဲ။

ဇယားများကို အပိုင်းပိုင်းခွဲခြင်း။. များသောအားဖြင့် ၎င်းတို့သည် disk ပေါ်ရှိ သီးခြားဖိုင်များဖြစ်သည်။ query plan သည် partition တစ်ခုအား ပို၍အကောင်းဆုံးရွေးချယ်သည်။ အများအားဖြင့် အပိုင်းခွဲခြင်းကို အပိုင်းအခြားအလိုက် အသုံးပြုသည် - ၎င်းသည် Zabbix အတွက်လည်း မှန်ပါသည်။ ကျွန်ုပ်တို့သည် ထိုနေရာတွင် "အချိန်တံဆိပ်" ကိုအသုံးပြုသည် - ခေတ်၏အစကတည်းကအချိန်ဖြစ်သည်။ ဤအရာများသည် ကျွန်ုပ်တို့အတွက် သာမန်ကိန်းဂဏန်းများဖြစ်သည်။ သင်နေ့၏အစနှင့်အဆုံးကိုသတ်မှတ်သည် - ဤသည်အပိုင်းပိုင်းတစ်ခုဖြစ်သည်။

အမြန်ဖယ်ရှားခြင်း။ - DELETE. ဖျက်ရန်အတွက် အတန်းရွေးချယ်ခြင်းထက် ဖိုင်/subtable တစ်ခုအား ရွေးချယ်ထားသည်။

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

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

မင်္ဂလာပါ

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

TimescaleDB တွင် အယူအဆတစ်ခုရှိသည်။ စားပွဲတင်ခုံ သင်ဖန်တီးသော (hypertable)။ ကပါဝင်သည် အတုံးများ - partitions များ။ အပိုင်းအစများသည် အခြားအပိုင်းအစများကို မထိခိုက်စေသော hypertable အပိုင်းအစများကို အလိုအလျောက် စီမံခန့်ခွဲပါသည်။ အပိုင်းတစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်အချိန်အပိုင်းအခြားရှိသည်။

TimescaleDB နှင့် PostgreSQL

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

အတန်းပေါင်း သန်း 200 ပြီးနောက်၊ PostgreSQL သည် အများအားဖြင့် သိသိသာသာ ဆုတ်ယုတ်လာပြီး စွမ်းဆောင်ရည် 0 သို့ ဆုံးရှုံးသွားပါသည်။ TimescaleDB သည် သင့်အား မည်သည့်ဒေတာပမာဏအတွက်မဆို “ထည့်သွင်းမှုများ” ကို ထိထိရောက်ရောက် ထည့်သွင်းနိုင်စေပါသည်။

ustanovka

TimescaleDB ကို ထည့်သွင်းခြင်းသည် မည်သည့်ပက်ကေ့ဂျ်အတွက်မဆို လွယ်ကူပါသည်။ IN စာရွက်စာတမ်း အရာအားလုံးကိုအသေးစိတ်ဖော်ပြထားသည် - ၎င်းသည်တရားဝင် PostgreSQL ပက်ကေ့ခ်ျများပေါ်တွင်မူတည်သည်။ TimescaleDB ကိုလည်း ကိုယ်တိုင်တည်ဆောက်ပြီး ပြုစုနိုင်သည်။

Zabbix ဒေတာဘေ့စ်အတွက် ကျွန်ုပ်တို့သည် တိုးချဲ့မှုကို ရိုးရိုးရှင်းရှင်း အသက်သွင်းသည်-

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

သင်အသက်သွင်းပါ။ extension Zabbix database အတွက် ဖန်တီးပါ။ နောက်ဆုံးအဆင့်မှာ hypertable တစ်ခုကို ဖန်တီးရန်ဖြစ်သည်။

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

ဒီအတွက် အထူးလုပ်ဆောင်ချက်တစ်ခုရှိပါတယ်။ create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

function တွင် parameter သုံးခုရှိသည်။ ပထမ- ဒေတာဘေ့စ်တွင်ဇယားhypertable တစ်ခုကို ဖန်တီးရန် လိုအပ်သည်။ ဒုတိယ- လယ်ယာသင်ဖန်တီးရန်လိုအပ်သည့်အတိုင်း၊ chunk_time_interval - အပိုင်းခွဲအပိုင်းများကို အသုံးပြုရမည့်ကာလ။ ငါ့ကိစ္စတွင်၊ ကြားကာလသည်တစ်နေ့ - ၈၆,၄၀၀ ဖြစ်သည်။

တတိယသတ်မှတ်ချက် - migrate_data. သတ်မှတ်ရင် trueထို့နောက် လက်ရှိဒေတာအားလုံးကို ကြိုတင်ဖန်တီးထားသည့်အပိုင်းများသို့ လွှဲပြောင်းပေးသည်။ ငါကိုယ်တိုင်သုံးတယ်။ migrate_data. ကျွန်တော့်မှာ 1 TB လောက်ရှိတော့ တစ်နာရီကျော်ကြာတယ်။ အချို့သောကိစ္စများတွင်၊ စမ်းသပ်နေစဉ်တွင်ပင်၊ သိမ်းဆည်းရန်မလိုအပ်သော ဇာတ်ကောင်အမျိုးအစားများ၏ သမိုင်းအချက်အလက်ကို ဖျက်လိုက်သောကြောင့် ၎င်းတို့ကို မလွှဲပြောင်းနိုင်ပါ။

နောက်ဆုံးအဆင့် - UPDATE: မှာ db_extension ထား timescaledbသို့မှသာ ဒေတာဘေ့စ်သည် ဤတိုးချဲ့မှုရှိကြောင်း နားလည်နိုင်မည်ဖြစ်သည်။ Zabbix သည် ၎င်းကို အသက်သွင်းပြီး TimescaleDB အတွက် လိုအပ်သော ဒေတာဘေ့စ်သို့ အထားအသိုနှင့် မေးမြန်းချက်များကို မှန်ကန်စွာ အသုံးပြုပါသည်။

ဟာ့ဒ်ဝဲဖွဲ့စည်းမှု

ဆာဗာနှစ်ခုကိုသုံးခဲ့တယ်။ ပထမ- VMware စက်. ၎င်းသည် အလွန်သေးငယ်သည်- 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz ပရိုဆက်ဆာများ၊ 16 GB RAM နှင့် 200 GB SSD ။

OS နဲ့ PostgreSQL 10.8 ကို install လုပ်လိုက်တယ်။ Debian 10.8-1.pgdg90+1 နဲ့ xfs ဖိုင်စနစ်။ Zabbix ကိုယ်တိုင်အသုံးပြုမယ့်အရာကလွဲရင် ဒီဒေတာဘေ့စ်ကိုသုံးဖို့ အရာအားလုံးကို အနည်းဆုံးဖြစ်အောင် ပြင်ဆင်ထားပါတယ်။

တူညီသောစက်တွင် Zabbix ဆာဗာ၊ PostgreSQL နှင့် အေးဂျင့်များကိုတင်ပါ။. ကျွန်ုပ်တွင် အသုံးပြုနေသော တက်ကြွသော အေးဂျင့် ၅၀ ရှိသည်။ LoadableModuleမတူညီသောရလဒ်များကို လျင်မြန်စွာဖန်တီးရန်- နံပါတ်များ၊ ကြိုးများ။ ဒေတာဘေ့စ်ကို ဒေတာများစွာနဲ့ ဖြည့်ခဲ့တယ်။

အစပိုင်းမှာတော့ configuration ပါပါတယ်။ 5 ဖင် host တစ်ခုစီအတွက်ဒေတာ။ အစိတ်အပိုင်းတိုင်းနီးပါးတွင် ၎င်းကို စစ်မှန်သောထည့်သွင်းမှုများနှင့် ဆင်တူစေရန် အစပျိုးတစ်ခုပါရှိသည်။ အချို့ကိစ္စများတွင် အစပျိုးမှုတစ်ခုထက်ပိုပါသည်။ network node တစ်ခုအတွက် 3-000 အစပျိုး.

ဒေတာအကြောင်းအရာ အပ်ဒိတ်ကြားကာလ − စက္ကန့် ၃၀-၄၀. အေးဂျင့် 50 ကိုသာသာမက အပိုထည့်ခြင်းဖြင့် ဝန်ကို သူ့ဘာသာသူ ထိန်းညှိပေးပါသည်။ ထို့အပြင်၊ ဒေတာဒြပ်စင်များကို အသုံးပြု၍ ဝန်အားကို အင်တိုက်အားတိုက် ချိန်ညှိပြီး အပ်ဒိတ်ကြားကာလကို 4 စက္ကန့်အထိ လျှော့ချခဲ့သည်။

PostgreSQL 35 nvps

ဤဟာ့ဒ်ဝဲတွင် ကျွန်ုပ်၏ပထမဆုံးလုပ်ဆောင်မှုသည် တစ်စက္ကန့်လျှင် 35,ဝဝဝ တန်ဘိုးရှိသော PostgreSQL စင်ပေါ်တွင်ဖြစ်သည်။ သင်တွေ့မြင်ရသည့်အတိုင်း ဒေတာထည့်သွင်းခြင်းသည် တစ်စက္ကန့်၏အပိုင်းအစများ ကြာသည် - အရာအားလုံးသည် ကောင်းမွန်ပြီး မြန်ဆန်သည်။ တစ်ခုတည်းသောအချက်မှာ 200 GB SSD disk သည် လျင်မြန်စွာ ဖြည့်သွင်းနိုင်ခြင်းဖြစ်သည်။

၎င်းသည် ပုံမှန် Zabbix ဆာဗာစွမ်းဆောင်ရည် ဒက်ရှ်ဘုတ်တစ်ခုဖြစ်သည်။

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

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

PostgreSQL 50 nvps

ထို့နောက် တူညီသော ဟာ့ဒ်ဝဲတွင် တစ်စက္ကန့်လျှင် 50 တန်ဘိုးအထိ တိုးမြှင့်ခဲ့သည်။

Housekeeper ထံမှ 10 တန်ဘိုးကို ထည့်သွင်းသည့်အခါ 2-3 စက္ကန့်ကြာပါသည်။

အိမ်ထိန်းက အလုပ်မှာ အနှောင့်အယှက်ဖြစ်နေပြီ။

တတိယဂရပ်သည် ယေဘူယျအားဖြင့် trappers နှင့် history syncchers များပေါ်တွင် load သည် 60% တွင်ရှိနေသေးကြောင်းပြသသည်။ စတုတ္ထဂရပ်တွင်၊ HistoryCache သည် Housekeeper လည်ပတ်မှုအတွင်း အတော်လေးတက်ကြွစွာ ဖြည့်စပြုနေပြီဖြစ်သည်။ ၎င်းသည် 20% အပြည့်ဖြစ်ပြီး 0,5 GB ခန့်ရှိသည်။

PostgreSQL 80 nvps

ပြီးတော့ တစ်စက္ကန့်ကို 80,ဝဝဝ တန်ဘိုးအထိ မြှင့်တင်လိုက်တယ်။ ၎င်းသည် ခန့်မှန်းခြေအားဖြင့် 400 ဒေတာဒြပ်စင်များနှင့် 280 အစပျိုးမှုများဖြစ်သည်။

မှတ်တမ်း syncchers XNUMX ၏ loading ကုန်ကျစရိတ်သည် အတော်လေးမြင့်မားနေပြီဖြစ်သည်။

ကျွန်ုပ်သည် အမျိုးမျိုးသော ကန့်သတ်ချက်များ- သမိုင်းထပ်တူပြုခြင်းများ၊ ကက်ရှ်များကိုလည်း တိုးမြှင့်ခဲ့သည်။

ကျွန်ုပ်၏ ဟာ့ဒ်ဝဲတွင်၊ မှတ်တမ်းစင့်ခ်လုပ်ခြင်းများကို အမြင့်ဆုံးအထိ တိုးထားသည်။ HistoryCache သည် ဒေတာများဖြင့် လျင်မြန်စွာ ပြည့်သွားသည် - လုပ်ဆောင်ခြင်းအတွက် ဒေတာကို ကြားခံတွင် စုဆောင်းထားသည်။

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

ငါအသုံးပြုမှုအောင်မြင်ပြီ။ အများဆုံး disk စွမ်းဆောင်ရည် ဤ hardware နှင့် ဤ virtual machine ပေါ်တွင်။ ထိုကဲ့သို့ပြင်းထန်မှုနှင့်အတူ PostgreSQL သည် ဒေတာများကို အတော်လေး တက်ကြွစွာ ဖြုန်းတီးလာခဲ့ပြီး disk တွင် ရေးသားဖတ်ရန် အချိန်မရှိတော့ပါ။

ဒုတိယဆာဗာ

ပရိုဆက်ဆာ 48 နှင့် 128 GB RAM ပါပြီးသားအခြားဆာဗာတစ်ခုကိုယူခဲ့သည်။ အဲဒါကို ချိန်ညှိပြီး - အဲဒါကို 60 history syncer လို့ သတ်မှတ်ပြီး လက်ခံနိုင်တဲ့ စွမ်းဆောင်ရည်ကို ရရှိခဲ့ပါတယ်။

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

TimescaleDB 80 nvps

ကျွန်ုပ်၏အဓိကတာဝန်မှာ Zabbix load ကိုဆန့်ကျင်သည့် TimescaleDB ၏စွမ်းရည်များကိုစမ်းသပ်ရန်ဖြစ်သည်။ တစ်စက္ကန့်လျှင် တန်ဖိုး 80 သည် များပြားသည်၊ မက်ထရစ်များ စုဆောင်းသည့် အကြိမ်ရေ (Yandex မှလွဲ၍) နှင့် အလွန်ကြီးမားသော "တပ်ဆင်မှု" ဖြစ်သည်။

ဂရပ်တိုင်းတွင် ကျဆင်းသွားသည် - ၎င်းသည် အတိအကျ ဒေတာ ရွှေ့ပြောင်းခြင်း ဖြစ်သည်။ Zabbix ဆာဗာတွင် ပျက်ကွက်ပြီးနောက်၊ history syncer ၏ loading profile သည် များစွာပြောင်းလဲသွားသည် - ၎င်းသည် သုံးဆကျသွားသည်။

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

ထို့ကြောင့် သင်သည် ဒေတာများကို အချိန်နှင့်တပြေးညီ ရရှိမည်ဖြစ်သည်။

TimescaleDB 120 nvps

ထို့နောက် ဒေတာဒြပ်စင်အရေအတွက်ကို 500 သို့တိုး၍ အဓိကတာဝန်မှာ TimescaleDB ၏ လုပ်ဆောင်နိုင်စွမ်းများကို စမ်းသပ်ရန်ဖြစ်သည် - တစ်စက္ကန့်လျှင် တွက်ချက်တန်ဖိုး 125 တန်ဘိုး ရရှိခဲ့ပါသည်။

၎င်းသည် အချိန်ကြာမြင့်စွာ အလုပ်လုပ်နိုင်သော "တပ်ဆင်မှု" ဖြစ်သည်။ သို့သော် ကျွန်ုပ်၏ဒစ်သည် 1,5 TB သာရှိသောကြောင့် ရက်အနည်းငယ်အတွင်း ကျွန်ုပ်ဖြည့်သွင်းခဲ့ပါသည်။

အရေးကြီးဆုံးအချက်မှာ TimescaleDB partitions အသစ်များကို တစ်ချိန်တည်းတွင် ဖန်တီးထားခြင်းဖြစ်သည်။

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

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

တွေ့ရှိချက်များ

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

TimescaleDB သည် configure လုပ်ရန် လွယ်ကူသည်၊ စွမ်းဆောင်ရည် အမြတ်များ ပေးသည်၊ Zabbix နှင့် ကောင်းမွန်စွာ အလုပ်လုပ်ပါသည်။ PostgreSQL ထက် အားသာချက်များရှိသည်။.

အကယ်၍ သင်သည် PostgreSQL ကိုအသုံးပြုပြီး ၎င်းကိုပြောင်းလဲရန် အစီအစဉ်မရှိပါက၊ ကျွန်ုပ်အကြံပြုလိုပါသည်။ Zabbix နှင့် အတူ TimescaleDB တိုးချဲ့မှုဖြင့် PostgreSQL ကို အသုံးပြုပါ။. ဤဖြေရှင်းချက်သည် ကြားခံ "တပ်ဆင်မှု" အထိ ထိထိရောက်ရောက် လုပ်ဆောင်သည်။

"မြင့်မားသောစွမ်းဆောင်ရည်" ဟုဆိုသောအခါကျွန်ုပ်တို့ဆိုလိုသည်။ HighLoad++. သုံးစွဲသူ သန်းပေါင်းများစွာကို ဝန်ဆောင်မှုပေးနိုင်ရန် ဝန်ဆောင်မှုများကို ပံ့ပိုးပေးသည့် နည်းပညာများနှင့် အလေ့အကျင့်များအကြောင်း လေ့လာရန် သင်သည် အချိန်အကြာကြီး စောင့်ရလိမ့်မည်မဟုတ်ပါ။ စာရင်း အစီရင်ခံစာများ နိုဝင်ဘာလ 7 နှင့် 8 အတွက်ကျွန်ုပ်တို့စုစည်းပြီးပါပြီ၊ ဒါပေမယ့်ဒီမှာ တွေ့ဆုံပွဲများ နောက်ထပ်အကြံပြုနိုင်ပါတယ်။

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

source: www.habr.com