VictoriaMetrics, TimescaleDB și InfluxDB au fost comparate în rapoarte cu un set de date de un miliard de puncte de date, aparținând 40K de serii temporale unice.
Acum câțiva ani, era epoca Zabbix. Fiecare server bare metal avea nu mai mult de câteva metrici – utilizarea procesorului, utilizarea memoriei RAM, utilizarea discului și utilizarea rețelei. Astfel, metricile de pe mii de servere puteau fi folosite în 40 de mii de serii temporale unice, iar Zabbix putea folosi MySQL ca backend pentru datele acestor serii temporale 🙂
În prezent, un cu configurații implicite oferă peste 500 de metrici pe un host mediu. Există numeroși pentru diverse baze de date, servere web, sisteme hardware etc. Toți oferă o mulțime de metrici utile. Tot încep să expună diferite metrici pentru sine. Există Kubernetes cu clustere și pod-uri care dezvăluie o mulțime de metrici. Acest lucru duce la faptul că serverele expun mii de metrici unice pe host. Astfel, o serie temporală unică de 40K nu mai reprezintă o putere mare. Devine mainstream, care ar trebui să fie ușor procesat de orice TSDB modern pe un singur server.
Ce este un număr atât de mare de serii temporale unice în prezent? Probabil, 400K sau 4M? Sau 40M? Să comparăm TSDB moderne cu aceste cifre.
Configurarea benchmark-ului
întâmpină o excelentă unealtă de benchmarking pentru TSDB-uri. Aceasta permite generarea unui număr arbitrar de metrici, prin transmiterea numărului necesar de serii temporale, împărțite la 10 — flag-ul (fostul -scale-var). 10 este numărul de dimensiuni (metrici) generate pe fiecare host, server. Următoarele seturi de date au fost create cu TSBS pentru benchmark:
- 400K serii temporale unice, interval de 60 de secunde între punctele de date, datele acoperă 3 zile complete, ~1.7B numărul total de puncte de date.
- 4M serii temporale unice, interval de 600 de secunde, datele acoperă 3 zile complete, ~1.7B numărul total de puncte de date.
- 40M serii temporale unice, interval de 1 oră, datele acoperă 3 zile complete, ~2.8B numărul total de puncte de date.
Clientul și serverul au fost pornite pe instanțe dedicate în cloudul Google. Aceste instanțe au avut următoarele configurații:
- vCPUs: 16
- RAM: 60 GB
- Stocare: disc dur standard de 1 TB. Acesta oferă o lățime de bandă de citire/scriere de 120Mbps, 750 operații de citire pe secundă și 1,5K operații de scriere pe secundă.
TSDB-urile au fost extrase din imaginile oficiale Docker și rulate în Docker cu următoarele configurații:
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metricsValorile InfluxDB (-e sunt necesare pentru a susține un throughput mare. Detalii în ):
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 (configurația a fost preluată din fișier):
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=100Încărcătorul de date a fost pornit cu 16 fire paralele.
Acest articol conține doar rezultatele pentru indicatorii de inserție. Rezultatele benchmark-ului cu eșantionare vor fi publicate într-un articol separat.
400K serii temporale unice
Să începem cu elementele simple — 400K. Rezultatele benchmark-ului:
- VictoriaMetrics: 2,6M puncte de date pe secundă; utilizare a memoriei RAM: 3 GB; dimensiunea finală a datelor pe disc: 965 MB
- InfluxDB: 1,2M puncte de date pe secundă; utilizare a memoriei RAM: 8,5 GB; dimensiunea finală a datelor pe disc: 1,6 GB
- Timescale: 849K puncte de date pe secundă; utilizare a memoriei RAM: 2,5 GB; dimensiunea finală a datelor pe disc: 50 GB
După cum puteți observa din rezultatele de mai sus, VictoriaMetrics are avantaje în performanța inserției și gradul de compresie. Timescale câștigă în utilizarea memoriei RAM, dar utilizează mult spațiu pe disc — 29 de bytes pe punct de date.
Mai jos sunt graficele utilizării CPU pentru fiecare dintre TSDB-uri în timpul benchmark-ului:
În imaginea de mai sus: VictoriaMetrics — Sarcină CPU în testul de inserție pentru o metrică unică de 400K.
În imaginea de mai sus: InfluxDB — Sarcină CPU în testul de inserție pentru o metrică unică de 400K.
Captura de ecran de mai sus: TimescaleDB — Încărcarea CPU în timpul testului de inserare pentru o metrică unică de 400K.
VictoriaMetrics utilizează toate vCPUs disponibile, în timp ce InfluxDB folosește insuficient ~2 din 16 vCPUs.
Timescale utilizează doar 3-4 din 16 vCPUs. Proporțiile ridicate de iowait și system pe graficul TimescaleDB indică o congestie în subsistemul de intrare-ieșire (I/O). Să ne uităm la graficele de utilizare a lățimii de bandă a discului:
Captura de ecran de mai sus: VictoriaMetrics — Utilizarea lățimii de bandă a discului în timpul testului de inserare pentru metrici unice de 400K.
Captura de ecran de mai sus: InfluxDB — Utilizarea lățimii de bandă a discului în timpul testului de inserare pentru metrici unice de 400K.
Captura de ecran de mai sus: TimescaleDB — Utilizarea lățimii de bandă a discului în timpul testului de inserare pentru metrici unice de 400K.
VictoriaMetrics scrie date cu o viteză de 20 Mbps, cu vârfuri de până la 45 Mbps. Vârfurile corespund unor fuziuni parțiale mari în arbore. .
InfluxDB scrie date cu o viteză de 160 MB/s, în timp ce un disc de 1 TB la o lățime de bandă de scriere de 120 MB/s.
TimescaleDB este limitată la o lățime de bandă de scriere de 120 Mbps, dar uneori depășește această limită și ajunge la 220 Mbps în valori de vârf. Aceste vârfuri corespund unor scăderi de încărcare a procesorului insuficiente pe graficul anterior.
Să ne uităm la graficele de utilizare a I/O:
Captura de ecran de mai sus: VictoriaMetrics — Utilizarea I/O în timpul testului de inserare pentru 400K metrici unice.
Captura de ecran de mai sus: InfluxDB — Utilizarea I/O în timpul testului de inserare pentru 400K metrici unice.
Captura de ecran de mai sus: TimescaleDB — Utilizarea I/O în timpul testului de inserare pentru 400K metrici unice.
Acum este clar că TimescaleDB atinge limita de I/O, așadar nu poate utiliza celelalte 12 vCPUs.
4M seriile temporale unice
4M serii temporale par să fie puțin provocatoare. Dar competitorii noștri trec cu succes acest examen. Rezultatele benchmark-ului:
- VictoriaMetrics: 2,2M puncte de date pe secundă; utilizarea memoriei: 6 GB; dimensiunea finală a datelor pe disc: 3 GB.
- InfluxDB: 330K puncte de date pe secundă; utilizarea memoriei: 20,5 GB; dimensiunea finală a datelor pe disc: 18,4 GB.
- TimescaleDB: 480K de puncte de date pe secundă; utilizarea memoriei RAM: 2,5 GB; dimensiunea finală a datelor pe disc: 52 GB.
Performanța InfluxDB a scăzut de la 1,2 milioane de puncte de date pe secundă pentru 400K serii temporale la 330 mii puncte de date pe secundă pentru 4M serii temporale. Aceasta este o pierdere semnificativă de performanță în comparație cu alți concurenți. Să ne uităm la graficele utilizării CPU pentru a înțelege cauza principală a acestei pierderi:
Mai sus este screenshot-ul: VictoriaMetrics — Utilizarea CPU în testul de inserare pentru o serie temporală unică de 4M.
Mai sus este screenshot-ul: InfluxDB — Utilizarea CPU în testul de inserare pentru o serie temporală unică de 4M.
Mai sus este screenshot-ul: TimescaleDB — Utilizarea CPU în testul de inserare pentru o serie temporală unică de 4M.
VictoriaMetrics folosește aproape toată puterea procesorului (CPU). Scăderea de la final corespunde fuziunilor LSM restante după inserarea tuturor datelor.
InfluxDB folosește doar 8 din 16 vCPUs, în timp ce TimescaleDB folosește 4 din 16 vCPUs. Ce au în comun graficile lor? O proporție mare iowait, ceea ce, din nou, indică un col bottleneck de I/O.
TimescaleDB are o proporție mare sistem. Presupunem că puterea mare a dus la multe apeluri de sistem sau multe .
Să ne uităm la graficele lățimii de bandă a discului:
Mai sus este screenshot-ul: VictoriaMetrics — Utilizarea lățimii de bandă a discului pentru inserarea a 4M de metrici unice.
Mai sus este screenshot-ul: InfluxDB — Utilizarea lățimii de bandă a discului pentru inserarea a 4M de metrici unice.
Mai sus este screenshot-ul: TimescaleDB — Utilizarea lățimii de bandă a discului pentru inserarea a 4M de metrici unice.
VictoriaMetrics a atins limita de 120 MB/s în vârf, în timp ce viteza medie de scriere a fost de 40 MB/s. Probabil, în timpul vârfului au avut loc câteva fuziuni LSM grele.
InfluxDB își extrage din nou viteza medie de lățime de bandă de scriere de 200 MB/s cu vârfuri de până la 340 MB/s pe un disc cu o limită de scriere de 120 MB/s 🙂
TimescaleDB nu mai este limitată de disc. Se pare că este limitată de altceva legat de o proporție mare a încărcării CPU.
Să ne uităm la graficele utilizării IO:
Mai sus este screenshot-ul: VictoriaMetrics — Utilizarea I/O în timpul testului de inserare pentru o serie temporală unică de 4M.
Mai sus este screenshot-ul: InfluxDB — Utilizarea I/O în timpul testului de inserare pentru o serie temporală unică de 4M.
Mai sus, screenshot: TimescaleDB — Utilizarea input/output în timpul testului de inserție pentru o serie temporală unică de 4M.
Graficele utilizării I/O replică graficele utilizării lățimii de bandă a discului — InfluxDB are o limitare a I/O-ului, în timp ce VictoriaMetrics și TimescaleDB dispun de resurse de rezervă pentru I/O.
40M serii temporale unice
40M serii temporale unice au fost prea mari pentru InfluxDB 🙁
Rezultatele benchmark-ului:
- VictoriaMetrics: 1,7M puncte de date pe secundă; utilizarea memoriei: 29GB; utilizarea spațiului pe disc: 17GB.
- InfluxDB: nu a terminat, deoarece era necesară mai mult de 60GB de memorie.
- TimescaleDB: 330K puncte de date pe secundă, utilizarea memoriei: 2,5GB; utilizarea spațiului pe disc: 84GB.
TimescaleDB arată o utilizare excepțional de scăzută și stabilă a memoriei – 2,5GB — aceeași cantitate cât pentru metricile unice de 4M și 400K.
VictoriaMetrics a crescut lent la o viteză de 100 de mii de puncte de date pe secundă, până când toate cele 40M de nume de metrici cu etichete au fost procesate. Apoi, a atins o viteză constantă de inserție de 1,5-2,0M puncte de date pe secundă, astfel încât rezultatul final a fost de 1,7M puncte de date pe secundă.
Graficele pentru 40M serii temporale unice sunt similare cu graficele pentru 4M serii temporale unice, așa că vom sări peste acestea.
Conclusions
- TSDB-urile moderne sunt capabile să gestioneze inserții pentru milioane de serii temporale unice pe un singur server. În articolul următor, vom verifica cât de bine execută TSDB-urile interogări pentru milioane de serii temporale unice.
- O utilizare insuficientă a procesorului indică de obicei un punct slab de input/output. În plus, aceasta poate indica o blocare prea brută, unde doar câteva fire pot funcționa simultan.
- Un punct slab de input/output există cu adevărat, în special în depozitele fără SSD-uri, cum ar fi dispozitivele de blocare virtualizate ale furnizorilor de cloud.
- VictoriaMetrics oferă cea mai bună optimizare pentru depozitele lente cu un nivel scăzut de input/output. Oferă cea mai bună viteză și cea mai bună rată de comprimare.
Descărcați și încercați-o pe datele dumneavoastră. Fișierul binar static corespunzător este disponibil pe .
Aflați mai multe despre VictoriaMetrics în acest articol .
Actualizare: publicat cu rezultate reproducibile.
Actualizare #2: Citiți și .
Actualizare #3: !
Chat Telegram:
Sursa: habr.com
