ស្តង់ដារ TSDB ដែលមានប្រសិទ្ធភាពខ្ពស់ VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB និង InfluxDB ត្រូវបានប្រៀបធៀបនៅក្នុង អត្ថបទមុន នៅលើសំណុំទិន្នន័យដែលមានចំណុចទិន្នន័យរាប់ពាន់លានដែលជាកម្មសិទ្ធិរបស់ស៊េរីពេលវេលាតែមួយគត់ 40K ។

ពីរបីឆ្នាំមុនមានសម័យ Zabbix ។ ម៉ាស៊ីនមេដែកទទេនីមួយៗមិនមានសូចនាករលើសពីពីរបីទេ - ការប្រើប្រាស់ស៊ីភីយូ ការប្រើប្រាស់ RAM ការប្រើប្រាស់ថាស និងការប្រើប្រាស់បណ្តាញ។ វិធីនេះ រង្វាស់ពីម៉ាស៊ីនមេរាប់ពាន់អាចសមនឹងស៊េរីពេលវេលាពិសេសចំនួន 40 ពាន់ ហើយ Zabbix អាចប្រើ MySQL ជាកម្មវិធីខាងក្រោយសម្រាប់ទិន្នន័យស៊េរីពេលវេលា :)

បច្ចុប្បន្ននៅម្នាក់ឯង node_exporter ជាមួយនឹងការកំណត់លំនាំដើមផ្តល់នូវជាង 500 ម៉ែត្រនៅលើម៉ាស៊ីនជាមធ្យម។ មាន​ច្រើន អ្នកនាំចេញ សម្រាប់មូលដ្ឋានទិន្នន័យផ្សេងៗ ម៉ាស៊ីនមេគេហទំព័រ ប្រព័ន្ធផ្នែករឹង។ល។ ពួកវាទាំងអស់ផ្តល់នូវភាពខុសគ្នានៃម៉ែត្រដែលមានប្រយោជន៍។ ទាំងអស់។ កម្មវិធីកាន់តែច្រើន ចាប់ផ្តើមកំណត់សូចនាករផ្សេងៗសម្រាប់ខ្លួនគេ។ មាន Kubernetes ដែលមានចង្កោម និងផតដែលបង្ហាញម៉ែត្រជាច្រើន។ លទ្ធផលនេះនៅក្នុងម៉ាស៊ីនមេបង្ហាញការវាស់វែងប្លែកៗរាប់ពាន់ក្នុងមួយម៉ាស៊ីន។ ដូច្នេះស៊េរីពេលវេលា 40K តែមួយគត់គឺលែងមានថាមពលខ្ពស់ទៀតហើយ។ វាកំពុងក្លាយជាចរន្តសំខាន់ ហើយគួរតែត្រូវបានគ្រប់គ្រងយ៉ាងងាយស្រួលដោយ TSDB ទំនើបណាមួយនៅលើម៉ាស៊ីនមេតែមួយ។

តើចំនួនដ៏ច្រើននៃស៊េរីពេលវេលាពិសេសនៅពេលនេះគឺជាអ្វី? ប្រហែលជា 400K ឬ 4M? ឬ 40 ម៉ែត្រ? ចូរយើងប្រៀបធៀប TSDBs ទំនើបទៅនឹងលេខទាំងនេះ។

ការដំឡើងស្តង់ដារ

TSBS គឺជាឧបករណ៍ស្ដង់ដារដ៏ល្អសម្រាប់ TSDBs ។ វាអនុញ្ញាតឱ្យអ្នកបង្កើតចំនួនម៉ែត្រដោយបំពានដោយឆ្លងកាត់ចំនួនដែលត្រូវការនៃស៊េរីពេលវេលាដែលបែងចែកដោយ 10 - ទង់ - មាត្រដ្ឋាន (អតីត -scale-var) 10 គឺជាចំនួនរង្វាស់ (ម៉ែត្រ) ដែលបង្កើតនៅលើម៉ាស៊ីន ឬម៉ាស៊ីនមេនីមួយៗ។ សំណុំទិន្នន័យខាងក្រោមត្រូវបានបង្កើតដោយប្រើ TSBS សម្រាប់គោល៖

• ស៊េរីពេលវេលាពិសេស 400K ចន្លោះពេល 60 វិនាទីរវាងចំណុចទិន្នន័យ ទិន្នន័យមានរយៈពេល 3 ថ្ងៃពេញ ~ 1.7B ចំនួនសរុបនៃចំណុចទិន្នន័យ។
• ស៊េរីពេលវេលាពិសេស 4M, ចន្លោះពេល 600 វិនាទី, ទិន្នន័យមានរយៈពេល 3 ថ្ងៃពេញ, ~ 1.7B ចំនួនសរុបនៃចំណុចទិន្នន័យ។
• ស៊េរីពេលវេលាពិសេស 40M ចន្លោះពេល 1 ម៉ោង ទិន្នន័យមានរយៈពេលពេញ 3 ថ្ងៃ ~ 2.8B ចំនួនសរុបនៃចំណុចទិន្នន័យ។

ម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេកំពុងដំណើរការលើករណីជាក់លាក់ n1-ស្តង់ដារ-16 នៅក្នុង Google cloud ។ ករណីទាំងនេះមានការកំណត់រចនាសម្ព័ន្ធដូចខាងក្រោមៈ

• vCPUs៖ ១៦
• អង្គចងចាំ: 60 GB
• ទំហំផ្ទុក៖ HDD ស្តង់ដារ 1TB ។ វាផ្តល់នូវការអាន/សរសេរ 120 Mbps ដំណើរការអាន 750 ក្នុងមួយវិនាទី និង 1,5K សរសេរក្នុងមួយវិនាទី។

TSDBs ត្រូវបានស្រង់ចេញពីរូបភាព 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

កម្មវិធីផ្ទុកទិន្នន័យត្រូវបានដំណើរការជាមួយ 16 ខ្សែប៉ារ៉ាឡែល។

អត្ថបទនេះមានលទ្ធផលសម្រាប់តែការបញ្ចូលគំរូ។ លទ្ធផល​នៃ​ការ​ជ្រើសរើស​គោល​នឹង​ត្រូវ​បាន​បោះពុម្ព​ផ្សាយ​ក្នុង​អត្ថបទ​ដាច់​ដោយ​ឡែក​មួយ។

ស៊េរីពេលវេលាពិសេស 400K

ចូរចាប់ផ្តើមជាមួយនឹងធាតុសាមញ្ញ - 400K ។ លទ្ធផល​ស្តង់ដារ៖

• VictoriaMetrics៖ ចំណុចទិន្នន័យ 2,6M ក្នុងមួយវិនាទី; ការប្រើប្រាស់ RAM: 3 GB; ទំហំទិន្នន័យចុងក្រោយនៅលើថាស៖ 965 MB
• InfluxDB: 1.2M ចំណុចទិន្នន័យក្នុងមួយវិនាទី; ការប្រើប្រាស់ RAM: 8.5 GB; ទំហំទិន្នន័យចុងក្រោយនៅលើថាស៖ 1.6 GB
• មាត្រដ្ឋានពេលវេលា៖ ៨៤៩K ចំណុចទិន្នន័យក្នុងមួយវិនាទី; ការប្រើប្រាស់ RAM: 849 GB; ទំហំទិន្នន័យចុងក្រោយនៅលើថាស៖ 2,5 GB

ដូចដែលអ្នកអាចមើលឃើញពីលទ្ធផលខាងលើ VictoriaMetrics ឈ្នះក្នុងការអនុវត្តការបញ្ចូល និងសមាមាត្របង្ហាប់។ បន្ទាត់ពេលវេលាឈ្នះក្នុងការប្រើប្រាស់ RAM ប៉ុន្តែវាប្រើទំហំថាសច្រើន - 29 បៃក្នុងមួយចំណុចទិន្នន័យ។

ខាងក្រោមនេះជាក្រាហ្វនៃការប្រើប្រាស់ស៊ីភីយូសម្រាប់ TSDBs នីមួយៗក្នុងអំឡុងពេលកំណត់ស្តង់ដារ៖

ខាងលើគឺជារូបថតអេក្រង់៖ VictoriaMetrics - ការផ្ទុកស៊ីភីយូអំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ម៉ែត្រ 400K តែមួយគត់។

ខាងលើគឺជារូបថតអេក្រង់៖ InfluxDB - ការផ្ទុកស៊ីភីយូកំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ម៉ែត្រតែមួយគត់ 400K ។

ខាងលើគឺជារូបថតអេក្រង់៖ TimescaleDB - ការផ្ទុកស៊ីភីយូអំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ម៉ែត្រតែមួយគត់នៃ 400K ។

VictoriaMetrics ប្រើ vCPUs ដែលមានទាំងអស់ ខណៈពេលដែល InfluxDB ប្រើប្រាស់តិចជាង ~2 ក្នុងចំណោម vCPUs 16 ។

Timescale ប្រើតែ 3-4 នៃ vCPUs 16 ប៉ុណ្ណោះ។ សមាមាត្រខ្ពស់នៃ iowait និងប្រព័ន្ធនៅក្នុងក្រាហ្វខ្នាតពេលវេលា TimescaleDB បង្ហាញពីការជាប់គាំងនៅក្នុងប្រព័ន្ធរង input/output (I/O) ។ សូមក្រឡេកមើលក្រាហ្វនៃការប្រើប្រាស់កម្រិតបញ្ជូនរបស់ថាស៖

ខាងលើគឺជារូបថតអេក្រង់៖ VictoriaMetrics - Disk Bandwidth Usage in Insertion Test for Unique Metrics 400K។

ខាងលើគឺជារូបថតអេក្រង់៖ InfluxDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K។

ខាងលើគឺជារូបថតអេក្រង់៖ TimescaleDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K។

VictoriaMetrics កត់ត្រាទិន្នន័យនៅល្បឿន 20 Mbps ជាមួយនឹងកម្រិតកំពូលរហូតដល់ 45 Mbps ។ កំពូលត្រូវគ្នាទៅនឹងការបញ្ចូលគ្នានៃផ្នែកធំនៅក្នុងដើមឈើ អង្គការក្រៅរដ្ឋាភិបាល.

InfluxDB សរសេរទិន្នន័យក្នុងល្បឿន 160 MB/s ខណៈដ្រាយ 1 TB គួរតែត្រូវបានកំណត់ សរសេរឆ្លងកាត់ 120 MB/s ។

TimescaleDB ត្រូវបានកំណត់ក្នុងការសរសេរឆ្លងកាត់ 120 Mbps ប៉ុន្តែពេលខ្លះវាបំបែកដែនកំណត់នេះហើយឈានដល់ 220 Mbps ក្នុងតម្លៃខ្ពស់បំផុត។ កំពូលទាំងនេះត្រូវគ្នាទៅនឹងជ្រលងនៃការប្រើប្រាស់ស៊ីភីយូមិនគ្រប់គ្រាន់នៅក្នុងក្រាហ្វមុន។

សូមក្រឡេកមើលក្រាហ្វការប្រើប្រាស់បញ្ចូល/ទិន្នផល (I/O)៖

ខាងលើគឺជារូបថតអេក្រង់៖ VictoriaMetrics - បញ្ចូលការប្រើប្រាស់តេស្ត I/O សម្រាប់ម៉ែត្រតែមួយគត់ 400K។

ខាងលើគឺជារូបថតអេក្រង់៖ InfluxDB - បញ្ចូលការប្រើប្រាស់តេស្ត I/O សម្រាប់ម៉ែត្រតែមួយគត់ 400K ។

ខាងលើគឺជារូបថតអេក្រង់៖ TimescaleDB - បញ្ចូលការប្រើប្រាស់តេស្ត I/O សម្រាប់ម៉ែត្រតែមួយគត់ 400K ។

ឥឡូវនេះវាច្បាស់ណាស់ថា TimescaleDB កំពុងឈានដល់ដែនកំណត់ I/O របស់វា ដូច្នេះវាមិនអាចប្រើ vCPU ដែលនៅសល់ 12 បានទេ។

ស៊េរីពេលវេលាពិសេស 4M

ស៊េរីពេលវេលា 4M មើលទៅពិបាកបន្តិច។ ប៉ុន្តែអ្នកប្រកួតប្រជែងរបស់យើងបានប្រឡងជាប់ដោយជោគជ័យ។ លទ្ធផល​ស្តង់ដារ៖

• VictoriaMetrics៖ ចំណុចទិន្នន័យ 2,2M ក្នុងមួយវិនាទី; ការប្រើប្រាស់ RAM: 6 GB; ទំហំទិន្នន័យចុងក្រោយនៅលើថាស៖ 3 GB ។
• InfluxDB: 330K ចំណុចទិន្នន័យក្នុងមួយវិនាទី; ការប្រើប្រាស់ RAM: 20,5 GB; ទំហំទិន្នន័យចុងក្រោយនៅលើថាស៖ 18,4 GB ។
• TimescaleDB: 480K ចំណុចទិន្នន័យក្នុងមួយវិនាទី; ការប្រើប្រាស់ RAM: 2,5 GB; ទំហំទិន្នន័យចុងក្រោយនៅលើថាស៖ 52 GB ។

ការអនុវត្តរបស់ InfluxDB បានធ្លាក់ចុះពីចំណុចទិន្នន័យ 1,2M ក្នុងមួយវិនាទីសម្រាប់ស៊េរីពេលវេលា 400K ទៅ 330K ចំណុចទិន្នន័យក្នុងមួយវិនាទីសម្រាប់ស៊េរីពេលវេលា 4M ។ នេះ​ជា​ការ​ខាត​បង់​យ៉ាង​ខ្លាំង​បើ​ធៀប​នឹង​គូ​ប្រជែង​ផ្សេង​ទៀត។ សូមក្រឡេកមើលក្រាហ្វនៃការប្រើប្រាស់ CPU ដើម្បីស្វែងយល់ពីមូលហេតុដើមនៃការបាត់បង់នេះ៖

ខាងលើគឺជារូបថតអេក្រង់៖ VictoriaMetrics - ការប្រើប្រាស់ស៊ីភីយូអំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ស៊េរីពេលវេលា 4M តែមួយគត់។

ខាងលើគឺជារូបថតអេក្រង់៖ InfluxDB - ការប្រើប្រាស់ស៊ីភីយូអំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ស៊េរីពេលវេលា 4M តែមួយគត់។

ខាងលើគឺជារូបថតអេក្រង់៖ TimescaleDB - ការប្រើប្រាស់ស៊ីភីយូអំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ស៊េរីពេលវេលា 4M តែមួយគត់។

VictoriaMetrics ប្រើប្រាស់ថាមពលស្ទើរតែទាំងអស់នៃអង្គភាពដំណើរការ (CPU) ។ ការធ្លាក់ចុះនៅចុងបញ្ចប់ត្រូវគ្នាទៅនឹងការបញ្ចូល LSM ដែលនៅសល់បន្ទាប់ពីទិន្នន័យទាំងអស់ត្រូវបានបញ្ចូល។

InfluxDB ប្រើតែ 8 vCPUs 16 ប៉ុណ្ណោះ ខណៈ TimsecaleDB ប្រើ vCPU 4 ក្នុងចំណោម 16 ។ តើក្រាហ្វរបស់ពួកគេមានអ្វីខ្លះដូចគ្នា? ភាគហ៊ុនខ្ពស់។ iowaitដែលបង្ហាញពីការស្ទះ I/O ម្តងទៀត។

TimescaleDB មានភាគហ៊ុនខ្ពស់។ system. យើងសន្មត់ថាថាមពលខ្ពស់បណ្តាលឱ្យមានការហៅតាមប្រព័ន្ធជាច្រើនឬច្រើន។ កំហុសទំព័រតូច.

សូមក្រឡេកមើលក្រាហ្វនៃការបញ្ចូលថាស៖

ខាងលើគឺជារូបថតអេក្រង់៖ VictoriaMetrics - ការប្រើកម្រិតបញ្ជូនថាសដើម្បីបញ្ចូលម៉ែត្រតែមួយគត់ 4M ។

ខាងលើគឺជារូបថតអេក្រង់៖ InfluxDB - ការប្រើកម្រិតបញ្ជូនថាសដើម្បីបញ្ចូលម៉ែត្រតែមួយគត់ 4M ។

ខាងលើគឺជារូបថតអេក្រង់៖ TimescaleDB - ការប្រើកម្រិតបញ្ជូនថាសដើម្បីបញ្ចូលម៉ែត្រតែមួយគត់ 4M ។

VictoriaMetrics ឈានដល់កម្រិតកំណត់ 120 MB/s នៅកម្រិតកំពូល ខណៈល្បឿនសរសេរជាមធ្យមគឺ 40 MB/s ។ វាទំនងជាថាការលាយ LSM ធ្ងន់ៗជាច្រើនត្រូវបានអនុវត្តកំឡុងពេលកំពូល។

InfluxDB ច្របាច់ចេញម្តងទៀតនូវការសរសេរជាមធ្យម 200 MB/s ជាមួយនឹងកម្រិតខ្ពស់រហូតដល់ 340 MB/s នៅលើថាសដែលមានដែនកំណត់សរសេរ 120 MB/s :)

TimescaleDB លែងមានកំណត់ថាសទៀតហើយ។ វាហាក់ដូចជាត្រូវបានកំណត់ដោយអ្វីផ្សេងទៀតដែលទាក់ទងនឹងសមាមាត្រខ្ពស់។ системной បន្ទុកស៊ីភីយូ។

តោះមើលក្រាហ្វនៃការប្រើប្រាស់ IO៖

ខាងលើគឺជារូបថតអេក្រង់៖ VictoriaMetrics - ការប្រើប្រាស់ I/O កំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ស៊េរីពេលវេលា 4M តែមួយគត់។

ខាងលើគឺជារូបថតអេក្រង់៖ InfluxDB - ការប្រើប្រាស់ I/O កំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ស៊េរីពេលវេលា 4M តែមួយគត់។

ខាងលើគឺជារូបថតអេក្រង់៖ TimescaleDB - ការប្រើប្រាស់ I/O កំឡុងពេលធ្វើតេស្តបញ្ចូលសម្រាប់ស៊េរីពេលវេលា 4M តែមួយគត់។

គំរូការប្រើប្រាស់ IO ឆ្លុះបញ្ចាំងពីកម្រិតបញ្ជូនរបស់ថាស - InfluxDB ត្រូវបានកំណត់ IO ខណៈពេលដែល VictoriaMetrics និង TimescaleDB មានធនធាន IO ទំនេរ។

40M ស៊េរីពេលវេលាពិសេស

ស៊េរីពេលវេលាពិសេស 40M គឺធំពេកសម្រាប់ InfluxDB :)

លទ្ធផល​ស្តង់ដារ៖

• VictoriaMetrics: 1,7M ចំណុចទិន្នន័យក្នុងមួយវិនាទី; ការប្រើប្រាស់ RAM: 29 GB; ការប្រើប្រាស់ទំហំថាស៖ ១៧ ជីកាបៃ។
• InfluxDB៖ មិនបានបញ្ចប់ទេព្រោះវាត្រូវការ RAM លើសពី 60GB។
• TimescaleDB: 330K ចំណុចទិន្នន័យក្នុងមួយវិនាទី ការប្រើប្រាស់ RAM: 2,5 GB; ការប្រើប្រាស់ទំហំថាស៖ ៨៤ ជីកាបៃ។

TimescaleDB បង្ហាញការប្រើប្រាស់ RAM ទាប និងមានស្ថេរភាពពិសេសនៅ 2,5 GB - ដូចគ្នាទៅនឹងម៉ែត្រ 4M និង 400K តែមួយគត់។

VictoriaMetrics បានពង្រីកបន្តិចម្តងៗក្នុងអត្រា 100k data point ក្នុងមួយវិនាទី រហូតដល់រាល់ 40M tagged names ត្រូវបានដំណើរការ។ បន្ទាប់មកគាត់សម្រេចបាននូវអត្រាបញ្ចូលប្រកបដោយនិរន្តរភាពនៃ 1,5-2,0M ចំណុចទិន្នន័យក្នុងមួយវិនាទី ដូច្នេះលទ្ធផលចុងក្រោយគឺ 1,7M ចំណុចទិន្នន័យក្នុងមួយវិនាទី។

ក្រាហ្វសម្រាប់ស៊េរីពេលវេលាពិសេស 40M គឺស្រដៀងនឹងក្រាហ្វសម្រាប់ស៊េរីពេលវេលាតែមួយគត់ 4M ដូច្នេះសូមរំលងពួកវា។

ការរកឃើញ

• TSDBs ទំនើបមានសមត្ថភាពដំណើរការការបញ្ចូលសម្រាប់ស៊េរីពេលវេលាពិសេសរាប់លាននៅលើម៉ាស៊ីនមេតែមួយ។ នៅក្នុងអត្ថបទបន្ទាប់ យើងនឹងសាកល្បងថាតើ TSDBs ដំណើរការការជ្រើសរើសបានល្អប៉ុណ្ណានៅលើស៊េរីពេលវេលាប្លែកៗរាប់លាន។
• ការប្រើប្រាស់ស៊ីភីយូមិនគ្រប់គ្រាន់ជាធម្មតាបង្ហាញពីការស្ទះ I/O ។ វាក៏អាចបង្ហាញថាការទប់ស្កាត់គឺមានភាពស្រួចស្រាវពេក ដោយមានតែខ្សែស្រឡាយពីរបីប៉ុណ្ណោះដែលអាចដំណើរការបានក្នុងពេលតែមួយ។
• ការរារាំង I/O មានជាពិសេសនៅក្នុងកន្លែងផ្ទុកដែលមិនមែនជា SSD ដូចជាឧបករណ៍ប្លុកនិម្មិតរបស់អ្នកផ្តល់សេវាពពក។
• VictoriaMetrics ផ្តល់នូវការបង្កើនប្រសិទ្ធភាពល្អបំផុតសម្រាប់ការផ្ទុក I/O យឺត និងទាប។ វាផ្តល់នូវល្បឿនល្អបំផុត និងសមាមាត្របង្ហាប់ល្អបំផុត។

ទាញយក រូបថតរបស់ VictoriaMetrics single-server ហើយសាកល្បងវានៅលើទិន្នន័យរបស់អ្នក។ គោលពីរឋិតិវន្តដែលត្រូវគ្នាគឺអាចរកបាននៅ GitHub.

សូមអានបន្ថែមអំពី VictoriaMetrics នៅក្នុងនេះ។ អត្ថបទ.

បច្ចុប្បន្នភាព៖ បោះពុម្ពផ្សាយ អត្ថបទប្រៀបធៀបដំណើរការបញ្ចូលរបស់ VictoriaMetrics ជាមួយ InfluxDB ជាមួយនឹងលទ្ធផលដែលអាចបន្តពូជបាន។

ធ្វើបច្ចុប្បន្នភាព # 2: អានផងដែរ។ អត្ថបទស្តីពីការធ្វើមាត្រដ្ឋានបញ្ឈរ VictoriaMetrics vs InfluxDB vs TimescaleDB.

អាប់ដេត #3៖ ឥឡូវនេះ VictoriaMetrics គឺជាប្រភពបើកចំហ!

ការជជែកតាមតេឡេក្រាម៖ https://t.me/VictoriaMetrics_ru1

ប្រភព: www.habr.com