A VictoriaMetrics-t, a TimescaleDB-t és az InfluxDB-t összehasonlították egy milliárd adatpontot tartalmazó adatkészleten, amely 40 ezer egyedi idősorhoz tartozik.
Néhány évvel ezelőtt volt a Zabbix korszaka. Minden csupasz fém szerveren nem volt több, mint néhány mutató – CPU-használat, RAM-használat, lemezhasználat és hálózathasználat. Így több ezer szerver metrikái 40 ezer egyedi idősorba férnek bele, a Zabbix pedig a MySQL-t használhatja háttérként az idősoros adatokhoz :)
Jelenleg egyedül alapértelmezett konfigurációkkal több mint 500 mérőszámot biztosít egy átlagos gazdagépen. Sokan vannak különféle adatbázisokhoz, webszerverekhez, hardverrendszerekhez stb. Ezek mindegyike számos hasznos mérőszámot kínál. Minden elkezdenek különféle mutatókat beállítani maguknak. Van Kubernetes fürtökkel és podokkal, amelyek számos mérőszámot tesznek közzé. Ez azt eredményezi, hogy a szerverek gazdagépenként több ezer egyedi mérőszámot tesznek közzé. Így az egyedülálló 40K-os idősor már nem nagy teljesítményű. Egyre általánossá válik, és bármely modern TSDB-nek könnyen kezelnie kell egyetlen szerveren.
Mennyi az egyedi idősorok nagy száma jelenleg? Valószínűleg 400K vagy 4M? Vagy 40 m? Hasonlítsuk össze a modern TSDB-ket ezekkel a számokkal.
Egy benchmark telepítése
kiváló benchmarking eszköz a TSDB-k számára. Lehetővé teszi, hogy tetszőleges számú mérőszámot generáljon a szükséges számú idősor átadásával osztva 10-zel - jelző (korábbi -scale-var). A 10 az egyes gazdagépeken vagy szervereken generált mérések (metrikák) száma. A következő adatkészleteket állítottuk elő a TSBS segítségével a benchmarkhoz:
- 400 60 egyedi idősor, 3 másodperces intervallum az adatpontok között, az adatok teljes 1.7 napot ölelnek fel, összesen ~XNUMX milliárd adatpont.
- 4 millió egyedi idősor, 600 másodperces intervallum, az adatok 3 teljes napot ölelnek fel, összesen ~1.7 milliárd adatpont.
- 40 millió egyedi idősor, 1 órás intervallum, az adatok teljes 3 napot ölelnek fel, összesen ~2.8 milliárd adatpont.
Az ügyfél és a szerver dedikált példányokon futott a Google felhőben. Ezek a példányok a következő konfigurációkkal rendelkeztek:
- vCPU-k: 16
- RAM: 60 GB
- Tárhely: Normál 1TB HDD. 120 Mbps írási/olvasási sebességet, 750 olvasási műveletet és másodpercenként 1,5 XNUMX írást biztosít.
A TSDB-k a hivatalos docker-képekből lettek kivonva, és a következő konfigurációkkal futottak a dockerben:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
InfluxDB (-e) értékek szükségesek a nagy teljesítmény támogatásához. Lásd a részleteket ):
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 influxdb -
TimescaleDB (a konfiguráció innen származik fájl):
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=100Az adatbetöltő 16 párhuzamos szállal futott.
Ez a cikk csak a beillesztési referenciaértékekre vonatkozó eredményeket tartalmazza. A szelektív benchmark eredményeit külön cikkben tesszük közzé.
400 ezer egyedi idősor
Kezdjük az egyszerű elemekkel - 400K. Benchmark eredmények:
- VictoriaMetrics: 2,6 millió adatpont másodpercenként; RAM használat: 3 GB; végleges adatméret a lemezen: 965 MB
- InfluxDB: 1.2 millió adatpont másodpercenként; RAM használat: 8.5 GB; végleges adatméret a lemezen: 1.6 GB
- Időskála: 849 2,5 adatpont másodpercenként; RAM használat: 50 GB; végleges adatméret a lemezen: XNUMX GB
Amint a fenti eredményekből látható, a VictoriaMetrics nyer a beillesztési teljesítményben és a tömörítési arányban. Az idővonal nyer a RAM használatában, de sok lemezterületet használ – adatpontonként 29 bájtot.
Az alábbiakban az egyes TSDB-k CPU-használati grafikonjai láthatók a benchmark során:
Fent egy képernyőkép: VictoriaMetrics – CPU terhelés a beillesztési teszt során egy egyedi 400 XNUMX mérőszámhoz.
Fent egy képernyőkép: InfluxDB – CPU terhelés a beillesztési teszt során az egyedi 400K metrika számára.
A fenti képernyőkép látható: TimescaleDB – CPU terhelés a beillesztési teszt során egy egyedi, 400 KB-os mérőszámhoz.
A VictoriaMetrics az összes elérhető vCPU-t használja, míg az InfluxDB 2 vCPU-ból kb. 16-t.
Az időskála a 3 vCPU-ból csak 4-16-et használ. Az iowait és a rendszer magas aránya a TimescaleDB időskála grafikonon szűk keresztmetszetet jelez az input/output (I/O) alrendszerben. Nézzük a lemez sávszélesség-használati grafikonjait:
Fent egy képernyőkép: VictoriaMetrics – Lemez sávszélesség-használata a 400K egyedi metrikák beszúrási tesztjében.
Fent egy képernyőkép: InfluxDB – Lemez sávszélesség-használata beillesztéskor egyedi metrikákhoz 400K.
A fenti képernyőkép látható: TimescaleDB – Lemez sávszélesség-használata a beillesztési teszthez 400K egyedi metrikákhoz.
A VictoriaMetrics 20 Mbps-os adatrögzítést tesz lehetővé, maximum 45 Mbps-os csúcsokkal. A csúcsok nagy részleges egyesüléseknek felelnek meg a fában .
Az InfluxDB 160 MB/s sebességgel ír adatokat, míg egy 1 TB-os meghajtó írási sebesség 120 MB/s.
A TimescaleDB 120 Mbps írási sebességre korlátozódik, de néha átlépi ezt a határt, és csúcsértékekben eléri a 220 Mbps-ot. Ezek a csúcsok az előző grafikonon az elégtelen CPU kihasználtság völgyeinek felelnek meg.
Nézzük az input/output (I/O) használati grafikonokat:
Fent látható egy képernyőkép: VictoriaMetrics – 400 XNUMX egyedi metrika beszúrása teszt I/O használathoz.
Fent látható egy képernyőkép: InfluxDB – 400 XNUMX egyedi metrika beszúrása teszt I/O használathoz.
A fenti képernyőkép látható: TimescaleDB – 400 XNUMX egyedi mérőszám teszt I/O-használatának beszúrása.
Most már világos, hogy a TimescaleDB eléri I/O korlátját, így nem tudja használni a fennmaradó 12 vCPU-t.
4M egyedi idősor
A 4M idősorok kissé kihívást jelentenek. Versenyzőink azonban sikeresen letették ezt a vizsgát. Benchmark eredmények:
- VictoriaMetrics: 2,2 millió adatpont másodpercenként; RAM használat: 6 GB; végleges adatméret a lemezen: 3 GB.
- InfluxDB: 330 20,5 adatpont másodpercenként; RAM használat: 18,4 GB; végleges adatméret a lemezen: XNUMX GB.
- TimescaleDB: 480 2,5 adatpont másodpercenként; RAM használat: 52 GB; végleges adatméret a lemezen: XNUMX GB.
Az InfluxDB teljesítménye a 1,2 400 idősorok másodpercenkénti 330 millió adatpontjáról 4 milliós idősorok esetén XNUMX XNUMX adatpontra esett vissza. Ez más versenytársakhoz képest jelentős teljesítménycsökkenést jelent. Nézzük meg a CPU-használati grafikonokat, hogy megértsük a veszteség kiváltó okát:
Fent egy képernyőkép: VictoriaMetrics – CPU-használat a beillesztési teszt során egy egyedi 4M idősorhoz.
Fent egy képernyőkép: InfluxDB – CPU-használat a beillesztési teszt során egyedi 4M idősorokhoz.
A fenti képernyőkép látható: TimescaleDB – CPU-használat a beillesztési teszt során egy egyedi 4M idősorhoz.
A VictoriaMetrics a feldolgozóegység (CPU) szinte teljes teljesítményét felhasználja. A végén lévő csepp az összes adat beillesztése után fennmaradó LSM-összevonásoknak felel meg.
Az InfluxDB 8 vCPU-ból csak 16-at, míg a TimsecaleDB 4-ból 16-et használ. Mi a közös a grafikonjaikban? Magas részesedés iowait, ami ismét egy I/O szűk keresztmetszetet jelez.
A TimescaleDB aránya magas system. Feltételezzük, hogy a nagy teljesítmény sok vagy sok rendszerhívást eredményezett .
Nézzük a lemez átviteli grafikonjait:
Fent egy képernyőkép: VictoriaMetrics – Lemezsávszélesség használata 4M egyedi mérőszám beillesztéséhez.
A fenti képernyőkép látható: InfluxDB – Lemez sávszélességének használata 4M egyedi mérőszám beillesztéséhez.
A fenti képernyőkép látható: TimescaleDB – Lemezsávszélesség használata 4M egyedi mérőszám beillesztéséhez.
A VictoriaMetrics csúcson elérte a 120 MB/s-os határt, míg az átlagos írási sebesség 40 MB/s volt. Valószínűleg több nehéz LSM fúziót hajtottak végre a csúcs idején.
Az InfluxDB ismét kipréseli a 200 MB/s-os átlagos írási sebességet, maximum 340 MB/s-os csúcsokkal egy 120 MB/s írási korláttal rendelkező lemezen :)
A TimescaleDB már nem lemezkorlátozott. Úgy tűnik, hogy valami más, a magas arányhoz kapcsolódóan korlátozza системной CPU terhelés.
Nézzük az IO használati grafikonokat:
A fenti képernyőkép látható: VictoriaMetrics – I/O használata a beillesztési teszt során egy egyedi 4M idősorhoz.
A fenti képernyőkép látható: InfluxDB – I/O használata a beillesztési teszt során egy egyedi 4M idősorhoz.
A fenti képernyőkép látható: TimescaleDB – I/O használat a beillesztési teszt során egyedi 4M idősorokhoz.
Az IO használati minták tükrözik a lemez sávszélességét – az InfluxDB IO korlátozott, míg a VictoriaMetrics és a TimescaleDB tartalék IO-erőforrásokkal rendelkezik.
40 millió egyedi idősor
40 millió egyedi idősor túl nagy volt az InfluxDB számára :)
Benchmark eredmények:
- VictoriaMetrics: 1,7 millió adatpont másodpercenként; RAM használat: 29 GB; Lemezterület használat: 17 GB.
- InfluxDB: Nem fejeződött be, mert több mint 60 GB RAM-ot igényelt.
- TimescaleDB: 330 2,5 adatpont másodpercenként, RAM-használat: 84 GB; Lemezterület használat: XNUMX GB.
A TimescaleDB kivételesen alacsony és stabil RAM-használatot mutat 2,5 GB-on – ugyanaz, mint az egyedi 4M és 400K metrikák esetében.
A VictoriaMetrics lassan 100 40 adatpont/másodperc sebességgel bővült, amíg az összes 1,5 millió címkézett metrikanevet feldolgozták. Ezután 2,0-1,7 millió adatpont/másodperc tartós beillesztési sebességet ért el, így a végeredmény XNUMX millió adatpont/másodperc lett.
A 40 millió egyedi idősor grafikonjai hasonlóak a 4 millió egyedi idősor grafikonjaihoz, ezért ezeket hagyjuk ki.
Álláspontja
- A modern TSDB-k képesek több millió egyedi idősor beszúrására egyetlen szerveren. A következő cikkben megvizsgáljuk, hogy a TSDB-k milyen jól hajtják végre a kijelölést több millió egyedi idősor között.
- Az elégtelen CPU kihasználtság általában I/O szűk keresztmetszetet jelez. Azt is jelezheti, hogy a blokkolás túl durva, és egyszerre csak néhány szál futhat.
- Az I/O szűk keresztmetszet létezik, különösen a nem SSD-tárolókban, például a felhőszolgáltatók virtualizált blokkeszközeinél.
- A VictoriaMetrics biztosítja a legjobb optimalizálást a lassú, alacsony I/O tároláshoz. Ez biztosítja a legjobb sebességet és a legjobb tömörítési arányt.
Letöltés és próbálja ki az adatain. A megfelelő statikus bináris a következő címen érhető el .
Olvasson többet a VictoriaMetrics-ről ebben .
Frissítés: közzétéve reprodukálható eredménnyel.
2. frissítés: Olvassa el .
3. frissítés: !
Telegram chat:
Forrás: will.com