🥇High-performance TSDB benchmark VictoriaMetrics vs TimescaleDB vs InfluxDB

Ang VictoriaMetrics, TimescaleDB ug InfluxDB gitandi sa miaging artikulo sa usa ka dataset nga adunay usa ka bilyon nga mga punto sa datos nga iya sa 40K talagsaon nga serye sa panahon.

Pipila ka tuig ang milabay adunay panahon sa Zabbix. Ang matag hubo nga metal nga server adunay dili labaw sa pipila nga mga timailhan - paggamit sa CPU, paggamit sa RAM, paggamit sa disk ug paggamit sa network. Niining paagiha, ang mga sukatan gikan sa libu-libo nga mga server mahimong mohaum sa 40 ka libo nga talagsaon nga serye sa oras, ug magamit ni Zabbix ang MySQL ingon usa ka backend alang sa datos sa serye sa oras :)

Sa pagkakaron nag-inusara node_exporter nga adunay default nga mga pag-configure naghatag labaw sa 500 nga sukatan sa kasagaran nga host. Naay daghan mga eksporter para sa lain-laing database, web server, hardware system, ug uban pa. Silang tanan naghatag ug lain-laing mapuslanong metrics. Tanan nagkadaghang mga aplikasyon magsugod sa pagbutang sa lain-laing mga indicators alang sa ilang kaugalingon. Adunay mga Kubernetes nga adunay mga kumpol ug mga pod nga nagpadayag sa daghang mga sukatan. Nagresulta kini sa mga server nga nagbutyag sa libu-libo nga talagsaon nga mga sukatan matag host. Busa ang talagsaon nga 40K time series dili na taas nga gahum. Kini nahimo nga mainstream ug kinahanglan nga dali madumala sa bisan unsang modernong TSDB sa usa ka server.

Unsa ang daghang gidaghanon sa talagsaon nga serye sa panahon sa pagkakaron? Tingali 400K o 4M? O 40m? Atong itandi ang mga modernong TSDB niini nga mga numero.

Pag-instalar sa usa ka benchmark

TSBS usa ka maayo kaayo nga himan sa pag-benchmark alang sa mga TSDB. Gitugotan ka niini nga makamugna usa ka arbitraryong gidaghanon sa mga sukatan pinaagi sa pagpasa sa gikinahanglan nga gidaghanon sa serye sa oras nga gibahin sa 10 - bandila - timbangan (kanhi -scale-var). Ang 10 mao ang gidaghanon sa mga sukod (metrics) nga nahimo sa matag host o server. Ang mosunud nga mga datos gihimo gamit ang TSBS alang sa benchmark:

400K nga talagsaon nga serye sa panahon, 60 segundos nga agwat tali sa mga punto sa datos, ang datos nagsangkap sa usa ka bug-os nga 3 ka adlaw, ~ 1.7B nga kinatibuk-ang gidaghanon sa mga punto sa datos.
Ang 4M talagsaon nga serye sa panahon, 600 segundos nga agwat, ang datos nagsangkad sa 3 ka tibuok nga mga adlaw, ~ 1.7B nga kinatibuk-ang gidaghanon sa mga punto sa datos.
40M nga talagsaon nga serye sa oras, 1 ka oras nga agwat, ang datos nagsangkap sa usa ka bug-os nga 3 ka adlaw, ~ 2.8B nga kinatibuk-ang gidaghanon sa mga puntos sa datos.

Ang kliyente ug server nagdagan sa gipahinungod nga mga higayon n1-standard-16 sa Google cloud. Kini nga mga higayon adunay mga mosunod nga mga pag-configure:

vCPUs: 16
RAM: 60 GB
Pagtipig: Standard 1TB HDD. Naghatag kini og 120 Mbps read/write throughput, 750 read operations kada segundo ug 1,5K writes kada segundo.

Ang mga TSDB gikuha gikan sa opisyal nga mga imahe sa docker ug gipadagan sa docker nga adunay mga mosunud nga pag-configure:

VictoriaMetrics:

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

Ang mga kantidad sa InfluxDB (-e) gikinahanglan aron masuportahan ang taas nga gahum. Tan-awa ang mga detalye sa dokumentasyon):

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 (konfigurasyon gikuha gikan sa kini file):

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

Ang data loader gipadagan nga adunay 16 ka parallel thread.

Kini nga artikulo naglangkob lamang sa mga resulta alang sa pagsal-ot nga mga benchmark. Ang mga resulta sa pinili nga benchmark ipatik sa usa ka bulag nga artikulo.

400K talagsaon nga serye sa panahon

Magsugod ta sa yano nga mga elemento - 400K. Mga resulta sa benchmark:

VictoriaMetrics: 2,6M data points kada segundo; Paggamit sa RAM: 3 GB; katapusang gidak-on sa datos sa disk: 965 MB
InfluxDB: 1.2M data points kada segundo; Paggamit sa RAM: 8.5 GB; katapusang gidak-on sa datos sa disk: 1.6 GB
Timescale: 849K data points kada segundo; Paggamit sa RAM: 2,5 GB; katapusang gidak-on sa datos sa disk: 50 GB

Sama sa imong makita gikan sa mga resulta sa ibabaw, ang VictoriaMetrics nakadaog sa insertion performance ug compression ratio. Nagdaog ang timeline sa paggamit sa RAM, apan naggamit kini daghang espasyo sa disk - 29 bytes matag punto sa datos.

Sa ubos mao ang mga graph sa paggamit sa CPU alang sa matag TSDB sa panahon sa benchmark:

Sa ibabaw kay usa ka screenshot: VictoriaMetrics - CPU load atol sa insertion test para sa talagsaong 400K metric.

Sa ibabaw mao ang screenshot: InfluxDB - CPU load atol sa insertion test para sa talagsaong metric 400K.

Sa ibabaw kay usa ka screenshot: TimescaleDB - CPU load atol sa insertion test para sa talagsaong metric nga 400K.

Gigamit sa VictoriaMetrics ang tanan nga magamit nga vCPU, samtang ang InfluxDB wala kaayo magamit ~ 2 sa 16 nga vCPU.

Gigamit lang sa timescale ang 3-4 sa 16 ka vCPU. Ang taas nga proporsyon sa iowait ug sistema sa TimescaleDB time scale graph nagpakita sa usa ka bottleneck sa input/output (I/O) subsystem. Atong tan-awon ang mga graph sa paggamit sa bandwidth sa disk:

Sa ibabaw kay usa ka screenshot: VictoriaMetrics - Disk Bandwidth Usage sa Insertion Test para sa Unique Metrics 400K.

Sa taas kay usa ka screenshot: InfluxDB - Disk Bandwidth Usage sa Insertion Test para sa Unique Metrics 400K.

Sa ibabaw kay usa ka screenshot: TimescaleDB - Disk Bandwidth Usage sa Insertion Test para sa Unique Metrics 400K.

Girekord sa VictoriaMetrics ang datos sa 20 Mbps nga adunay mga peak hangtod sa 45 Mbps. Ang mga taluktok katumbas sa dagkong partial mergers sa kahoy NGO.

Ang InfluxDB nagsulat sa datos sa 160 MB/s, samtang ang 1 TB drive kinahanglan nga limitado pagsulat throughput 120 MB/s.

Limitado ang TimescaleDB sa pagsulat sa throughput nga 120 Mbps, apan usahay kini makalapas niini nga limitasyon ug moabot sa 220 Mbps sa peak values. Kini nga mga taluktok katumbas sa mga walog sa dili igo nga paggamit sa CPU sa miaging graph.

Atong tan-awon ang input/output (I/O) nga mga graph sa paggamit:

Sa ibabaw kay usa ka screenshot: VictoriaMetrics - Isulod ang pagsulay I/O nga paggamit para sa 400K nga talagsaon nga metrics.

Sa ibabaw kay usa ka screenshot: InfluxDB - Insert test I/O usage para sa 400K unique metrics.

Sa ibabaw kay usa ka screenshot: TimescaleDB - Insert test I/O usage for 400K unique metrics.

Klaro na karon nga ang TimescaleDB nakaabot na sa I/O limit niini, mao nga dili kini magamit sa nahabilin nga 12 vCPUs.

4M talagsaon nga serye sa panahon

Ang 4M nga time series medyo mahagiton. Apan malampuson nga nakapasar ang among mga kakompetensya niini nga pasulit. Mga resulta sa benchmark:

VictoriaMetrics: 2,2M data points kada segundo; Paggamit sa RAM: 6 GB; katapusang gidak-on sa datos sa disk: 3 GB.
InfluxDB: 330K data points kada segundo; Paggamit sa RAM: 20,5 GB; katapusang gidak-on sa datos sa disk: 18,4 GB.
TimescaleDB: 480K data points kada segundo; Paggamit sa RAM: 2,5 GB; katapusang gidak-on sa datos sa disk: 52 GB.

Ang performance sa InfluxDB mius-os gikan sa 1,2M data points kada segundo para sa 400K time series ngadto sa 330K data points kada segundo para sa 4M time series. Kini usa ka hinungdanon nga pagkawala sa pasundayag kung itandi sa ubang mga kakompetensya. Atong tan-awon ang mga graph sa paggamit sa CPU aron masabtan ang hinungdan niini nga pagkawala:

Sa ibabaw kay usa ka screenshot: VictoriaMetrics - Paggamit sa CPU atol sa insertion test para sa talagsaong 4M time series.

Sa ibabaw mao ang screenshot: InfluxDB - Paggamit sa CPU atol sa insertion test alang sa talagsaong 4M time series.

Sa ibabaw mao ang screenshot: TimescaleDB - Paggamit sa CPU atol sa insertion test para sa talagsaong 4M time series.

Gigamit sa VictoriaMetrics ang hapit tanan nga gahum sa yunit sa pagproseso (CPU). Ang drop sa katapusan katumbas sa nahabilin nga LSM merges human ang tanan nga mga data nga gisal-ut.

Ang InfluxDB naggamit lamang sa 8 sa 16 ka vCPU, samtang ang TimsecaleDB naggamit sa 4 sa 16 ka vCPU. Unsay komon sa ilang mga graph? Taas nga bahin iowait, nga nagpakita pag-usab sa usa ka bottleneck sa I/O.

Ang TimescaleDB adunay taas nga bahin system. Nagtuo kami nga ang taas nga gahum miresulta sa daghang mga tawag sa sistema o daghan menor de edad nga mga sayup sa panid.

Atong tan-awon ang disk throughput graphs:

Sa ibabaw kay usa ka screenshot: VictoriaMetrics - Paggamit sa bandwidth sa disk aron isulod ang 4M nga talagsaon nga sukatan.

Sa ibabaw usa ka screenshot: InfluxDB - Paggamit sa bandwidth sa disk aron isulud ang 4M nga talagsaon nga sukatan.

Sa ibabaw usa ka screenshot: TimescaleDB - Paggamit sa bandwidth sa disk aron isulud ang 4M nga talagsaon nga mga sukatan.

Ang VictoriaMetrics nakaabot sa limitasyon sa 120 MB/s sa kinatas-ang bahin, samtang ang kasagarang katulin sa pagsulat kay 40 MB/s. Lagmit nga daghang bug-at nga LSM fusions ang gihimo sa panahon sa peak.

Ang InfluxDB usab nagpugos sa usa ka average nga pagsulat sa throughput nga 200 MB/s nga adunay mga peak hangtod sa 340 MB/s sa usa ka disk nga adunay limitasyon sa pagsulat nga 120 MB/s :)

Ang TimescaleDB dili na limitado sa disk. Mopatim-aw nga kini limitado sa laing butang nga may kalabutan sa taas nga proporsiyon системной load sa CPU.

Atong tan-awon ang mga graph sa paggamit sa IO:

Sa ibabaw mao ang screenshot: VictoriaMetrics - Paggamit sa I/O atol sa insertion test para sa talagsaong 4M time series.

Sa ibabaw mao ang screenshot: InfluxDB - Paggamit sa I/O atol sa insertion test para sa talagsaong 4M time series.

Sa ibabaw kay usa ka screenshot: TimescaleDB - I/O nga paggamit atol sa insertion test para sa talagsaong 4M time series.

Ang mga sumbanan sa paggamit sa IO nagsalamin sa mga bandwidth sa disk - Ang InfluxDB limitado sa IO, samtang ang VictoriaMetrics ug TimescaleDB adunay ekstra nga mga kapanguhaan sa IO.

40M talagsaon nga serye sa panahon

Ang 40M nga talagsaon nga serye sa oras dako kaayo alang sa InfluxDB :)

Mga resulta sa benchmark:

VictoriaMetrics: 1,7M data points kada segundo; Paggamit sa RAM: 29 GB; Paggamit sa espasyo sa disk: 17 GB.
InfluxDB: Wala nahuman tungod kay nanginahanglan kini labaw sa 60GB nga RAM.
TimescaleDB: 330K data points kada segundo, paggamit sa RAM: 2,5 GB; Paggamit sa espasyo sa disk: 84GB.

Gipakita sa TimescaleDB ang labi ka ubos ug lig-on nga paggamit sa RAM sa 2,5 GB - parehas sa alang sa talagsaon nga 4M ug 400K nga sukatan.

Ang VictoriaMetrics hinayhinay nga mitaas sa rate nga 100k data points kada segundo hangtod maproseso ang tanang 40M nga tag metric nga ngalan. Nakab-ot dayon niya ang padayon nga rate sa pagsal-ot nga 1,5-2,0M nga mga puntos sa datos matag segundo, mao nga ang katapusan nga resulta mao ang 1,7M nga mga puntos sa datos matag segundo.

Ang mga graph alang sa 40M nga talagsaon nga serye sa panahon susama sa mga graph alang sa 4M nga talagsaon nga serye sa panahon, busa ato kining laktawan.

kaplag

Ang mga modernong TSDB makahimo sa pagproseso sa mga pagsal-ot alang sa minilyon nga talagsaon nga serye sa panahon sa usa ka server. Sa sunod nga artikulo, atong sulayan kung unsa ka maayo ang TSDB nga naghimo sa pagpili sa milyon-milyon nga talagsaon nga serye sa oras.
Ang dili igo nga paggamit sa CPU kasagaran nagpaila sa usa ka bottleneck sa I/O. Mahimo usab nga magpakita nga ang pag-ali kay grabe, nga adunay pipila ra nga mga hilo nga makadagan sa usa ka higayon.
Ang I/O bottleneck naglungtad, ilabina sa non-SSD storage sama sa cloud providers' virtualized block devices.
Naghatag ang VictoriaMetrics sa labing kaayo nga pag-optimize alang sa hinay, ubos nga pagtipig sa I/O. Naghatag kini sa labing kaayo nga tulin ug labing kaayo nga ratio sa compression.

Pag-download Imahe sa usa ka server sa VictoriaMetrics ug sulayi kini sa imong data. Ang katugbang nga static binary anaa sa GitHub.

Basaha ang dugang bahin sa VictoriaMetrics niini artikulo.

Update: gimantala artikulo nga nagtandi sa insert performance sa VictoriaMetrics sa InfluxDB nga adunay mga reproducible nga resulta.

Update #2: Basaha usab artikulo sa bertikal nga scalability VictoriaMetrics vs InfluxDB vs TimescaleDB.

Update #3: Ang VictoriaMetrics karon bukas nga tinubdan!

Telegram chat: https://t.me/VictoriaMetrics_ru1

Source: www.habr.com