Kõrge jõudlusega TSDB testimine VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB ja InfluxDB võrreldi eelnevas artiklis miljardi andmepunktiga andmekogumil, mis kuulub 40K unikaalsele ajareale.

Mõni aasta tagasi oli Zabbixi aeg. Igal bare metal serveril oli vaid mõned näitajad – protsessori kasutus, mälu kasutus, ketta kasutus ja võrgu kasutus. Seega suudavad tuhandete serverite meetrikad mahtuda 40 000 unikaalsesse ajareasse, ja Zabbix saab kasutada MySQL-i ajarealiste andmete tagaplaanina 🙂

Praegu pakub üks node_exporter vaikimisi seadistustega enam kui 500 näitajat keskmisel hostil. On olemas hulgaliselt eksportijaid erinevate andmebaaside, veebiserverite, riistvarasüsteemide jms jaoks. Kõik need pakuvad mitmeid kasulikke näitajaid. Kõik rohkem ja rohkem rakendusi hakkavad esitama erinevaid näitajaid. On olemas Kubernetes koos klastrite ja pod'idega, mis avavad mitmeid meetrikaid. See toob kaasa selle, et serverid esitavad tuhandeid unikaalseid näitajaid hesti. Seega, unikaalne ajajoon 40K ei ole enam kõrge jõudluse näitaja. See muutub peavooluks, mida peab suutma töödelda iga kaasaegne TSDB ühel serveril.

Mis on hetkel suur hulk unikaalseid ajajoone? Kas see on 400K või 4M? Või 40M? Võrrelgem kaasaegseid TSDB-sid nende numbritega.

Benchmarki seadmine

TSBS – on suurepärane benchmarkimine tool TSDB-de jaoks. See võimaldab genereerida meelevaldset hulka näitajaid, edastades vajaliku arvu ajajoone, mille jagamine on 10 — flaag -scale (endine -scale-var). 10 on mõõtmete (näitajate) arv, mis genereeritakse iga hosti, serveri kohta. Järgmised andmekogud loodi TSBS-i abil benchmarkimiseks:

• 400K unikaalne ajajoon, 60 sekundi intervall andmepunktide vahel, andmed katavad täpselt 3 päeva, ~1,7B kokku andmepunkti.
• 4M ainulaadne ajasari, intervall 600 sekundit, andmed katavad täielikult 3 päeva, ~1.7B kogus kogu andmepunkte.
• 40M ainulaadne ajasari, intervall 1 tund, andmed katavad täielikult 3 päeva, ~2.8 B kogus kogu andmepunkte.

Kliendi ja serveri käivitamine toimus pühendatud eksperimentides. n1-standard-16 Google'is. Need eksperdid olid järgmiste konfiguratsioonidega:

• vCPUs: 16
• RAM: 60 GB
• Salvestus: standardne 1TB kõvaketas. Tagab lugemise/kirjutamise ribalaiuse 120 Mbit/s, 750 lugemisoperatsiooni sekundis ja 1,5K kirjutamisoperatsiooni sekundis.

TSDB-d on välja tõstetud ametlikest Docker-piltidest ja käivitatud Dockeris järgmiste konfiguratsioonidega:

• VictoriaMetrics:

  docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics

• InfluxDB väärtused (-e vajalikud kõrge jõudluse toetamiseks. Rohkem teavet vaata dokumentatsioonis):

  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 (konfiguratsioon võeti failist): sellest файла):

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

Andme laadija käivitus 16 samaaegse niidiga.

See artikkel sisaldab ainult tulemusi sisestamise mõõdikute kohta. Valikuline jõudluse hindamine avaldatakse eraldi artiklis.

400K ainulaadset ajajoont

Alustame lihtsatest elementidest — 400K. Jõudlusmõõdikud:

• VictoriaMetrics: 2,6 miljonit andmepunkti sekundis; mälu kasutamine: 3 GB; andmete lõplik suurus ketasel: 965 MB
• InfluxDB: 1,2 miljonit andmepunkti sekundis; mälu kasutamine: 8,5 GB; andmete lõplik suurus ketasel: 1,6 GB
• Timescale: 849K andmepunkti sekundis; mälu kasutamine: 2,5 GB; andmete lõplik suurus ketasel: 50 GB

Nagu näha ülaltoodud tulemustest, on VictoriaMetrics sisestuse ja kokkusurumise osas kõige tõhusam. Ajaline skaala kasutab rohkem mälu, kuid see tarbib palju kõvakettaruumi — 29 baiti andmepunkti kohta.

Allpool on esitatud igas TSDB-s kasutatava protsessori (CPU) kasutamise graafikud benchmarkimise ajal:

Ülaltoodud ekraanipilt: VictoriaMetrics — CPU koormus sisestustesti ajal unikaalsele mõõdikule 400K.

Ülaltoodud ekraanipilt: InfluxDB — CPU koormus sisestustesti ajal unikaalsele mõõdikule 400K.

Ülaltoodud ekraanipilt: TimescaleDB — CPU koormus sisestustesti ajal unikaalsele mõõdikule 400K.

VictoriaMetrics kasutab kõiki saadaval olevaid vCPUs, samas kui InfluxDB kasutab vaid ~2 16-st vCPUs.

Timescale kasutab ainult 3-4 16-st vCPUs. Kõrged iowait ja system osakaalad TimescaleDB ajaliste graafikute puhul näitavad I/O alamsüsteemis kitsaskohta. Vaatame diskikasutuse ribalaiuse graafikuid:

Ülaltoodud ekraanipilt: VictoriaMetrics — Diskikasutuse ribalaius sisestustesti ajal unikaalsete mõõdikute puhul 400K.

Ülalolev ekraanipilt: InfluxDB — Ketta ribalaiuse kasutamine sisestustestide korral unikaalsete 400K mõõdikute jaoks.

Ülalolev ekraanipilt: TimescaleDB — Ketta ribalaiuse kasutamine sisestustestide korral unikaalsete 400K mõõdikute jaoks.

VictoriaMetrics salvestab andmeid kiirusel 20 Mbit/s, ulatudes harva kuni 45 Mbit/s. Tipphetked vastavad suurtele osalistele ühinemistele puu struktuuris. LSM.

InfluxDB salvestab andmeid kiirusel 160 MB/s, samas kui 1 TB ketas peaks olema piiratud kirjutamise ribalaiusega 120 MB/s.

TimescaleDB on piiratud kirjutamise ribalaiusega 120 Mbit/s, kuid mõnikord ületab see piiri ja saavutab tipptasemel 220 Mbit/s. Need tipud vastavad protsessori madala koormuse eelnevale diagrammile.

Vaadakem sisendi- ja väljundi (I/O) kasutuse graafikuid:

Ülalolev ekraanipilt: VictoriaMetrics — Sisendi-väljundi kasutamine sisestustestide korral unikaalsete 400K mõõdikute jaoks.

Ülalolev ekraanipilt: InfluxDB — Sisendi-väljundi kasutamine sisestustestide korral unikaalsete 400K mõõdikute jaoks.

Ülalolev ekraanipilt: TimescaleDB — Sisendi-väljundi kasutamine sisestustestide korral unikaalsete 400K mõõdikute jaoks.

Nüüd on selge, et TimescaleDB jõuab sisendi-väljundi piirini, seetõttu ei suuda ta kasutada ülejäänud 12 vCPU-d.

4M unikaalset ajaseeriat

4M ajaseeriad tunduvad veidi väljakutsuvad. Kuid meie konkurendid läbivad selle eksami edukalt. Jõudluse testimistulemused:

• VictoriaMetrics: 2,2M andmepunkti sekundis; mälu kasutamine: 6 GB; lõplik andmete suurus kettal: 3 GB.
• InfluxDB: 330K andmepunkti sekundis; mälu kasutamine: 20,5 GB; lõplik andmete suurus kettal: 18,4 GB.
• TimescaleDB: 480K andmepunkti sekundis; mälu kasutamine: 2,5 GB; lõplik andmete suurus kettal: 52 GB.

InfluxDB jõudlus langes 1,2 miljoni andmepunkti sekundi pealt 400K ajaseeria jaoks 330 000 andmepunkti sekundi peale 4M ajaseeria jaoks. See on märkimisväärne jõudluse kadu võrreldes teiste konkurentidega. Vaatame protsessori kasutamise graafikuid, et mõista selle kadu põhjuseid:

Ülal olev ekraanipilt: VictoriaMetrics — CPU kasutamine sisestustestil unikaalse ajaseeria 4M jaoks.

Ülalolev ekraanipilt: InfluxDB — CPU kasutamine sisestustestil unikaalse ajajoone jaoks 4M.

Ülalolev ekraanipilt: TimescaleDB — CPU kasutamine sisestustestil unikaalse ajajoone jaoks 4M.

VictoriaMetrics kasutab peaaegu kogu protsessori (CPU) võimsust. Langus lõpus vastab ülejäänud LSM-i ühinemistele pärast kõigi andmete sisestamist.

InfluxDB kasutab vaid 8 16-st vCPust, samas kui TimescaleDB kasutab 4 16-st vCPust. Mis on nende graafikute ühine joon? Suur iowait osakaal iowait, mis viitab taas sisendi-väljundi kitsaskohale.

TimescaleDB-l on kõrge iowait osakaal süsteem. Eeldame, et kõrge võimsus tõi kaasa palju süsteemikutsungite või palju minor page faults.

Vaadakem ketta läbilaskevõime graafikuid:

Ülalolev ekraanipilt: VictoriaMetrics — ketta läbilaskevõime kasutamine 4M unikaalse mõõtiku sisestamiseks.

Ülalolev ekraanipilt: InfluxDB — ketta läbilaskevõime kasutamine 4M unikaalse mõõtiku sisestamiseks.

Ülalolev ekraanipilt: TimescaleDB — ketta läbilaskevõime kasutamine 4M unikaalse mõõtiku sisestamiseks.

VictoriaMetrics on saavutanud tippu 120 MB/s, samas kui keskmine kirjutuskiirus oli 40 MB/s. Tõenäoliselt tehti tipptundides mitu keerulist LSM-i ühinemist.

InfluxDB saavutab taas keskmise kirjutusvõime 200 MB/s, ulatudes tippudeni 340 MB/s 120 MB/s kirjutuspiiranguga kettal 🙂

TimescaleDB ei ole enam kettaga piiratud. Tundub, et see on piiratud millelegi muule, mis on seotud kõrge koormusega. süsteemi CPU koormus.

Vaatame IO kasutuse graafikuid:

Ülaltoodud ekraanipilt: VictoriaMetrics - IO kasutus sisestustestide ajal unikaalse ajajoonte jaoks, 4M.

Ülaltoodud ekraanipilt: InfluxDB - IO kasutus sisestustestide ajal unikaalse ajajoonte jaoks, 4M.

Ülaltoodud ekraanipilt: TimescaleDB - IO kasutus sisestustestide ajal unikaalse ajajoonte jaoks, 4M.

IO kasutuse graafikud kordavad ketta ribalaiuse kasutuse graafikuid - InfluxDB on IO piiratud, samas kui VictoriaMetrics ja TimescaleDB omavad IO ressursse üle.

40M unikaalset ajajoonte

40M unikaalset ajajoonte olid InfluxDB jaoks liiga suured 🙁

Katsed tulemused:

• VictoriaMetrics: 1,7 miljonit andmepunkti sekundis; mälu kasutamine: 29 GB; ketta ruumi kasutamine: 17 GB.
• InfluxDB: ei lõpetanud, kuna selle jaoks oli vajalik rohkem kui 60 GB mälu.
• TimescaleDB: 330 tuhat andmepunkti sekundis, mälu kasutamine: 2,5 GB; ketta ruumi kasutamine: 84GB.

TimescaleDB näitab erakordselt madalat ja stabiilset mälu kasutust – 2,5 GB — sama palju kui unikaalsetele mõõtmetele 4M ja 400K.

VictoriaMetrics kasvas aeglaselt 100 tuhandest andmepunktist sekundis, kuni kõik 40M mõõtmenimekandidaadid koos siltidega olid töödeldud. Seejärel saavutas see stabiilse sisestuskiirusena 1,5-2,0 miljonit andmepunkti sekundis, seega lõplik tulemus oli 1,7 miljonit andmepunkti sekundis.

Graafikud 40M unikaalse ajaseeria jaoks on samad, mis 4M unikaalse ajaseeria jaoks, seega jätame need vahele.

Järeldused

• Kaasaegsed TSDB-d on võimelised käitlema sisestusi miljonite unikaalsete ajaseeriate jaoks ühel serveril. Järgmises artiklis vaatame, kui hästi TSDB-d täidavad valimist miljonitest unikaalsetest ajaseeriatest.
• Puuduv protsessori koormus viitab tavaliselt I/O kitsaskohale. Samuti võib see viidata liiga jäigale lukustusele, kus korraga saab töötada ainult mõni lõng.
• I/O kitsaskohad on tõeliselt olemas, eriti ladudes, kus ei ole SSD-sid, nagu pilvepakkujate virtualiseeritud plokiseadmed.
• VictoriaMetrics tagab parima optimeerimise aeglastele madala I/O säästmisvõimetega ladudele. See pakub parimat kiirus ja parimat tihendust.

Laadi alla ühe serveri VictoriaMetrics pilt ja proovi seda oma andmetel. Vastav staatiline binaarfail on saadaval GitHub.

VictoriaMetrics'i kohta loe rohkem sellest artiklis.

Uuendus: on avaldatud artikkel, mis võrdleb VictoriaMetrics'i sisestamiste jõudlust InfluxDB-ga kaasaskantavate tulemustega.

Uuendus#2: Vaata ka artiklit VictoriaMetrics'i vertikaalsest skaleeritavusest vs InfluxDB vs TimescaleDB.

Uuendus #3: VictoriaMetrics on nüüd avatud lähtekoodiga!

Telegrami vestlus: https://t.me/VictoriaMetrics_ru1

Allikas: habr.com