🥇Vysoko výkonný TSDB benchmark VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB a InfluxDB boli porovnané v predchádzajúcej článku súbore údajov s miliardou bodov údajov pochádzajúcich z 40K jedinečných časových radov.

Pred niekoľkými rokmi bola éra Zabbixu. Každý bare metal server mal maximálne niekoľko metrík – využitie procesora, využitie pamäte, využitie disku a využitie siete. Takto môžu metriky z tisícov serverov zmestiť do 40 tisíc jedinečných časových radov a Zabbix môže využívať MySQL ako backend pre údaje časových radov 🙂

V súčasnosti jeden node_exporter s prednastavenými konfiguráciami poskytuje viac než 500 metrík na priemernom hoste. Existuje množstvo exportérov pre rôzne databázy, webové servery, hardvérové systémy a podobne. Všetci poskytujú množstvo užitočných metrík. Všetky viac a viac aplikácií začínajú vystavovať rôzne metriky o sebe. Existuje Kubernetes s klastrami a podmi, ktoré odhaľujú množstvo metrík. To vedie k tomu, že servery vystavujú tisíce jedinečných metrík na hoste. Takže jedinečný časový rad 40K už nie je vysoký výkon. Stáva sa hlavným prúdom, ktorý by mala bez problémov spracovať akákoľvek moderná TSDB na jednom serveri.

Aké je to veľké množstvo jedinečných časových radov v súčasnosti? Pravdepodobne 400K alebo 4M? Alebo 40M? Porovnajme moderné TSDB s týmito číslami.

Nastavenie benchmarku

TSBS je skvelý nástroj na benchmarking pre TSDB. Umožňuje generovať ľubovoľné množstvo metrík tým, že odovzdá potrebné množstvo časových radov delených na 10 – prepínač -scale (predtým -scale-var). 10 je počet meraní (metrik), ktoré sa generujú na každom hoste, serveri. Nasledujúce súbory údajov boli vytvorené pomocou TSBS pre benchmark:

400K jedinečných časových radov, 60 sekúnd interval medzi bodmi údajov, údaje pokrývajú celé 3 dni, ~1.7B celkový počet bodov údajov.
4M jedinečných časových radov, interval 600 sekúnd, údaje pokrývajú celé 3 dni, ~1.7B celkový počet bodov údajov.
40M jedinečných časových radov, interval 1 hodina, údaje pokrývajú celé 3 dni, ~2.8 B celkový počet bodov údajov.

Klient a server boli spustené na vyhradených inštanciách n1-standard-16 v cloude Google. Tieto instance mali nasledujúce konfigurácie:

vCPU: 16
RAM: 60 GB
Úložisko: štandardný pevný disk s kapacitou 1 TB. Zabezpečuje priepustnosť čítania/zápisu 120 Mbit/s, 750 čítaní za sekundu a 1,5K zápisov za sekundu.

TSDB boli extrahované z oficiálnych docker obrazov a boli spustené v dockeri s nasledujúcimi konfiguráciami:

VictoriaMetrics:

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

Hodnoty InfluxDB (-e sú potrebné na podporu vysokého výkonu. Viac podrobností nájdete v dokumenácie):

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 (konfigurácia bola prevzatá z tohto súboru):

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

Načítavač údajov bol spustený s 16 paralelnými vláknami.

Tento článok obsahuje iba výsledky pre kontrolné metriky inkasovania. Výsledky vzorkovania benchmarku budú uverejnené v samostatnom článku.

400K unikátnych časových radov

Začnime s jednoduchými prvkami — 400K. Výsledky benchmarku:

VictoriaMetrics: 2,6M bodov údajov za sekundu; využitie pamäte: 3 GB; konečná veľkosť údajov na disku: 965 MB
InfluxDB: 1,2M bodov údajov za sekundu; využitie pamäte: 8,5 GB; konečná veľkosť údajov na disku: 1,6 GB
Timescale: 849K bodov údajov za sekundu; využitie pamäte: 2,5 GB; konečná veľkosť údajov na disku: 50 GB

Ako vidíte z uvedených výsledkov, VictoriaMetrics vyhráva v rýchlosti inkasovania a miere kompresie. Timescale vyhráva v využití pamäte, ale zaberá veľa diskového priestoru — 29 bajtov na bod údajov.

Nižšie sú grafy využitia CPU pre každý z TSDB počas benchmarku:

Úvodný snímok: VictoriaMetrics — zaťaženie CPU počas testu inkasovania pre jedinečnú metriky 400K.

Úvodný snímok: InfluxDB — zaťaženie CPU počas testu inkasovania pre jedinečnú metriky 400K.

Vyššie je screenshot: TimescaleDB — Zaťažovanie CPU pri teste vkladania pre jedinečnú metriku 400K.

VictoriaMetrics využíva všetky dostupné vCPUs, zatiaľ čo InfluxDB nedostatočne využíva ~2 z 16 vCPUs.

Timescale využíva len 3-4 z 16 vCPUs. Vysoké podiely iowait a system na grafe TimescaleDB naznačujú úzke miesto v subsystéme vstupu a výstupu (I/O). Pozrime sa na grafy využitia priepustnosti disku:

Vyššie je screenshot: VictoriaMetrics — Využitie priepustnosti disku pri teste vkladania pre jedinečné ukazovatele 400K.

Vyššie je screenshot: InfluxDB — Využitie priepustnosti disku pri teste vkladania pre jedinečné ukazovatele 400K.

Vyššie je screenshot: TimescaleDB — Využitie priepustnosti disku pri teste vkladania pre jedinečné ukazovatele 400K.

VictoriaMetrics zapisuje dáta rýchlosťou 20 Mbit/s s vrcholmi až 45 Mbit/s. Vrcholy zodpovedajú veľkým častým zlúčeninám v strome. LSM.

InfluxDB zapisuje dáta rýchlosťou 160 MB/s, zatiaľ čo 1 TB disk musí byť obmedzený priepustnosťou záznamu 120 MB/s.

TimescaleDB je obmedzená priepustnosťou záznamu 120 Mbit/s, avšak niekedy tento limit porušuje a dosahuje 220 Mbit/s v špičkách. Tieto špičky zodpovedajú poklesom nedostatočného zaťaženia procesora na predchádzajúcom grafe.

Pozrime sa na grafy využitia vstupu a výstupu (I/O):

Vyššie je screenshot: VictoriaMetrics — Využitie vstupu a výstupu pri teste vkladania pre 400K jedinečných metrík.

Vyššie je screenshot: InfluxDB — Využitie vstupu a výstupu pri teste vkladania pre 400K jedinečných metrík.

Vyššie je screenshot: TimescaleDB — Využitie vstupu a výstupu pri teste vkladania pre 400K jedinečných metrík.

Teraz je jasné, že TimescaleDB dosahuje limit vstupu a výstupu, a preto nemôže využiť zostávajúcich 12 vCPUs.

4M jedinečných časových radov

4M časové rady vyzerajú trochu provokujúco. Ale naši konkurenti tento test úspešne zvládajú. Výsledky benchmarku:

VictoriaMetrics: 2,2M bodov dát za sekundu; využitie operačnej pamäte: 6 GB; konečná veľkosť dát na disku: 3 GB.
InfluxDB: 330K bodov dát za sekundu; využitie operačnej pamäte: 20,5 GB; konečná veľkosť dát na disku: 18,4 GB.
TimescaleDB: 480K bodov dát za sekundu; použitie pamäte: 2,5 GB; konečná veľkosť dát na disku: 52 GB.

Výkon InfluxDB klesol z 1,2 milióna bodov dát za sekundu pre 400K časový rad na 330 tisíc bodov dát za sekundu pre 4M časový rad. Je to značná strata výkonu v porovnaní s inými konkurentmi. Pozrime sa na grafy využitia procesora, aby sme pochopili prvotnú príčinu tejto straty:

Vyššie je screenshot: VictoriaMetrics — Využitie CPU pri teste vloženia pre jedinečný časový rad 4M.

Vyššie je screenshot: InfluxDB — Využitie CPU pri teste vloženia pre jedinečný časový rad 4M.

Vyššie je screenshot: TimescaleDB — Využitie CPU pri teste vloženia pre jedinečný časový rad 4M.

VictoriaMetrics využíva takmer celú CPU kapacitu. Pokles na konci zodpovedá zostávajúcim zlučovaniam LSM po vložení všetkých dát.

InfluxDB využíva iba 8 z 16 vCPU, zatiaľ čo TimescaleDB využíva 4 z 16 vCPU. Čo majú ich grafy spoločné? Vysoký podiel iowait, čo opäť naznačuje úzke miesto vstupu a výstupu.

TimescaleDB má vysoký podiel systém. Predpokladáme, že vysoká kapacita viedla k mnohým systémovým volaniam alebo mnohým minor page faults.

Pozrime sa na grafy priepustnosti disku:

Vyššie je screenshot: VictoriaMetrics — Využitie šírky pásma disku pre vloženie 4M jedinečných metrik.

Vyššie je screenshot: InfluxDB — Využitie šírky pásma disku pre vloženie 4M jedinečných metrik.

Vyššie je screenshot: TimescaleDB — Využitie šírky pásma disku pre vloženie 4M jedinečných metrik.

VictoriaMetrics dosiahli limit 120 MB/s v maxime, zatiaľ čo priemerná rýchlosť zápisu bola 40 MB/s. Pravdepodobne počas maxima došlo k viacerým náročným zlučovaniam LSM.

InfluxDB opäť dosahuje priemernú priepustnosť zápisu 200 MB/s s maxím až 340 MB/s na disku s obmedzením zápisu 120 MB/s 🙂

TimescaleDB už nie je obmedzená diskom. Zdá sa, že je obmedzená niečím iným, súvisiacim s vysokým podielom systémovej zaťaženia CPU.

Pozrime sa na grafy využitia IO:

Vyššie je screenshot: VictoriaMetrics — Využitie vstupu a výstupu počas testu vloženia pre jedinečný časový rad 4M.

Vyššie je screenshot: InfluxDB — Využitie vstupu a výstupu počas testu vloženia pre jedinečný časový rad 4M.

Vyššie uvedený snímok: TimescaleDB – Využitie vstupu a výstupu počas testu vloženia pre jedinečné časové rady 4M.

Grafy využitia IO sa opakujú s grafmi využitia šírky pásma disku – InfluxDB je obmedzený IO, zatiaľ čo VictoriaMetrics a TimescaleDB majú rezervné zdroje vstupu a výstupu IO.

40M unikátne časové série

40M unikátne časové rady boli príliš veľké pre InfluxDB 🙁

Výsledky benchmarku:

VictoriaMetrics: 1,7M bodov údajov za sekundu; využitie operačnej pamäte: 29 GB; využitie diskového priestoru: 17 GB.
InfluxDB: nedokončil, pretože na to potreboval viac ako 60 GB operačnej pamäte.
TimescaleDB: 330K bodov údajov za sekundu, využitie operačnej pamäte: 2,5 GB; využitie diskového priestoru: 84GB.

TimescaleDB vykazuje mimoriadne nízke a stabilné využitie operačnej pamäte – 2,5 GB – čo je rovnaké ako pre jedinečné metriky 4M a 400K.

VictoriaMetrics sa pomaly zvyšovalo rýchlosťou 100 tisíc bodov údajov za sekundu, kým neboli spracované všetky 40M metrických názvov s etiketami. Potom dosiahlo stabilnú rýchlosť vloženia 1,5-2,0M bodov údajov za sekundu, takže konečný výsledok bol 1,7M bodov údajov za sekundu.

Grafy pre 40M unikátnych časových radov sú podobné grafom pre 4M unikátnych časových radov, takže ich preskočíme.

Zhrnutie

Súčasné TSDBs sú schopné spracovávať vklady pre milióny jedinečných časových radov na jednom serveri. V nasledujúcom článku preskúmame, ako dobre TSDBs vykonávajú dotazy na milióny jedinečných časových radov.
Nedostatočné zaťaženie procesora zvyčajne naznačuje úzke miesto v vstupoch a výstupoch. Okrem toho to môže naznačovať príliš hrubé zablokovanie, keď súčasne môže pracovať len niekoľko vlákien.
Úzke miesto v vstupoch a výstupoch skutočne existuje, najmä v úložiskách bez SSD, ako sú virtualizované blokové zariadenia cloudových poskytovateľov.
VictoriaMetrics poskytuje najlepšiu optimalizáciu pre pomalé úložiská s nízkou úrovňou vstupu a výstupu. Poskytuje najlepšiu rýchlosť a najlepšie kompresie.

Stiahnite si jednoserverový obraz VictoriaMetrics a vyskúšajte ho na svojich údajoch. Zodpovedajúci statický spustiteľný súbor je dostupný na GitHub.

Ďalšie informácie o VictoriaMetrics nájdete v tomto článku.

Aktualizácia: zverejnené článok porovnávajúci výkon vkladania VictoriaMetrics s InfluxDB s reprodukovateľnými výsledkami.

Aktualizácia #2: Prečítajte si tiež článok o vertikálnej škálovateľnosti VictoriaMetrics vs InfluxDB vs TimescaleDB.

Aktualizácia #3: VictoriaMetrics je teraz s otvoreným zdrojovým kódom!

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

Zdroj: habr.com