VictoriaMetrics, TimescaleDB e InfluxDB sono stati confrontati in un set di dati con un miliardo di punti dati appartenenti a 40K serie temporali uniche.
Qualche anno fa, c'era l'era di Zabbix. Ogni server bare metal aveva al massimo solo alcune metriche: utilizzo della CPU, utilizzo della memoria, utilizzo del disco e utilizzo della rete. Così, le metriche di migliaia di server possono essere contenute in 40.000 serie temporali uniche, e Zabbix può usare MySQL come backend per i dati delle serie temporali 🙂
Attualmente, un con configurazioni predefinite fornisce oltre 500 metriche su un host medio. Ci sono molti per diversi database, server web, sistemi hardware, ecc. Tutti forniscono molte metriche utili. Tutti iniziano a esporre diverse metriche. Esiste Kubernetes con cluster e pod che rivelano un gran numero di metriche. Questo porta i server ad esporre migliaia di metriche uniche per host. Così, una serie temporale unica di 40K non è più un'alta capacità. Diventa mainstream e deve essere facilmente gestita da qualsiasi moderna TSDB su un singolo server.
Qual è un gran numero di serie temporali uniche al momento? Forse 400K o 4M? O 40M? Confrontiamo le moderne TSDB con questi numeri.
Installazione del benchmark
è uno strumento eccellente per il benchmarking delle TSDB. Permette di generare un numero arbitrario di metriche passando la quantità necessaria di serie temporali, suddivise per 10 — la flag (ex -scale-var). 10 è il numero di misurazioni (metriche) generate su ogni host, server. I seguenti set di dati sono stati creati utilizzando TSBS per il benchmark:
- 400K serie temporali uniche, intervallo di 60 secondi tra i punti dati, i dati coprono 3 giorni interi, ~1.7B punti dati totali.
- 4M serie temporale unica, intervallo di 600 secondi, i dati coprono un periodo totale di 3 giorni, ~1,7B punti dati totali.
- 40M serie temporale unica, intervallo di 1 ora, i dati coprono un periodo totale di 3 giorni, ~2,8B punti dati totali.
Il client e il server sono stati avviati su istanze dedicate sul cloud di Google. Queste istanze avevano le seguenti configurazioni:
- vCPUs: 16
- RAM: 60 GB
- Storage: disco rigido standard da 1 TB. Garantisce una larghezza di banda in lettura/scrittura di 120 Mbit/s, 750 operazioni di lettura al secondo e 1,5K operazioni di scrittura al secondo.
Le TSDB sono state estratte da immagini ufficiali docker e avviate in docker con le seguenti configurazioni:
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metricsValori InfluxDB (-e necessari per supportare alta potenza. Maggiori dettagli si trovano 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 (la configurazione è stata presa dal file):
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=100Il caricatore di dati è stato avviato con 16 thread paralleli.
Questo articolo contiene solo i risultati per gli indicatori di prestazione delle inserzioni. I risultati del benchmark selettivo saranno pubblicati in un articolo separato.
400K serie temporali uniche
Iniziamo con gli elementi semplici — 400K. Risultati del benchmark:
- VictoriaMetrics: 2,6M punti dati al secondo; utilizzo della memoria: 3 GB; dimensione finale dei dati su disco: 965 MB
- InfluxDB: 1.2M punti dati al secondo; utilizzo della memoria: 8,5 GB; dimensione finale dei dati su disco: 1,6 GB
- Timescale: 849K punti dati al secondo; utilizzo della memoria: 2,5 GB; dimensione finale dei dati su disco: 50 GB
Come puoi vedere dai risultati sopra, VictoriaMetrics eccelle nelle prestazioni di inserimento e nel rapporto di compressione. Timescale si distingue per l'uso della memoria, ma consuma molto spazio su disco: 29 byte per punto dati.
Di seguito sono riportati i grafici sull'uso della CPU per ciascuno dei TSDB durante il benchmark:
Screenshot sopra: VictoriaMetrics - Carico della CPU durante il test di inserimento per una metrica unica di 400K.
Screenshot sopra: InfluxDB - Carico della CPU durante il test di inserimento per una metrica unica di 400K.
Screenshot sopra: TimescaleDB - Carico della CPU durante il test di inserimento per una metrica unica di 400K.
VictoriaMetrics utilizza tutti i vCPU disponibili, mentre InfluxDB sfrutta adeguatamente solo ~2 su 16 vCPU.
Timescale utilizza solo 3-4 su 16 vCPU. Le elevate percentuali di iowait e system nel grafico di TimescaleDB indicano un collo di bottiglia nella sottosistema di input-output (I/O). Diamo un'occhiata ai grafici sull'uso della larghezza di banda del disco:
Screenshot sopra: VictoriaMetrics - Utilizzo della larghezza di banda del disco durante il test di inserimento per metriche uniche di 400K.
Screenshot sopra: InfluxDB — Utilizzo della larghezza di banda del disco nel test di inserimento per metriche uniche di 400K.
Screenshot sopra: TimescaleDB — Utilizzo della larghezza di banda del disco nel test di inserimento per metriche uniche di 400K.
VictoriaMetrics registra i dati a una velocità di 20 Mbit/s con picchi fino a 45 Mbit/s. I picchi corrispondono a grandi fusioni parziali nell'albero. .
InfluxDB registra i dati a una velocità di 160 MB/s, mentre un disco da 1 TB alla larghezza di banda di scrittura di 120 MB/s.
TimescaleDB è limitata alla larghezza di banda di scrittura di 120 Mbit/s, ma a volte supera questo limite e raggiunge 220 Mbit/s in valori di picco. Questi picchi corrispondono a fallimenti dovuti a un carico della CPU insufficiente nel grafico precedente.
Diamo un'occhiata ai grafici di utilizzo dell'input-output (I/O):
Screenshot sopra: VictoriaMetrics — Utilizzo dell'input-output nel test di inserimento per 400K metriche uniche.
Screenshot sopra: InfluxDB — Utilizzo dell'input-output nel test di inserimento per 400K metriche uniche.
Screenshot sopra: TimescaleDB — Utilizzo dell'input-output nel test di inserimento per 400K metriche uniche.
Ora è chiaro che TimescaleDB raggiunge il limite di I/O, quindi non può utilizzare i restanti 12 vCPU.
4M serie temporali uniche
4M serie temporali sembrano un po' sfidanti. Ma i nostri concorrenti superano con successo questo test. Risultati del benchmark:
- VictoriaMetrics: 2,2M punti dati al secondo; utilizzo della memoria: 6 GB; dimensione finale dei dati su disco: 3 GB.
- InfluxDB: 330K punti dati al secondo; utilizzo della memoria: 20,5 GB; dimensione finale dei dati su disco: 18,4 GB.
- TimescaleDB: 480K punti dati al secondo; utilizzo della memoria: 2,5 GB; dimensione finale dei dati su disco: 52 GB.
Le prestazioni di InfluxDB sono scese da 1,2 milioni di punti dati al secondo per 400K serie temporali a 330K punti dati al secondo per 4M serie temporali. Questa è una perdita di prestazioni significativa rispetto agli altri concorrenti. Diamo un'occhiata ai grafici di utilizzo della CPU per comprendere la causa principale di questa perdita:
Screenshot sopra: VictoriaMetrics — Utilizzo della CPU durante il test di inserimento per la serie temporale unica 4M.
Sopra lo screenshot: InfluxDB — Utilizzo della CPU durante il test di inserimento per una serie temporale unica di 4M.
Sopra lo screenshot: TimescaleDB — Utilizzo della CPU durante il test di inserimento per una serie temporale unica di 4M.
VictoriaMetrics utilizza quasi tutta la potenza della CPU. Il calo finale corrisponde ai restanti merge LSM dopo l'inserimento di tutti i dati.
InfluxDB utilizza solo 8 dei 16 vCPU, mentre TimescaleDB utilizza 4 dei 16 vCPU. Qual è il punto in comune tra i loro grafici? Un'alta percentuale di iowait, che, di nuovo, indica un collo di bottiglia nell'input/output.
TimescaleDB ha un'alta percentuale di sistema. Riteniamo che l'alta potenza abbia portato a molte chiamate di sistema o a molti .
Esaminiamo i grafici della capacità di scrittura su disco:
Sopra lo screenshot: VictoriaMetrics — Utilizzo della larghezza di banda del disco per l'inserimento di 4M metriche uniche.
Sopra lo screenshot: InfluxDB — Utilizzo della larghezza di banda del disco per l'inserimento di 4M metriche uniche.
Sopra lo screenshot: TimescaleDB — Utilizzo della larghezza di banda del disco per l'inserimento di 4M metriche uniche.
VictoriaMetrics ha raggiunto un limite di 120 MB/s in picco, mentre la velocità di scrittura media era di 40 MB/s. Probabilmente, durante i picchi sono state eseguite alcune pesanti fusioni LSM.
InfluxDB torna a estrarre una velocità di scrittura media di 200 MB/s, con picchi fino a 340 MB/s su un disco con limitazione di scrittura di 120 MB/s 🙂
TimescaleDB non è più limitata dal disco. Sembra che sia limitata da qualcos'altro legato a un'alta percentuale di carico sulla CPU.
Diamo un'occhiata ai grafici di utilizzo dell'I/O:
Sopra lo screenshot: VictoriaMetrics — Utilizzo dell'I/O durante il test di inserimento per una serie temporale unica di 4M.
Sopra lo screenshot: InfluxDB — Utilizzo dell'I/O durante il test di inserimento per una serie temporale unica di 4M.
Sopra lo screenshot: TimescaleDB — Utilizzo dell'I/O durante il test di inserimento per una serie temporale unica di 4M.
I grafici di utilizzo dell'I/O ripetono i grafici di utilizzo della larghezza di banda del disco: InfluxDB è limitato dall'I/O, mentre VictoriaMetrics e TimescaleDB hanno risorse di I/O disponibili.
40M serie temporali uniche
40M serie temporali uniche erano troppo grandi per InfluxDB 🙁
Risultati del benchmark:
- VictoriaMetrics: 1,7M punti dati al secondo; utilizzo della memoria: 29 GB; utilizzo dello spazio su disco: 17 GB.
- InfluxDB: non completato, perché richiedeva più di 60 GB di memoria.
- TimescaleDB: 330K punti dati al secondo, utilizzo della memoria: 2,5 GB; utilizzo dello spazio su disco: 84 GB.
TimescaleDB mostra un utilizzo della memoria eccezionalmente basso e stabile: 2,5 GB, lo stesso richiesto per metriche uniche di 4M e 400K.
VictoriaMetrics è lentamente aumentata a una velocità di 100.000 punti dati al secondo, fino a quando non sono stati elaborati tutti i 40M nomi metrici con etichette. Successivamente ha raggiunto una velocità di inserimento sostenuta di 1,5-2,0M punti dati al secondo, quindi il risultato finale è stato di 1,7M punti dati al secondo.
I grafici per 40M serie temporali uniche sono simili a quelli per 4M serie temporali uniche, quindi li saltiamo.
Conclusioni
- I moderni TSDB possono gestire inserimenti per milioni di serie temporali uniche su un singolo server. Nel prossimo articolo verificheremo quanto bene i TSDB eseguono query su milioni di serie temporali uniche.
- Un caricamento insufficiente della CPU indica generalmente un collo di bottiglia nell'I/O. Inoltre, potrebbe segnalare un blocco eccessivamente grossolano, dove solo pochi thread possono essere in esecuzione contemporaneamente.
- Il collo di bottiglia nell'I/O esiste davvero, specialmente nei sistemi di storage senza SSD, come i dispositivi di blocco virtualizzati dei provider cloud.
- VictoriaMetrics offre la migliore ottimizzazione per gli storage lenti con bassi livelli di I/O. Garantisce la massima velocità e il miglior livello di compressione.
Scarica e provala con i tuoi dati. Il file binario statico pertinente è disponibile su .
Per maggiori informazioni su VictoriaMetrics, leggi questo .
Aggiornamento: è stato pubblicato un con risultati riproducibili.
Aggiornamento #2: Leggi anche .
Aggiornamento #3: !
Chat Telegram:
Fonte: habr.com
