စွမ်းဆောင်ရည်မြင့် TSDB စံသတ်မှတ်ချက် VictoriaMetrics vs TimescaleDB နှင့် InfluxDB

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

လွန်ခဲ့သောနှစ်အနည်းငယ်က Zabbix ခေတ်တစ်ခုရှိခဲ့သည်။ သတ္တုမပါသော ဆာဗာတစ်ခုစီတွင် ညွှန်ကိန်းအနည်းငယ်ထက် မပိုပါ - CPU အသုံးပြုမှု၊ RAM အသုံးပြုမှု၊ ဒစ်အသုံးပြုမှုနှင့် ကွန်ရက်အသုံးပြုမှု။ ဤနည်းအားဖြင့် ဆာဗာထောင်ပေါင်းများစွာမှ မက်ထရစ်များကို 40 သီးသန့်အချိန်စီးရီးများတွင် အံဝင်ခွင်ကျဖြစ်စေနိုင်ပြီး Zabbix သည် အချိန်စီးရီးဒေတာအတွက် နောက်ခံအဖြစ် MySQL ကို အသုံးပြုနိုင်ပါသည်။ :)

လောလောဆယ် တစ်ယောက်တည်း node_exporter ပုံသေဖွဲ့စည်းပုံများဖြင့် ပျမ်းမျှ host တွင် မက်ထရစ် 500 ကျော်ကို ပံ့ပိုးပေးသည်။ များစွာရှိပါသည် တင်ပို့သူများ ဒေတာဘေ့စ်အမျိုးမျိုး၊ ဝဘ်ဆာဗာများ၊ ဟာ့ဒ်ဝဲစနစ်များ စသည်တို့အတွက် ၎င်းတို့အားလုံးသည် အသုံးဝင်သော မက်ထရစ်အမျိုးမျိုးကို ပေးဆောင်သည်။ အားလုံး ပိုများသော applications များ ၎င်းတို့အတွက် အမျိုးမျိုးသော ညွှန်ကိန်းများကို စတင်သတ်မှတ်ပါ။ မက်ထရစ်များစွာကို ဖော်ပြသည့် အစုအစည်းများနှင့် ပေါ့ဒ်များပါရှိသော Kubernetes ရှိသည်။ ၎င်းသည် host တစ်ခုလျှင် ထောင်ပေါင်းများစွာသော ထူးခြားသော မက်ထရစ်များကို ပြသသည့် ဆာဗာများကို ဖြစ်ပေါ်စေသည်။ ထို့ကြောင့် ထူးခြားသော 40K အချိန်စီးရီးသည် ပါဝါမြင့်မားတော့မည်မဟုတ်ပါ။ ၎င်းသည် ပင်မရေစီးကြောင်းဖြစ်လာပြီး မည်သည့်ခေတ်မီသော TSDB မဆို ဆာဗာတစ်ခုတည်းတွင် အလွယ်တကူကိုင်တွယ်သင့်သည်။

ယခုအချိန်တွင် ထူးခြားသော အချိန်စီးရီးအရေအတွက် မည်မျှရှိသနည်း။ 400K သို့မဟုတ် 4M ဖြစ်နိုင်ပါသလား။ ဒါမှမဟုတ် 40 မီတာ? ခေတ်မီ TSDB များကို ဤနံပါတ်များနှင့် နှိုင်းယှဉ်ကြည့်ရအောင်။

စံသတ်မှတ်ချက်တစ်ခု ထည့်သွင်းခြင်း။

TSBS TSDB များအတွက် အလွန်ကောင်းမွန်သော စံသတ်မှတ်ခြင်းကိရိယာတစ်ခုဖြစ်သည်။ ၎င်းသည် သင့်အား အလံ 10 ဖြင့် ပိုင်းခြားထားသော လိုအပ်သော အချိန်စီးရီးအရေအတွက်ကို ကျော်ဖြတ်ခြင်းဖြင့် မထင်သလိုကိန်းဂဏန်းများကို ထုတ်လုပ်နိုင်စေပါသည်။ -စကေး (ဟောင်း -scale-var) 10 သည် လက်ခံသူ သို့မဟုတ် ဆာဗာတစ်ခုစီတွင် ထုတ်ပေးသည့် အတိုင်းအတာ (မက်ထရစ်များ) ဖြစ်သည်။ စံသတ်မှတ်ချက်အတွက် TSBS ကို အသုံးပြု၍ အောက်ပါဒေတာအတွဲများကို ထုတ်ပေးခဲ့သည်-

• 400K ထူးခြားသောအချိန်စီးရီး၊ ဒေတာအချက်များကြား 60 စက္ကန့်ကြားကာလ၊ ဒေတာသည် 3 ရက်အပြည့်၊ ဒေတာစုစုပေါင်းအရေအတွက် ~1.7B ဖြစ်သည်။
• 4M ထူးခြားသောအချိန်စီးရီး၊ 600 စက္ကန့်ကြားကာလ၊ ဒေတာသည် 3 ရက်အပြည့်၊ ဒေတာစုစုပေါင်းအရေအတွက် ~1.7B။
• 40M ထူးခြားသောအချိန်စီးရီး၊ 1 နာရီကြားကာလ၊ ဒေတာသည် 3 ရက်အပြည့်၊ ဒေတာစုစုပေါင်းအရေအတွက် ~2.8B။

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

• vCPU များ- ၁၆
• RAM ကို - 60 GB
• သိုလှောင်မှု- ပုံမှန် 1TB HDD။ ၎င်းသည် 120 Mbps read/write throughput၊ တစ်စက္ကန့်လျှင် 750 read operations နှင့် 1,5K writes per second တို့ကို ထောက်ပံ့ပေးသည်။

TSDB များကို တရားဝင် docker ပုံများမှ ထုတ်ယူပြီး အောက်ပါပုံစံများဖြင့် docker တွင် လုပ်ဆောင်သည်-

• VictoriaMetrics-

  docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics

• မြင့်မားသောပါဝါကိုပံ့ပိုးရန် InfluxDB (-e) တန်ဖိုးများ လိုအပ်ပါသည်။ အသေးစိတ်အချက်အလက်များကို တွင်ကြည့်ပါ။ စာရွက်စာတမ်း):

  docker run -it --rm -p 8086:8086 
  -e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 
  -e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g 
  -e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 
  -v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb

• TimescaleDB (ဖွဲ့စည်းပုံမှ ယူသည်။ က ဖိုင်):

MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432 
--shm-size=${SHARED}MB 
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data 
timescale/timescaledb:latest-pg10 postgres 
-cmax_wal_size=${WAL}MB 
-clog_line_prefix="%m [%p]: [%x] %u@%d" 
-clogging_collector=off 
-csynchronous_commit=off 
-cshared_buffers=${SHARED}MB 
-ceffective_cache_size=${CACHE}MB 
-cwork_mem=${WORK}MB 
-cmaintenance_work_mem=${MAINT}MB 
-cmax_files_per_process=100

data loader ကို parallel threads 16 ခုဖြင့် run ထားသည်။

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

400K ထူးခြားသောအချိန်စီးရီး

ရိုးရှင်းသောဒြပ်စင်များ - 400K ဖြင့်စကြပါစို့။ စံရလဒ်များ-

• VictoriaMetrics- တစ်စက္ကန့်လျှင် ဒေတာအချက် 2,6 သန်း၊ RAM အသုံးပြုမှု- 3 GB; disk ပေါ်ရှိ နောက်ဆုံးဒေတာအရွယ်အစား- 965 MB
• InfluxDB- တစ်စက္ကန့်လျှင် ဒေတာအချက်များ 1.2M၊ RAM အသုံးပြုမှု- 8.5 GB; ဒစ်ခ်ရှိ နောက်ဆုံးဒေတာအရွယ်အစား- 1.6 GB
• အချိန်အတိုင်းအတာ- တစ်စက္ကန့်လျှင် ဒေတာအမှတ် ၈၄၉K၊ RAM အသုံးပြုမှု- 849 GB; ဒစ်ပေါ်တွင် နောက်ဆုံးဒေတာအရွယ်အစား- 2,5 GB

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

စံသတ်မှတ်ချိန်အတွင်း TSDBs တစ်ခုစီအတွက် CPU အသုံးပြုမှုဂရပ်များသည် အောက်ပါတို့ဖြစ်သည်-

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံဖြစ်သည်- VictoriaMetrics - ထူးခြားသော 400K မက်ထရစ်အတွက် ထည့်သွင်းစမ်းသပ်စဉ်အတွင်း CPU ဝန်ထုပ်ဝန်ပိုး။

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံဖြစ်သည်- InfluxDB - ထူးခြားသောမက်ထရစ် 400K အတွက် ထည့်သွင်းစမ်းသပ်စဉ်အတွင်း CPU load

အပေါ်က ဖန်သားပြင်ဓာတ်ပုံတစ်ခုဖြစ်ပါသည်- TimescaleDB - 400K ၏ထူးခြားသောမက်ထရစ်အတွက် ထည့်သွင်းစမ်းသပ်နေစဉ် CPU load

VictoriaMetrics သည် ရရှိနိုင်သော vCPU အားလုံးကို အသုံးပြုသော်လည်း InfluxDB သည် vCPU 2 ခုအနက်မှ 16 ခုကို အသုံးမပြုတော့ပါ။

Timescale သည် vCPU 3 ခုအနက် 4-16 ခုသာအသုံးပြုသည်။ TimescaleDB အချိန်စကေးဂရပ်ရှိ iowait နှင့် စနစ်၏ အချိုးအစားမြင့်မားမှုသည် input/output (I/O) စနစ်ခွဲတွင် ပိတ်ဆို့မှုကို ညွှန်ပြသည်။ disk bandwidth အသုံးပြုမှုဂရပ်များကို ကြည့်ကြပါစို့။

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံ- VictoriaMetrics - Unique Metrics 400K အတွက် Insertion Test တွင် Disk Bandwidth အသုံးပြုမှု။

အထက်ဖော်ပြပါ မျက်နှာပြင်ပုံသည် InfluxDB - Unique Metrics 400K အတွက် Insertion Test တွင် Disk Bandwidth အသုံးပြုမှု။

အပေါ်က မျက်နှာပြင်ပုံတစ်ပုံပါ- TimescaleDB - Unique Metrics 400K အတွက် Insertion Test တွင် Disk Bandwidth အသုံးပြုမှု။

VictoriaMetrics သည် 20 Mbps ဖြင့် ဒေတာကို အမြင့်ဆုံး 45 Mbps အထိ မှတ်တမ်းတင်သည်။ တောင်ထိပ်များသည် သစ်ပင်ရှိ ကြီးမားသော တစ်စိတ်တစ်ပိုင်း ပေါင်းစပ်မှုများနှင့် ကိုက်ညီသည်။ NGO.

InfluxDB သည် 160 MB/s ဖြင့် ဒေတာကို 1 TB ဒရိုက်ဖြင့် ရေးသားသည်။ ကန့်သတ်သင့်သည်။ throughput 120 MB/s ကို ရေးပါ။

TimescaleDB သည် 120 Mbps ၏ ဖြတ်သန်းမှုအား ရေးသားရန် ကန့်သတ်ထားသော်လည်း တစ်ခါတစ်ရံတွင် ၎င်းသည် ဤကန့်သတ်ချက်ကို ချိုးဖျက်ပြီး အမြင့်ဆုံးတန်ဖိုးများတွင် 220 Mbps အထိ ရောက်ရှိသည်။ ဤအထွတ်အထိပ်များသည် ယခင်ဂရပ်တွင် မလုံလောက်သော CPU အသုံးပြုမှုချိုင့်များနှင့် ကိုက်ညီပါသည်။

အဝင်/အထွက် (I/O) အသုံးပြုမှုဂရပ်များကို ကြည့်ကြပါစို့။

အပေါ်က ဖန်သားပြင်ဓာတ်ပုံ- VictoriaMetrics - 400K ထူးခြားသော မက်ထရစ်များအတွက် စမ်းသပ်မှု I/O အသုံးပြုမှုကို ထည့်သွင်းပါ။

အပေါ်က မျက်နှာပြင်ပုံတစ်ပုံပါ- InfluxDB - 400K ထူးခြားသောမက်ထရစ်များအတွက် စမ်းသပ်မှု I/O အသုံးပြုမှုကို ထည့်သွင်းပါ။

အပေါ်က ဖန်သားပြင်ဓာတ်ပုံ- TimescaleDB - 400K ထူးခြားသောမက်ထရစ်များအတွက် စမ်းသပ်မှု I/O အသုံးပြုမှုကို ထည့်သွင်းပါ။

TimescaleDB သည် ၎င်း၏ I/O ကန့်သတ်ချက်သို့ ရောက်ရှိနေပြီဖြစ်ရာ ၎င်းသည် ကျန် 12 vCPU များကို အသုံးမပြုနိုင်တော့ပေ။

4M ထူးခြားသောအချိန်စီးရီး

4M time series သည် အနည်းငယ် စိန်ခေါ်ပုံပေါက်သည်။ ဒါပေမယ့် ကျွန်တော်တို့ရဲ့ ပြိုင်ဘက်တွေက ဒီစာမေးပွဲကို အောင်မြင်စွာ အောင်ခဲ့ပါတယ်။ စံရလဒ်များ-

• VictoriaMetrics- တစ်စက္ကန့်လျှင် ဒေတာအမှတ် 2,2M၊ RAM အသုံးပြုမှု- 6 GB; ဒစ်ခ်ရှိ နောက်ဆုံးဒေတာအရွယ်အစား- 3 GB။
• InfluxDB- တစ်စက္ကန့်လျှင် 330K ဒေတာအချက်များ။ RAM အသုံးပြုမှု- 20,5 GB; disk တွင်နောက်ဆုံးဒေတာအရွယ်အစား- 18,4 GB ။
• TimescaleDB- တစ်စက္ကန့်လျှင် 480K ဒေတာအချက်များ။ RAM အသုံးပြုမှု- 2,5 GB; ဒစ်ပေါ်တွင် နောက်ဆုံးဒေတာအရွယ်အစား- 52 GB။

InfluxDB စွမ်းဆောင်ရည်သည် 1,2M အချိန်စီးရီးတစ်ခုအတွက် တစ်စက္ကန့်လျှင် 400M ဒေတာမှတ်များမှ 330K အချိန်စီးရီးအတွက် တစ်စက္ကန့်လျှင် 4K ဒေတာအမှတ်သို့ ကျဆင်းသွားသည်။ ဒါဟာ တခြားပြိုင်ဘက်တွေနဲ့ ယှဉ်ရင် သိသိသာသာ စွမ်းဆောင်ရည်ကျခြင်းပါပဲ။ ဤဆုံးရှုံးမှု၏အရင်းအမြစ်ကိုနားလည်ရန် CPU အသုံးပြုမှုဂရပ်များကိုကြည့်ကြပါစို့။

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံ- VictoriaMetrics - ထူးခြားသော 4M အချိန်စီးရီးအတွက် ထည့်သွင်းစမ်းသပ်မှုအတွင်း CPU အသုံးပြုမှု။

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံဖြစ်သည်- InfluxDB - ထူးခြားသော 4M အချိန်စီးရီးအတွက် ထည့်သွင်းစမ်းသပ်မှုအတွင်း CPU အသုံးပြုမှု။

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံ- TimescaleDB - ထူးခြားသော 4M အချိန်စီးရီးအတွက် ထည့်သွင်းစမ်းသပ်မှုအတွင်း CPU အသုံးပြုမှု။

VictoriaMetrics သည် လုပ်ဆောင်ဆဲယူနစ် (CPU) ပါဝါအားလုံးနီးပါးကို အသုံးပြုသည်။ ဒေတာအားလုံးကို ထည့်သွင်းပြီးနောက် အဆုံးတွင် ကျဆင်းမှုသည် ကျန်ရှိသော LSM များ ပေါင်းစည်းမှုနှင့် သက်ဆိုင်သည်။

InfluxDB သည် vCPU 8 ခုအနက် 16 ခုကိုသာအသုံးပြုပြီး TimsecaleDB သည် vCPU 4 ခုအနက် 16 ခုကိုအသုံးပြုသည်။ သူတို့ရဲ့ ဂရပ်ဖစ်တွေက ဘာတွေလဲ။ မြင့်ဝေ iowait၎င်းသည် I/O ပိတ်ဆို့မှုကို ညွှန်ပြပြန်သည်။

TimescaleDB တွင် မျှဝေမှု မြင့်မားသည်။ system. မြင့်မားသော ပါဝါသည် စနစ်ခေါ်ဆိုမှုများ သို့မဟုတ် အများအပြားကို ဖြစ်ပေါ်စေသည်ဟု ကျွန်ုပ်တို့ ယူဆပါသည်။ စာမျက်နှာ အသေးအမွှားများ.

disk throughput graphs ကို ကြည့်ရအောင်။

အထက်တွင်ဖော်ပြထားသော ဖန်သားပြင်ဓာတ်ပုံ- VictoriaMetrics - 4M ထူးခြားသောမက်ထရစ်များကိုထည့်သွင်းရန် disk bandwidth ကိုအသုံးပြုခြင်း။

အပေါ်က ဖန်သားပြင်ဓာတ်ပုံတစ်ခုဖြစ်ပါသည်- InfluxDB - 4M ထူးခြားသောမက်ထရစ်များကိုထည့်သွင်းရန် disk bandwidth ကိုအသုံးပြုခြင်း။

အပေါ်က မျက်နှာပြင်ပုံတစ်ပုံပါ- TimescaleDB - 4M ထူးခြားသောမက်ထရစ်များကို ထည့်သွင်းရန် ဒစ်ခ်ဘန်းဝဒ်ကို အသုံးပြုခြင်း။

VictoriaMetrics သည် အထွတ်အထိပ်တွင် 120 MB/s ကန့်သတ်ချက်သို့ရောက်ရှိခဲ့ပြီး ပျမ်းမျှရေးသားမှုနှုန်းမှာ 40 MB/s ဖြစ်သည်။ အထွတ်အထိပ်ကာလအတွင်း လေးလံသော LSM ပေါင်းမြောက်များစွာကို လုပ်ဆောင်ခဲ့ဖွယ်ရှိသည်။

InfluxDB သည် 200 MB/s ကန့်သတ်ထားသော 340 MB/s ဖြင့် disk တစ်ခုပေါ်တွင် 120 MB/s အထိ အမြင့်ဆုံး XNUMX MB/s ဖြင့် ပျမ်းမျှ ရေးနိုင်မှုအား ထပ်မံ ညှစ်ထုတ်သည် :)

TimescaleDB သည် ဒစ်ခ်အကန့်အသတ်မဟုတ်တော့ပါ။ မြင့်မားသောအချိုးအစားနှင့် ပတ်သက်သည့် အခြားအရာများဖြင့် ကန့်သတ်ထားပုံပေါ်သည်။ системной CPU ဝန်။

IO အသုံးပြုမှုဂရပ်များကို ကြည့်ကြပါစို့။

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံ- VictoriaMetrics - ထူးခြားသော 4M အချိန်စီးရီးအတွက် ထည့်သွင်းစမ်းသပ်မှုအတွင်း I/O ကို အသုံးပြုခြင်း။

အထက်တွင်ဖော်ပြထားသည်မှာ ဖန်သားပြင်ဓာတ်ပုံဖြစ်သည်- InfluxDB - ထူးခြားသော 4M အချိန်စီးရီးအတွက် ထည့်သွင်းစမ်းသပ်မှုအတွင်း I/O ကို အသုံးပြုခြင်း။

အထက်ဖော်ပြပါ ဖန်သားပြင်ဓာတ်ပုံ- TimescaleDB - ထူးခြားသော 4M အချိန်စီးရီးအတွက် ထည့်သွင်းစမ်းသပ်မှုအတွင်း I/O အသုံးပြုမှု။

IO အသုံးပြုမှုပုံစံများသည် disk bandwidth ကိုထင်ဟပ်စေသည် - InfluxDB သည် IO အကန့်အသတ်ရှိပြီး VictoriaMetrics နှင့် TimescaleDB တွင် IO အရင်းအမြစ်များ အပိုပါရှိသည်။

40M ထူးခြားသောအချိန်စီးရီး

40M ထူးခြားသောအချိန်စီးရီးသည် InfluxDB အတွက် အလွန်ကြီးမားသည် :)

စံရလဒ်များ-

• VictoriaMetrics- တစ်စက္ကန့်လျှင် ဒေတာအချက် ၁.၇ သန်း၊ RAM အသုံးပြုမှု- 1,7 GB; Disk နေရာအသုံးပြုမှု- 29 GB။
• InfluxDB- RAM 60GB ထက်ပိုလိုအပ်သောကြောင့် မပြီးပါ။
• TimescaleDB- တစ်စက္ကန့်လျှင် ဒေတာအချက် 330K၊ RAM အသုံးပြုမှု- 2,5 GB; Disk နေရာအသုံးပြုမှု- 84GB။

TimescaleDB သည် ထူးခြားသော 2,5M နှင့် 4K မက်ထရစ်များအတွက် တူညီသော 400 GB တွင် အလွန်နိမ့်ပြီး တည်ငြိမ်သော RAM အသုံးပြုမှုကို ပြသသည်။

VictoriaMetrics သည် တစ်စက္ကန့်လျှင် ဒေတာအချက်ပေါင်း 100k နှုန်းဖြင့် တဖြည်းဖြည်း ချဲ့ထွင်ကာ မက်ထရစ်အမည် 40M အားလုံးကို တဂ်ထားသော မက်ထရစ်အမည်များ လုပ်ဆောင်ပြီးသည်အထိ ချဲ့ထွင်ခဲ့သည်။ ထို့နောက် သူသည် တစ်စက္ကန့်လျှင် ဒေတာမှတ်တိုင် 1,5-2,0M ဆက်တိုက် ထည့်သွင်းနှုန်းကို ရရှိခဲ့ပြီး နောက်ဆုံးရလဒ်မှာ တစ်စက္ကန့်လျှင် ဒေတာမှတ် 1,7M ဖြစ်သည်။

40M ထူးခြားသည့်အချိန်စီးရီးများအတွက် ဂရပ်များသည် 4M ထူးခြားသည့်အချိန်စီးရီးများအတွက် ဂရပ်များနှင့်ဆင်တူသောကြောင့် ၎င်းတို့ကို ကျော်လိုက်ကြပါစို့။

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

• ခေတ်မီ TSDB များသည် ဆာဗာတစ်ခုတည်းရှိ သန်းပေါင်းများစွာသော အချိန်စီးရီးများအတွက် ထည့်သွင်းမှုများကို လုပ်ဆောင်နိုင်စွမ်းရှိသည်။ နောက်ဆောင်းပါးတွင်၊ သန်းနှင့်ချီသောထူးခြားသောအချိန်စီးရီးများတစ်လျှောက် TSDB များသည် ရွေးချယ်မှုကို မည်မျှကောင်းစွာလုပ်ဆောင်နိုင်သည်ကို ကျွန်ုပ်တို့စမ်းသပ်ပါမည်။
• CPU အသုံးပြုမှု မလုံလောက်ခြင်းသည် I/O ပိတ်ဆို့မှုကို ညွှန်ပြသည်။ တစ်ကြိမ်လျှင် လိုင်းအနည်းငယ်သာ လုပ်ဆောင်နိုင်သဖြင့် ပိတ်ဆို့ခြင်းသည် ကြမ်းလွန်းသည်ဟုလည်း ညွှန်ပြနိုင်သည်။
• အထူးသဖြင့် cloud ဝန်ဆောင်မှုပေးသူများ၏ virtualized block devices များကဲ့သို့သော SSD မဟုတ်သော သိုလှောင်မှုတွင် I/O ပိတ်ဆို့မှု ရှိပါသည်။
• VictoriaMetrics သည် နှေးကွေးပြီး နိမ့်သော I/O သိုလှောင်မှုအတွက် အကောင်းဆုံး ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ပေးပါသည်။ ၎င်းသည် အကောင်းဆုံးအမြန်နှုန်းနှင့် အကောင်းဆုံး compression အချိုးကို ပေးဆောင်သည်။

ဒေါင်းလုပ် VictoriaMetrics တစ်ခုတည်း-ဆာဗာပုံ သင်၏ဒေတာကိုစမ်းကြည့်ပါ။ သက်ဆိုင်ရာ static binary မှာ ရနိုင်ပါတယ်။ GitHub.

ဤတွင် VictoriaMetrics အကြောင်းပိုမိုဖတ်ပါ။ ဆောင်းပါး.

အပ်ဒိတ်- ထုတ်ဝေခဲ့သည်။ InfluxDB နှင့် VictoriaMetrics ၏ ထည့်သွင်းဆောင်ရွက်မှု နှိုင်းယှဉ်ဆောင်းပါး မျိုးပွားနိုင်သောရလဒ်များနှင့်အတူ။

အပ်ဒိတ် #2- ကိုလည်းဖတ်ပါ။ ဒေါင်လိုက် တတ်နိုင်မှု VictoriaMetrics vs InfluxDB vs TimescaleDB ဆောင်းပါး.

အပ်ဒိတ် #3- VictoriaMetrics သည် ယခု open source ဖြစ်သည်။!

ကြေးနန်းချတ်- https://t.me/VictoriaMetrics_ru1

source: www.habr.com