VictoriaMetrics, TimescaleDB a InfluxDB boli porovnané v na množine údajov s miliardou údajových bodov patriacich do 40 XNUMX jedinečných časových radov.
Pred pár rokmi bola éra Zabbixu. Každý holý kovový server mal iba niekoľko ukazovateľov - využitie procesora, využitie RAM, využitie disku a využitie siete. Týmto spôsobom sa metriky z tisícok serverov zmestia do 40 XNUMX jedinečných časových radov a Zabbix môže použiť MySQL ako backend pre údaje časových radov :)
Momentálne sám s predvolenými konfiguráciami poskytuje viac ako 500 metrík na priemernom hostiteľovi. Je ich veľa pre rôzne databázy, webové servery, hardvérové systémy atď. Všetky poskytujú množstvo užitočných metrík. Všetky začať nastavovať rôzne ukazovatele pre seba. Existuje Kubernetes s klastrami a modulmi, ktoré odhaľujú veľa metrík. Výsledkom je, že servery odhaľujú tisíce jedinečných metrík na hostiteľa. Jedinečný časový rad 40 XNUMX už teda nemá vysoký výkon. Stáva sa hlavným prúdom a mal by ho ľahko zvládnuť každý moderný TSDB na jednom serveri.
Aký je v súčasnosti veľký počet jedinečných časových radov? Pravdepodobne 400 4 alebo 40 milióny? alebo XNUMXm? Porovnajme moderné TSDB s týmito číslami.
Inštalácia benchmarku
je vynikajúci benchmarkingový nástroj pre TSDB. Umožňuje vám vygenerovať ľubovoľný počet metrík prejdením požadovaného počtu časových radov delených 10 - príznak (bývalý -scale-var). 10 je počet meraní (metrík) vygenerovaných na každom hostiteľovi alebo serveri. Nasledujúce súbory údajov boli vygenerované pomocou TSBS pre benchmark:
- 400 60 jedinečných časových radov, 3-sekundový interval medzi dátovými bodmi, dáta pokrývajú celé 1.7 dni, ~XNUMXB celkový počet dátových bodov.
- Jedinečný časový rad 4 miliónov, interval 600 sekúnd, údaje zahŕňajú celé 3 dni, celkový počet dátových bodov ~ 1.7 miliardy.
- 40 miliónov jedinečných časových radov, 1-hodinový interval, údaje pokrývajú celé 3 dni, celkový počet dátových bodov ~ 2.8 miliardy.
Klient a server bežali na vyhradených inštanciách v cloude Google. Tieto inštancie mali nasledujúce konfigurácie:
- vCPU: 16
- RAM: 60 GB
- Úložisko: Štandardný 1TB HDD. Poskytuje priepustnosť čítania/zápisu 120 Mb/s, 750 operácií čítania za sekundu a 1,5 XNUMX zápisov za sekundu.
TSDB boli extrahované z oficiálnych obrazov dockerov a spustené v dockeroch 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. Podrobnosti nájdete v ):
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 prevzatá z súbor):
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=100Načítač údajov bol spustený so 16 paralelnými vláknami.
Tento článok obsahuje iba výsledky pre porovnávacie hodnoty vkladania. Výsledky selektívneho benchmarku budú uverejnené v samostatnom článku.
400 XNUMX jedinečný časový rad
Začnime jednoduchými prvkami - 400K. Výsledky porovnávania:
- VictoriaMetrics: 2,6 milióna dátových bodov za sekundu; využitie RAM: 3 GB; konečná veľkosť dát na disku: 965 MB
- InfluxDB: 1.2 milióna dátových bodov za sekundu; Využitie RAM: 8.5 GB; konečná veľkosť dát na disku: 1.6 GB
- Časový rozsah: 849 2,5 dátových bodov za sekundu; Využitie RAM: 50 GB; konečná veľkosť dát na disku: XNUMX GB
Ako môžete vidieť z výsledkov vyššie, VictoriaMetrics vyhráva vo výkone vkladania a kompresnom pomere. Časová os víťazí v používaní RAM, ale využíva veľa miesta na disku – 29 bajtov na dátový bod.
Nižšie sú uvedené grafy využitia CPU pre každú z TSDB počas benchmarku:
Vyššie je snímka obrazovky: VictoriaMetrics – zaťaženie procesora počas testu vkladania pre jedinečnú metriku 400 kB.
Vyššie je snímka obrazovky: InfluxDB – zaťaženie procesora počas testu vkladania pre jedinečnú metriku 400 kB.
Vyššie je snímka obrazovky: TimescaleDB – zaťaženie procesora počas testu vkladania pre jedinečnú metriku 400 kB.
VictoriaMetrics používa všetky dostupné vCPU, zatiaľ čo InfluxDB nedostatočne využíva ~ 2 zo 16 vCPU.
Časová mierka používa iba 3-4 zo 16 vCPU. Vysoké podiely iowait a systému v grafe časovej mierky TimescaleDB naznačujú prekážku vo vstupno/výstupnom (I/O) subsystéme. Pozrime sa na grafy využitia šírky pásma disku:
Vyššie je snímka obrazovky: VictoriaMetrics – využitie šírky pásma disku pri teste vloženia pre jedinečné metriky 400 kB.
Vyššie je snímka obrazovky: InfluxDB – využitie šírky pásma disku pri teste vloženia pre jedinečné metriky 400 kB.
Vyššie je snímka obrazovky: TimescaleDB – využitie šírky pásma disku pri teste vloženia pre jedinečné metriky 400 kB.
VictoriaMetrics zaznamenáva dáta rýchlosťou 20 Mbps so špičkami až 45 Mbps. Vrcholy zodpovedajú veľkým čiastočným zlúčeniam v strome .
InfluxDB zapisuje dáta rýchlosťou 160 MB/s, zatiaľ čo 1 TB disk priepustnosť zápisu 120 MB/s.
TimescaleDB je obmedzená na priepustnosť zápisu 120 Mbps, no niekedy tento limit prelomí a v špičkových hodnotách dosiahne 220 Mbps. Tieto vrcholy zodpovedajú údoliam nedostatočného využitia CPU v predchádzajúcom grafe.
Pozrime sa na grafy využitia vstupu/výstupu (I/O):
Vyššie je snímka obrazovky: VictoriaMetrics – Vloženie testovacieho I/O využitia pre 400 XNUMX jedinečných metrík.
Vyššie je snímka obrazovky: InfluxDB – Vloženie testovacieho využitia I/O pre 400 XNUMX jedinečných metrík.
Vyššie je snímka obrazovky: TimescaleDB – Vloženie testovacieho využitia I/O pre 400 XNUMX jedinečných metrík.
Teraz je jasné, že TimescaleDB dosahuje svoj I/O limit, takže nemôže použiť zvyšných 12 vCPU.
4M jedinečný časový rad
4M časové rady vyzerajú trochu náročne. Ale naši konkurenti úspešne absolvujú túto skúšku. Výsledky porovnávania:
- VictoriaMetrics: 2,2 milióna dátových bodov za sekundu; využitie RAM: 6 GB; konečná veľkosť dát na disku: 3 GB.
- InfluxDB: 330 20,5 dátových bodov za sekundu; Využitie RAM: 18,4 GB; konečná veľkosť dát na disku: XNUMX GB.
- TimescaleDB: 480 2,5 dátových bodov za sekundu; Využitie RAM: 52 GB; konečná veľkosť dát na disku: XNUMX GB.
Výkon InfluxDB klesol z 1,2 milióna dátových bodov za sekundu pre 400 330 časových radov na 4 XNUMX dátových bodov za sekundu pre XNUMX milióny časových radov. V porovnaní s ostatnými konkurentmi ide o výraznú stratu výkonu. Pozrime sa na grafy využitia procesora, aby sme pochopili hlavnú príčinu tejto straty:
Vyššie je snímka obrazovky: VictoriaMetrics – využitie procesora počas testu vkladania pre jedinečný časový rad 4 miliónov.
Vyššie je snímka obrazovky: InfluxDB – využitie procesora počas testu vloženia pre jedinečné časové rady 4 miliónov.
Vyššie je snímka obrazovky: TimescaleDB – využitie procesora počas testu vkladania pre jedinečný časový rad 4 miliónov.
VictoriaMetrics využíva takmer všetok výkon procesorovej jednotky (CPU). Pokles na konci zodpovedá zostávajúcim zlúčeniam LSM po vložení všetkých údajov.
InfluxDB používa iba 8 zo 16 vCPU, zatiaľ čo TimsecaleDB používa 4 zo 16 vCPU. Čo majú spoločné ich grafy? Vysoký podiel iowait, čo opäť naznačuje I/O úzke miesto.
TimescaleDB má vysoký podiel system. Predpokladáme, že vysoký výkon viedol k mnohým systémovým volaniam alebo mnohým .
Pozrime sa na grafy priepustnosti disku:
Vyššie je snímka obrazovky: VictoriaMetrics – Použitie šírky pásma disku na vloženie 4 miliónov jedinečných metrík.
Vyššie je snímka obrazovky: InfluxDB – Použitie šírky pásma disku na vloženie 4 miliónov jedinečných metrík.
Vyššie je snímka obrazovky: TimescaleDB – Použitie šírky pásma disku na vloženie 4 miliónov jedinečných metrík.
VictoriaMetrics dosiahla v špičke hranicu 120 MB/s, pričom priemerná rýchlosť zápisu bola 40 MB/s. Je pravdepodobné, že počas vrcholu sa uskutočnilo niekoľko ťažkých fúzií LSM.
InfluxDB opäť vyžmýka priemernú priepustnosť zápisu 200 MB/s so špičkami až 340 MB/s na disku s limitom zápisu 120 MB/s :)
TimescaleDB už nie je diskovo obmedzená. Zdá sa, že ho obmedzuje niečo iné, čo súvisí s vysokým podielom системной zaťaženie procesora.
Pozrime sa na grafy využitia IO:
Vyššie je snímka obrazovky: VictoriaMetrics – Používanie I/O počas testu vkladania pre jedinečný časový rad 4 miliónov.
Vyššie je snímka obrazovky: InfluxDB – Používanie I/O počas testu vkladania pre jedinečný časový rad 4 miliónov.
Vyššie je snímka obrazovky: TimescaleDB – využitie I/O počas testu vkladania pre jedinečné časové rady 4 miliónov.
Vzory využitia IO odzrkadľujú modely šírky pásma disku – InfluxDB je IO obmedzený, zatiaľ čo VictoriaMetrics a TimescaleDB majú náhradné IO zdroje.
40 miliónov jedinečných časových radov
40 miliónov jedinečných časových radov bolo pre InfluxDB príliš veľké :)
Výsledky porovnávania:
- VictoriaMetrics: 1,7 milióna dátových bodov za sekundu; využitie RAM: 29 GB; Využitie miesta na disku: 17 GB.
- InfluxDB: Nedokončené, pretože to vyžadovalo viac ako 60 GB RAM.
- TimescaleDB: 330 2,5 dátových bodov za sekundu, využitie RAM: 84 GB; Využitie miesta na disku: XNUMX GB.
TimescaleDB ukazuje výnimočne nízke a stabilné využitie pamäte RAM pri 2,5 GB – rovnako ako v prípade jedinečných metrík 4M a 400K.
VictoriaMetrics sa pomaly zvyšovala rýchlosťou 100 40 dátových bodov za sekundu, kým sa nespracovalo všetkých 1,5 miliónov označených názvov metrík. Potom dosiahol trvalú rýchlosť vkladania 2,0 až 1,7 milióna dátových bodov za sekundu, takže konečný výsledok bol XNUMX milióna dátových bodov za sekundu.
Grafy pre 40 miliónov unikátnych časových radov sú podobné grafom pre 4 miliónové unikátne časové rady, takže ich preskočme.
Závery
- Moderné TSDB sú schopné spracovať vložky pre milióny jedinečných časových radov na jednom serveri. V ďalšom článku otestujeme, ako dobre TSDB vykonáva výber v miliónoch jedinečných časových radov.
- Nedostatočné využitie CPU zvyčajne indikuje I/O úzke miesto. Môže to tiež naznačovať, že blokovanie je príliš hrubé a súčasne môže bežať len niekoľko vlákien.
- Prekážka I/O existuje, najmä v úložiskách iných ako SSD, ako sú virtualizované blokové zariadenia poskytovateľov cloudu.
- VictoriaMetrics poskytuje najlepšiu optimalizáciu pre pomalé, nízke I/O úložisko. Poskytuje najlepšiu rýchlosť a najlepší kompresný pomer.
na stiahnutie a skúste to na svojich dátach. Príslušný statický binárny súbor je dostupný na .
Prečítajte si viac o VictoriaMetrics v tomto .
Aktualizácia: zverejnená s reprodukovateľnými výsledkami.
Aktualizácia č. 2: Prečítajte si tiež .
Aktualizácia č. 3: !
Telegramový rozhovor:
Zdroj: hab.com