VictoriaMetricsiä, TimescaleDB:tä ja InfluxDB:tä verrattiin vuonna tietojoukossa, jossa on miljardi datapistettä, jotka kuuluvat 40 XNUMX yksilölliseen aikasarjaan.
Muutama vuosi sitten oli Zabbixin aikakausi. Jokaisella paljasmetallipalvelimella oli vain muutama indikaattori - suorittimen käyttö, RAM-käyttö, levyn käyttö ja verkon käyttö. Tällä tavalla tuhansien palvelimien mittarit mahtuvat 40 XNUMX ainutlaatuiseen aikasarjaan, ja Zabbix voi käyttää MySQL:ää aikasarjatietojen taustana :)
Tällä hetkellä yksin oletuskokoonpanoilla tarjoaa yli 500 mittaria keskimääräisellä isännällä. On olemassa monia erilaisille tietokannoille, web-palvelimille, laitteistojärjestelmille jne. Ne kaikki tarjoavat erilaisia hyödyllisiä mittareita. Kaikki alkaa asettaa itselleen erilaisia indikaattoreita. On olemassa Kubernetes, jossa on klustereita ja podeja, jotka paljastavat monia mittareita. Tämä johtaa siihen, että palvelimet paljastavat tuhansia ainutlaatuisia mittareita isäntä kohden. Joten ainutlaatuinen 40 XNUMX aikasarja ei ole enää suuritehoinen. Siitä on tulossa valtavirtaa, ja minkä tahansa nykyaikaisen TSDB:n pitäisi helposti käsitellä sitä yhdellä palvelimella.
Mikä on suuri määrä ainutlaatuisia aikasarjoja tällä hetkellä? Varmaan 400K tai 4M? tai 40m? Verrataanpa nykyaikaisia TSDB:itä näihin lukuihin.
Vertailuarvon asentaminen
on erinomainen benchmarking-työkalu TSDB:ille. Sen avulla voit luoda mielivaltaisen määrän mittareita välittämällä tarvittava määrä aikasarjoja jaettuna 10:llä - lippu (entinen -scale-var). 10 on kullekin isännälle tai palvelimelle luotujen mittausten (metriikan) lukumäärä. Seuraavat tietojoukot luotiin käyttämällä TSBS:ää vertailukohtana:
- 400 60 yksilöllistä aikasarjaa, 3 sekunnin aikaväli datapisteiden välillä, tiedot kattavat täydet 1.7 päivää, ~XNUMX miljardia datapisteiden kokonaismäärä.
- 4 miljoonaa yksilöllistä aikasarjaa, 600 sekunnin väli, data kattaa 3 täyttä päivää, ~1.7 miljardia datapisteiden kokonaismäärä.
- 40 miljoonaa yksilöllistä aikasarjaa, 1 tunnin väli, data kattaa 3 täyttä päivää, ~2.8 miljardia datapisteiden kokonaismäärä.
Asiakas ja palvelin toimivat omistetuissa tapauksissa Google pilvessä. Näissä tapauksissa oli seuraavat kokoonpanot:
- vCPU:t: 16
- RAM: 60 Gt
- Tallennus: Vakio 1TB HDD. Se tarjoaa 120 Mbps luku-/kirjoitusnopeuden, 750 lukutoimintoa sekunnissa ja 1,5 XNUMX kirjoitusta sekunnissa.
TSDB:t poimittiin virallisista Docker-kuvista ja ajettiin Dockerissa seuraavilla kokoonpanoilla:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
InfluxDB (-e) -arvot vaaditaan tukemaan suurta tehoa. Katso lisätietoja kohdasta ):
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 (konfiguraatio otettu osoitteesta tiedosto):
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=100Tiedonlataajaa ajettiin 16 rinnakkaisella säikeellä.
Tämä artikkeli sisältää vain lisäysvertailujen tulokset. Valikoivan benchmarkin tulokset julkaistaan erillisessä artikkelissa.
400 XNUMX ainutlaatuista aikasarjaa
Aloitetaan yksinkertaisista elementeistä - 400K. Vertailutulokset:
- VictoriaMetrics: 2,6 miljoonaa datapistettä sekunnissa; RAM-muistin käyttö: 3 Gt; lopullinen tietojen koko levyllä: 965 MB
- InfluxDB: 1.2 miljoonaa datapistettä sekunnissa; RAM-muistin käyttö: 8.5 Gt; lopullinen tietojen koko levyllä: 1.6 Gt
- Aikaskaala: 849 2,5 datapistettä sekunnissa; RAM-muistin käyttö: 50 Gt; lopullinen tietojen koko levyllä: XNUMX Gt
Kuten yllä olevista tuloksista näet, VictoriaMetrics voittaa lisäyssuorituskyvyn ja pakkaussuhteen. Aikajana voittaa RAM-muistin käytössä, mutta se käyttää paljon levytilaa - 29 tavua datapistettä kohti.
Alla on kunkin TSDB:n suorittimen käyttökaaviot vertailun aikana:
Yllä on kuvakaappaus: VictoriaMetrics - Prosessorin kuormitus lisäystestin aikana ainutlaatuista 400 XNUMX metriikkaa varten.
Yllä on kuvakaappaus: InfluxDB - Prosessorin kuormitus lisäystestin aikana ainutlaatuiselle metriikolle 400K.
Yllä on kuvakaappaus: TimescaleDB - prosessorin kuormitus lisäystestin aikana ainutlaatuiselle 400 kt:lle.
VictoriaMetrics käyttää kaikkia saatavilla olevia vCPU:ita, kun taas InfluxDB alikäyttöä ~2:sta 16 vCPU:sta.
Aikaskaala käyttää vain 3-4 vCPU:sta 16:sta. Suuret iowaitin ja järjestelmän osuudet TimescaleDB-aikaskaalakaaviossa osoittavat pullonkaulan tulo/lähtö (I/O) -alijärjestelmässä. Katsotaanpa levyn kaistanleveyden käyttökaavioita:
Yllä on kuvakaappaus: VictoriaMetrics - Levyn kaistanleveyden käyttö Unique Metrics 400K:n lisäystestissä.
Yllä on kuvakaappaus: InfluxDB - Levyn kaistanleveyden käyttö lisäystestissä 400K Unique Metricsille.
Yllä on kuvakaappaus: TimescaleDB - Levyn kaistanleveyden käyttö lisäystestissä 400K Unique Metricsille.
VictoriaMetrics tallentaa tietoja 20 Mbps:n nopeudella huipuilla jopa 45 Mbps. Huiput vastaavat suuria osittaisia sulautumisia puussa .
InfluxDB kirjoittaa tietoja nopeudella 160 Mt/s, kun taas 1 Tt:n asema kirjoitusnopeus 120 MB/s.
TimescaleDB on rajoitettu 120 Mbps:n kirjoitusnopeuteen, mutta joskus se rikkoo tämän rajan ja saavuttaa huippuarvoissa 220 Mbps. Nämä huiput vastaavat edellisen kaavion riittämättömän suorittimen käyttöasteen laaksoja.
Katsotaanpa tulo/lähtö (I/O) käyttökaavioita:
Yllä on kuvakaappaus: VictoriaMetrics - Lisää testi-I/O-käyttö 400 XNUMX ainutlaatuiselle mittarille.
Yllä on kuvakaappaus: InfluxDB - Lisää testi-I/O-käyttö 400 XNUMX ainutlaatuiselle mittarille.
Yllä on kuvakaappaus: TimescaleDB - Lisää testi-I/O-käyttö 400 XNUMX ainutlaatuiselle mittarille.
Nyt on selvää, että TimescaleDB saavuttaa I/O-rajansa, joten se ei voi käyttää jäljellä olevia 12 vCPU:ta.
4 miljoonaa ainutlaatuista aikasarjaa
4M-aikasarjat näyttävät hieman haastavilta. Mutta kilpailijamme läpäisevät tämän kokeen onnistuneesti. Vertailutulokset:
- VictoriaMetrics: 2,2 miljoonaa datapistettä sekunnissa; RAM-muistin käyttö: 6 Gt; lopullinen tietojen koko levyllä: 3 Gt.
- InfluxDB: 330 20,5 datapistettä sekunnissa; RAM-muistin käyttö: 18,4 Gt; lopullinen tietojen koko levyllä: XNUMX Gt.
- TimescaleDB: 480 2,5 datapistettä sekunnissa; RAM-muistin käyttö: 52 Gt; lopullinen tietojen koko levyllä: XNUMX Gt.
InfluxDB-suorituskyky laski 1,2 miljoonasta datapisteestä sekunnissa 400 330 aikasarjassa 4 XNUMX datapisteeseen sekunnissa XNUMX miljoonan aikasarjan osalta. Tämä on huomattava suorituskyvyn menetys verrattuna muihin kilpailijoihin. Katsotaanpa suorittimen käyttökaavioita ymmärtääksemme tämän menetyksen perimmäisen syyn:
Yllä on kuvakaappaus: VictoriaMetrics - CPU:n käyttö lisäystestin aikana ainutlaatuisille 4M-aikasarjoille.
Yllä on kuvakaappaus: InfluxDB - CPU:n käyttö lisäystestin aikana ainutlaatuisille 4M-aikasarjoille.
Yllä on kuvakaappaus: TimescaleDB - CPU:n käyttö lisäystestin aikana ainutlaatuiselle 4M-aikasarjalle.
VictoriaMetrics käyttää lähes kaiken prosessointiyksikön (CPU) tehon. Lopussa oleva pudotus vastaa jäljellä olevia LSM-liitoksia, kun kaikki tiedot on lisätty.
InfluxDB käyttää vain 8 vCPU:sta 16:sta, kun taas TimsecaleDB käyttää neljää 4 vCPU:sta. Mitä yhteistä heidän kaavioilla on? Korkea osuus iowait, mikä taas osoittaa I/O-pullonkaulan.
TimescaleDB:llä on suuri osuus system. Oletetaan, että suuri teho johti useisiin järjestelmäkutsuihin tai useisiin .
Katsotaanpa levyn suoritustehokaavioita:
Yllä on kuvakaappaus: VictoriaMetrics - Levyn kaistanleveyden käyttäminen 4M ainutlaatuisten mittareiden lisäämiseen.
Yllä on kuvakaappaus: InfluxDB - Levyn kaistanleveyden käyttäminen 4M ainutlaatuisten mittareiden lisäämiseen.
Yllä on kuvakaappaus: TimescaleDB - Levyn kaistanleveyden käyttäminen 4M ainutlaatuisten mittareiden lisäämiseen.
VictoriaMetrics saavutti huipussaan 120 Mt/s rajan, kun taas keskimääräinen kirjoitusnopeus oli 40 Mt/s. On todennäköistä, että huipun aikana suoritettiin useita raskaita LSM-fuusioita.
InfluxDB puristaa jälleen keskimääräisen kirjoitusnopeuden 200 MB/s huippujen ollessa jopa 340 MB/s levyltä, jonka kirjoitusnopeus on 120 MB/s :)
TimescaleDB ei ole enää levyrajoitettu. Sitä näyttää rajoittavan jokin muu suureen osuuteen liittyvä системной CPU kuormitus.
Katsotaanpa IO-käyttökaavioita:
Yllä on kuvakaappaus: VictoriaMetrics – I/O:n käyttö lisäystestin aikana ainutlaatuiselle 4M-aikasarjalle.
Yllä on kuvakaappaus: InfluxDB - I/O:n käyttö lisäystestin aikana ainutlaatuiselle 4M-aikasarjalle.
Yllä on kuvakaappaus: TimescaleDB - I/O-käyttö lisäystestin aikana ainutlaatuisille 4M-aikasarjoille.
IO-käyttömallit heijastavat levyn kaistanleveyttä - InfluxDB on IO-rajoitettu, kun taas VictoriaMetricsillä ja TimescaleDB:llä on ylimääräisiä IO-resursseja.
40 miljoonaa ainutlaatuista aikasarjaa
40 miljoonaa ainutlaatuista aikasarjaa oli liian iso InfluxDB:lle :)
Vertailutulokset:
- VictoriaMetrics: 1,7 miljoonaa datapistettä sekunnissa; RAM-muistin käyttö: 29 Gt; Levytilan käyttö: 17 Gt.
- InfluxDB: Ei valmis, koska se vaati yli 60 Gt RAM-muistia.
- TimescaleDB: 330 2,5 datapistettä sekunnissa, RAM-muistin käyttö: 84 Gt; Levytilan käyttö: XNUMX Gt.
TimescaleDB näyttää poikkeuksellisen alhaisen ja vakaan RAM-muistin käytön 2,5 Gt:lla - sama kuin ainutlaatuisilla 4M- ja 400K-mittareilla.
VictoriaMetrics skaalautui hitaasti nopeudella 100 40 datapistettä sekunnissa, kunnes kaikki 1,5 miljoonaa merkittyä metriikan nimeä käsiteltiin. Sitten hän saavutti jatkuvan lisäysnopeuden 2,0–1,7 miljoonaa datapistettä sekunnissa, joten lopputulos oli XNUMX miljoonaa datapistettä sekunnissa.
40 miljoonan yksilöllisen aikasarjan kaaviot ovat samanlaisia kuin 4 miljoonan yksilöllisen aikasarjan kaaviot, joten ohitetaan ne.
Tulokset
- Nykyaikaiset TSDB:t pystyvät käsittelemään miljoonien ainutlaatuisten aikasarjojen liitteitä yhdellä palvelimella. Seuraavassa artikkelissa testaamme, kuinka hyvin TSDB:t suorittavat valinnan miljoonien ainutlaatuisten aikasarjojen välillä.
- Riittämätön suorittimen käyttöaste osoittaa yleensä I/O-pullonkaulan. Se voi myös viitata siihen, että esto on liian karkea, sillä vain muutama lanka voi kulkea kerrallaan.
- I/O-pullonkaula on olemassa, etenkin ei-SSD-tallennustilassa, kuten pilvipalveluntarjoajien virtualisoiduissa lohkolaitteissa.
- VictoriaMetrics tarjoaa parhaan optimoinnin hitaalle ja alhaiselle I/O-tallennukselle. Se tarjoaa parhaan nopeuden ja parhaan puristussuhteen.
ladata ja kokeile sitä tiedoillasi. Vastaava staattinen binaari on saatavilla osoitteessa .
Lue lisää VictoriaMetricsistä tästä .
Päivitys: julkaistu toistettavilla tuloksilla.
Päivitys 2: Lue myös .
Päivitys #3: !
Telegram chat:
Lähde: will.com