VictoriaMetrics, TimescaleDB und InfluxDB wurden verglichen in einem Datensatz mit einer Milliarde Datenpunkten, die 40.000 einzigartigen Zeitreihen gehören.
Vor einigen Jahren gab es die Ära von Zabbix. Jeder Bare Metal-Server hatte nicht mehr als einige Kennzahlen – CPU-Auslastung, RAM-Nutzung, Festplattennutzung und Netzwerknutzung. Somit konnten die Metriken von tausenden Servern in 40.000 einzigartigen Zeitreihen Platz finden, und Zabbix konnte MySQL als Backend für diese Zeitreihen verwenden 🙂
Heute liefert ein mit den Standardkonfigurationen über 500 Metriken auf einem durchschnittlichen Host. Es gibt zahlreiche für verschiedene Datenbanken, Webserver, Hardware-Systeme usw. Alle bieten viele nützliche Kennzahlen. Immer beginnen, verschiedene Kennzahlen zu erfassen. Es gibt Kubernetes mit Clustern und Pods, die zahlreiche Metriken entfalten. Das führt dazu, dass Server Tausende von einzigartigen Metriken auf dem Host bereitstellen. So wird eine einzigartige Zeitreihe von 40K nicht mehr als hohe Leistung angesehen. Sie wird zum Mainstream, der von jeder modernen TSDB auf einem Server problemlos verarbeitet werden sollte.
Was bedeutet eine große Anzahl einzigartiger Zeitreihen derzeit? Vielleicht 400K oder 4M? Oder 40M? Lassen Sie uns moderne TSDBs mit diesen Zahlen vergleichen.
Benchmark-Installation
ist ein hervorragendes Benchmark-Tool für TSDBs. Es ermöglicht die Generierung einer beliebigen Anzahl von Metriken, indem die erforderliche Anzahl von Zeitreihen über 10 verteilt wird — Flagge (ehemals -scale-var). 10 ist die Anzahl der Messungen (Metriken), die auf jedem Host, Server generiert werden. Die folgenden Datensätze wurden mit TSBS für das Benchmarking erstellt:
- 400K einzigartige Zeitreihe, 60 Sekunden Intervall zwischen den Datenpunkten, die Daten decken insgesamt 3 Tage ab, ~1,7B Gesamtanzahl der Datenpunkte.
- 4M einzigartiger Zeitreihe, Intervall 600 Sekunden, Daten decken volle 3 Tage ab, ~1,7B Gesamtzahl der Datenpunkte.
- 40M einzigartiger Zeitreihe, Intervall 1 Stunde, Daten decken volle 3 Tage ab, ~2,8B Gesamtzahl der Datenpunkte.
Client und Server wurden auf dedizierten Instanzen gestartet. in der Google Cloud. Diese Instanzen hatten folgende Konfigurationen:
- vCPUs: 16
- RAM: 60 GB
- Speicher: Standardfestplatte mit 1 TB. Sie bietet eine Lese-/Schreibbandbreite von 120 Mbit/s, 750 Lesevorgänge pro Sekunde und 1,5K Schreibvorgänge pro Sekunde.
TSDBs wurden aus offiziellen Docker-Images extrahiert und in Docker mit folgenden Konfigurationen gestartet:
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metricsWerte InfluxDB (- e erforderlich, um hohe Leistung zu unterstützen. Einzelheiten siehe in ):
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 influxdbTimescaleDB (Konfiguration wurde aus Datei übernommen):
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=100Der Datenladeprozess wurde mit 16 parallelen Threads gestartet.
Dieser Artikel enthält nur die Ergebnisse für die Einsiehverhältnisse. Die Ergebnisse des stichprobenartigen Benchmarkings werden in einem separaten Artikel veröffentlicht.
400K einzigartige Zeitreihen
Lassen Sie uns mit einfachen Elementen beginnen – 400K. Benchmark-Ergebnisse:
- VictoriaMetrics: 2,6 Millionen Datenpunkte pro Sekunde; Speicherverbrauch: 3 GB; endgültige Datengröße auf der Festplatte: 965 MB
- InfluxDB: 1,2 Millionen Datenpunkte pro Sekunde; Speicherverbrauch: 8,5 GB; endgültige Datengröße auf der Festplatte: 1,6 GB
- Timescale: 849K Datenpunkte pro Sekunde; Speicherverbrauch: 2,5 GB; endgültige Datengröße auf der Festplatte: 50 GB
Wie aus den obigen Ergebnissen ersichtlich ist, bietet VictoriaMetrics eine überlegene Einfügegeschwindigkeit und eine höhere Kompressionsrate. Die Zeitreihe benötigt zwar mehr RAM, verbraucht jedoch viel Speicherplatz – 29 Byte pro Datenpunkt.
Im Folgenden sind die CPU-Nutzungsdiagramme (CPU) für jedes der TSDBs während des Benchmarks dargestellt:
Oben ein Screenshot: VictoriaMetrics – CPU-Auslastung beim Einfügetest für eine einzigartige Metrik von 400K.
Oben ein Screenshot: InfluxDB – CPU-Auslastung beim Einfügetest für eine einzigartige Metrik von 400K.
Oben ein Screenshot: TimescaleDB – CPU-Auslastung beim Einfügetest für eine einzigartige Metrik von 400K.
VictoriaMetrics nutzt alle verfügbaren vCPUs, während InfluxDB etwa 2 von 16 vCPUs nicht ausreichend verwendet.
Timescale nutzt nur 3-4 von 16 vCPUs. Hohe Anteile von iowait und system im Diagramm von TimescaleDB deuten auf einen Engpass in der Eingabe-/Ausgabesubsystem hin. Schauen wir uns die Diagramme zur Nutzung der Datenträgerbandbreite an:
Oben ein Screenshot: VictoriaMetrics – Nutzung der Datenträgerbandbreite beim Einfügetest für einzigartige Metriken von 400K.
Oben ist ein Screenshot: InfluxDB – Diskdurchsatz während des Einfügetests für 400K einzigartige Metriken.
Oben ist ein Screenshot: TimescaleDB – Diskdurchsatz während des Einfügetests für 400K einzigartige Metriken.
VictoriaMetrics zeichnet Daten mit 20 Mbit/s auf, mit Spitzen von bis zu 45 Mbit/s. Diese Spitzen entsprechen größeren teilweisen Fusionen im Baum. .
InfluxDB schreibt Daten mit 160 MB/s, während eine 1 TB Festplatte Schreibdurchsatz von 120 MB/s begrenzt sein sollte.
TimescaleDB hat einen Schreibdurchsatz von 120 Mbit/s, überschreitet jedoch manchmal dieses Limit und erreicht Spitzenwerte von bis zu 220 Mbit/s. Diese Spitzen entsprechen den Abstürzen durch unzureichende CPU-Auslastung im vorherigen Diagramm.
Sehen wir uns die I/O-Diagramme an:
Oben ist ein Screenshot: VictoriaMetrics – I/O-Nutzung während des Einfügetests für 400K einzigartige Metriken.
Oben ist ein Screenshot: InfluxDB – I/O-Nutzung während des Einfügetests für 400K einzigartige Metriken.
Oben ist ein Screenshot: TimescaleDB – I/O-Nutzung während des Einfügetests für 400K einzigartige Metriken.
Es ist jetzt klar, dass TimescaleDB die I/O-Grenze erreicht, weshalb es die verbleibenden 12 vCPUs nicht nutzen kann.
4 Mio. einzigartige Zeitreihen
4 Mio. Zeitreihen erscheinen etwas herausfordernd. Aber unsere Wettbewerber bestehen diese Prüfung mit Erfolg. Benchmark-Ergebnisse:
- VictoriaMetrics: 2,2 Mio. Datenpunkte pro Sekunde; Arbeitsspeicherverbrauch: 6 GB; endgültige Datengröße auf der Festplatte: 3 GB.
- InfluxDB: 330.000 Datenpunkte pro Sekunde; Arbeitsspeicherverbrauch: 20,5 GB; endgültige Datengröße auf der Festplatte: 18,4 GB.
- TimescaleDB: 480.000 Datenpunkte pro Sekunde; Arbeitsspeicherverbrauch: 2,5 GB; endgültige Datengröße auf der Festplatte: 52 GB.
Die Leistung von InfluxDB fiel von 1,2 Mio. Datenpunkten pro Sekunde für 400.000 Zeitreihen auf 330.000 Datenpunkte pro Sekunde für 4 Mio. Zeitreihen. Dies ist ein erheblicher Leistungsabfall im Vergleich zu anderen Wettbewerbern. Lassen Sie uns die CPU-Nutzungsdiagramme betrachten, um die Ursache dieses Rückgangs zu verstehen:
Oben Screenshot: VictoriaMetrics – CPU-Auslastung beim Einfügetest für die einzigartige Zeitreihe von 4 Mio.
Oben ist ein Screenshot: InfluxDB — CPU-Nutzung bei einem Einfügetest für eine einzigartige Zeitreihe von 4 Millionen.
Oben ist ein Screenshot: TimescaleDB — CPU-Nutzung bei einem Einfügetest für eine einzigartige Zeitreihe von 4 Millionen.
VictoriaMetrics nutzt nahezu die gesamte CPU-Leistung. Der Rückgang am Ende entspricht den verbleibenden LSM-Mergen nach dem Einfügen aller Daten.
InfluxDB verwendet nur 8 von 16 vCPUs, während TimescaleDB 4 von 16 vCPUs nutzt. Was haben ihre Grafiken gemeinsam? Ein hoher Anteil iowait, was erneut auf ein Eingabe- und Ausgabeengpass hinweist.
TimescaleDB hat einen hohen Anteil System. Wir vermuten, dass die hohe Leistung zu vielen Systemaufrufen oder zu vielen .
Schauen wir uns die Grafiken der Datentransferrate an:
Oben ist ein Screenshot: VictoriaMetrics — Nutzung der Datentransferrate für das Einfügen von 4 Millionen einzigartigen Metriken.
Oben ist ein Screenshot: InfluxDB — Nutzung der Datentransferrate für das Einfügen von 4 Millionen einzigartigen Metriken.
Oben ist ein Screenshot: TimescaleDB — Nutzung der Datentransferrate für das Einfügen von 4 Millionen einzigartigen Metriken.
VictoriaMetrics erreichte einen Spitzenwert von 120 MB/s, während die durchschnittliche Schreibgeschwindigkeit bei 40 MB/s lag. Wahrscheinlich wurden während des Spitzenzeitraums mehrere intensive LSM-Merges durchgeführt.
InfluxDB erzielt erneut eine durchschnittliche Schreibdurchsatzrate von 200 MB/s mit Spitzenwerten von bis zu 340 MB/s auf einer Festplatte mit einer Schreibgrenze von 120 MB/s 🙂
TimescaleDB ist nicht mehr durch die Festplatte limitiert. Es scheint, dass es durch etwas anderes mit einer hohen Auslastung begrenzt ist. systemseitig CPU-Auslastung.
Lassen Sie uns die IO-Nutzungsdiagramme betrachten:
Oben der Screenshot: VictoriaMetrics – IO-Nutzung während des Insert-Tests für eine einzigartige Zeitreihe von 4M.
Oben der Screenshot: InfluxDB – IO-Nutzung während des Insert-Tests für eine einzigartige Zeitreihe von 4M.
Oben der Screenshot: TimescaleDB – IO-Nutzung während des Insert-Tests für eine einzigartige Zeitreihe von 4M.
Die IO-Nutzungsgrafiken spiegeln die Grafiken der Festplattenbandbreitenauslastung wider – InfluxDB ist durch IO limitiert, während VictoriaMetrics und TimescaleDB über IO-Ressourcen verfügen.
40M einzigartige Zeitserien
40M einzigartige Zeitreihen waren zu groß für InfluxDB 🙁
Benchmark-Ergebnisse:
- VictoriaMetrics: 1,7 Millionen Datenpunkte pro Sekunde; RAM-Nutzung: 29 GB; Speicherplatznutzung: 17 GB.
- InfluxDB: nicht abgeschlossen, da mehr als 60 GB RAM erforderlich waren.
- TimescaleDB: 330.000 Datenpunkte pro Sekunde, RAM-Nutzung: 2,5 GB; Speicherplatznutzung: 84 GB.
TimescaleDB zeigt eine außerordentlich niedrige und stabile RAM-Nutzung – 2,5 GB – das gleiche wie für die einzigartigen Metriken von 4M und 400K.
VictoriaMetrics steigerten sich langsam mit einer Rate von 100.000 Datenpunkten pro Sekunde, bis alle 40 Millionen Metrik-Namen mit Labels verarbeitet waren. Danach erreichte es eine stetige Einfügungsrate von 1,5-2,0 Millionen Datenpunkten pro Sekunde, sodass das Endergebnis 1,7 Millionen Datenpunkte pro Sekunde betrug.
Die Grafiken für 40 Millionen einzigartige Zeitreihen sind vergleichbar mit den Grafiken für 4 Millionen einzigartige Zeitreihen, daher lassen wir diese aus.
Fazit
- Moderne TSDBs sind in der Lage, Einfügungen für Millionen von einzigartigen Zeitreihen auf einem einzigen Server zu verarbeiten. Im nächsten Artikel werden wir untersuchen, wie gut TSDBs Abfragen für Millionen von einzigartigen Zeitreihen ausführen.
- Eine unzureichende CPU-Auslastung weist oft auf einen Engpass bei der Ein- und Ausgabe hin. Außerdem kann dies auf eine zu grobe Sperrung hinweisen, bei der gleichzeitig nur wenige Threads arbeiten können.
- Engpässe bei der Ein- und Ausgabe sind insbesondere in Speichersystemen ohne SSDs zu beobachten, wie bei virtualisierten Blockgeräten von Cloud-Anbietern.
- VictoriaMetrics bietet die beste Optimierung für langsame Speicher mit niedriger Ein- und Ausgabe. Es gewährleistet die höchste Geschwindigkeit und die beste Kompression.
Laden Sie herunter und testen Sie es mit Ihren Daten. Die entsprechende statische Binärdatei ist verfügbar unter .
Lesen Sie mehr über VictoriaMetrics in diesem .
Update: veröffentlicht mit reproduzierbaren Ergebnissen.
Update #2: Lesen Sie auch .
Update #3: !
Telegram-Chat:
Quelle: habr.com
