VictoriaMetrics, TimescaleDB und InfluxDB wurden in einer Datenmenge mit einer Milliarde Datenpunkten, die 40.000 einzigartigen Zeitreihen zugeordnet sind, verglichen.
Vor einigen Jahren war Zabbix die Norm. Jeder Bare-Metal-Server hatte nicht mehr als einige Kennzahlen – CPU-Auslastung, Arbeitsspeicherauslastung, Festplattenspeicher und Netzwerktraffic. So konnten die Metriken von tausenden von Servern in 40.000 einzigartigen Zeitreihen untergebracht werden, und Zabbix konnte MySQL als Backend für die Zeitreihendaten verwenden 🙂
Heute stellt ein mit den Standardkonfigurationen mehr als 500 Metriken auf einem durchschnittlichen Host bereit. Es gibt viele für verschiedene Datenbanken, Webserver, Hardware-Systeme usw. Alle bieten eine Vielzahl nützlicher Kennzahlen. Immer beginnen, verschiedene Kennzahlen selbst auszugeben. Es gibt Kubernetes mit Clustern und Pods, die viele Metriken offenlegen. Das führt dazu, dass Server tausende einzigartiger Metriken pro Host ausgeben. Damit ist eine einzigartige Zeitreihe von 40K längst nicht mehr außergewöhnlich. Sie wird zum Mainstream, der von jeder modernen TSDB auf einem Server problemlos verarbeitet werden kann.
Was bedeutet eine große Anzahl einzigartiger Zeitreihen heutzutage? Vielleicht 400K oder 4M? Oder 40M? Lassen Sie uns moderne TSDBs mit diesen Zahlen vergleichen.
Die Installation des Benchmarks
ist ein großartiges Benchmarking-Tool für TSDBs. Es ermöglicht die Generierung einer beliebigen Anzahl von Metriken, indem die erforderliche Anzahl von Zeitreihen über 10 angegeben wird – das Kennzeichen (ehemals -scale-var). 10 ist die Anzahl der Dimensionen (Metriken), die auf jedem Host, Server generiert werden. Die folgenden Datensätze wurden mit TSBS für den Benchmark erstellt:
- 400K einzigartige Zeitreihe, 60 Sekunden Intervall zwischen den Datenpunkten, die Daten decken vollständige 3 Tage ab, ~1,7B Gesamtanzahl der Datenpunkte.
- 4M einzigartige Zeitreihe, Intervall 600 Sekunden, die Daten decken vollständige 3 Tage ab, ~1,7B Gesamtanzahl der Datenpunkte.
- 40M einzigartige Zeitreihe, Intervall 1 Stunde, die Daten decken vollständige 3 Tage ab, ~2,8 B Gesamtanzahl der Datenpunkte.
Client und Server wurden auf dedizierten Instanzen in der Google Cloud ausgeführt. Diese Instanzen hatten folgende Konfigurationen:
- vCPUs: 16
- RAM: 60 GB
- Speicher: Standardfestplatte mit einer Kapazität von 1 TB. Sie bietet eine Lese-/Schreibgeschwindigkeit von 120 Mbit/s, 750 Lesevorgänge pro Sekunde und 1,5K Schreibvorgänge pro Sekunde.
TSDBs wurden aus offiziellen Docker-Images extrahiert und mit folgenden Konfigurationen in Docker ausgeführt:
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metricsInfluxDB-Werte (-e sind erforderlich, um hohe Leistungsfähigkeit zu unterstützen. Einzelheiten finden Sie 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 der 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 Datenlader wurde mit 16 parallelen Threads gestartet.
Dieser Artikel enthält nur Ergebnisse für die Insert-Benchmarks. Die Ergebnisse der Stichprobenbenchmarks werden in einem separaten Artikel veröffentlicht.
400K eindeutige Zeitreihen
Lassen Sie uns mit einfachen Elementen beginnen — 400K. Benchmark-Ergebnisse:
- VictoriaMetrics: 2,6M Datenpunkte pro Sekunde; RAM-Nutzung: 3 GB; endgültige Datengröße auf der Festplatte: 965 MB
- InfluxDB: 1.2M Datenpunkte pro Sekunde; RAM-Nutzung: 8.5 GB; endgültige Datengröße auf der Festplatte: 1.6 GB
- Timescale: 849K Datenpunkte pro Sekunde; RAM-Nutzung: 2,5 GB; endgültige Datengröße auf der Festplatte: 50 GB
Wie Sie aus den oben genannten Ergebnissen sehen können, gewinnt VictoriaMetrics in Bezug auf die Insert-Leistung und den Komprimierungsgrad. Timescale gewinnt bei der RAM-Nutzung, verwendet jedoch viel Speicherplatz - 29 Byte pro Datenpunkt.
Im Folgenden finden Sie CPU-Auslastungsgrafiken für jede der TSDBs während des Benchmarks:
Oben Screenshot: VictoriaMetrics - CPU-Auslastung während des Insert-Tests für die eindeutige Metrik 400K.
Oben Screenshot: InfluxDB - CPU-Auslastung während des Insert-Tests für die eindeutige Metrik 400K.
Oben Screenshot: TimescaleDB - CPU-Auslastung während des Insert-Tests für die eindeutige Metrik 400K.
VictoriaMetrics nutzt alle verfügbaren vCPUs, während InfluxDB nur etwa 2 von 16 vCPUs optimal nutzt.
Timescale verwendet nur 3-4 von 16 vCPUs. Hohe iowait- und system-Anteile im TimescaleDB-Diagramm zeigen auf ein Engpass im I/O-Subsystem hin. Lassen Sie uns die Diagramme der Datenträgerbandbreitennutzung anschauen:
Oben ist ein Screenshot: VictoriaMetrics - Nutzung der Datenträgerbandbreite bei einem Einfügetest für 400K einzigartige Metriken.
Oben ist ein Screenshot: InfluxDB - Nutzung der Datenträgerbandbreite bei einem Einfügetest für 400K einzigartige Metriken.
Oben ist ein Screenshot: TimescaleDB - Nutzung der Datenträgerbandbreite bei einem Einfügetest für 400K einzigartige Metriken.
VictoriaMetrics schreibt Daten mit einer Geschwindigkeit von 20 Mbit/s und Spitzen von bis zu 45 Mbit/s. Die Spitzen entsprechen großen partiellen Zusammenführungen im Baum. .
InfluxDB schreibt Daten mit einer Geschwindigkeit von 160 MB/s, während eine 1 TB-Festplatte Schreibbandbreite von 120 MB/s beschränkt sein sollte.
TimescaleDB ist auf eine Schreibbandbreite von 120 Mbit/s beschränkt, überschreitet diesen Grenzwert jedoch gelegentlich und erreicht Spitzenwerte von 220 Mbit/s. Diese Spitzenwerte entsprechen den Rückgängen aufgrund unzureichender CPU-Auslastung im vorherigen Diagramm.
Lassen Sie uns die Grafiken zur I/O-Nutzung (E/A) betrachten:
Oben ist ein Screenshot: VictoriaMetrics - I/O-Nutzung beim Einfügetest für 400K einzigartige Metriken.
Oben ist ein Screenshot: InfluxDB - I/O-Nutzung beim Einfügetest für 400K einzigartige Metriken.
Oben ist ein Screenshot: TimescaleDB - I/O-Nutzung beim Einfügetest für 400K einzigartige Metriken.
Jetzt ist deutlich, dass TimescaleDB den I/O-Grenzwert erreicht, weshalb es die verbleibenden 12 vCPUs nicht nutzen kann.
4M einzigartige Zeitreihen
4M Zeitreihen erscheinen etwas herausfordernd. Aber unsere Wettbewerber bestehen diese Prüfung erfolgreich. Benchmark-Ergebnisse:
- VictoriaMetrics: 2,2M Datenpunkte pro Sekunde; RAM-Nutzung: 6 GB; endgültige Datengröße auf der Festplatte: 3 GB.
- InfluxDB: 330K Datenpunkte pro Sekunde; RAM-Nutzung: 20,5 GB; endgültige Datengröße auf der Festplatte: 18,4 GB.
- TimescaleDB: 480K Datenpunkte pro Sekunde; RAM-Nutzung: 2,5 GB; endgültige Datengröße auf der Festplatte: 52 GB.
Die Leistung von InfluxDB ist von 1,2 Millionen Datenpunkten pro Sekunde für 400K Zeitreihen auf 330.000 Datenpunkte pro Sekunde für 4M Zeitreihen gesunken. Dies ist ein erheblicher Leistungsabfall im Vergleich zu anderen Mitbewerbern. Lassen Sie uns die CPU-Nutzungsdiagramme betrachten, um die Ursache dieses Verlusts zu verstehen:
Oben Screenshot: VictoriaMetrics - CPU-Nutzung während des Einfügetests für eine einzigartige 4M-Zeitreihe.
Oben Screenshot: InfluxDB - CPU-Nutzung während des Einfügetests für eine einzigartige 4M-Zeitreihe.
Oben Screenshot: TimescaleDB - CPU-Nutzung während des Einfügetests für eine einzigartige 4M-Zeitreihe.
VictoriaMetrics nutzt fast die gesamte CPU-Leistung. Der Rückgang am Ende entspricht den verbleibenden LSM-Verschmelzungen nach dem Einfügen aller Daten.
InfluxDB verwendet nur 8 von 16 vCPUs, während TimescaleDB 4 von 16 vCPUs verwendet. Was haben ihre Diagramme gemeinsam? Ein hoher Anteil iowait, was wiederum auf einen Engpass beim ein- und ausgeben hinweist.
TimescaleDB hat einen hohen Anteil System. Wir nehmen an, dass die hohe Leistung zu vielen Systemaufrufen oder vielen .
führt. Lassen Sie uns die Diagramme der Datenträgerdurchsatzrate betrachten:
Oben Screenshot: VictoriaMetrics - Datenträgerdurchsatznutzung beim Einfügen von 4M einzigartigen Metriken.
Oben Screenshot: InfluxDB - Datenträgerdurchsatznutzung beim Einfügen von 4M einzigartigen Metriken.
Oben Screenshot: TimescaleDB - Datenträgerdurchsatznutzung beim Einfügen von 4M einzigartigen Metriken.
VictoriaMetrics erreichten einen Spitzenwert von 120 MB/s, während die durchschnittliche Schreibgeschwindigkeit 40 MB/s betrug. Wahrscheinlich wurden während des Spitzenwerts mehrere intensive LSM-Verschmelzungen durchgeführt.
InfluxDB erzielt erneut eine durchschnittliche Schreibdurchsatzrate von 200 MB/s mit Spitzenwerten von bis zu 340 MB/s auf einer Festplatte mit einem Schreiblimit von 120 MB/s 🙂
TimescaleDB wird nicht mehr durch die Festplatte eingeschränkt. Es scheint, dass es durch etwas anderes mit einem hohen Anteil System- CPU-Auslastung begrenzt ist.
Lassen Sie uns die IO-Nutzungsdiagramme betrachten:
Oben Screenshot: VictoriaMetrics - Ein- und Ausgabennutzung während des Einfügetests für eine einzigartige 4M-Zeitreihe.
Oben Screenshot: InfluxDB - Ein- und Ausgabennutzung während des Einfügetests für eine einzigartige 4M-Zeitreihe.
Oben Screenshot: TimescaleDB - Ein- und Ausgabennutzung während des Einfügetests für eine einzigartige 4M-Zeitreihe.
Die IO-Nutzungsdiagramme entsprechen den Diagrammen der Bandbreitennutzung der Festplatte – InfluxDB ist in Bezug auf IO limitiert, während VictoriaMetrics und TimescaleDB über zusätzliche IO-Ressourcen verfügen.
40M einzigartige Zeitserien
40M einzigartige Zeitreihen waren für InfluxDB zu groß 🙁
Benchmark-Ergebnisse:
- VictoriaMetrics: 1,7M Datenpunkte pro Sekunde; Speicherverbrauch: 29 GB; Speicherplatzverbrauch: 17 GB.
- InfluxDB: nicht abgeschlossen, da dafür mehr als 60 GB RAM benötigt wurden.
- TimescaleDB: 330K Datenpunkte pro Sekunde, Speicherverbrauch: 2,5 GB; Speicherplatzverbrauch: 84 GB.
TimescaleDB zeigt eine außergewöhnlich niedrige und stabile Speicherauslastung – 2,5 GB – ebenso viel wie für die einzigartigen Metriken 4M und 400K.
VictoriaMetrics steigerte sich langsam mit einer Rate von 100.000 Datenpunkten pro Sekunde, bis alle 40M Metriknamen mit Labels verarbeitet waren. Dann wurde eine stabile Einfügerate von 1,5-2,0M Datenpunkten pro Sekunde erreicht, sodass das Endergebnis 1,7M Datenpunkte pro Sekunde betrug.
Die Diagramme für 40M einzigartige Zeitreihen sind ähnlich denen für 4M einzigartige Zeitreihen, also lassen Sie uns diese überspringen.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
- Moderne TSDBs sind in der Lage, Einfügungen für Millionen einzigartiger Zeitreihen auf einem Server zu verarbeiten. Im nächsten Artikel werden wir untersuchen, wie gut TSDBs bei Abfragen über Millionen einzigartiger Zeitreihen abschneiden.
- Eine unzureichende CPU-Auslastung weist normalerweise auf einen IO-Engpass hin. Darüber hinaus kann dies auf eine zu grobe Sperre hinweisen, bei der gleichzeitig nur wenige Threads arbeiten können.
- Ein IO-Engpass existiert tatsächlich, insbesondere in Speichern ohne SSDs, wie sie in virtualisierten Blockgeräten von Cloud-Anbietern vorkommen.
- VictoriaMetrics bietet die beste Optimierung für langsame Speicher mit niedrigem IO. Es gewährleistet die beste Geschwindigkeit und die beste Komprimierungsrate.
Laden Sie herunter und probieren Sie es mit Ihren Daten aus. Die entsprechende statische Binärdatei ist verfügbar unter .
Mehr über VictoriaMetrics erfahren Sie in diesem .
Update: veröffentlicht wurde ein mit reproduzierbaren Ergebnissen.
Aktualisierung#2: Lesen Sie auch .
Aktualisierung #3: !
Telegram-Chat:
Quelle: habr.com
