Kõrge jõudlusega TSDB tulemuslikkuse test VictoriaMetrics vs TimescaleDB vs InfluxDB

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

Mõni aasta tagasi oli Zabbixi ajastu. Iga bare metal serveril oli mitte rohkem kui paar indikatiivset mõõdikut – protsessori kasutamine, mälukasutus, ketas ja võrgukasutus. Nii mahtusid tuhandete serverite mõõdikud 40 tuhande unikaalse ajarea sisse, ja Zabbix suudab kasutada MySQL-i ajareade andmete tagaplaanina 🙂

Praegu üks node_exporter vaikimisi konfiguratsioonidega pakub keskmine host üle 500 mõõdiku. On palju ekspordijaid erinevatele andmebaasidele, veebiserveritele, riistvarasüsteemidele jne. Kõik need pakuvad palju kasulikke mõõdikuid. Kõik üha rohkem rakendusi algavad erinevate mõõdikute näitamisega enda kohta. On Kubernetes koos klastrite ja pod-idega, mis näitavad palju mõõdikuid. See toob kaasa selle, et serverid esitavad tuhandeid unikaalseid mõõdikuid hostis. Seega ei ole 40K unikaalne ajareal enam suur jõudlus. See muutub mainstreamiks, millega peaks ablema hõlpsasti toime tulla ükskõik milline tänapäevane TSDB ühel serveril.

Mis on hetkel suur hulk unikaalseid ajareale? Tõenäoliselt 400K või 4M? Või 40M? Võtame kaasaegsed TSDB-d nende numbritega.

Benkmarki seadistamine

TSBS on suurepärane tööriist TSDB-de testimiseks. See võimaldab genereerida meelevaldse arvu mõõdikuid, edastades vajaliku hulga ajareale, jagatuna 10 – lipp -scale (endine -scale-var). 10 – see on mõõtmiste (mõõdikute) arv, mis genereeritakse igal hostil, serveril. Järgnevad andmekogud loodi TSBS-i abil benchmarkimiseks:

• 400K unikaalne ajareal, 60 sekundi intervall andmepunktide vahel, andmed katab täielikke 3 päeva, ~1,7B koguarv andmepunkte.
• 4M unikaalne ajareal, intervall 600 sekundit, andmed katab täielikke 3 päeva, ~1,7B koguarv andmepunkte.
• 40M unikaalne ajareal, intervall 1 tund, andmed katab täielikke 3 päeva, ~2,8B koguarv andmepunkte.

Kliendi ja serveri käivitamine toimus pühendatud instantsidel n1-standard-16 Google'i pilves. Need instantsid omasid järgmisi konfiguratsioone:

• vCPU-d: 16
• RAM: 60 GB
• Mälu: tavaline 1 TB kõvaketas. See pakub lugemise/kirjutamise ribalaiust 120 Mbit/s, 750 lugemisoperatsiooni sekundis ja 1,5K kirjutamisoperatsiooni sekundis.

TSDB-d on välja tõmmatud ametlikest docker'i piltidest ja käivitatud docker'is järgnevate seadistustega:

• 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. Üksikasjade kohta vaadake dokumentatsioon):

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

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

Andmeedastaja käivitati 16 paralleelse niidiga.

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

400K unikaalset ajasarja

Alustame lihtsatest elementidest — 400K. Jõudlustest:

• VictoriaMetrics: 2,6M andmepunkti sekundis; mälukasutamine: 3 GB; lõplik andmemahu suurus kettal: 965 MB
• InfluxDB: 1.2M andmepunkti sekundis; mälukasutamine: 8,5 GB; lõplik andmemahu suurus kettal: 1,6 GB
• Timescale: 849K andmepunkti sekundis; mälukasutamine: 2,5 GB; lõplik andmemahu suurus kettal: 50 GB

Kuidas näha ülaltoodud tulemustest, VictoriaMetrics võidab sisestusjõudluses ja tihendamise astmes. Ajakava võidab mälukasutuses, kuid see kasutab palju kettaruumi — 29 baiti andmepunkti kohta.

Allpool on vaikuse kasutuse diagrammid (CPU) iga TSDB jaoks testimise ajal:

Ülal pildil: VictoriaMetrics — CPU koormus sisestamise testi ajal unikaalse mõõdiku 400K jaoks.

Ülal pildil: InfluxDB — CPU koormus sisestamise testi ajal unikaalse mõõdiku 400K jaoks.

Ülal pildil: TimescaleDB — CPU koormus sisestamise testi ajal unikaalse mõõdiku 400K jaoks.

VictoriaMetrics kasutab kõiki saadaval olevaid vCPU-sid, samas kui InfluxDB kasutab piisavalt ainult ~2 16-st vCPU-st.

Timescale kasutab ainult 3-4 16-st vCPU-st. Ajavahemike graafikus kõrged iowait ja system proportsioonid viitavad I/O ala kitsaskohale. Vaatame ketta läbilaskevõime kasutamise graafi:

Ülalolev ekraanipilt: VictoriaMetrics – ketta läbilaskevõime kasutamine sisestustestil unikaalsete mõõdikute jaoks 400K.

Ülalolev ekraanipilt: InfluxDB – ketta läbilaskevõime kasutamine sisestustestil unikaalsete mõõdikute jaoks 400K.

Ülalolev ekraanipilt: TimescaleDB – ketta läbilaskevõime kasutamine sisestustestil unikaalsete mõõdikute jaoks 400K.

VictoriaMetrics salvestab andmeid kiirusel 20 Mbit/s, saavutades tipud kuni 45 Mbit/s. Tipphetked vastavad suurtele osalistele sulandumistele puus. LSM.

InfluxDB salvestab andmeid kiirusel 160 MB/s, samas kui 1 TB kett peaks olema piiratud kirjutamise läbilaskevõimega 120 MB/s.

TimescaleDB-l on kirjutamise läbilaskevõime piiratud 120 Mbit/s, kuid mõnikord ületab see piiri ja saavutab tipphetked kuni 220 Mbit/s. Need tipud vastavad varasema graafiku protsessorikoormuse puudujääkidele.

Vaatame I/O (sisend-väljund) kasutamise graafikuid:

Ülalolev ekraanipilt: VictoriaMetrics – I/O kasutamine sisestustestil 400K unikaalsete mõõdikute jaoks.

Ülalolev ekraanipilt: InfluxDB – I/O kasutamine sisestustestil 400K unikaalsete mõõdikute jaoks.

Ülalolev ekraanipilt: TimescaleDB – I/O kasutamine sisestustestil 400K unikaalsete mõõdikute jaoks.

Nüüd on selge, et TimescaleDB saavutab I/O piiri, mistõttu ei suuda see kasutada ülejäänud 12 vCPU-d.

4M unikaalset ajavoogu

4M ajavoogu näevad välja veidi väljakutsuvad. Kuid meie konkurendid edukalt selle eksami sooritavad. Benchmarki tulemused:

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

InfluxDB jõudlus langes 1,2 miljonilt andmepunktilt sekundis 400K ajareale 330 000 andmepunktile sekundis 4M ajareale. See on märkimisväärne jõudluse langus võrreldes teiste konkurentidega. Vaatame protsessori kasutuse graafikuid, et mõista selle languse peamist põhjust:

Ülalolev ekraanipilt: VictoriaMetrics — CPU kasutus sisestustestide ajal ainulaadse 4M ajareaga.

Ülalolev ekraanipilt: InfluxDB — CPU kasutus sisestustestide ajal ainulaadse 4M ajareaga.

Ülalolev ekraanipilt: TimescaleDB — CPU kasutus sisestustestide ajal ainulaadse 4M ajareaga.

VictoriaMetrics kasutab peaaegu kogu protsessorivõimsust (CPU). Langus lõpus vastab erakordsete LSM-i liitumiste kohta pärast kogu andmete sisestamist.

InfluxDB kasutab ainult 8 16-st vCPU-st, samas kui TimescaleDB kasutab 4 16-st vCPU-st. Mis on nende graafikutes ühist? Kõrge osakaal iowait, mis viitab taas sisendi/väljundi kitsaskohale.

TimescaleDB-l on kõrge osakaal system. Eeldame, et kõrge jõudlus põhjustas palju süsteemi kutsungite olnud või palju minor page faults.

Vaatame diskikäideldavuse graafikuid:

Ülalolev ekraanipilt: VictoriaMetrics — Diski ribakäideldavus ainulaadsete 4M mõõtmete sisestamise ajal.

Ülalolev ekraanipilt: InfluxDB — Diski ribakäideldavus ainulaadsete 4M mõõtmete sisestamise ajal.

Ülalolev ekraanipilt: TimescaleDB — Diski ribakäideldavus ainulaadsete 4M mõõtmete sisestamise ajal.

VictoriaMetrics saavutas 120 MB/s piiri tipu ajal, samas kui keskmine kirjutamiskiirus oli 40 MB/s. Tõenäoliselt toimus tipul mitu rasket LSM-i liitumist.

InfluxDB pigistab taas välja keskmise kirjakäideldavuse 200 MB/s, püstitades tipud kuni 340 MB/s kettal, mille kirjutamispiir on 120 MB/s 🙂

TimescaleDB ei ole enam kettaga piiratud. Tundub, et see on piiratud millegi muuga, mis on seotud kõrge osakaaluga süsteemse CPU koormuse.

Vaatame IO kasutuse graafikuid:

Ülalolev ekraanipilt: VictoriaMetrics — IO kasutus sisestustestide ajal ainulaadse 4M ajareaga.

Ülalolev ekraanipilt: InfluxDB — IO kasutus sisestustestide ajal ainulaadse 4M ajareaga.

Ülalolev ekraanipilt: TimescaleDB — IO kasutus sisestustestide ajal ainulaadse 4M ajareaga.

IO kasutuse graafikud jäljendavad kettalaeva kasutuse graafikuid - InfluxDB-l on IO piirangud, samas kui VictoriaMetrics ja TimescaleDB omavad varu IO ressursse.

40M unikaalset ajaseeriat

40M unikaalset ajajoonet oli InfluxDB jaoks liiga suur 🙁

Benkmarki tulemused:

• VictoriaMetrics: 1,7M andmepunkti sekundis; mälukasutuse: 29 GB; kettaruumi kasutamine: 17 GB.
• InfluxDB: ei lõpetanud, kuna see nõudis rohkem kui 60 GB mälu.
• TimescaleDB: 330K andmepunkti sekundis, mälukasutuse: 2,5 GB; kettaruumi kasutamine: 84GB.

TimescaleDB näitab erakordselt madalat ja stabiilset mälukasutust – 2,5 GB – sama palju kui unikaalsete mõõdikute puhul 4M ja 400K.

VictoriaMetrics kasvas aeglaselt 100 tuhat andmepunkti sekundis, kuni kõik 40M mõõdikute nimetused koos siltidega olid töödeldud. Siis saavutati stabiilne sisestamise kiirus 1,5-2,0M andmepunkti sekundis, nii et lõpptulemus oli 1,7M andmepunkti sekundis.

40M unikaalse ajajoonte graafikud sarnanevad 4M unikaalse ajajoonte graafikutega, seega jätame need vahele.

Järeldused

• Tänapäeva TSDB-d suudavad hallata sisestusi miljonite unikaalsete ajajoonte jaoks ühel serveril. Järgmises artiklis uurime, kui hästi TSDB-d suudavad valikut teha miljonite unikaalsete ajajoonte seas.
• Ebapiisav protsessori koormus näitab tavaliselt IO kitsaskohta. Lisaks võib see viidata liiga jämedale lukustusele, kus samal ajal võib töötada ainult mõni lõng.
• IO kitsaskohad eksisteerivad tõeliselt, eriti talletustes, kus pole SSD-sid, näiteks pilveteenuste pakkujate virtualiseeritud plokkseadmetes.
• VictoriaMetrics pakub parimat optimeerimist aeglastele madala IO-talumisega talletustele. See tagab parima kiirus ja parima tihenduse.

Laadige alla ühe serveriga VictoriaMetrics pilt ja proovige seda oma andmetel. Vastav staatiline binaarfail on saadaval GitHub.

VictoriaMetrics kohta lugege rohkem selles artiklis.

Uuendus: avaldatud artikkel, mis võrdleb VictoriaMetrics'i sisestuse jõudlust InfluxDB-ga koos korduvate tulemustega.

Uuendus #2: Loe ka artiklit vertikaalsest skaleeritavusest VictoriaMetrics vs InfluxDB vs TimescaleDB.

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

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

Allikas: habr.com