ProHoster > Blogs > Administrācija > Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

gadā tika salÄ«dzināti VictoriaMetrics, TimescaleDB un InfluxDB iepriekŔējais raksts datu kopā ar miljardu datu punktu, kas pieder 40 XNUMX unikālām laikrindām.

Pirms dažiem gadiem bija Zabbix laikmets. Katram tukŔa metāla serverim bija ne vairāk kā daži rādītāji - CPU lietojums, RAM lietojums, diska lietojums un tīkla lietojums. Tādā veidā metrika no tūkstoŔiem serveru var iekļauties 40 tūkstoŔos unikālu laikrindu, un Zabbix var izmantot MySQL kā aizmuguri laikrindu datiem :)

PaÅ”laik vienatnē mezgls_eksportētājs ar noklusējuma konfigurācijām nodroÅ”ina vairāk nekā 500 metrikas vidējā resursdatorā. Tur ir daudz eksportētājiem dažādām datu bāzēm, tÄ«mekļa serveriem, aparatÅ«ras sistēmām utt. Tie visi nodroÅ”ina dažādus noderÄ«gus rādÄ«tājus. Visi arvien vairāk lietojumprogrammu sāk sev noteikt dažādus rādÄ«tājus. Ir Kubernetes ar klasteriem un podiem, kas atklāj daudzus rādÄ«tājus. Tā rezultātā serveri katram resursdatoram atklāj tÅ«kstoÅ”iem unikālu metrikas. Tātad unikālajai 40 K laikrindai vairs nav lielas jaudas. Tas kļūst par galveno, un ar to vajadzētu viegli rÄ«koties ar jebkuru modernu TSDB vienā serverÄ«.

Kāds Ŕobrīd ir lielais unikālo laikrindu skaits? DroŔi vien 400K vai 4M? Vai 40 m? Salīdzināsim mūsdienu TSDB ar Ŕiem skaitļiem.

Etalona uzstādīŔana

TSBS ir lielisks salÄ«dzinoŔās novērtÄ“Å”anas rÄ«ks TSDB. Tas ļauj Ä£enerēt patvaļīgu skaitu metrikas, nododot nepiecieÅ”amo laikrindu skaitu, dalÄ«tu ar 10 - karodziņŔ - mērogs (bijuÅ”ais -scale-var). 10 ir mērÄ«jumu (metriku) skaits, kas Ä£enerēts katrā resursdatorā vai serverÄ«. Izmantojot TSBS etalonam, tika Ä£enerētas Ŕādas datu kopas:

  • 400 60 unikālas laikrindas, 3 sekunžu intervāls starp datu punktiem, dati aptver visas 1.7 dienas, ~XNUMX B kopējais datu punktu skaits.
  • 4 miljoni unikālas laika rindas, 600 sekunžu intervāls, dati aptver 3 pilnas dienas, ~1.7 B kopējais datu punktu skaits.
  • 40 miljoni unikālas laikrindas, 1 stunda, dati aptver 3 pilnas dienas, ~2.8 B kopējais datu punktu skaits.

Klients un serveris darbojās Ä«paŔās instancēs n1-standarta-16 Google mākonÄ«. Å iem gadÄ«jumiem bija Ŕādas konfigurācijas:

  • vCPU: 16
  • RAM: 60 GB
  • UzglabāŔana: standarta 1 TB HDD. Tas nodroÅ”ina 120 Mb/s lasÄ«Å”anas/rakstÄ«Å”anas caurlaidspēju, 750 lasÄ«Å”anas operācijas sekundē un 1,5 K rakstÄ«Å”anas ātrumu sekundē.

TSDB tika iegÅ«ti no oficiālajiem docker attēliem un tika palaisti dockerā ar Ŕādām konfigurācijām:

  • VictoriaMetrics:

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

  • InfluxDB (-e) vērtÄ«bas ir nepiecieÅ”amas, lai atbalstÄ«tu lielu jaudu. Skatiet sÄ«kāku informāciju dokumentācija):

    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 (konfigurācija ņemta no tā fails):

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 ielādētājs tika palaists ar 16 paralēliem pavedieniem.

Å ajā rakstā ir ietverti tikai ievietoÅ”anas etalonu rezultāti. SelektÄ«vā etalona rezultāti tiks publicēti atseviŔķā rakstā.

400 XNUMX unikālas laikrindas

Sāksim ar vienkārŔiem elementiem - 400K. Etalona rezultāti:

  • VictoriaMetrics: 2,6 miljoni datu punktu sekundē; RAM lietojums: 3 GB; galÄ«gais datu apjoms diskā: 965 MB
  • InfluxDB: 1.2 miljoni datu punktu sekundē; RAM lietojums: 8.5 GB; galÄ«gais datu apjoms diskā: 1.6 GB
  • Laika skala: 849 2,5 datu punktu sekundē; RAM lietojums: 50 GB; galÄ«gais datu apjoms diskā: XNUMX GB

Kā redzat no iepriekÅ” minētajiem rezultātiem, VictoriaMetrics uzvar ievietoÅ”anas veiktspējā un saspieÅ”anas pakāpē. Laika skala uzvar RAM lietoÅ”anā, taču tā izmanto daudz vietas diskā - 29 baiti uz vienu datu punktu.

Tālāk ir sniegtas CPU lietojuma diagrammas katram TSDB etalona laikā:

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: VictoriaMetrics ā€” CPU slodze ievietoÅ”anas pārbaudes laikā unikālai 400 K metrikai.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: InfluxDB ā€” CPU slodze ievietoÅ”anas pārbaudes laikā unikālai metrikai 400 K.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: TimescaleDB ā€” CPU slodze ievietoÅ”anas pārbaudes laikā unikālai 400 K metrikai.

VictoriaMetrics izmanto visus pieejamos vCPU, savukārt InfluxDB nepietiekami izmanto ~ 2 no 16 vCPU.

Laika skalā tiek izmantoti tikai 3ā€“4 no 16 vCPU. Liela iowait un sistēmas proporcija TimescaleDB laika skalas grafikā norāda uz vājo vietu ievades/izvades (I/O) apakÅ”sistēmā. ApskatÄ«sim diska joslas platuma lietojuma grafikus:

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: VictoriaMetrics ā€” diska joslas platuma lietojums unikālo metrikas 400 K ievietoÅ”anas testā.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: InfluxDB ā€” diska joslas platuma lietojums ievietoÅ”anas testā unikālai metrikai 400 K.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: TimescaleDB ā€” diska joslas platuma lietojums ievietoÅ”anas testā unikālai metrikai 400 K.

VictoriaMetrics ieraksta datus ar ātrumu 20 Mb/s ar maksimumu lÄ«dz 45 Mb/s. Virsotnes atbilst lielai daļējai saplÅ«Å”anai kokā NVO.

InfluxDB ieraksta datus ar ātrumu 160 MB/s, savukārt 1 TB disks bÅ«tu jāierobežo rakstÄ«Å”anas caurlaidspēja 120 MB/s.

TimescaleDB ir ierobežota rakstÄ«Å”anas caurlaidspēja 120 Mb/s, taču dažreiz tas pārkāpj Å”o ierobežojumu un sasniedz 220 Mb/s maksimālās vērtÄ«bās. Å Ä«s virsotnes atbilst nepietiekamas CPU izmantoÅ”anas ielejām iepriekŔējā grafikā.

Apskatīsim ievades/izvades (I/O) lietojuma diagrammas:

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: VictoriaMetrics ā€” ievietojiet testa I/O lietojumu 400 XNUMX unikālo rādÄ«tāju.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: InfluxDB ā€” ievietojiet testa I/O lietojumu 400 XNUMX unikālo rādÄ«tāju.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: TimescaleDB ā€” ievietojiet testa I/O lietojumu 400 XNUMX unikālo rādÄ«tāju.

Tagad ir skaidrs, ka TimescaleDB sasniedz savu I/O ierobežojumu, tāpēc tas nevar izmantot atlikuÅ”os 12 vCPU.

4 miljoni unikālas laikrindas

4M laikrindas izskatās nedaudz izaicinoŔas. Taču mūsu konkurenti Ŕo eksāmenu nokārto veiksmīgi. Etalona rezultāti:

  • VictoriaMetrics: 2,2 miljoni datu punktu sekundē; RAM lietojums: 6 GB; galÄ«gais datu apjoms diskā: 3 GB.
  • InfluxDB: 330 20,5 datu punktu sekundē; RAM lietojums: 18,4 GB; galÄ«gais datu apjoms diskā: XNUMX GB.
  • TimescaleDB: 480 2,5 datu punktu sekundē; RAM lietojums: 52 GB; galÄ«gais datu apjoms diskā: XNUMX GB.

InfluxDB veiktspēja ir samazinājusies no 1,2 miljoniem datu punktiem sekundē 400 330 laikrindai lÄ«dz 4 XNUMX datu punktiem sekundē XNUMX miljonu laika rindām. Tas ir ievērojams veiktspējas zudums salÄ«dzinājumā ar citiem konkurentiem. ApskatÄ«sim CPU izmantoÅ”anas diagrammas, lai saprastu Ŕī zaudējuma galveno cēloni:

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: VictoriaMetrics ā€” CPU lietojums ievietoÅ”anas testa laikā unikālai 4 M laikrindai.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: InfluxDB ā€” CPU lietojums ievietoÅ”anas testa laikā unikālai 4M laikrindai.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: TimescaleDB ā€” CPU lietojums ievietoÅ”anas testa laikā unikālai 4 M laikrindai.

VictoriaMetrics izmanto gandrÄ«z visu procesora (CPU) jaudu. Piliens beigās atbilst atlikuÅ”ajiem LSM sapludinājumiem pēc visu datu ievietoÅ”anas.

InfluxDB izmanto tikai 8 no 16 vCPU, savukārt TimsecaleDB izmanto 4 no 16 vCPU. Kas kopÄ«gs viņu grafikiem? Augsta daļa iowait, kas atkal norāda uz I/O saÅ”aurinājumu.

TimescaleDB ir liela daļa system. Mēs pieņemam, ka liela jauda izraisīja daudzus vai daudzus sistēmas zvanus nelieli lapas defekti.

Apskatīsim diska caurlaidspējas grafikus:

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: VictoriaMetrics ā€” diska joslas platuma izmantoÅ”ana, lai ievietotu 4 M unikālus rādÄ«tājus.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: InfluxDB ā€” diska joslas platuma izmantoÅ”ana, lai ievietotu 4 M unikālus rādÄ«tājus.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: TimescaleDB ā€” diska joslas platuma izmantoÅ”ana, lai ievietotu 4 M unikālus rādÄ«tājus.

VictoriaMetrics maksimumā sasniedza 120 MB/s robežu, savukārt vidējais rakstÄ«Å”anas ātrums bija 40 MB/s. Visticamāk, ka pÄ«Ä·a laikā tika veiktas vairākas smagas LSM saplÅ«Å”anas.

InfluxDB atkal izspiež vidējo rakstÄ«Å”anas jaudu 200 MB/s ar maksimālo ātrumu lÄ«dz 340 MB/s diskā ar rakstÄ«Å”anas ierobežojumu 120 MB/s :)

TimescaleDB vairs nav disks ierobežots. Å Ä·iet, ka to ierobežo kaut kas cits, kas saistÄ«ts ar lielo Ä«patsvaru сŠøстŠµŠ¼Š½Š¾Š¹ CPU slodze.

Apskatīsim IO lietoŔanas diagrammas:

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: VictoriaMetrics ā€” ievades/izvades izmantoÅ”ana ievietoÅ”anas testa laikā unikālai 4M laikrindai.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: InfluxDB ā€” ievades/izvades izmantoÅ”ana ievietoÅ”anas testa laikā unikālai 4M laikrindai.

Augstas veiktspējas TSDB etalons VictoriaMetrics vs TimescaleDB vs InfluxDB

IepriekÅ” ir ekrānuzņēmums: TimescaleDB ā€” I/O lietojums ievietoÅ”anas testa laikā unikālai 4M laika rindai.

IO izmantoÅ”anas modeļi atspoguļo diska joslas platuma modeļus ā€” InfluxDB ir ierobežots IO, savukārt VictoriaMetrics un TimescaleDB ir rezerves IO resursi.

40 miljoni unikālu laikrindu

40 miljoni unikālas laikrindas bija pārāk lielas priekÅ” InfluxDB :)

Etalona rezultāti:

  • VictoriaMetrics: 1,7 miljoni datu punktu sekundē; RAM lietojums: 29 GB; Diska vietas lietojums: 17 GB.
  • InfluxDB: nepabeidza, jo bija nepiecieÅ”ams vairāk nekā 60 GB RAM.
  • TimescaleDB: 330 2,5 datu punktu sekundē, RAM lietojums: 84 GB; Diska vietas patēriņŔ: XNUMX GB.

TimescaleDB parāda ārkārtÄ«gi zemu un stabilu RAM lietojumu 2,5 GB apmērā ā€” tāpat kā unikālajiem 4 M un 400 XNUMX metrikiem.

VictoriaMetrics lēnām palielinājās ar ātrumu 100 40 datu punktu sekundē, lÄ«dz tika apstrādāti visi 1,5 miljoni marķēto metrikas nosaukumu. Pēc tam viņŔ sasniedza ilgstoÅ”u ievietoÅ”anas ātrumu 2,0ā€“1,7 miljoni datu punktu sekundē, tāpēc gala rezultāts bija XNUMX miljoni datu punktu sekundē.

Grafiki 40 miljoniem unikālu laika rindu ir lÄ«dzÄ«gi 4 miljonu unikālo laikrindu grafikiem, tāpēc izlaidÄ«sim tos.

Atzinumi

  • MÅ«sdienu TSDB spēj apstrādāt ieliktņus miljoniem unikālu laikrindu vienā serverÄ«. Nākamajā rakstā mēs pārbaudÄ«sim, cik labi TSDB veic atlasi miljoniem unikālu laikrindu.
  • Nepietiekama CPU izmantoÅ”ana parasti norāda uz I/O vājo vietu. Tas var arÄ« norādÄ«t, ka bloÄ·Ä“Å”ana ir pārāk rupja, jo vienlaikus var darboties tikai daži pavedieni.
  • I/O saÅ”aurinājums pastāv, jo Ä«paÅ”i krātuvē, kas nav SSD, piemēram, mākoņpakalpojumu sniedzēju virtualizētās bloku ierÄ«cēs.
  • VictoriaMetrics nodroÅ”ina vislabāko optimizāciju lēnai, zemai I/O uzglabāŔanai. Tas nodroÅ”ina vislabāko ātrumu un labāko kompresijas pakāpi.

Lejupielādēt VictoriaMetrics viena servera attēls un izmēģiniet to ar saviem datiem. AtbilstoÅ”ais statiskais binārs ir pieejams vietnē GitHub.

Lasiet vairāk par VictoriaMetrics Ŕajā raksts.

Atjauninājums: publicēts raksts, kurā tiek salÄ«dzināta VictoriaMetrics ievietoÅ”anas veiktspēja ar InfluxDB ar reproducējamiem rezultātiem.

Atjauninājums #2: lasiet arī raksts par vertikālo mērogojamību VictoriaMetrics vs InfluxDB vs TimescaleDB.

Atjauninājums Nr. 3: VictoriaMetrics tagad ir atvērtā koda versija!

Telegrammas tērzÄ“Å”ana: https://t.me/VictoriaMetrics_ru1

Avots: www.habr.com

Pievieno komentāru