VictoriaMetrics, TimescaleDB a InfluxDB byly porovnány v přes datovou sadu s miliardou datových bodů patřících do 40 XNUMX jedinečných časových řad.
Před pár lety byla éra Zabbix. Každý server z holého kovu neměl více než několik metrik – využití procesoru, využití RAM, využití disku a využití sítě. Metriky z tisíců serverů se tak vejdou do 40 tisíc unikátních časových řad a Zabbix může použít MySQL jako backend pro data časových řad 🙂
Aktuálně jeden s výchozí konfigurací poskytuje více než 500 metrik na průměrném hostiteli. Je jich mnoho pro různé databáze, webové servery, hardwarové systémy atd. Všechny poskytují mnoho užitečných metrik. Všechno začnou na sobě vykazovat různé ukazatele. Existuje Kubernetes s clustery a pody, které odhalují spoustu metrik. To způsobí, že servery vystaví tisíce jedinečných metrik na hostitele. Jedinečná časová řada 40 XNUMX již tedy není příliš výkonná. Stává se mainstreamem, který by měl snadno zvládnout každý moderní TSDB na jediném serveru.
Jaký je v současnosti velký počet unikátních časových řad? Pravděpodobně 400K nebo 4M? nebo 40m? Srovnejme moderní TSDB s těmito čísly.
Benchmark instalace
je skvělý nástroj pro benchmarking pro TSDB. Umožňuje generovat libovolný počet metrik předáním požadovaného počtu časových řad děleno 10 - příznak (bývalý -scale-var). 10 je počet měření (metriky) generovaných na každém hostiteli, serveru. Následující datové sady byly vytvořeny pomocí TSBS pro srovnávání:
- Jedinečná časová řada 400 60, interval mezi datovými body 3 sekund, data pokrývají celé 1.7 dny, celkový počet datových bodů ~ XNUMX miliardy.
- 4M unikátní časová řada, 600 sekundový interval, data pokrývají celé 3 dny, ~1.7B celkových datových bodů.
- Jedinečná časová řada 40 milionů, interval 1 hodiny, data pokrývají celé 3 dny, celkový počet datových bodů ~ 2.8 miliardy.
Klient a server běželi na vyhrazených instancích v cloudu Google. Tyto instance měly následující konfigurace:
- vCPU: 16
- RAM: 60 GB
- Úložiště: Standardní pevný disk 1 TB. Poskytuje propustnost čtení/zápisu 120 Mb/s, 750 čtení za sekundu a 1,5 XNUMX zápisů za sekundu.
Soubory TSDB byly staženy z oficiálních obrazů dockeru a běží na dockeru s následujícími konfiguracemi:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Hodnoty InfluxDB (-e) jsou vyžadovány pro podporu vysoké mohutnosti. Podrobnosti viz ):
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 (konfigurace byla převzata z soubor):
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=100Zavaděč dat byl spuštěn s 16 paralelními vlákny.
Tento článek obsahuje pouze výsledky pro srovnávací testy vložení. Výsledky výběrového benchmarku budou zveřejněny v samostatném článku.
400K unikátní časová řada
Začněme jednoduchými prvky – 400K. Srovnávací výsledky:
- VictoriaMetrics: 2,6 milionů datových bodů za sekundu; Využití RAM: 3 GB; konečná velikost dat na disku: 965 MB
- InfluxDB: 1.2 milionu datových bodů za sekundu; Využití RAM: 8.5 GB; konečná velikost dat na disku: 1.6 GB
- Časová osa: 849 tisíc datových bodů za sekundu; Využití RAM: 2,5 GB; konečná velikost dat na disku: 50 GB
Jak můžete vidět z výsledků výše, VictoriaMetrics vítězí ve výkonu břitové destičky a kompresním poměru. Časová osa vítězí ve využití RAM, ale využívá hodně místa na disku – 29 bajtů na datový bod.
Níže jsou uvedeny grafy využití CPU pro každou z TSDB během benchmarku:
Snímek obrazovky nahoře: VictoriaMetrics – vložte testovací využití procesoru pro 400K unikátní metriku.
Snímek obrazovky nahoře: InfluxDB – využití CPU při testu vložení pro 400 kB unikátní metriky.
Snímek obrazovky nahoře: TimescaleDB – využití CPU při testu vložení pro 400 kB unikátní metriky.
VictoriaMetrics používá všechny dostupné vCPU, zatímco InfluxDB nedostatečně využívá ~2 z 16 vCPU.
Timescale používá pouze 3-4 z 16 vCPU. Vysoké podíly iowait a systému v grafu časové škály TimescaleDB naznačují úzké místo v subsystému vstup/výstup (I/O). Podívejme se na grafy využití šířky pásma disku:
Snímek obrazovky nahoře: VictoriaMetrics – Využití šířky pásma vložení testovacího disku pro 400 XNUMX jedinečných metrik.
Snímek obrazovky nahoře: InfluxDB – Vložit využití šířky pásma testovacího disku pro 400 XNUMX jedinečných metrik.
Snímek obrazovky nahoře: TimescaleDB – Vložit využití šířky pásma testovacího disku pro 400 XNUMX jedinečných metrik.
VictoriaMetrics zaznamenává data rychlostí 20 Mbps se špičkami až 45 Mbps. Vrcholy odpovídají velkým částečným sloučením ve stromu .
InfluxDB zapisuje data rychlostí 160 MB/s, zatímco 1TB disk šířka pásma zápisu 120 MB/s.
TimescaleDB je omezena na propustnost zápisu 120 Mb/s, ale někdy tento limit prolomí a dosáhne vrcholu na 220 Mb/s. Tyto vrcholy odpovídají propadům nedostatečného využití v předchozím grafu.
Podívejme se na grafy využití I/O:
Snímek obrazovky nahoře: VictoriaMetrics – Vložte testovací I/O využití pro 400 XNUMX jedinečných metrik.
Snímek obrazovky nahoře: InfluxDB – Vložte testovací I/O využití pro 400 XNUMX unikátních metrik.
Snímek obrazovky nahoře: TimescaleDB – Vložte testovací I/O využití pro 400 XNUMX jedinečných metrik.
Nyní je jasné, že TimescaleDB naráží na I/O limit, takže nemůže využít zbývajících 12 vCPU.
4M unikátní časová řada
4M časové řady vypadají trochu vzdorovitě. Naši soutěžící ale tuto zkoušku úspěšně skládají. Srovnávací výsledky:
- VictoriaMetrics: 2,2 milionu datových bodů za sekundu; Využití RAM: 6 GB; konečná velikost dat na disku: 3 GB.
- InfluxDB: 330 tisíc datových bodů za sekundu; Využití RAM: 20,5 GB; konečná velikost dat na disku: 18,4 GB.
- TimescaleDB: 480 2,5 datových bodů za sekundu; Využití RAM: 52 GB; konečná velikost dat na disku: XNUMX GB.
Výkon InfluxDB klesl z 1,2 milionu datových bodů za sekundu pro časovou řadu 400 tisíc na 330 tisíc datových bodů za sekundu pro časovou řadu 4 milionů. To je ve srovnání s ostatními konkurenty výrazná výkonnostní ztráta. Podívejme se na grafy využití CPU, abychom pochopili hlavní příčinu této ztráty:
Snímek obrazovky nahoře: VictoriaMetrics – Vložte testovací využití CPU pro unikátní 4M časové řady.
Snímek obrazovky nahoře: InfluxDB – Vložte testovací využití CPU pro 4M Unique Time Series.
Snímek obrazovky nahoře: TimescaleDB - Vložte testovací využití CPU pro unikátní 4M časové řady.
VictoriaMetrics využívá téměř veškerý výpočetní výkon (CPU). Pokles na konci odpovídá zbývajícím sloučením LSM po vložení všech dat.
InfluxDB používá pouze 8 z 16 vCPU, zatímco TimsecaleDB používá 4 z 16 vCPU. Co mají jejich grafy společného? vysoký podíl iowait, což opět indikuje I/O úzké místo.
TimescaleDB má vysoký podíl system. Věříme, že vysoký výkon vedl k mnoha systémovým voláním nebo k mnoha .
Podívejme se na grafy šířky pásma disku:
Snímek obrazovky nahoře: VictoriaMetrics – využití šířky pásma disku k vložení 4 milionů unikátních metrik.
Snímek obrazovky nahoře: InfluxDB – využití šířky pásma disku pro vložení unikátních metrik 4M.
Snímek obrazovky nahoře: TimescaleDB – využití šířky pásma disku pro vložení 4 milionů unikátních metrik.
VictoriaMetrics dosáhl vrcholu na 120 MB/s, zatímco průměrná rychlost zápisu byla 40 MB/s. Během špičky bylo pravděpodobně provedeno několik těžkých sloučení LSM.
InfluxDB opět ždímá průměrnou propustnost zápisu 200 MB/s se špičkami až 340 MB/s na disku s limitem zápisu 120 MB/s :)
TimescaleDB již není diskově omezená. Vypadá to, že je limitován něčím jiným, co souvisí s vysokým podílem системной zatížení CPU.
Podívejme se na grafy využití IO:
Snímek obrazovky nahoře: VictoriaMetrics – využití I/O během vkládacího testu pro 4M unikátní časové řady.
Snímek obrazovky nahoře: InfluxDB – využití I/O během testu vložení pro 4M jedinečnou časovou řadu.
Snímek obrazovky nahoře: TimescaleDB – využití I/O během testu vložení pro 4M jedinečnou časovou řadu.
Grafy využití IO odrážejí grafy využití šířky pásma disku – InfluxDB je IO omezený, zatímco VictoriaMetrics a TimescaleDB mají náhradní IO IO zdroje.
40M unikátní časová řada
40M unikátní časová řada byla pro InfluxDB příliš velká 🙁
Srovnávací výsledky:
- VictoriaMetrics: 1,7 milionu datových bodů za sekundu; Využití RAM: 29 GB; využití místa na disku: 17 GB.
- InfluxDB: Nedokončeno, protože to vyžadovalo více než 60 GB RAM.
- TimescaleDB: 330K datových bodů za sekundu, využití RAM: 2,5 GB; využití místa na disku: 84 GB.
TimescaleDB ukazuje výjimečně nízké a stabilní využití RAM 2,5 GB, stejně jako jedinečné metriky 4M a 400K.
VictoriaMetrics se pomalu zvyšoval rychlostí 100 40 datových bodů za sekundu, dokud nebylo zpracováno všech 1,5 milionů označených názvů metrik. Poté dosáhl ustálené rychlosti vkládání 2,0-1,7 milionu datových bodů za sekundu, takže konečný výsledek byl XNUMX milionu datových bodů za sekundu.
Grafy pro 40M unikátní časové řady jsou podobné jako pro 4M jedinečné časové řady, takže je přeskočme.
Závěry
- Moderní TSDB jsou schopny zpracovávat inserty pro miliony unikátních časových řad na jediném serveru. V příštím článku vyzkoušíme, jak dobře TSDB provádějí selekci v milionech unikátních časových řad.
- Nedostatečné využití procesoru obvykle ukazuje na úzké místo I/O. Navíc to může naznačovat příliš hrubé blokování, kdy může pracovat pouze několik vláken současně.
- Úzké místo I/O existuje, zejména v úložištích bez SSD, jako jsou virtualizovaná bloková zařízení poskytovatelů cloudu.
- VictoriaMetrics poskytuje nejlepší optimalizaci pro pomalé, nízké I/O úložiště. Poskytuje nejlepší rychlost a nejlepší kompresní poměr.
Stažení a zkuste to na svých datech. Odpovídající statický binární soubor je k dispozici na adrese .
Přečtěte si více o VictoriaMetrics v tomto .
Aktualizace: zveřejněno s reprodukovatelnými výsledky.
Aktualizace #2: Přečtěte si také .
Aktualizace č. 3: !
Telegramový chat:
Zdroj: www.habr.com