🥇Benchmark i lartë i TSDB VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB dhe InfluxDB janë krahasuar në artikulli i mëparshëm me një set të dhënash që përfshin një miliard pikash të dhënash, që i përkasin 40K serive unike temporale.

Disa vite më parë ishte epoka e Zabbix. Çdo server bare metal kishte maksimum disa indikatorë – përdorimi i procesorit, përdorimi i memorisë, përdorimi i diskut dhe përdorimi i rrjetit. Kështu, metrikat nga mijëra serverë mund të përfshihen në 40 mijë seri unike temporale, dhe Zabbix mund të përdorë MySQL si backend për të dhënat e serive temporale 🙂

Aktualisht, një node_exporter me konfigurimet e paracaktuara ofron më shumë se 500 metrika në një host mesatar. Ekzistojnë shumë eksportuesish për bazat e të dhënave të ndryshme, serverët e uebit, sistemet harduerike etj. Të gjitha ofrojnë shumë indikatorë të dobishëm. Të gjitha më shumë e më shumë aplikacione fillojnë të nxjerrin tregues të ndryshëm. Ka Kubernetes me klasterë dhe pod-e që zbulojnë shumë metrika. Kjo çon në atë që serverët nxjerrin mijëra metrika unike për hostin. Në këtë mënyrë, një seri e vetme kohore 40K nuk është më një kapacitet i lartë. Ai bëhet mainstream, i cili duhet të përballohet lehtë nga çdo TSDB moderne në një server.

Cila është sasia e madhe e serive unike kohore aktualisht? Ndoshta 400K ose 4M? Ose 40m? Le të krahasojmë TSDB-të moderne me këto numra.

Vendosja e benchmark-ut

TSBS është një mjet i shkëlqyer për të bërë benchmarking për TSDB. Ai lejon gjenerimin e një numri të shtegtueshëm të metrikeve, duke transmetuar numrin e nevojshëm të serive kohore, të ndara në 10 - flamuri -scale (ish -scale-var). 10 është numri i matjeve (metrikeve) që gjenerohen në çdo host, server. Grumbujt e mëposhtëm të të dhënave u krijuan me ndihmën e TSBS për benchmark-un:

400K seri unike kohore, intervali 60 sekonda midis pikave të dhënash, të dhënat mbulojnë plot 3 ditë, ~1.7B numri i përgjithshëm i pikave të dhënash.
4M serit të veçantë, intervali 600 sekonda, të dhënat mbulojnë plot 3 ditë, ~1.7B numri total i pikave të të dhënave.
40M serit të veçantë, intervali 1 orë, të dhënat mbulojnë plot 3 ditë, ~2.8 B numri total i pikave të të dhënave.

Klienti dhe serveri u aktivizuan në instancat e dedikuara. n1-standard-16 në cloudin Google. Këto instance kishin konfigurimet e mëposhtme:

vCPUs: 16
RAM: 60 GB
Ruan: disk i ngurtë standard me kapacitet 1 TB. Ai siguron bandwidth leximi/shkrimi 120 Mbit/s, 750 operacione leximi në sekondë dhe 1.5K operacione shkrimi në sekondë.

TSDB-të u nxorrën nga imazhet zyrtare docker dhe u aktivizuan në docker me konfigurimet e mëposhtme:

VictoriaMetrics:

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

Vlerat InfluxDB (-e janë të nevojshme për mbështetje të energjisë së lartë. Detajet shihni në dokumentacion):

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 (konfigurimi u mor nga ky file):

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

Ngarkuesi i të dhënave u nis me 16 rrjedha paralel.

Ky artikull përmban vetëm rezultatet për treguesit e futjes. Rezultatet e testimit të mostrave do të publikohen në një artikull të veçantë.

400K seritë unike të kohës

Le të fillojmë me elementët e thjeshtë — 400K. Rezultatet e testimit:

VictoriaMetrics: 2,6M pika të dhënash në sekondë; përdorimi i memories: 3 GB; madhësia përfundimtare e të dhënave në disk: 965 MB
InfluxDB: 1.2M pika të dhënash në sekondë; përdorimi i memories: 8.5 GB; madhësia përfundimtare e të dhënave në disk: 1.6 GB
Timescale: 849K pika të dhënash në sekondë; përdorimi i memories: 2,5 GB; madhësia përfundimtare e të dhënave në disk: 50 GB

Siç e shihni nga rezultatet e mësipërme, VictoriaMetrics është përparuar në performancën e vendosjes dhe shkallën e kompresimit. Të dhënat e linjës së kohës përdorin më shumë memorje, por kërkojnë shumë hapësirë disku — 29 byte për pikën e të dhënave.

Më poshtë janë grafiket e përdorimit të CPU për secilin nga TSDB gjatë testit të benchmarkut:

Screenshot më lart: VictoriaMetrics — Ngarkesa e CPU gjatë testit të vendosjes për një metrikë unike 400K.

Screenshot më lart: InfluxDB — Ngarkesa e CPU gjatë testit të vendosjes për një metrikë unike 400K.

Screenshot më lart: TimescaleDB — Ngarkesa e CPU gjatë testit të vendosjes për një metrikë unike 400K.

VictoriaMetrics përdor të gjitha vCPU-të e disponueshme, ndërsa InfluxDB përdor vetëm rreth 2 nga 16 vCPU-të.

Timescale përdor vetëm 3-4 nga 16 vCPU-të. Shkallët e larta të iowait dhe sistemit në grafikun e TimescaleDB tregojnë një ngushtesë në nënstacionin e hyrjes-dalitjes (I/O). Le të hedhim një vështrim në grafiket e përdorimit të kapacitetit të diskut:

Screenshot më lart: VictoriaMetrics — Përdorimi i kapacitetit të diskut gjatë testit të vendosjes për metrika unike 400K.

Screenshot i lartem: InfluxDB — Përdorimi i kapacitetit të diskut gjatë provës së inserimit për metrikat unike 400K.

Screenshot i lartem: TimescaleDB — Përdorimi i kapacitetit të diskut gjatë provës së inserimit për metrikat unike 400K.

VictoriaMetrics regjistron të dhëna me shpejtësi 20 Mbit/s me pika deri në 45 Mbit/s. Pikat korrespondojnë me bashkime të mëdha pjesore në pemë. LSM.

InfluxDB regjistron të dhëna me shpejtësi 160 MB/s, ndërsa një disk nga 1 TB duhet të jetë i kufizuar në kapacitetin e shkrimit 120 MB/s.

TimescaleDB është e kufizuar në kapacitetin e shkrimit 120 Mbit/s, por ndonjëherë e kalon këtë kufi dhe arrin 220 Mbit/s në pikat maksimale. Këto pika korrespondojnë me dështime të ngarkesës së pamjaftueshme të procesorit në grafikun e mëparshëm.

Le të shikojmë grafiku i përdorimit të input-output (I/O):

Screenshot i lartem: VictoriaMetrics — Përdorimi i input-output gjatë provës së inserimit për 400K metrika unike.

Screenshot i lartem: InfluxDB — Përdorimi i input-output gjatë provës së inserimit për 400K metrika unike.

Screenshot i lartem: TimescaleDB — Përdorimi i input-output gjatë provës së inserimit për 400K metrika unike.

Tani është e qartë se TimescaleDB arrin kufirin e hyrjes dhe daljes, prandaj nuk mund të përdorë 12 vCPU-të e mbetura.

4M seri të veçanta temporale

4M seri temporale duken pak provokuese. Por konkurrentët tanë e kalojnë këtë provim me sukses. Rezultatet e testit:

VictoriaMetrics: 2.2M pika të dhënash në sekondë; përdorimi i memories: 6 GB; madhësia përfundimtare e të dhënave në disk: 3 GB.
InfluxDB: 330K pika të dhënash në sekondë; përdorimi i memories: 20.5 GB; madhësia përfundimtare e të dhënave në disk: 18.4 GB.
TimescaleDB: 480K pika të dhënash në sekondë; përdorimi i memories: 2.5 GB; madhësia përfundimtare e të dhënave në disk: 52 GB.

Performanca e InfluxDB ra nga 1.2M pika të dhënash në sekondë për 400K seri temporale në 330K pika të dhënash në sekondë për 4M seri temporale. Kjo është një humbje e konsiderueshme e performancës në krahasim me konkurrentët e tjerë. Le të shohim grafikët e përdorimit të CPU-së për të kuptuar shkakun themelor të kësaj humbjeje:

Më lart është një screenshot: VictoriaMetrics — Përdorimi i CPU gjatë testit të inserting për serinë unike temporale 4M.

Screenshoti më lart: InfluxDB — Përdorimi i CPU gjatë testit të futjes për një seri të veçantë të kohës 4M.

Screenshoti më lart: TimescaleDB — Përdorimi i CPU gjatë testit të futjes për një seri të veçantë të kohës 4M.

VictoriaMetrics përdor pothuajse gjithë fuqinë e procesorit (CPU). Rënia në fund përputhet me bashkimet e mbetura LSM pas futjes së të dhënave.

InfluxDB përdor vetëm 8 nga 16 vCPUs, ndërsa TimescaleDB përdor 4 nga 16 vCPUs. Çfarë kanë të përbashkët grafiket e tyre? Pjesa e lartë iowait, e cila, përsëri, tregon për një ngushticë në hyrje-dalje.

TimescaleDB ka një pjesë të lartë system. Mendojmë se fuqia e lartë çoi në shumë thirrje sistemike ose në shumë minor page faults.

Le të shohim grafikët e kapacitetit të diskut:

Screenshoti më lart: VictoriaMetrics — Përdorimi i kapacitetit të diskut për futjen e 4M metrikave unike.

Screenshoti më lart: InfluxDB — Përdorimi i kapacitetit të diskut për futjen e 4M metrikave unike.

Screenshoti më lart: TimescaleDB — Përdorimi i kapacitetit të diskut për futjen e 4M metrikave unike.

VictoriaMetrics arriti kulminacionin e 120 MB/s në pik, ndërsa shpejtësia mesatare e shkrimit ishte 40 MB/s. Probabilisht, gjatë kulmit u bënë disa bashkime të rënda LSM.

InfluxDB përsëri arrin një shpejtësi mesatare shkrimi prej 200 MB/s, me kulme deri në 340 MB/s në disk me kufizim shkrimi prej 120 MB/s 🙂

TimescaleDB nuk është më e kufizuar nga disku. Duket se është e kufizuar nga diçka tjetër që lidhet me një përqindje të lartë sistematike ngarkesës së CPU.

Le të shikojmë grafiket e përdorimit të IO:

Më sipër është screenshot: VictoriaMetrics — Përdorimi i hyrjes dhe daljes gjatë testit të shkarkimit për një seri të veçantë prej 4M.

Më sipër është screenshot: InfluxDB — Përdorimi i hyrjes dhe daljes gjatë testit të shkarkimit për një seri të veçantë prej 4M.

Më sipër është screenshot: TimescaleDB — Përdorimi i hyrjes dhe daljes gjatë testit të shkarkimit për një seri të veçantë prej 4M.

Grafiket e përdorimit të IO përsërisin grafiket e përdorimit të bandwidth-it të diskut — InfluxDB është e kufizuar nga IO, ndërsa VictoriaMetrics dhe TimescaleDB kanë resurse të lira për hyrje dhe dalje.

40M seri të veçanta të kohës

40M seri të veçanta të kohës ishin shumë të mëdha për InfluxDB 🙁

Rezultatet e benchmark-ut:

VictoriaMetrics: 1.7M piksel në sekondë; përdorimi i memories: 29 GB; përdorimi i hapësirës diskore: 17 GB.
InfluxDB: nuk u përfundua, sepse kërkonte më shumë se 60 GB memorie.
TimescaleDB: 330K piksel në sekondë, përdorimi i memories: 2.5 GB; përdorimi i hapësirës diskore: 84GB.

TimescaleDB tregon përdorim të jashtëzakonshëm të ulët dhe stabil të memories – 2.5 GB – po aq sa për metrikat unike 4M dhe 400K.

VictoriaMetrics u rrit ngadalë me një shpejtësi prej 100 mijë piksel në sekondë, derisa u përpunuan të gjitha 40M emrat e metrikave me etiketa. Pastaj arriti një shpejtësi të qëndrueshme të futjes prej 1.5-2.0M piksel në sekondë, kështu që rezultati përfundimtar ishte 1.7M piksel në sekondë.

Grafikët për 40M seri unike kohore janë të ngjashëm me grafikët për 4M seri unike kohore, kështu që le t'i kalojmë ato.

Përfundimet

TSDB moderne janë të afta të përpunojnë futje për miliona seri unike kohore në një server. Në artikullin e ardhshëm do të shikojmë se sa mirë TSDB-të realizojnë zgjedhjen për miliona seri unike kohore.
Ngarkesa e pamjaftueshme e procesorit zakonisht tregon një ngushticë në hyrje-dalje. Përveç kësaj, kjo mund të tregojë bllokim shumë të coars, kur vetëm disa procese mund të funksionojnë në të njëjtën kohë.
Ngushtica në hyrje-dalje është vërtet e pranishme, sidomos në ruajtjet pa SSD, siç janë pajisjet e bllokut të virtualizuara të ofruesve të mjeteve.
VictoriaMetrics ofron optimizimin më të mirë për ruajtjet e ngadalta me nivele të ulta hyrje-dalje. Ai siguron shpejtësinë më të mirë dhe shkallën më të mirë të kompresimit.

Shkarko imazhin një-server të VictoriaMetrics dhe provoje me të dhënat e tua. Skedari statik përkatës është i disponueshëm në GitHub.

Më shumë rreth VictoriaMetrics mund të lexosh në këtë artikullin.

Përditësim: është publikuar një artikull që krahason performancën e futjes së VictoriaMetrics me InfluxDB me rezultate të riprodhueshme.

Përditësim#2: Lexo gjithashtu artikullin mbi shkallëzimin vertikal të VictoriaMetrics vs InfluxDB vs TimescaleDB.

Përditësim #3: VictoriaMetrics tani është me burim të hapur!

Grupi në Telegram: https://t.me/VictoriaMetrics_ru1

Burimi: habr.com