🥇High-performance TSDB benchmark VictoriaMetrics vs TimescaleDB vs InfluxDB

Ang VictoriaMetrics, TimescaleDB at InfluxDB ay inihambing sa nakaraang artikulo sa isang dataset na may isang bilyong data point na kabilang sa 40K natatanging serye ng oras.

Ilang taon na ang nakararaan nagkaroon ng panahon ng Zabbix. Ang bawat bare metal server ay may hindi hihigit sa ilang mga indicator - paggamit ng CPU, paggamit ng RAM, paggamit ng disk at paggamit ng network. Sa ganitong paraan, maaaring magkasya ang mga sukatan mula sa libu-libong server sa 40 libong natatanging serye ng oras, at magagamit ng Zabbix ang MySQL bilang backend para sa data ng time series :)

Kasalukuyang nag-iisa node_exporter na may mga default na configuration ay nagbibigay ng higit sa 500 sukatan sa average na host. marami naman mga exporter para sa iba't ibang database, web server, hardware system, atbp. Lahat sila ay nagbibigay ng iba't ibang kapaki-pakinabang na sukatan. Lahat parami nang parami ang mga aplikasyon magsimulang magtakda ng iba't ibang mga tagapagpahiwatig para sa kanilang sarili. Mayroong Kubernetes na may mga cluster at pod na naglalantad ng maraming sukatan. Nagreresulta ito sa paglalantad ng mga server ng libu-libong natatanging sukatan bawat host. Kaya ang natatanging 40K time series ay hindi na high power. Nagiging mainstream na ito at dapat madaling pangasiwaan ng anumang modernong TSDB sa isang server.

Ano ang malaking bilang ng mga natatanging serye ng panahon sa ngayon? Malamang 400K o 4M? O 40m? Ihambing natin ang mga modernong TSDB sa mga numerong ito.

Pag-install ng benchmark

TSBS ay isang mahusay na tool sa benchmarking para sa mga TSDB. Binibigyang-daan ka nitong bumuo ng arbitrary na bilang ng mga sukatan sa pamamagitan ng pagpasa sa kinakailangang bilang ng serye ng oras na hinati sa 10 - flag -scale (dating -scale-var). Ang 10 ay ang bilang ng mga sukat (sukatan) na nabuo sa bawat host o server. Ang mga sumusunod na dataset ay nabuo gamit ang TSBS para sa benchmark:

400K natatanging serye ng oras, 60 segundong pagitan sa pagitan ng mga punto ng data, ang data ay sumasaklaw ng isang buong 3 araw, ~1.7B kabuuang bilang ng mga punto ng data.
4M natatanging serye ng oras, 600 segundong pagitan, ang data ay sumasaklaw ng 3 buong araw, ~1.7B kabuuang bilang ng mga puntos ng data.
40M natatanging serye ng oras, 1 oras na pagitan, ang data ay sumasaklaw ng 3 buong araw, ~2.8B kabuuang bilang ng mga puntos ng data.

Ang kliyente at server ay tumatakbo sa mga nakalaang pagkakataon n1-pamantayan-16 sa Google cloud. Ang mga pagkakataong ito ay may mga sumusunod na configuration:

Mga vCPU: 16
RAM: 60 GB
Imbakan: Karaniwang 1TB HDD. Nagbibigay ito ng 120 Mbps read/write throughput, 750 read operations per second at 1,5K writes per second.

Ang mga TSDB ay nakuha mula sa mga opisyal na imahe ng docker at tumakbo sa docker na may mga sumusunod na pagsasaayos:

VictoriaMetrics:

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

Ang mga halaga ng InfluxDB (-e) ay kinakailangan upang suportahan ang mataas na kapangyarihan. Tingnan 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 (kumuha ng configuration mula sa ito 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 ay pinatakbo na may 16 na parallel na mga thread.

Ang artikulong ito ay naglalaman lamang ng mga resulta para sa paglalagay ng mga benchmark. Ang mga resulta ng piniling benchmark ay ilalathala sa isang hiwalay na artikulo.

400K natatanging serye ng oras

Magsimula tayo sa mga simpleng elemento - 400K. Mga resulta ng benchmark:

VictoriaMetrics: 2,6M data point bawat segundo; Paggamit ng RAM: 3 GB; panghuling laki ng data sa disk: 965 MB
InfluxDB: 1.2M data point bawat segundo; Paggamit ng RAM: 8.5 GB; panghuling laki ng data sa disk: 1.6 GB
Timescale: 849K data point bawat segundo; Paggamit ng RAM: 2,5 GB; panghuling laki ng data sa disk: 50 GB

Gaya ng nakikita mo mula sa mga resulta sa itaas, ang VictoriaMetrics ay nanalo sa insertion performance at compression ratio. Panalo ang timeline sa paggamit ng RAM, ngunit gumagamit ito ng maraming espasyo sa disk - 29 bytes bawat data point.

Nasa ibaba ang mga graph ng paggamit ng CPU para sa bawat TSDB sa panahon ng benchmark:

Sa itaas ay isang screenshot: VictoriaMetrics - CPU load sa panahon ng insertion test para sa isang natatanging 400K metric.

Sa itaas ay isang screenshot: InfluxDB - CPU load sa panahon ng insertion test para sa natatanging sukatan na 400K.

Sa itaas ay isang screenshot: TimescaleDB - CPU load sa panahon ng insertion test para sa isang natatanging sukatan na 400K.

Ginagamit ng VictoriaMetrics ang lahat ng available na vCPU, habang hindi gaanong ginagamit ng InfluxDB ang ~2 sa 16 na vCPU.

Gumagamit lang ang Timescale ng 3-4 sa 16 na vCPU. Ang mataas na proporsyon ng iowait at system sa TimescaleDB timescale graph ay nagpapahiwatig ng bottleneck sa input/output (I/O) subsystem. Tingnan natin ang mga graph ng paggamit ng bandwidth ng disk:

Sa itaas ay isang screenshot: VictoriaMetrics - Paggamit ng Bandwidth ng Disk sa Insertion Test para sa Mga Natatanging Sukatan 400K.

Sa itaas ay isang screenshot: InfluxDB - Paggamit ng Bandwidth ng Disk sa Insertion Test para sa Mga Natatanging Sukatan 400K.

Sa itaas ay isang screenshot: TimescaleDB - Paggamit ng Bandwidth ng Disk sa Insertion Test para sa Mga Natatanging Sukatan 400K.

Itinatala ng VictoriaMetrics ang data sa 20 Mbps na may mga peak hanggang 45 Mbps. Ang mga taluktok ay tumutugma sa malalaking bahagyang pagsasanib sa puno NGO.

Ang InfluxDB ay nagsusulat ng data sa 160 MB/s, habang isang 1 TB drive dapat limitado write throughput 120 MB/s.

Limitado ang TimescaleDB sa pagsulat ng throughput na 120 Mbps, ngunit kung minsan ay nilalabag nito ang limitasyong ito at umabot sa 220 Mbps sa mga peak value. Ang mga taluktok na ito ay tumutugma sa mga lambak ng hindi sapat na paggamit ng CPU sa nakaraang graph.

Tingnan natin ang mga graph ng paggamit ng input/output (I/O):

Sa itaas ay isang screenshot: VictoriaMetrics - Ipasok ang pagsubok na paggamit ng I/O para sa 400K natatanging sukatan.

Sa itaas ay isang screenshot: InfluxDB - Ipasok ang pagsubok na paggamit ng I/O para sa 400K natatanging sukatan.

Sa itaas ay isang screenshot: TimescaleDB - Ipasok ang pagsubok na paggamit ng I/O para sa 400K natatanging sukatan.

Malinaw na ngayon na ang TimescaleDB ay umaabot sa limitasyon ng I/O nito, kaya hindi nito magagamit ang natitirang 12 vCPU.

4M natatanging serye ng oras

Ang 4M time series ay mukhang medyo mahirap. Ngunit matagumpay na naipasa ng aming mga kakumpitensya ang pagsusulit na ito. Mga resulta ng benchmark:

VictoriaMetrics: 2,2M data point bawat segundo; Paggamit ng RAM: 6 GB; panghuling laki ng data sa disk: 3 GB.
InfluxDB: 330K data point bawat segundo; Paggamit ng RAM: 20,5 GB; panghuling laki ng data sa disk: 18,4 GB.
TimescaleDB: 480K data point bawat segundo; Paggamit ng RAM: 2,5 GB; panghuling laki ng data sa disk: 52 GB.

Bumaba ang performance ng InfluxDB mula 1,2M data point bawat segundo para sa isang 400K time series hanggang 330K data point bawat segundo para sa isang 4M time series. Ito ay isang makabuluhang pagkawala ng pagganap kumpara sa iba pang mga kakumpitensya. Tingnan natin ang mga graph ng paggamit ng CPU upang maunawaan ang ugat ng pagkawalang ito:

Sa itaas ay isang screenshot: VictoriaMetrics - Paggamit ng CPU sa panahon ng insertion test para sa isang natatanging 4M time series.

Sa itaas ay isang screenshot: InfluxDB - Paggamit ng CPU sa panahon ng insertion test para sa natatanging 4M time series.

Sa itaas ay isang screenshot: TimescaleDB - Paggamit ng CPU sa panahon ng insertion test para sa isang natatanging 4M time series.

Ginagamit ng VictoriaMetrics ang halos lahat ng processing unit (CPU) power. Ang pagbaba sa dulo ay tumutugma sa natitirang LSM merges pagkatapos maipasok ang lahat ng data.

Gumagamit lamang ang InfluxDB ng 8 sa 16 na vCPU, habang gumagamit ang TimsecaleDB ng 4 sa 16 na vCPU. Ano ang pagkakatulad ng kanilang mga graph? Mataas na share iowait, na muling nagpapahiwatig ng I/O bottleneck.

Ang TimescaleDB ay may mataas na bahagi system. Ipinapalagay namin na ang mataas na kapangyarihan ay nagresulta sa maraming system call o marami menor de edad na mga pagkakamali sa pahina.

Tingnan natin ang mga graph ng disk throughput:

Sa itaas ay isang screenshot: VictoriaMetrics - Paggamit ng disk bandwidth upang magpasok ng 4M na natatanging sukatan.

Sa itaas ay isang screenshot: InfluxDB - Paggamit ng disk bandwidth upang magpasok ng 4M na natatanging sukatan.

Sa itaas ay isang screenshot: TimescaleDB - Paggamit ng disk bandwidth upang magpasok ng 4M na natatanging sukatan.

Naabot ng VictoriaMetrics ang limitasyon na 120 MB/s sa peak, habang ang average na bilis ng pagsulat ay 40 MB/s. Malamang na maraming mabibigat na pagsasanib ng LSM ang isinagawa sa panahon ng rurok.

Muling pinipiga ng InfluxDB ang average na write throughput na 200 MB/s na may mga peak na hanggang 340 MB/s sa isang disk na may write limit na 120 MB/s :)

Ang TimescaleDB ay hindi na limitado sa disk. Mukhang nalilimitahan ito ng ibang bagay na may kaugnayan sa mataas na proporsyon системной load ng CPU.

Tingnan natin ang mga graph ng paggamit ng IO:

Sa itaas ay isang screenshot: VictoriaMetrics - Paggamit ng I/O habang insertion test para sa isang natatanging 4M time series.

Sa itaas ay isang screenshot: InfluxDB - Paggamit ng I/O sa panahon ng insertion test para sa isang natatanging 4M time series.

Sa itaas ay isang screenshot: TimescaleDB - I/O na paggamit sa panahon ng insertion test para sa natatanging 4M time series.

Ang mga pattern ng paggamit ng IO ay sumasalamin sa mga bandwidth ng disk - Ang InfluxDB ay limitado sa IO, habang ang VictoriaMetrics at TimescaleDB ay may mga ekstrang mapagkukunan ng IO.

40M natatanging serye ng oras

Masyadong malaki ang 40M natatanging serye ng oras para sa InfluxDB :)

Mga resulta ng benchmark:

VictoriaMetrics: 1,7M data point bawat segundo; Paggamit ng RAM: 29 GB; Paggamit ng espasyo sa disk: 17 GB.
InfluxDB: Hindi natapos dahil nangangailangan ito ng higit sa 60GB ng RAM.
TimescaleDB: 330K data point bawat segundo, paggamit ng RAM: 2,5 GB; Paggamit ng espasyo sa disk: 84GB.

Ang TimescaleDB ay nagpapakita ng napakababa at stable na paggamit ng RAM sa 2,5 GB - katulad ng para sa natatanging 4M at 400K na sukatan.

Unti-unting nag-scale up ang VictoriaMetrics sa rate na 100k data point bawat segundo hanggang sa maproseso ang lahat ng 40M na naka-tag na pangalan ng sukatan. Pagkatapos ay nakamit niya ang matagal na rate ng pagpapasok na 1,5-2,0M data point bawat segundo, kaya ang huling resulta ay 1,7M data point bawat segundo.

Ang mga graph para sa 40M natatanging serye ng oras ay katulad ng mga graph para sa 4M natatanging serye ng oras, kaya laktawan natin ang mga ito.

Natuklasan

Ang mga modernong TSDB ay may kakayahang magproseso ng mga pagsingit para sa milyun-milyong natatanging serye ng oras sa isang server. Sa susunod na artikulo, susuriin namin kung gaano kahusay na gumaganap ng pagpili ang mga TSDB sa milyun-milyong natatanging serye ng oras.
Ang hindi sapat na paggamit ng CPU ay karaniwang nagpapahiwatig ng I/O bottleneck. Maaari rin itong magpahiwatig na ang pagharang ay masyadong magaspang, na may ilang mga thread lamang ang maaaring tumakbo nang sabay-sabay.
Ang I/O bottleneck ay umiiral, lalo na sa non-SSD storage gaya ng mga virtualized block device ng mga cloud provider.
Nagbibigay ang VictoriaMetrics ng pinakamahusay na pag-optimize para sa mabagal, mababang storage ng I/O. Nagbibigay ito ng pinakamahusay na bilis at ang pinakamahusay na ratio ng compression.

Mag-download Larawan ng single-server ng VictoriaMetrics at subukan ito sa iyong data. Ang kaukulang static binary ay makukuha sa GitHub.

Magbasa pa tungkol sa VictoriaMetrics dito Artikulo.

Update: nai-publish artikulong naghahambing ng insert performance ng VictoriaMetrics sa InfluxDB na may mga reproducible na resulta.

Update #2: Basahin din artikulo sa vertical scalability VictoriaMetrics vs InfluxDB vs TimescaleDB.

Update #3: Ang VictoriaMetrics ay open source na ngayon!

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

Pinagmulan: www.habr.com