„VictoriaMetrics“, „TimescaleDB“ ir „InfluxDB“ buvo lyginami duomenų rinkinyje su milijardu duomenų taškų, priklausančių 40 XNUMX unikalių laiko eilučių.
Prieš keletą metų buvo Zabbix era. Kiekvienas pliko metalo serveris turėjo ne daugiau kaip kelis rodiklius – procesoriaus naudojimą, RAM naudojimą, disko naudojimą ir tinklo naudojimą. Tokiu būdu metrika iš tūkstančių serverių gali tilpti į 40 tūkstančių unikalių laiko eilučių, o Zabbix gali naudoti MySQL kaip laiko eilučių duomenų bazę :)
Šiuo metu vienas su numatytosiomis konfigūracijomis suteikia daugiau nei 500 metrikų vidutiniame pagrindiniame kompiuteryje. Yra daug įvairioms duomenų bazėms, žiniatinklio serveriams, aparatinės įrangos sistemoms ir kt. Jie visi pateikia įvairių naudingų metrikų. Visi pradeda sau nustatyti įvairius rodiklius. Yra „Kubernetes“ su klasteriais ir ankštimis, kurios atskleidžia daugybę metrikų. Dėl to serveriai atskleidžia tūkstančius unikalių metrikų kiekvienam kompiuteriui. Taigi unikali 40 XNUMX laiko eilutė nebėra didelės galios. Jis tampa įprastas ir turėtų būti lengvai tvarkomas bet kurio šiuolaikinio TSDB viename serveryje.
Koks šiuo metu yra daug unikalių laiko eilučių? Tikriausiai 400 tūkst. ar 4 mln. Arba 40 m? Palyginkime šiuolaikinius TSDB su šiais skaičiais.
Etalono diegimas
yra puikus TSDB palyginimo įrankis. Tai leidžia sugeneruoti savavališką skaičių metrikų perduodant reikiamą laiko eilučių skaičių, padalytą iš 10 – vėliavėlė (buvęs -scale-var). 10 yra kiekviename pagrindiniame kompiuteryje arba serveryje sugeneruotų matavimų (metrikos) skaičius. Šie duomenų rinkiniai buvo sukurti naudojant TSBS etalonui:
- 400 60 unikalių laiko eilučių, 3 sekundžių intervalas tarp duomenų taškų, duomenys apima visas 1.7 dienas, bendras duomenų taškų skaičius ~XNUMX mlrd.
- 4 mln. unikalių laiko eilučių, 600 sekundžių intervalas, duomenys apima 3 pilnas dienas, bendras duomenų taškų skaičius ~1.7 mlrd.
- 40 mln. unikalių laiko eilučių, 1 valandos intervalas, duomenys apima 3 pilnas dienas, bendras duomenų taškų skaičius ~2.8 mlrd.
Klientas ir serveris veikė tam skirtuose egzemplioriuose „Google“ debesyje. Šių atvejų konfigūracija buvo tokia:
- vCPU: 16
- RAM: 60 GB
- Saugykla: Standartinis 1TB HDD. Jis užtikrina 120 Mbps skaitymo / rašymo pralaidumą, 750 skaitymo operacijų per sekundę ir 1,5 XNUMX įrašymo per sekundę.
TSDB buvo išgauti iš oficialių „Docker“ vaizdų ir paleisti „Docker“ su šiomis konfigūracijomis:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Norint palaikyti didelę galią, reikalingos InfluxDB (-e) reikšmės. Išsamią informaciją žr ):
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 (konfigūracija paimta iš failas):
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=100Duomenų įkėlimo programa buvo paleista su 16 lygiagrečių gijų.
Šiame straipsnyje pateikiami tik įterpimo etalonų rezultatai. Atrankinio etalono rezultatai bus paskelbti atskirame straipsnyje.
400 XNUMX unikalių laiko eilučių
Pradėkime nuo paprastų elementų – 400K. Lyginamieji rezultatai:
- VictoriaMetrics: 2,6 mln. duomenų taškų per sekundę; RAM naudojimas: 3 GB; galutinis duomenų dydis diske: 965 MB
- InfluxDB: 1.2 mln. duomenų taškų per sekundę; RAM naudojimas: 8.5 GB; galutinis duomenų dydis diske: 1.6 GB
- Laiko skalė: 849 tūkst. duomenų taškų per sekundę; RAM naudojimas: 2,5 GB; galutinis duomenų dydis diske: 50 GB
Kaip matote iš aukščiau pateiktų rezultatų, „VictoriaMetrics“ laimi pagal įterpimo našumą ir suspaudimo koeficientą. Laiko juosta laimi naudojant RAM, tačiau ji naudoja daug vietos diske – 29 baitai vienam duomenų taškui.
Žemiau pateikiamos kiekvieno TSDB procesoriaus naudojimo grafikai atliekant etaloną:
Viršuje yra ekrano kopija: „VictoriaMetrics“ – procesoriaus apkrova atliekant unikalios 400 XNUMX metrikos įterpimo testą.
Aukščiau yra ekrano kopija: „InfluxDB“ – procesoriaus apkrova atliekant unikalios 400 XNUMX metrikos įterpimo testą.
Aukščiau yra ekrano kopija: TimescaleDB – procesoriaus apkrova atliekant įterpimo testą, siekiant unikalios 400 XNUMX metrikos.
„VictoriaMetrics“ naudoja visus galimus vCPU, o „InfluxDB“ nepakankamai išnaudoja ~ 2 iš 16 vCPU.
Laiko skalėje naudojami tik 3–4 iš 16 vCPU. Didelės iowait ir sistemos proporcijos TimescaleDB laiko skalės grafike rodo įvesties/išvesties (I/O) posistemio kliūtį. Pažvelkime į disko pralaidumo naudojimo grafikus:
Viršuje yra ekrano kopija: „VictoriaMetrics“ – disko pralaidumo naudojimas atliekant unikalių metrikų 400 XNUMX įterpimo testą.
Aukščiau yra ekrano kopija: „InfluxDB“ – disko pralaidumo naudojimas įterpiant unikalią metriką 400K.
Aukščiau yra ekrano kopija: TimescaleDB – disko pralaidumo naudojimas įterpiant unikalią metriką 400K.
„VictoriaMetrics“ įrašo duomenis 20 Mbps greičiu, o didžiausias – iki 45 Mbps. Smailės atitinka didelius dalinius susiliejimus medyje .
„InfluxDB“ įrašo duomenis 160 MB/s greičiu, o 1 TB diskas rašymo pralaidumas 120 MB/s.
„TimescaleDB“ riboja 120 Mbps rašymo pralaidumą, tačiau kartais jis peržengia šią ribą ir pasiekia 220 Mbps didžiausias vertes. Šios smailės atitinka ankstesniame grafike pateiktus nepakankamo procesoriaus panaudojimo slėnius.
Pažvelkime į įvesties/išvesties (I/O) naudojimo diagramas:
Aukščiau yra ekrano kopija: „VictoriaMetrics“ – įterpkite 400 XNUMX unikalių metrikų I/O naudojimo testą.
Aukščiau yra ekrano kopija: „InfluxDB“ – įterpkite 400 XNUMX unikalių metrikų I/O naudojimo testą.
Aukščiau yra ekrano kopija: „TimescaleDB“ – įterpkite 400 XNUMX unikalių metrikų bandymo įvesties / išvesties naudojimą.
Dabar aišku, kad TimescaleDB pasiekia įvesties / išvesties ribą, todėl negali naudoti likusių 12 vCPU.
4M unikali laiko eilutė
4M laiko eilutės atrodo šiek tiek sudėtingos. Tačiau mūsų konkurentai šį egzaminą išlaiko sėkmingai. Lyginamieji rezultatai:
- VictoriaMetrics: 2,2 mln. duomenų taškų per sekundę; RAM naudojimas: 6 GB; galutinis duomenų dydis diske: 3 GB.
- InfluxDB: 330 20,5 duomenų taškų per sekundę; RAM naudojimas: 18,4 GB; galutinis duomenų dydis diske: XNUMX GB.
- TimescaleDB: 480 2,5 duomenų taškų per sekundę; RAM naudojimas: 52 GB; galutinis duomenų dydis diske: XNUMX GB.
„InfluxDB“ našumas sumažėjo nuo 1,2 mln. duomenų taškų per sekundę 400 330 laiko eilutėje iki 4 XNUMX duomenų taškų per sekundę XNUMX mln. Tai yra didelis našumo praradimas, palyginti su kitais konkurentais. Pažvelkime į procesoriaus naudojimo grafikus, kad suprastume pagrindinę šio praradimo priežastį:
Aukščiau yra ekrano kopija: VictoriaMetrics – procesoriaus naudojimas atliekant unikalios 4M laiko eilutės įterpimo testą.
Aukščiau yra ekrano kopija: InfluxDB – procesoriaus naudojimas atliekant unikalių 4M laiko eilučių įterpimo testą.
Aukščiau yra ekrano kopija: TimescaleDB – procesoriaus naudojimas atliekant unikalios 4M laiko eilutės įterpimo testą.
„VictoriaMetrics“ naudoja beveik visą procesoriaus (CPU) galią. Pabaigoje esantis kritimas atitinka likusius LSM sujungimus po visų duomenų įterpimo.
InfluxDB naudoja tik 8 iš 16 vCPU, o TimsecaleDB naudoja 4 iš 16 vCPU. Ką bendro turi jų grafikai? Didelė dalis iowait, kuris vėl rodo įvesties / išvesties kliūtį.
TimescaleDB turi didelę dalį system. Manome, kad didelė galia sukėlė daug arba daug sistemos skambučių .
Pažvelkime į disko pralaidumo grafikus:
Aukščiau yra ekrano kopija: VictoriaMetrics – disko pralaidumo naudojimas norint įterpti 4M unikalią metriką.
Aukščiau yra ekrano kopija: InfluxDB – disko pralaidumo naudojimas norint įterpti 4M unikalią metriką.
Aukščiau yra ekrano kopija: TimescaleDB – disko pralaidumo naudojimas norint įterpti 4M unikalią metriką.
„VictoriaMetrics“ piko metu pasiekė 120 MB/s ribą, o vidutinis rašymo greitis buvo 40 MB/s. Tikėtina, kad piko metu buvo atlikta keletas sunkių LSM sintezių.
„InfluxDB“ vėl išspaudžia vidutinį 200 MB/s įrašymo pralaidumą su smailėmis iki 340 MB/s diske su įrašymo riba 120 MB/s :)
TimescaleDB nebėra diskas ribojamas. Atrodo, kad jį riboja kažkas, kas susiję su didele dalimi системной CPU apkrova.
Pažvelkime į IO naudojimo diagramas:
Aukščiau yra ekrano kopija: VictoriaMetrics – Įvesties / išvesties naudojimas atliekant unikalios 4M laiko eilutės įterpimo testą.
Aukščiau yra ekrano kopija: InfluxDB – įvesties / išvesties naudojimas atliekant unikalios 4M laiko eilutės įterpimo testą.
Aukščiau yra ekrano kopija: TimescaleDB – įvesties / išvesties naudojimas atliekant unikalių 4M laiko eilučių įterpimo testą.
IO naudojimo modeliai atspindi disko pralaidumą – „InfluxDB“ yra ribotas IO, o „VictoriaMetrics“ ir „TimescaleDB“ turi atsarginių IO išteklių.
40 mln. unikalių laiko eilučių
40 milijonų unikalių laiko eilučių buvo per didelė InfluxDB :)
Lyginamieji rezultatai:
- VictoriaMetrics: 1,7 mln. duomenų taškų per sekundę; RAM naudojimas: 29 GB; Vietos diske naudojimas: 17 GB.
- InfluxDB: nebaigta, nes reikėjo daugiau nei 60 GB RAM.
- TimescaleDB: 330 2,5 duomenų taškų per sekundę, RAM naudojimas: 84 GB; Vietos diske naudojimas: XNUMX GB.
„TimescaleDB“ rodo išskirtinai žemą ir stabilų 2,5 GB operatyviosios atminties naudojimą – tą patį, kaip ir unikalios 4M ir 400K metrikos.
„VictoriaMetrics“ lėtai didėjo 100 40 duomenų taškų per sekundę greičiu, kol buvo apdoroti visi 1,5 mln. pažymėtų metrikų pavadinimų. Tada jis pasiekė nuolatinį 2,0–1,7 mln. duomenų taškų per sekundę įterpimo greitį, todėl galutinis rezultatas buvo XNUMX mln. duomenų taškų per sekundę.
40 mln. unikalių laiko eilučių grafikai yra panašūs į 4 mln. unikalių laiko eilučių grafikus, todėl jas praleiskime.
išvados
- Šiuolaikiniai TSDB gali apdoroti milijonų unikalių laiko eilučių intarpus viename serveryje. Kitame straipsnyje išbandysime, kaip gerai TSDB atlieka atranką iš milijonų unikalių laiko eilučių.
- Nepakankamas procesoriaus panaudojimas paprastai rodo įvesties/išvesties kliūtis. Tai taip pat gali reikšti, kad blokavimas yra per grubus, o vienu metu gali eiti tik keli siūlai.
- Įvesties / išvesties kliūtis egzistuoja, ypač ne SSD saugykloje, pvz., debesų tiekėjų virtualizuotuose blokiniuose įrenginiuose.
- „VictoriaMetrics“ suteikia geriausią optimizavimą lėtai, mažai įvesties / išvesties saugyklai. Tai užtikrina geriausią greitį ir geriausią suspaudimo laipsnį.
Atsisiųsti ir išbandykite savo duomenis. Atitinkamą statinį dvejetainį failą rasite adresu .
Daugiau apie VictoriaMetrics skaitykite čia .
Atnaujinimas: paskelbtas su atkuriamais rezultatais.
2 atnaujinimas: taip pat skaitykite .
3 naujinimas: !
Telegramos pokalbis:
Šaltinis: www.habr.com