Errendimendu handiko TSDB erreferentzia VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB eta InfluxDB alderatu ziren aurreko artikulua 40K denbora serie bakarreko mila milioi datu-puntu dituen datu multzo batean.

Duela urte batzuk Zabbixen aro bat izan zen. Bare metal zerbitzari bakoitzak ez zituen adierazle batzuk baino gehiago: PUZaren erabilera, RAMaren erabilera, diskoaren erabilera eta sarearen erabilera. Horrela, milaka zerbitzariren neurketak 40 mila denbora-serie bakarrean sar daitezke, eta Zabbix-ek MySQL erabil dezake denbora-serieen datuetarako backend gisa :)

Momentuz bakarrik nodo_esportatzailea konfigurazio lehenetsiekin 500 metrika baino gehiago eskaintzen ditu batez besteko ostalariaren gainean. Asko daude esportatzaileak hainbat datu-baseetarako, web zerbitzarietarako, hardware-sistemetarako, etab. Guztiek hainbat neurketa erabilgarria eskaintzen dute. Denak gero eta aplikazio gehiago bere buruari hainbat adierazle ezartzen hasteko. Kubernetes dago metrika asko erakusten dituzten klusterrak eta lekak. Horren ondorioz, zerbitzariek ostalari bakoitzeko milaka metrika esklusiboak erakusten dituzte. Beraz, 40K denbora serie paregabea jada ez da potentzia handikoa. Nagusia bihurtzen ari da eta zerbitzari bakarreko edozein TSDB modernok erraz kudeatu beharko luke.

Zein da momentu honetan denbora-serie berezien kopuru handia? Seguruenik 400K edo 4M? Edo 40m? Konpara ditzagun TSDB modernoak zenbaki hauekin.

Erreferentzia bat instalatzea

TSBS TSDBentzako benchmarking tresna bikaina da. Neurri-kopuru arbitrario bat sortzeko aukera ematen du beharrezko denbora-serie-kopurua 10ez zatituta pasatuz - bandera -eskala (lehen -scale-var). 10 ostalari edo zerbitzari bakoitzean sortutako neurketa (neurriak) kopurua da. Erreferentziarako TSBS erabiliz datu multzo hauek sortu ziren:

• 400K denbora-serie esklusiboak, datu-puntuen arteko 60 segundoko tartea, datuak 3 egun osoz hartzen ditu, ~1.7B datu-puntu guztira.
• 4M denbora serie bakarra, 600 segundoko tartea, datuak 3 egun osoz hartzen ditu, ~1.7B datu-puntu guztira.
• 40 milioi denbora-serie esklusiboak, ordu bateko tartea, datuak 1 egun osokoak dira, ~3 milioi datu-puntu guztira.

Bezeroa eta zerbitzaria instantzia dedikatuetan exekutatzen ari ziren n1-estandar-16 Google hodeian. Instantzia hauek konfigurazio hauek zituzten:

• vCPUak: 16
• RAM: 60 GB
• Biltegiratzea: 1TB HDD estandarra. 120 Mbps irakurketa/idazketa-erritmoa eskaintzen du, 750 irakurketa eragiketa segundoko eta 1,5K idazketa segundoko.

TSDBak docker irudi ofizialetatik atera ziren eta docker-en exekutatzen ziren konfigurazio hauekin:

• VictoriaMetrics:

  docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics

• InfluxDB (-e) balioak behar dira potentzia handia onartzeko. Ikusi xehetasunak atalean dokumentazioa):

  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 (konfigurazioa da fitxategia):

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

Datu-kargatzailea 16 hari paralelorekin exekutatu zen.

Artikulu honek txertatzeko erreferentziazko emaitzak baino ez ditu. Erreferentzia selektiboaren emaitzak aparteko artikulu batean argitaratuko dira.

400K denbora serie bakarra

Has gaitezen elementu sinpleekin - 400K. Erreferentziazko emaitzak:

• VictoriaMetrics: 2,6 milioi datu-puntu segundoko; RAM erabilera: 3 GB; azken datuen tamaina diskoan: 965 MB
• InfluxDB: 1.2M datu-puntu segundoko; RAM erabilera: 8.5 GB; azken datuen tamaina diskoan: 1.6 GB
• Denbora-eskala: 849K datu-puntu segundoko; RAM erabilera: 2,5 GB; azken datuen tamaina diskoan: 50 GB

Goiko emaitzetan ikus dezakezunez, VictoriaMetrics-ek txertatzeko errendimenduan eta konpresio-erlazioan irabazten du. Denbora-lerroak irabazten du RAM erabileran, baina diskoko espazio asko erabiltzen du - 29 byte datu-puntu bakoitzeko.

Jarraian, TSDB bakoitzerako PUZaren erabilera grafikoak daude erreferentziazko erreferentzian zehar:

Goian pantaila-argazki bat dago: VictoriaMetrics - PUZaren karga txertatzeko proban 400K metrika esklusibo baterako.

Goian pantaila-argazki bat dago: InfluxDB - PUZaren karga txertatzeko proban 400K metriko esklusiborako.

Goian pantaila-argazki bat dago: TimescaleDB - PUZaren karga txertatzeko proban 400K-ko metrika esklusibo baterako.

VictoriaMetrics-ek erabilgarri dauden vCPU guztiak erabiltzen ditu, eta InfluxDB-k 2 vCPUetatik 16 gutxiegi erabiltzen ditu.

Denbora-eskalak 3 vCPUetatik 4-16 bakarrik erabiltzen ditu. TimescaleDB denbora-eskalaren grafikoan iowait-en eta sistemaren proportzio handiek sarrera/irteera (I/O) azpisisteman botila-lepoa adierazten dute. Ikus ditzagun diskoaren banda-zabaleraren erabilera grafikoak:

Goian pantaila-argazki bat dago: VictoriaMetrics - Disk Bandwidth Usage Insertion Test for Unique Metrics 400K.

Goian pantaila-argazki bat dago: InfluxDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.

Goian pantaila-argazki bat dago: TimescaleDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.

VictoriaMetrics-ek 20 Mbps-ko datuak erregistratzen ditu 45 Mbps-ko gailurrekin. Gailurrak zuhaitzaren fusio partzial handiei dagozkie GKE.

InfluxDB-k 160 MB/s-ko abiaduran idazten ditu datuak, 1 TB-ko disko batek mugatua izan behar da idazteko abiadura 120 MB/s.

TimescaleDB 120 Mbps-ko idazketa-sarbidera mugatzen da, baina batzuetan muga hori hausten du eta 220 Mbps-ra iristen da balio gailurretan. Gailu hauek aurreko grafikoko CPU erabilera eskasaren haranei dagozkie.

Ikus ditzagun sarrera/irteera (I/O) erabilera grafikoak:

Goian pantaila-argazki bat dago: VictoriaMetrics - Txertatu probako I/O erabilera 400K metrika esklusiboetarako.

Goian pantaila-argazki bat dago: InfluxDB - Txertatu probako I/O erabilera 400K metrika esklusiboetarako.

Goian pantaila-argazki bat dago: TimescaleDB - Txertatu probako I/O erabilera 400K metrika esklusiboetarako.

Orain argi dago TimescaleDB bere I/O mugara iristen ari dela, beraz, ezin ditu gainerako 12 vCPUak erabili.

4M denbora serie berezia

4M denbora serie apur bat erronka dirudi. Baina gure lehiakideek arrakastaz gainditzen dute azterketa hau. Erreferentziazko emaitzak:

• VictoriaMetrics: 2,2 milioi datu-puntu segundoko; RAM erabilera: 6 GB; azken datuen tamaina diskoan: 3 GB.
• InfluxDB: 330K datu-puntu segundoko; RAM erabilera: 20,5 GB; azken datuen tamaina diskoan: 18,4 GB.
• TimescaleDB: 480K datu-puntu segundoko; RAM erabilera: 2,5 GB; azken datuen tamaina diskoan: 52 GB.

InfluxDBren errendimendua segundoko 1,2 milioi datu-puntutik 400K denbora-serierako 330K datu-puntu segundoko 4M denbora-serierako jaitsi da. Errendimendu galera nabarmena da beste lehiakideekin alderatuta. Ikus ditzagun PUZaren erabilera grafikoak galera honen arrazoi nagusia ulertzeko:

Goian pantaila-argazki bat dago: VictoriaMetrics - PUZaren erabilera txertatzeko proban 4M denbora serie berezi baterako.

Goian pantaila-argazki bat dago: InfluxDB - PUZaren erabilera txertatzeko proban 4M denbora-serie berezietarako.

Goian pantaila-argazki bat dago: TimescaleDB - PUZaren erabilera txertatzeko proban 4M denbora serie berezi baterako.

VictoriaMetrics-ek prozesatzeko unitatearen (CPU) potentzia ia guztia erabiltzen du. Amaieran dagoen tantoa datu guztiak txertatu ondoren geratzen diren LSM batuei dagokie.

InfluxDB-k 8 vCPUetatik 16 bakarrik erabiltzen ditu, eta TimsecaleDB-k, berriz, 4 vCPUetatik 16 erabiltzen ditu. Zer dute haien grafikoek komunean? Kuota handia iowait, eta horrek berriro I/O botila-lepoa adierazten du.

TimescaleDB-k kuota handia du system. Suposatzen dugu potentzia handiak sistema-dei asko edo asko eragin zituela orrialdeko akats txikiak.

Ikus ditzagun diskoaren errendimenduaren grafikoak:

Goian pantaila-argazki bat dago: VictoriaMetrics - Diskoaren banda-zabalera erabiltzea 4M metrika esklusiboak txertatzeko.

Goian pantaila-argazki bat dago: InfluxDB - Diskoaren banda-zabalera erabiltzea 4M metrika esklusiboak txertatzeko.

Goian pantaila-argazki bat dago: TimescaleDB - Diskoaren banda-zabalera erabiltzea 4M metrika esklusiboak txertatzeko.

VictoriaMetrics 120 MB/s-ko mugara iritsi zen gailurrean, batez besteko idazketa-abiadura 40 MB/s-koa zen bitartean. Litekeena da gailurrean zehar hainbat LSM fusio astun egitea.

InfluxDB-k 200 MB/s-ko batez besteko idazketa-sarrera estutzen du berriro 340 MB/s-ko gailurrekin 120 MB/s-ko idazketa muga duen disko batean :)

TimescaleDB jada ez da disko mugatua. Proportzio altuarekin lotutako beste zerbaitek mugatuta dagoela dirudi системной CPU karga.

Ikus ditzagun IO erabilera grafikoak:

Goian pantaila-argazki bat dago: VictoriaMetrics - I/O erabiltzea txertatzeko proban 4M denbora serie berezi baterako.

Goian pantaila-argazki bat dago: InfluxDB - I/O erabiltzea txertatzeko proban 4M denbora-serie berezi baterako.

Goian pantaila-argazki bat dago: TimescaleDB - I/O erabilera txertatzeko proban 4M denbora-serie berezietarako.

IO erabilera-ereduak diskoaren banda-zabalerarenak islatzen ditu - InfluxDB IO mugatua da, VictoriaMetrics eta TimescaleDB-k ordezko IO baliabideak dituzte.

40M denbora serie paregabea

40M denbora serie paregabea handiegia zen InfluxDBrentzat :)

Erreferentziazko emaitzak:

• VictoriaMetrics: 1,7 milioi datu-puntu segundoko; RAM erabilera: 29 GB; Diskoko espazioaren erabilera: 17 GB.
• InfluxDB: ez da amaitu 60 GB RAM baino gehiago behar zituelako.
• TimescaleDB: 330K datu-puntu segundoko, RAM erabilera: 2,5 GB; Diskoko espazioaren erabilera: 84 GB.

TimescaleDB-k RAM erabilera oso baxua eta egonkorra erakusten du 2,5 GB-n - 4M eta 400K neurri berezien berdina.

VictoriaMetrics-ek poliki-poliki eskalatu zuen 100 datu-puntu segundoko 40M etiketatutako metrika-izen guztiak prozesatu arte. Ondoren, segundoko 1,5-2,0M datu-puntu iraunkorra lortu zuen, beraz, azken emaitza segundoko 1,7M datu-puntu izan zen.

40M denbora-serie berezien grafikoak 4M denbora-serie esklusiboen grafikoen antzekoak dira, beraz, salta ditzagun.

Findings

• TSDB modernoak milioika denbora serie esklusiboen txertaketak prozesatzeko gai dira zerbitzari bakarrean. Hurrengo artikuluan, TSDB-ek milioika denbora-serie berezitan hautaketa nola egiten duen probatuko dugu.
• PUZaren erabilera eskasak normalean I/O botila-lepoa adierazten du. Blokeoa larregia dela ere adierazi dezake, hari gutxi batzuk aldi berean exekutatzeko gai direla.
• I/O botila-lepoa existitzen da, batez ere SSD ez diren biltegiratzeetan, hala nola hodeiko hornitzaileen bloke birtualizatuen gailuetan.
• VictoriaMetrics-ek optimizaziorik onena eskaintzen du I/O biltegiratze motel eta baxurako. Abiadura onena eta konpresio erlazio onena eskaintzen ditu.

Deskarga VictoriaMetrics zerbitzari bakarreko irudia eta proba ezazu zure datuekin. Dagokion bitar estatikoa helbidean dago eskuragarri GitHub.

Irakurri gehiago VictoriaMetrics-i buruz honetan Artikulu.

Eguneraketa: argitaratua VictoriaMetrics-en txertatze-errendimendua InfluxDB-rekin alderatzen duen artikulua emaitza errepikagarriekin.

Eguneraketa # 2: Irakurri ere VictoriaMetrics vs InfluxDB vs TimescaleDB eskalagarritasun bertikalari buruzko artikulua.

Eguneraketa #3: VictoriaMetrics orain kode irekia da!

Telegram txata: https://t.me/VictoriaMetrics_ru1

Iturria: www.habr.com