Kiwango cha utendaji wa juu cha TSDB VictoriaMetrics dhidi ya TimescaleDB dhidi ya InfluxDB

VictoriaMetrics, TimescaleDB na InfluxDB zililinganishwa katika makala iliyopita kwenye mkusanyiko wa data ulio na pointi bilioni za data zinazomilikiwa na mfululizo wa saa za kipekee wa 40K.

Miaka michache iliyopita kulikuwa na zama za Zabbix. Kila seva ya chuma tupu haikuwa na zaidi ya viashiria vichache - matumizi ya CPU, matumizi ya RAM, matumizi ya diski na matumizi ya mtandao. Kwa njia hii, vipimo kutoka kwa maelfu ya seva vinaweza kutoshea katika safu elfu 40 za kipekee za wakati, na Zabbix inaweza kutumia MySQL kama msingi wa data ya mfululizo wa saa :)

Hivi sasa peke yake nodi_nje na usanidi chaguo-msingi hutoa zaidi ya vipimo 500 kwa seva pangishi wastani. Wapo wengi wasafirishaji nje kwa hifadhidata mbalimbali, seva za wavuti, mifumo ya maunzi, n.k. Zote hutoa aina mbalimbali za vipimo muhimu. Wote maombi zaidi na zaidi kuanza kujiwekea viashiria mbalimbali. Kuna Kubernetes iliyo na vikundi na maganda ambayo hufichua vipimo vingi. Hii inasababisha seva kufichua maelfu ya vipimo vya kipekee kwa kila seva pangishi. Kwa hivyo mfululizo wa kipekee wa wakati wa 40K sio nguvu ya juu tena. Inakuwa ya kawaida na inapaswa kushughulikiwa kwa urahisi na TSDB yoyote ya kisasa kwenye seva moja.

Je, ni idadi gani kubwa ya mfululizo wa muda wa kipekee kwa sasa? Labda 400K au 4M? Au 40m? Wacha tulinganishe TSDB za kisasa na nambari hizi.

Inasakinisha alama

TSBS ni zana bora ya kuweka alama kwa TSDBs. Inakuruhusu kutoa nambari kiholela ya vipimo kwa kupitisha nambari inayohitajika ya safu ya saa iliyogawanywa na 10 - bendera. -kiwango (zamani -scale-var) 10 ni idadi ya vipimo (metrics) zinazozalishwa kwa kila seva pangishi au seva. Hifadhidata zifuatazo zilitolewa kwa kutumia TSBS kwa alama ya alama:

• Mfululizo wa muda wa kipekee wa 400K, muda wa sekunde 60 kati ya pointi za data, data hudumu siku 3 kamili, ~1.7B jumla ya idadi ya pointi za data.
• Mfululizo wa muda wa kipekee wa 4M, muda wa sekunde 600, data huchukua siku 3 kamili, ~1.7B jumla ya idadi ya pointi za data.
• Mfululizo wa muda wa kipekee wa 40M, muda wa saa 1, data huchukua siku 3 kamili, ~2.8B jumla ya idadi ya pointi za data.

Mteja na seva zilikuwa zikifanya kazi kwa matukio maalum n1-kiwango-16 katika Google cloud. Matukio haya yalikuwa na usanidi ufuatao:

• vCPU: 16
• RAM: 60 GB
• Hifadhi: HDD ya kawaida ya 1TB. Inatoa 120 Mbps kusoma / kuandika throughput, 750 kusoma shughuli kwa pili na 1,5K anaandika kwa pili.

TSDB zilitolewa kutoka kwa picha rasmi za docker na kukimbia kwenye docker na usanidi ufuatao:

• VictoriaMetrics:

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

• Thamani za InfluxDB (-e) zinahitajika ili kutumia nishati ya juu. Angalia maelezo katika nyaraka):

  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 (usanidi umechukuliwa kutoka ni faili):

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

Kipakiaji data kiliendeshwa na nyuzi 16 zinazofanana.

Makala haya yana matokeo ya alama za uwekaji pekee. Matokeo ya kigezo cha kuchagua yatachapishwa katika makala tofauti.

Mfululizo wa muda wa kipekee wa 400K

Wacha tuanze na vitu rahisi - 400K. Matokeo ya ulinganishaji:

• VictoriaMetrics: pointi za data 2,6M kwa sekunde; matumizi ya RAM: 3 GB; saizi ya mwisho ya data kwenye diski: 965 MB
• InfluxDB: pointi za data 1.2M kwa sekunde; matumizi ya RAM: 8.5 GB; saizi ya mwisho ya data kwenye diski: 1.6 GB
• Muda: pointi za data 849K kwa sekunde; matumizi ya RAM: 2,5 GB; saizi ya mwisho ya data kwenye diski: 50 GB

Kama unavyoona kutoka kwa matokeo hapo juu, VictoriaMetrics inashinda katika utendaji wa uwekaji na uwiano wa mbano. Rekodi ya wakati inashinda katika utumiaji wa RAM, lakini hutumia nafasi nyingi za diski - baiti 29 kwa kila nukta ya data.

Zifuatazo ni grafu za matumizi ya CPU kwa kila TSDB wakati wa kigezo:

Hapo juu ni picha ya skrini: VictoriaMetrics - Upakiaji wa CPU wakati wa jaribio la uwekaji kwa kipimo cha kipekee cha 400K.

Hapo juu ni picha ya skrini: InfluxDB - Upakiaji wa CPU wakati wa jaribio la uwekaji wa metric 400K ya kipekee.

Hapo juu ni picha ya skrini: TimescaleDB - Upakiaji wa CPU wakati wa jaribio la uwekaji kwa kipimo cha kipekee cha 400K.

VictoriaMetrics hutumia vCPU zote zinazopatikana, huku InfluxDB haitumii ~ 2 kati ya vCPU 16.

Muda hutumia 3-4 kati ya 16 vCPU pekee. Viwango vya juu vya iowait na mfumo katika grafu ya kipimo cha muda cha TimescaleDB huonyesha kizuizi katika mfumo mdogo wa ingizo/pato (I/O). Wacha tuangalie grafu za utumiaji wa data ya diski:

Hapo juu ni picha ya skrini: VictoriaMetrics - Matumizi ya Bandwidth ya Diski katika Jaribio la Uingizaji wa Vipimo vya Kipekee 400K.

Hapo juu ni picha ya skrini: InfluxDB - Matumizi ya Bandwidth ya Diski kwenye Jaribio la Uingizaji wa Vipimo vya Kipekee 400K.

Hapo juu ni picha ya skrini: TimescaleDB - Matumizi ya Bandwidth ya Diski kwenye Jaribio la Uingizaji wa Vipimo vya Kipekee 400K.

VictoriaMetrics hurekodi data kwa 20 Mbps na kilele hadi 45 Mbps. Vilele vinahusiana na muunganisho mkubwa wa sehemu kwenye mti NGO.

InfluxDB huandika data kwa 160 MB/s, huku kiendeshi cha 1 TB inapaswa kuwa mdogo andika upitishaji 120 MB/s.

TimescaleDB ina kikomo cha kuandika upitishaji wa 120 Mbps, lakini wakati mwingine huvunja kikomo hiki na kufikia Mbps 220 katika viwango vya kilele. Vilele hivi vinalingana na mabonde ya utumiaji duni wa CPU kwenye grafu iliyotangulia.

Wacha tuangalie grafu za matumizi ya pembejeo/pato (I/O):

Hapo juu ni picha ya skrini: VictoriaMetrics - Ingiza matumizi ya jaribio la I/O kwa vipimo vya kipekee vya 400K.

Hapo juu ni picha ya skrini: InfluxDB - Ingiza matumizi ya jaribio la I/O kwa vipimo vya kipekee vya 400K.

Hapo juu ni picha ya skrini: TimescaleDB - Ingiza matumizi ya jaribio la I/O kwa vipimo vya kipekee vya 400K.

Sasa ni wazi kuwa TimescaleDB inafikia kikomo chake cha I/O, kwa hivyo haiwezi kutumia vCPU 12 zilizosalia.

Mfululizo wa muda wa kipekee wa 4M

Mfululizo wa muda wa 4M unaonekana kuwa na changamoto kidogo. Lakini washindani wetu hufaulu mtihani huu kwa mafanikio. Matokeo ya ulinganishaji:

• VictoriaMetrics: pointi za data 2,2M kwa sekunde; matumizi ya RAM: 6 GB; saizi ya mwisho ya data kwenye diski: 3 GB.
• InfluxDB: pointi za data 330K kwa sekunde; matumizi ya RAM: 20,5 GB; saizi ya mwisho ya data kwenye diski: 18,4 GB.
• TimescaleDB: pointi za data 480K kwa sekunde; matumizi ya RAM: 2,5 GB; saizi ya mwisho ya data kwenye diski: 52 GB.

Utendaji wa InfluxDB umeshuka kutoka pointi za data 1,2M kwa sekunde kwa mfululizo wa muda wa 400K hadi pointi 330K za data kwa sekunde kwa mfululizo wa muda wa 4M. Hii ni hasara kubwa ya utendaji ikilinganishwa na washindani wengine. Wacha tuangalie grafu za utumiaji wa CPU ili kuelewa sababu kuu ya upotezaji huu:

Hapo juu ni picha ya skrini: VictoriaMetrics - Matumizi ya CPU wakati wa jaribio la uwekaji kwa mfululizo wa kipekee wa 4M.

Hapo juu ni picha ya skrini: InfluxDB - matumizi ya CPU wakati wa jaribio la kuwekewa kwa mfululizo wa kipekee wa 4M.

Hapo juu ni picha ya skrini: TimescaleDB - Matumizi ya CPU wakati wa jaribio la uwekaji kwa mfululizo wa kipekee wa 4M.

VictoriaMetrics hutumia karibu nguvu zote za kitengo cha uchakataji (CPU). Kushuka kwa mwisho kunalingana na miunganisho iliyobaki ya LSM baada ya data yote kuingizwa.

InfluxDB hutumia vCPU 8 pekee kati ya 16, huku TimsecaleDB inatumia vCPU 4 kati ya 16. Je, grafu zao zinafanana nini? Sehemu ya juu iowait, ambayo inaonyesha tena kizuizi cha I/O.

TimescaleDB ina hisa kubwa system. Tunadhani kuwa nishati ya juu ilisababisha simu nyingi za mfumo au nyingi makosa madogo ya ukurasa.

Wacha tuangalie grafu za upitishaji wa diski:

Hapo juu ni picha ya skrini: VictoriaMetrics - Kwa kutumia kipimo data cha diski kuingiza vipimo vya kipekee vya 4M.

Hapo juu ni picha ya skrini: InfluxDB - Kwa kutumia kipimo data cha diski kuingiza vipimo vya kipekee vya 4M.

Hapo juu ni picha ya skrini: TimescaleDB - Kwa kutumia kipimo data cha diski kuingiza vipimo vya kipekee vya 4M.

VictoriaMetrics ilifikia kikomo cha 120 MB/s kwa kilele, huku kasi ya wastani ya kuandika ilikuwa 40 MB/s. Kuna uwezekano kwamba michanganyiko kadhaa nzito ya LSM ilifanywa wakati wa kilele.

InfluxDB inabana tena wastani wa maandishi ya 200 MB/s na kilele cha hadi 340 MB/s kwenye diski yenye upeo wa kuandika wa 120 MB/s :)

TimescaleDB haina kikomo cha diski tena. Inaonekana kupunguzwa na kitu kingine kinachohusiana na idadi kubwa системной Upakiaji wa CPU.

Wacha tuangalie grafu za matumizi ya IO:

Hapo juu ni picha ya skrini: VictoriaMetrics - Kutumia I/O wakati wa jaribio la uwekaji kwa mfululizo wa kipekee wa 4M.

Hapo juu ni picha ya skrini: InfluxDB - Kutumia I/O wakati wa jaribio la uwekaji kwa mfululizo wa kipekee wa 4M.

Hapo juu ni picha ya skrini: TimescaleDB - Matumizi ya I/O wakati wa jaribio la uwekaji kwa mfululizo wa kipekee wa 4M.

Mifumo ya matumizi ya IO inaakisi yale ya kipimo data cha diski - InfluxDB ni IO chache, huku VictoriaMetrics na TimescaleDB zina rasilimali za IO.

Mfululizo wa muda wa kipekee wa 40M

Mfululizo wa muda wa kipekee wa 40M ulikuwa mkubwa sana kwa InfluxDB :)

Matokeo ya ulinganishaji:

• VictoriaMetrics: pointi za data 1,7M kwa sekunde; matumizi ya RAM: 29 GB; Matumizi ya nafasi ya diski: 17 GB.
• InfluxDB: Haijamaliza kwa sababu ilihitaji zaidi ya 60GB ya RAM.
• TimescaleDB: pointi za data 330K kwa sekunde, matumizi ya RAM: GB 2,5; Matumizi ya nafasi ya diski: 84GB.

TimescaleDB inaonyesha matumizi ya chini na thabiti ya RAM katika GB 2,5 - sawa na kwa vipimo vya kipekee vya 4M na 400K.

VictoriaMetrics iliongezeka polepole kwa kasi ya pointi 100k za data kwa sekunde hadi majina yote ya metriki yenye lebo ya 40M yakachakatwa. Kisha alipata kiwango endelevu cha uwekaji wa pointi za data 1,5-2,0M kwa sekunde, hivyo matokeo ya mwisho yalikuwa pointi za data 1,7M kwa sekunde.

Grafu za mfululizo wa muda wa kipekee wa 40M ni sawa na grafu za mfululizo wa muda wa kipekee wa 4M, kwa hivyo tuziruke.

Matokeo

• TSDB za kisasa zina uwezo wa kuchakata ingizo kwa mamilioni ya mfululizo wa kipekee wa saa kwenye seva moja. Katika makala inayofuata, tutajaribu jinsi TSDBs hufanya uteuzi vizuri katika mamilioni ya mfululizo wa kipekee wa wakati.
• Upungufu wa matumizi ya CPU kwa kawaida huonyesha tatizo la I/O. Inaweza pia kuonyesha kuwa kizuizi ni kibaya sana, na nyuzi chache tu zinazoweza kukimbia kwa wakati mmoja.
• Kikwazo cha I/O kipo, haswa katika hifadhi isiyo ya SSD kama vile vifaa vya kuzuia vilivyoboreshwa vya watoa huduma wa wingu.
• VictoriaMetrics hutoa uboreshaji bora zaidi kwa hifadhi ya polepole, ya chini ya I/O. Inatoa kasi bora na uwiano bora wa ukandamizaji.

Pakua Picha ya seva moja ya VictoriaMetrics na ujaribu kwenye data yako. Binari tuli inayolingana inapatikana kwa GitHub.

Soma zaidi kuhusu VictoriaMetrics katika hili Ibara ya.

Sasisho: iliyochapishwa makala kulinganisha utendakazi wa kuingiza wa VictoriaMetrics na InfluxDB na matokeo yanayoweza kurudiwa.

Sasisha #2: Soma pia Nakala juu ya uwekaji wima wa VictoriaMetrics dhidi ya InfluxDB dhidi ya TimescaleDB.

Sasisho #3: VictoriaMetrics sasa ni chanzo wazi!

Gumzo la telegraph: https://t.me/VictoriaMetrics_ru1

Chanzo: mapenzi.com