VictoriaMetrics, TimescaleDB og InfluxDB ble sammenlignet i på et datasett med en milliard datapunkter som tilhører 40K unike tidsserier.
For noen år siden var det en æra med Zabbix. Hver bare metallserver hadde ikke mer enn noen få indikatorer - CPU-bruk, RAM-bruk, diskbruk og nettverksbruk. På denne måten kan beregninger fra tusenvis av servere passe inn i 40 tusen unike tidsserier, og Zabbix kan bruke MySQL som backend for tidsseriedata :)
For tiden alene med standardkonfigurasjoner gir over 500 beregninger på den gjennomsnittlige verten. Det er mange for ulike databaser, webservere, maskinvaresystemer osv. De gir alle en rekke nyttige beregninger. Alle begynne å sette ulike indikatorer for seg selv. Det er Kubernetes med klynger og pods som avslører mange beregninger. Dette resulterer i at servere eksponerer tusenvis av unike beregninger per vert. Så den unike 40K-tidsserien er ikke lenger høyeffekt. Det er i ferd med å bli mainstream og bør enkelt håndteres av enhver moderne TSDB på en enkelt server.
Hva er det store antallet unike tidsserier for øyeblikket? Sannsynligvis 400K eller 4M? Eller 40m? La oss sammenligne moderne TSDB-er med disse tallene.
Installere en benchmark
er et utmerket benchmarkingverktøy for TSDBer. Den lar deg generere et vilkårlig antall beregninger ved å sende det nødvendige antallet tidsserier delt på 10 - flagg (tidligere -scale-var). 10 er antall målinger (metrikker) generert på hver vert eller server. Følgende datasett ble generert ved hjelp av TSBS for benchmark:
- 400K unike tidsserier, 60 sekunders intervall mellom datapunkter, data spenner over hele 3 dager, ~1.7B totalt antall datapunkter.
- 4M unike tidsserier, 600 sekunders intervall, data spenner over 3 hele dager, ~1.7B totalt antall datapunkter.
- 40 millioner unike tidsserier, 1 times intervall, data spenner over 3 hele dager, ~2.8B totalt antall datapunkter.
Klienten og serveren kjørte på dedikerte forekomster i Google sky. Disse forekomstene hadde følgende konfigurasjoner:
- vCPUer: 16
- RAM: 60 GB
- Lagring: Standard 1TB HDD. Den gir 120 Mbps lese-/skrivegjennomstrømning, 750 leseoperasjoner per sekund og 1,5K skriving per sekund.
TSDB-er ble trukket ut fra offisielle docker-bilder og kjørt i docker med følgende konfigurasjoner:
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metricsInfluxDB (-e)-verdier kreves for å støtte høy effekt. Se detaljer i ):
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 (konfigurasjon hentet fra fil):
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=100Datalasteren ble kjørt med 16 parallelle tråder.
Denne artikkelen inneholder kun resultater for benchmarks for innsetting. Resultatene av den selektive benchmarken vil bli publisert i en egen artikkel.
400K unike tidsserier
La oss starte med enkle elementer - 400K. Referanseresultater:
- VictoriaMetrics: 2,6 millioner datapunkter per sekund; RAM-bruk: 3 GB; endelig datastørrelse på disk: 965 MB
- InfluxDB: 1.2M datapunkter per sekund; RAM-bruk: 8.5 GB; endelig datastørrelse på disk: 1.6 GB
- Tidsskala: 849K datapunkter per sekund; RAM-bruk: 2,5 GB; endelig datastørrelse på disk: 50 GB
Som du kan se fra resultatene ovenfor, vinner VictoriaMetrics i innsettingsytelse og kompresjonsforhold. Tidslinjen vinner i RAM-bruk, men den bruker mye diskplass - 29 byte per datapunkt.
Nedenfor er CPU-bruksgrafene for hver av TSDB-ene under benchmark:
Over er et skjermbilde: VictoriaMetrics - CPU-belastning under innsettingstest for en unik 400K-metrikk.
Over er et skjermbilde: InfluxDB - CPU-belastning under innsettingstest for unike metriske 400K.
Over er et skjermbilde: TimescaleDB - CPU-belastning under innsettingstest for en unik metrikk på 400K.
VictoriaMetrics bruker alle tilgjengelige vCPUer, mens InfluxDB underutnytter ~2 av 16 vCPUer.
Tidsskala bruker bare 3-4 av de 16 vCPUene. Høye proporsjoner av iowait og system i TimescaleDB-tidsskalagrafen indikerer en flaskehals i input/output (I/O)-delsystemet. La oss se på grafene for bruk av diskbåndbredde:
Over er et skjermbilde: VictoriaMetrics - Disk Bandwidth Usage in Insertion Test for Unique Metrics 400K.
Ovenfor er et skjermbilde: InfluxDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
Ovenfor er et skjermbilde: TimescaleDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
VictoriaMetrics registrerer data med 20 Mbps med topper på opptil 45 Mbps. Topper tilsvarer store delvise fusjoner i treet .
InfluxDB skriver data med 160 MB/s, mens en 1 TB-stasjon skrivegjennomstrømning 120 MB/s.
TimescaleDB er begrenset til skrivegjennomstrømning på 120 Mbps, men noen ganger bryter den denne grensen og når 220 Mbps i toppverdier. Disse toppene tilsvarer dalene med utilstrekkelig CPU-utnyttelse i forrige graf.
La oss se på bruksgrafene for input/output (I/O):
Over er et skjermbilde: VictoriaMetrics - Sett inn test I/O-bruk for 400K unike beregninger.
Ovenfor er et skjermbilde: InfluxDB - Sett inn test I/O-bruk for 400K unike beregninger.
Ovenfor er et skjermbilde: TimescaleDB - Sett inn test I/O-bruk for 400K unike beregninger.
Det er nå klart at TimescaleDB når sin I/O-grense, så den kan ikke bruke de resterende 12 vCPUene.
4M unike tidsserier
4M tidsserier ser litt utfordrende ut. Men våre konkurrenter består denne eksamenen. Referanseresultater:
- VictoriaMetrics: 2,2 millioner datapunkter per sekund; RAM-bruk: 6 GB; endelig datastørrelse på disk: 3 GB.
- InfluxDB: 330K datapunkter per sekund; RAM-bruk: 20,5 GB; endelig datastørrelse på disk: 18,4 GB.
- TidsskalaDB: 480K datapunkter per sekund; RAM-bruk: 2,5 GB; endelig datastørrelse på disk: 52 GB.
InfluxDB-ytelsen falt fra 1,2M datapunkter per sekund for en 400K tidsserie til 330K datapunkter per sekund for en 4M tidsserie. Dette er et betydelig ytelsestap sammenlignet med andre konkurrenter. La oss se på CPU-bruksgrafene for å forstå årsaken til dette tapet:
Over er et skjermbilde: VictoriaMetrics - CPU-bruk under innsettingstest for en unik 4M tidsserie.
Over er et skjermbilde: InfluxDB - CPU-bruk under innsettingstest for unike 4M tidsserier.
Over er et skjermbilde: TimescaleDB - CPU-bruk under innsettingstest for en unik 4M tidsserie.
VictoriaMetrics bruker nesten all strøm fra prosessorenheten (CPU). Fallet på slutten tilsvarer gjenværende LSM-sammenslåinger etter at alle dataene er satt inn.
InfluxDB bruker bare 8 av 16 vCPUer, mens TimsecaleDB bruker 4 av 16 vCPUer. Hva har grafene deres til felles? Høy andel iowait, som igjen indikerer en I/O-flaskehals.
TimescaleDB har en høy andel system. Vi antar at høy effekt resulterte i mange systemanrop eller mange .
La oss se på diskgjennomstrømningsgrafene:
Over er et skjermbilde: VictoriaMetrics - Bruk av diskbåndbredde for å sette inn 4M unike metrikker.
Ovenfor er et skjermbilde: InfluxDB - Bruker diskbåndbredde for å sette inn 4M unike beregninger.
Ovenfor er et skjermbilde: TimescaleDB - Bruker diskbåndbredde for å sette inn 4M unike beregninger.
VictoriaMetrics nådde en grense på 120 MB/s på topp, mens gjennomsnittlig skrivehastighet var 40 MB/s. Det er sannsynlig at flere tunge LSM-fusjoner ble utført i løpet av toppen.
InfluxDB presser igjen ut en gjennomsnittlig skrivegjennomstrømning på 200 MB/s med topper på opptil 340 MB/s på en disk med skrivegrense på 120 MB/s :)
TimescaleDB er ikke lenger diskbegrenset. Det ser ut til å være begrenset av noe annet knyttet til høy andel системной CPU-belastning.
La oss se på IO-bruksgrafene:
Over er et skjermbilde: VictoriaMetrics - Bruke I/O under innsettingstest for en unik 4M tidsserie.
Over er et skjermbilde: InfluxDB - Bruk av I/O under innsettingstest for en unik 4M tidsserie.
Over er et skjermbilde: TimescaleDB - I/O-bruk under innsettingstest for unike 4M tidsserier.
IO-bruksmønstre gjenspeiler diskbåndbredden - InfluxDB er IO-begrenset, mens VictoriaMetrics og TimescaleDB har ledige IO-ressurser.
40 millioner unike tidsserier
40 millioner unike tidsserier var for store for InfluxDB :)
Referanseresultater:
- VictoriaMetrics: 1,7 millioner datapunkter per sekund; RAM-bruk: 29 GB; Diskplassbruk: 17 GB.
- InfluxDB: Fullførte ikke fordi det krevde mer enn 60 GB RAM.
- TimescaleDB: 330K datapunkter per sekund, RAM-bruk: 2,5 GB; Diskplassbruk: 84GB.
TimescaleDB viser eksepsjonelt lav og stabil RAM-bruk på 2,5 GB - det samme som for de unike 4M- og 400K-verdiene.
VictoriaMetrics skalerte sakte opp med en hastighet på 100 40 datapunkter per sekund til alle 1,5 millioner taggede metriske navn ble behandlet. Han oppnådde deretter en vedvarende innsettingshastighet på 2,0-1,7 millioner datapunkter per sekund, så sluttresultatet var XNUMX millioner datapunkter per sekund.
Grafene for 40 millioner unike tidsserier ligner på grafene for 4 millioner unike tidsserier, så la oss hoppe over dem.
Funn
- Moderne TSDB-er er i stand til å behandle inserts for millioner av unike tidsserier på en enkelt server. I den neste artikkelen skal vi teste hvor godt TSDBer utfører seleksjon på tvers av millioner av unike tidsserier.
- Utilstrekkelig CPU-utnyttelse indikerer vanligvis en I/O-flaskehals. Det kan også tyde på at blokkeringen er for grov, med bare noen få tråder som kan løpe om gangen.
- I/O-flaskehalsen eksisterer, spesielt i ikke-SSD-lagring som skyleverandørers virtualiserte blokkenheter.
- VictoriaMetrics gir den beste optimaliseringen for langsom, lav I/O-lagring. Det gir den beste hastigheten og det beste kompresjonsforholdet.
Last ned og prøv det på dataene dine. Den tilsvarende statiske binæren er tilgjengelig på .
Les mer om VictoriaMetrics i denne .
Oppdatering: publisert med reproduserbare resultater.
Oppdatering #2: Les også .
Oppdatering nr. 3: !
Telegram chat:
Kilde: www.habr.com
