VictoriaMetrics, TimescaleDB in InfluxDB so bili primerjani v na naboru podatkov z milijardo podatkovnih točk, ki pripadajo 40K edinstvenim časovnim vrstam.
Pred nekaj leti je bilo obdobje Zabbixa. Vsak goli strežnik ni imel več kot nekaj indikatorjev - poraba procesorja, poraba RAM-a, uporaba diska in uporaba omrežja. Na ta način se meritve iz več tisoč strežnikov lahko prilegajo v 40 tisoč edinstvenih časovnih vrst, Zabbix pa lahko uporabi MySQL kot zaledje za podatke časovnih vrst :)
Trenutno sama s privzetimi konfiguracijami ponuja več kot 500 meritev na povprečnem gostitelju. Veliko jih je za različne baze podatkov, spletne strežnike, sisteme strojne opreme itd. Vsi zagotavljajo vrsto uporabnih meritev. Vse sami sebi začnejo postavljati različne kazalnike. Obstaja Kubernetes z grozdi in podi, ki razkrivajo številne metrike. Rezultat tega je, da strežniki izpostavijo na tisoče edinstvenih meritev na gostitelja. Tako edinstvena časovna serija 40K ni več velika moč. Postaja mainstream in bi ga moral zlahka upravljati vsak sodoben TSDB na enem strežniku.
Kakšno je trenutno veliko število edinstvenih časovnih vrst? Verjetno 400K ali 4M? ali 40m? Primerjajmo sodobne TSDB s temi številkami.
Namestitev merila uspešnosti
je odlično orodje za primerjalno analizo za TSDB. Omogoča vam ustvarjanje poljubnega števila meritev s posredovanjem zahtevanega števila časovnih vrst, deljenih z 10 - zastavica (nekdanji -scale-var). 10 je število meritev (metrik), ustvarjenih na vsakem gostitelju ali strežniku. Naslednji nabori podatkov so bili ustvarjeni z uporabo TSBS za merilo uspešnosti:
- 400K edinstvenih časovnih vrst, 60-sekundni interval med podatkovnimi točkami, podatki zajemajo cele 3 dni, ~1.7B skupno število podatkovnih točk.
- 4 milijone edinstvenih časovnih vrst, 600-sekundni interval, podatki zajemajo 3 polne dni, ~1.7 milijarde skupno število podatkovnih točk.
- 40 milijonov edinstvenih časovnih vrst, 1-urni interval, podatki zajemajo cele 3 dni, ~2.8 milijarde skupno število podatkovnih točk.
Odjemalec in strežnik sta delovala na namenskih instancah v Googlovem oblaku. Ti primerki so imeli naslednje konfiguracije:
- vCPU-ji: 16
- RAM: 60 GB
- Shramba: standardni 1TB HDD. Zagotavlja prepustnost branja/pisanja 120 Mb/s, 750 bralnih operacij na sekundo in 1,5 K pisanja na sekundo.
TSDB so bili ekstrahirani iz uradnih slik dokerja in se izvajajo v dokerju z naslednjimi konfiguracijami:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Vrednosti InfluxDB (-e) so potrebne za podporo visoke moči. Glej podrobnosti v ):
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 (konfiguracija vzeta iz mapa):
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=100Nalagalnik podatkov je deloval s 16 vzporednimi nitmi.
Ta članek vsebuje samo rezultate za merila uspešnosti vstavljanja. Rezultati selektivnega primerjalnega testa bodo objavljeni v posebnem članku.
400K edinstvene časovne serije
Začnimo s preprostimi elementi - 400K. Rezultati primerjalnih preizkusov:
- VictoriaMetrics: 2,6 milijona podatkovnih točk na sekundo; Poraba RAM-a: 3 GB; končna velikost podatkov na disku: 965 MB
- InfluxDB: 1.2 milijona podatkovnih točk na sekundo; Poraba RAM-a: 8.5 GB; končna velikost podatkov na disku: 1.6 GB
- Časovni okvir: 849K podatkovnih točk na sekundo; Poraba RAM-a: 2,5 GB; končna velikost podatkov na disku: 50 GB
Kot lahko vidite iz zgornjih rezultatov, VictoriaMetrics zmaguje pri zmogljivosti vstavljanja in kompresijskem razmerju. Časovnica zmaga pri porabi RAM-a, vendar porabi veliko prostora na disku - 29 bajtov na podatkovno točko.
Spodaj so grafi porabe procesorja za vsakega od TSDB med primerjalnim preizkusom:
Zgoraj je posnetek zaslona: VictoriaMetrics – obremenitev procesorja med preizkusom vstavljanja za edinstveno metriko 400K.
Zgoraj je posnetek zaslona: InfluxDB – obremenitev procesorja med preskusom vstavljanja za edinstveno metriko 400K.
Zgoraj je posnetek zaslona: TimescaleDB – obremenitev procesorja med preskusom vstavljanja za edinstveno metriko 400K.
VictoriaMetrics uporablja vse razpoložljive vCPU-je, medtem ko InfluxDB premalo izkorišča ~2 od 16 vCPU-jev.
Timescale uporablja samo 3-4 od 16 vCPU-jev. Visoki deleži iowait in sistema v grafu časovne lestvice TimescaleDB kažejo na ozko grlo v vhodno/izhodnem (V/I) podsistemu. Poglejmo si grafe uporabe pasovne širine diska:
Zgoraj je posnetek zaslona: VictoriaMetrics – uporaba pasovne širine diska pri preizkusu vstavljanja za enolične meritve 400K.
Zgoraj je posnetek zaslona: InfluxDB – uporaba pasovne širine diska pri preskusu vstavljanja za edinstvene meritve 400K.
Zgoraj je posnetek zaslona: TimescaleDB – uporaba pasovne širine diska pri preskusu vstavljanja za edinstvene meritve 400K.
VictoriaMetrics snema podatke pri 20 Mb/s z najvišjimi hitrostmi do 45 Mb/s. Vrhovi ustrezajo velikim delnim združitvam v drevesu .
InfluxDB zapisuje podatke s hitrostjo 160 MB/s, disk s kapaciteto 1 TB prepustnost pisanja 120 MB/s.
TimescaleDB je omejen na prepustnost pisanja 120 Mb/s, vendar včasih preseže to mejo in doseže 220 Mb/s pri najvišjih vrednostih. Ti vrhovi ustrezajo dolinam nezadostne izkoriščenosti procesorja v prejšnjem grafu.
Poglejmo si grafe uporabe vhodno/izhodnih (I/O):
Zgoraj je posnetek zaslona: VictoriaMetrics – vstavite preskusno uporabo V/I za 400K edinstvenih meritev.
Zgoraj je posnetek zaslona: InfluxDB – vstavite preskusno V/I uporabo za 400K edinstvenih meritev.
Zgoraj je posnetek zaslona: TimescaleDB – vstavite preskusno uporabo V/I za 400K edinstvenih meritev.
Zdaj je jasno, da TimescaleDB dosega svojo mejo V/I, zato ne more uporabiti preostalih 12 vCPU-jev.
4M edinstvena časovna serija
4M časovne serije so videti nekoliko zahtevne. A naši tekmovalci ta izpit uspešno opravijo. Rezultati primerjalnih preizkusov:
- VictoriaMetrics: 2,2 milijona podatkovnih točk na sekundo; Poraba RAM-a: 6 GB; končna velikost podatkov na disku: 3 GB.
- InfluxDB: 330K podatkovnih točk na sekundo; Poraba RAM-a: 20,5 GB; končna velikost podatkov na disku: 18,4 GB.
- TimescaleDB: 480K podatkovnih točk na sekundo; Poraba RAM-a: 2,5 GB; končna velikost podatkov na disku: 52 GB.
Zmogljivost InfluxDB je padla z 1,2 milijona podatkovnih točk na sekundo za 400K časovno vrsto na 330K podatkovnih točk na sekundo za 4M časovno vrsto. To je precejšnja izguba zmogljivosti v primerjavi z drugimi konkurenti. Oglejmo si grafe porabe procesorja, da razumemo glavni vzrok te izgube:
Zgoraj je posnetek zaslona: VictoriaMetrics - uporaba procesorja med preskusom vstavljanja za edinstveno časovno vrsto 4M.
Zgoraj je posnetek zaslona: InfluxDB – uporaba procesorja med preskusom vstavljanja za edinstveno časovno vrsto 4M.
Zgoraj je posnetek zaslona: TimescaleDB – uporaba procesorja med preskusom vstavljanja za edinstveno časovno vrsto 4M.
VictoriaMetrics uporablja skoraj vso moč procesorske enote (CPE). Padec na koncu ustreza preostalim združitvam LSM po vstavitvi vseh podatkov.
InfluxDB uporablja le 8 od 16 vCPU-jev, medtem ko TimsecaleDB uporablja 4 od 16 vCPU-jev. Kaj imajo skupnega njuni grafi? Visok delež iowait, kar spet kaže na V/I ozko grlo.
TimescaleDB ima visok delež system. Predvidevamo, da je visoka moč povzročila veliko ali veliko sistemskih klicev .
Poglejmo grafe prepustnosti diska:
Zgoraj je posnetek zaslona: VictoriaMetrics - uporaba pasovne širine diska za vstavljanje 4 milijonov edinstvenih meritev.
Zgoraj je posnetek zaslona: InfluxDB – uporaba pasovne širine diska za vstavljanje 4 milijonov edinstvenih meritev.
Zgoraj je posnetek zaslona: TimescaleDB – uporaba pasovne širine diska za vstavljanje 4 milijonov edinstvenih meritev.
VictoriaMetrics je na vrhuncu dosegla mejo 120 MB/s, povprečna hitrost zapisovanja pa je bila 40 MB/s. Verjetno je bilo med vrhom izvedenih več težkih zlivanj LSM.
InfluxDB spet iztisne povprečno hitrost pisanja 200 MB/s z vrhovi do 340 MB/s na disku z omejitvijo pisanja 120 MB/s :)
TimescaleDB ni več omejen na disk. Zdi se, da ga omejuje nekaj drugega, kar je povezano z visokim deležem системной obremenitev procesorja.
Poglejmo si grafe uporabe IO:
Zgoraj je posnetek zaslona: VictoriaMetrics - Uporaba V/I med preskusom vstavljanja za edinstveno časovno vrsto 4M.
Zgoraj je posnetek zaslona: InfluxDB – Uporaba V/I med preskusom vstavljanja za edinstveno časovno vrsto 4M.
Zgoraj je posnetek zaslona: TimescaleDB – uporaba V/I med preizkusom vstavljanja za edinstveno časovno vrsto 4M.
Vzorci uporabe IO odražajo vzorce pasovne širine diska - InfluxDB je omejen na IO, medtem ko imata VictoriaMetrics in TimescaleDB rezervna sredstva IO.
40 milijonov edinstvenih časovnih vrst
40 milijonov edinstvenih časovnih vrst je bilo preveliko za InfluxDB :)
Rezultati primerjalnih preizkusov:
- VictoriaMetrics: 1,7 milijona podatkovnih točk na sekundo; Poraba RAM-a: 29 GB; Poraba prostora na disku: 17 GB.
- InfluxDB: Ni dokončan, ker je zahteval več kot 60 GB RAM-a.
- TimescaleDB: 330K podatkovnih točk na sekundo, uporaba RAM-a: 2,5 GB; Poraba prostora na disku: 84 GB.
TimescaleDB prikazuje izjemno nizko in stabilno uporabo RAM-a pri 2,5 GB – enako kot pri edinstveni meritvi 4M in 400K.
VictoriaMetrics se je počasi povečevala s hitrostjo 100 tisoč podatkovnih točk na sekundo, dokler ni bilo obdelanih vseh 40 milijonov označenih imen meritev. Nato je dosegel trajno hitrost vstavljanja 1,5–2,0 milijona podatkovnih točk na sekundo, tako da je bil končni rezultat 1,7 milijona podatkovnih točk na sekundo.
Grafi za 40M edinstvene časovne vrste so podobni grafom za 4M edinstvene časovne vrste, zato jih preskočimo.
Ugotovitve
- Sodobni TSDB so zmožni obdelave vstavkov za milijone edinstvenih časovnih vrst na enem samem strežniku. V naslednjem članku bomo preizkusili, kako dobro TSDB izvajajo izbiro med milijoni edinstvenih časovnih vrst.
- Nezadostna izkoriščenost procesorja običajno kaže na V/I ozko grlo. Lahko tudi pomeni, da je blokiranje pregrobo, saj lahko naenkrat teče le nekaj niti.
- V/I ozko grlo obstaja, zlasti pri pomnilnikih, ki niso SSD, kot so virtualizirane blokovne naprave ponudnikov v oblaku.
- VictoriaMetrics zagotavlja najboljšo optimizacijo za počasno shranjevanje V/I z nizko vsebnostjo. Zagotavlja najboljšo hitrost in najboljše kompresijsko razmerje.
Prenesi in poskusite na svojih podatkih. Ustrezna statična binarna datoteka je na voljo na .
Preberite več o VictoriaMetrics v tem .
Posodobitev: objavljena s ponovljivimi rezultati.
Posodobitev #2: Preberite tudi .
Posodobitev #3: !
Telegram klepet:
Vir: www.habr.com