VictoriaMetricsi, TimescaleDB ja InfluxDB võrreldi aastal miljardi andmepunktiga andmestikul, mis kuuluvad 40 XNUMX ainulaadsesse aegreasse.
Mõni aasta tagasi oli Zabbixi ajastu. Igal metallist serveril ei olnud rohkem kui paar näitajat – protsessori kasutus, RAM-i kasutus, kettakasutus ja võrgukasutus. Nii mahuvad tuhandete serverite mõõdikud 40 tuhandesse unikaalsesse aegreasse ja Zabbix saab kasutada MySQL-i aegridade andmete taustaprogrammina :)
Hetkel üksi vaikekonfiguratsioonidega pakub keskmisel hostil üle 500 mõõdiku. Seal on palju erinevate andmebaaside, veebiserverite, riistvarasüsteemide jne jaoks. Need kõik pakuvad mitmesuguseid kasulikke mõõdikuid. Kõik hakkavad endale erinevaid näitajaid seadma. Kubernetes on klastrite ja kaunadega, mis paljastavad palju mõõdikuid. Selle tulemuseks on serverid, mis paljastavad tuhandeid kordumatuid mõõdikuid hosti kohta. Seega pole ainulaadne 40K aegrida enam suure võimsusega. See on muutumas peavooluks ja seda peaks hõlpsasti käsitlema iga kaasaegne TSDB ühes serveris.
Kui suur on unikaalsete aegridade arv hetkel? Ilmselt 400K või 4M? Või 40 m? Võrdleme tänapäevaseid TSDB-sid nende numbritega.
Võrdlusaluse paigaldamine
on suurepärane võrdlusuuringute tööriist TSDB-de jaoks. See võimaldab teil genereerida suvalise arvu mõõdikuid, edastades vajaliku arvu aegridu jagatuna 10-ga - lipp (endine -scale-var). 10 on igas hostis või serveris genereeritud mõõtmiste (mõõdikute) arv. TSBS-i abil loodi võrdlusaluseks järgmised andmekogumid:
- 400 60 ainulaadset aegrida, 3-sekundiline intervall andmepunktide vahel, andmed hõlmavad tervet 1.7 päeva, andmepunktide koguarv ~XNUMX miljardit.
- 4 miljonit unikaalset aegrida, 600-sekundiline intervall, andmed hõlmavad 3 täispäeva, andmepunktide koguarv ~1.7 miljardit.
- 40 miljonit unikaalset aegrida, 1-tunnine intervall, andmed hõlmavad 3 täispäeva, andmepunktide koguarv ~2.8 miljardit.
Klient ja server töötasid spetsiaalsetel eksemplaridel Google'i pilves. Nendel juhtudel olid järgmised konfiguratsioonid:
- vCPU-d: 16
- RAM: 60 GB
- Salvestusruum: standardne 1TB kõvaketas. See tagab 120 Mbps lugemise/kirjutamise läbilaskevõime, 750 lugemistoimingut sekundis ja 1,5K kirjutamiskiirust sekundis.
TSDB-d ekstraheeriti ametlikest dockeri piltidest ja käitati 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 (-e) väärtused on vajalikud suure võimsuse toetamiseks. Vaadake üksikasju ):
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õetud kohast fail):
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=100Andmelaadijat käivitati 16 paralleelse keermega.
See artikkel sisaldab ainult sisestamise võrdlusaluste tulemusi. Valikulise võrdlusaluse tulemused avaldatakse eraldi artiklis.
400K unikaalne aegrida
Alustame lihtsatest elementidest - 400K. Võrdlusuuringu tulemused:
- VictoriaMetrics: 2,6 miljonit andmepunkti sekundis; RAM-i kasutus: 3 GB; lõplik andmemaht kettal: 965 MB
- InfluxDB: 1.2 miljonit andmepunkti sekundis; RAM-i kasutus: 8.5 GB; lõplik andmemaht kettal: 1.6 GB
- Ajaskaala: 849 2,5 andmepunkti sekundis; RAM-i kasutus: 50 GB; lõplik andmemaht kettal: XNUMX GB
Nagu ülaltoodud tulemustest näha, võidab VictoriaMetrics sisestamise jõudluse ja tihendussuhte osas. Ajaskaala võidab RAM-i kasutamises, kuid see kasutab palju kettaruumi – 29 baiti andmepunkti kohta.
Allpool on võrdlusuuringu ajal iga TSDB protsessori kasutamise graafikud:
Ülal on ekraanipilt: VictoriaMetrics – protsessori koormus sisestustesti ajal ainulaadse 400 XNUMX mõõdiku jaoks.
Ülal on ekraanipilt: InfluxDB – protsessori koormus sisestustesti ajal unikaalse mõõdiku 400K jaoks.
Ülal on ekraanipilt: TimescaleDB – protsessori koormus sisestustesti ajal ainulaadse 400 XNUMX mõõdiku jaoks.
VictoriaMetrics kasutab kõiki saadaolevaid vCPU-sid, samas kui InfluxDB kasutab alakasutamist ~ 2 vCPU-st 16-st.
Ajaskaala kasutab 3-st vCPU-st ainult 4–16. Iowaiti ja süsteemi suur osakaal TimescaleDB ajaskaala graafikus viitab kitsaskohale sisend/väljund (I/O) alamsüsteemis. Vaatame ketta ribalaiuse kasutamise graafikuid:
Ülal on ekraanipilt: VictoriaMetrics – ketta ribalaiuse kasutamine unikaalsete mõõdikute sisestamise testis 400K.
Ülal on ekraanipilt: InfluxDB – ketta ribalaiuse kasutamine sisestustestil unikaalsete mõõdikute jaoks 400K.
Ülal on ekraanipilt: TimescaleDB – unikaalsete mõõdikute 400K ketta ribalaiuse kasutamine sisestamise testil.
VictoriaMetrics salvestab andmeid kiirusel 20 Mbps, tippkiirusega kuni 45 Mbps. Tipud vastavad puu suurele osalisele ühinemisele .
InfluxDB kirjutab andmeid kiirusega 160 MB/s, samas kui 1 TB draiv kirjutusvõimsus 120 MB/s.
TimescaleDB on piiratud kirjutamisvõimsusega 120 Mbps, kuid mõnikord ületab see piiri ja saavutab tippväärtuste 220 Mbps. Need piigid vastavad eelmise graafiku ebapiisava CPU kasutuse orgudele.
Vaatame sisend/väljund (I/O) kasutusgraafikuid:
Ülal on ekraanipilt: VictoriaMetrics – sisestage 400 XNUMX unikaalse mõõdiku sisend-/väljundkasutustest.
Ülal on ekraanipilt: InfluxDB – sisestage 400 XNUMX unikaalse mõõdiku sisend-/väljundkasutustest.
Ülal on ekraanipilt: TimescaleDB – sisestage 400 XNUMX unikaalse mõõdiku sisend-/väljundkasutustest.
Nüüd on selge, et TimescaleDB on saavutamas oma I/O piiri, mistõttu ei saa see kasutada ülejäänud 12 vCPU-d.
4 miljonit unikaalset aegrida
4M aegread näevad veidi väljakutsuvad. Kuid meie konkurendid sooritavad selle eksami edukalt. Võrdlusuuringu tulemused:
- VictoriaMetrics: 2,2 miljonit andmepunkti sekundis; RAM-i kasutus: 6 GB; lõplik andmemaht kettal: 3 GB.
- InfluxDB: 330 20,5 andmepunkti sekundis; RAM-i kasutus: 18,4 GB; lõplik andmemaht kettal: XNUMX GB.
- TimescaleDB: 480 2,5 andmepunkti sekundis; RAM-i kasutus: 52 GB; lõplik andmemaht kettal: XNUMX GB.
InfluxDB jõudlus langes 1,2 miljonilt andmepunktilt sekundis 400 330 aegrea puhul 4 XNUMX andmepunktini sekundis XNUMX miljoni aegrea puhul. See on märkimisväärne jõudluse langus võrreldes teiste konkurentidega. Vaatame protsessori kasutamise graafikuid, et mõista selle kaotuse algpõhjust:
Ülal on ekraanipilt: VictoriaMetrics – protsessori kasutamine sisestustesti ajal ainulaadse 4M aegrea jaoks.
Ülal on ekraanipilt: InfluxDB – protsessori kasutamine sisestustesti ajal ainulaadsete 4M aegridade jaoks.
Ülal on ekraanipilt: TimescaleDB – protsessori kasutus sisestustesti ajal ainulaadse 4M aegrea jaoks.
VictoriaMetrics kasutab peaaegu kogu protsessori (CPU) võimsust. Lõpus olev langus vastab järelejäänud LSM-i liitmistele pärast kõigi andmete sisestamist.
InfluxDB kasutab ainult 8 vCPU-st 16-st, TimsecaleDB aga 4 vCPU-st 16-st. Mis on nende graafikutel ühist? Kõrge osakaal iowait, mis viitab taas I/O kitsaskohale.
TimescaleDB-l on suur osakaal system. Eeldame, et suure võimsuse tulemuseks oli palju või palju süsteemikõnesid .
Vaatame ketta läbilaskevõime graafikuid:
Ülal on ekraanipilt: VictoriaMetrics – ketta ribalaiuse kasutamine 4M unikaalse mõõdiku sisestamiseks.
Ülal on ekraanipilt: InfluxDB – ketta ribalaiuse kasutamine 4M unikaalse mõõdiku sisestamiseks.
Ülal on ekraanipilt: TimescaleDB – ketta ribalaiuse kasutamine 4M unikaalse mõõdiku sisestamiseks.
VictoriaMetrics saavutas tipphetkel 120 MB/s piiri, samas kui keskmine kirjutamiskiirus oli 40 MB/s. Tõenäoliselt viidi tippajal läbi mitu rasket LSM-i liitmist.
InfluxDB pigistab jällegi välja keskmise kirjutusvõimsuse 200 MB/s tippudega kuni 340 MB/s kettale kirjutuslimiidiga 120 MB/s :)
TimescaleDB ei ole enam kettaga piiratud. Näib, et seda piirab miski muu, mis on seotud suure osakaaluga системной CPU koormus.
Vaatame IO kasutamise graafikuid:
Ülal on ekraanipilt: VictoriaMetrics – sisend-/väljundi kasutamine sisestustesti ajal ainulaadse 4M aegrea jaoks.
Ülal on ekraanipilt: InfluxDB – sisend-/väljundi kasutamine sisestustesti ajal ainulaadse 4M aegrea jaoks.
Ülal on ekraanipilt: TimescaleDB – sisend-/väljundkasutus sisestustesti ajal ainulaadsete 4M aegridade jaoks.
IO kasutusmustrid peegeldavad ketta ribalaiuse omasid – InfluxDB on IO piiratud, samas kui VictoriaMetricsil ja TimescaleDB-l on vabad IO-ressursid.
40 miljonit unikaalset aegrida
40 miljonit unikaalset aegrida oli InfluxDB jaoks liiga suur :)
Võrdlusuuringu tulemused:
- VictoriaMetrics: 1,7 miljonit andmepunkti sekundis; RAM-i kasutus: 29 GB; Kettaruumi kasutus: 17 GB.
- InfluxDB: ei lõpetanud, kuna see nõudis rohkem kui 60 GB muutmälu.
- TimescaleDB: 330 2,5 andmepunkti sekundis, RAM-i kasutus: 84 GB; Kettaruumi kasutus: XNUMX GB.
TimescaleDB näitab erakordselt madalat ja stabiilset RAM-i kasutust 2,5 GB juures – sama, mis ainulaadsete 4M ja 400K mõõdikute puhul.
VictoriaMetrics suurenes aeglaselt kiirusega 100 40 andmepunkti sekundis, kuni kõik 1,5 miljonit märgistatud mõõdiku nime töödeldi. Seejärel saavutas ta püsiva sisestamise kiiruse 2,0–1,7 miljonit andmepunkti sekundis, seega oli lõpptulemuseks XNUMX miljonit andmepunkti sekundis.
40 miljoni kordumatu aegrea graafikud on sarnased 4 miljoni kordumatu aegrea graafikutega, nii et jätame need vahele.
Järeldused
- Kaasaegsed TSDB-d on võimelised ühes serveris töötlema miljonite ainulaadsete aegridade lisasid. Järgmises artiklis testime, kui hästi teostavad TSDB-d valikut miljonite ainulaadsete aegridade lõikes.
- CPU ebapiisav kasutamine viitab tavaliselt sisend-väljundi kitsaskohale. See võib viidata ka sellele, et blokeering on liiga jäme, korraga saab läbida vaid paar keerme.
- I/O kitsaskoht on olemas, eriti mitte-SSD-mäluseadmes, näiteks pilveteenuse pakkujate virtualiseeritud plokkseadmetes.
- VictoriaMetrics pakub parimat optimeerimist aeglase ja madala I/O-salvestuse jaoks. See tagab parima kiiruse ja parima tihendusastme.
Laadige alla ja proovige seda oma andmetega. Vastav staatiline binaarfail on saadaval aadressil .
Lisateavet VictoriaMetricsi kohta leiate siit .
Värskendus: avaldatud reprodutseeritavate tulemustega.
Värskendus nr 2: lugege ka .
Värskendus nr 3: !
Telegrami vestlus:
Allikas: www.habr.com