🥇Standard TSDB me performancë të lartë VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB dhe InfluxDB u krahasuan në artikulli i mëparshëm në një grup të dhënash me një miliard pika të dhënash që i përkasin 40K serive kohore unike.

Disa vite më parë ishte një epokë e Zabbix. Çdo server metalik i zhveshur kishte jo më shumë se disa tregues - përdorimin e CPU-së, përdorimin e RAM-it, përdorimin e diskut dhe përdorimin e rrjetit. Në këtë mënyrë, metrikat nga mijëra serverë mund të përshtaten në 40 mijë seri unike kohore, dhe Zabbix mund të përdorë MySQL si një backend për të dhënat e serive kohore :)

Aktualisht vetëm nyja_eksportues me konfigurime të paracaktuara ofron mbi 500 metrikë në hostin mesatar. Ka shume eksportuesit për baza të ndryshme të dhënash, serverë ueb, sisteme harduerike, etj. Të gjitha ato ofrojnë një shumëllojshmëri metrikash të dobishme. Të gjitha gjithnjë e më shumë aplikacione fillojnë të vendosin tregues të ndryshëm për veten e tyre. Ka Kubernetes me grupime dhe pods që ekspozojnë shumë metrika. Kjo rezulton në serverët që ekspozojnë mijëra metrika unike për host. Pra, seritë unike kohore 40K nuk janë më me fuqi të lartë. Ajo po bëhet e zakonshme dhe duhet të trajtohet lehtësisht nga çdo TSDB moderne në një server të vetëm.

Cili është numri i madh i serive kohore unike për momentin? Ndoshta 400 mijë apo 4 milion? Apo 40 m? Le të krahasojmë TSDB-të moderne me këta numra.

Instalimi i një standardi

TSBS është një mjet i shkëlqyer krahasimi për TSDB-të. Kjo ju lejon të gjeneroni një numër arbitrar të metrikës duke kaluar numrin e kërkuar të serive kohore të ndarë me 10 - flamur - shkallë (ish -scale-var). 10 është numri i matjeve (metrikave) të gjeneruara në çdo host ose server. Të dhënat e mëposhtme u krijuan duke përdorur TSBS për standardin:

400K seri unike kohore, interval prej 60 sekondash midis pikave të të dhënave, të dhënat zgjasin plot 3 ditë, ~ 1.7 miliardë numrin total të pikave të të dhënave.
4M seri unike kohore, interval 600 sekonda, të dhënat zgjasin 3 ditë të plota, ~1.7B numri total i pikave të të dhënave.
40 milion seri unike kohore, interval 1 ore, te dhenat perfshijne 3 dite te plota, ~2.8 B numri total i pikave te te dhenave.

Klienti dhe serveri funksiononin në instanca të dedikuara n1-standard-16 në Google cloud. Këto raste kishin konfigurimet e mëposhtme:

vCPU: 16
RAM: 60 GB
Hapësira ruajtëse: HDD standard 1 TB. Ofron xhiro leximi/shkrimi 120 Mbps, 750 operacione leximi për sekondë dhe 1,5K shkrime për sekondë.

TSDB-të janë nxjerrë nga imazhet zyrtare të dokerit dhe janë ekzekutuar në doker 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) kërkohen për të mbështetur fuqinë e lartë. Shihni detajet në dokumentacionin):

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 i marrë nga ajo skedari):

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 ekzekutua me 16 fije paralele.

Ky artikull përmban vetëm rezultate për standardet e futjes. Rezultatet e standardit selektiv do të publikohen në një artikull të veçantë.

400K seri unike kohore

Le të fillojmë me elementë të thjeshtë - 400K. Rezultatet e standardeve:

VictoriaMetrics: 2,6 milion pikë të dhënash për sekondë; Përdorimi RAM: 3 GB; Madhësia përfundimtare e të dhënave në disk: 965 MB
InfluxDB: 1.2M pikë të dhënash për sekondë; Përdorimi RAM: 8.5 GB; Madhësia përfundimtare e të dhënave në disk: 1.6 GB
Shkalla kohore: 849 mijë pika të dhënash për sekondë; Përdorimi i RAM-it: 2,5 GB; Madhësia përfundimtare e të dhënave në disk: 50 GB

Siç mund ta shihni nga rezultatet e mësipërme, VictoriaMetrics fiton në performancën e futjes dhe raportin e kompresimit. Timeline fiton në përdorimin e RAM-it, por përdor shumë hapësirë në disk - 29 bajt për pikë të dhënash.

Më poshtë janë grafikët e përdorimit të CPU-së për secilën prej TSDB-ve gjatë standardit:

Më sipër është një pamje e ekranit: VictoriaMetrics - Ngarkimi i CPU-së gjatë testit të futjes për një metrikë unike 400K.

Më sipër është një pamje e ekranit: InfluxDB - Ngarkesa e CPU-së gjatë testit të futjes për metrikë unike 400K.

Më sipër është një pamje e ekranit: TimescaleDB - Ngarkimi i CPU-së gjatë testit të futjes për një metrikë unike prej 400K.

VictoriaMetrics përdor të gjitha vCPU-të e disponueshme, ndërsa InfluxDB nuk përdor ~2 nga 16 vCPU.

Shkalla kohore përdor vetëm 3-4 nga 16 vCPU. Përqindjet e larta të iowait dhe sistemit në grafikun e shkallës kohore TimescaleDB tregojnë një pengesë në nënsistemin hyrje/dalje (I/O). Le të shohim grafikët e përdorimit të gjerësisë së brezit të diskut:

Më sipër është një pamje e ekranit: VictoriaMetrics - Përdorimi i gjerësisë së brezit të diskut në testin e futjes për Metrics Unique 400K.

Më sipër është një pamje e ekranit: InfluxDB - Përdorimi i gjerësisë së brezit të diskut në testin e futjes për metrikë unike 400K.

Më sipër është një pamje e ekranit: TimescaleDB - Përdorimi i gjerësisë së brezit të diskut në testin e futjes për Metrics Unique 400K.

VictoriaMetrics regjistron të dhëna në 20 Mbps me maksimum deri në 45 Mbps. Majat korrespondojnë me bashkimet e mëdha të pjesshme në pemë LSM.

InfluxDB shkruan të dhëna me 160 MB/s, ndërsa një disk 1 TB duhet të jetë i kufizuar shpejtësia e shkrimit 120 MB/s.

TimescaleDB është i kufizuar në xhiron e shkrimit prej 120 Mbps, por ndonjëherë e thyen këtë kufi dhe arrin 220 Mbps në vlerat maksimale. Këto maja korrespondojnë me luginat e shfrytëzimit të pamjaftueshëm të CPU-së në grafikun e mëparshëm.

Le të shohim grafikët e përdorimit të hyrjes/daljes (I/O):

Më sipër është një pamje ekrani: VictoriaMetrics - Fut përdorimin e testit të hyrjes/daljes për 400K metrikë unike.

Më sipër është një pamje e ekranit: InfluxDB - Fut përdorimin e testit të hyrjes/daljes për metrikë unike 400K.

Më sipër është një pamje e ekranit: TimescaleDB - Fut përdorimin e testit të hyrjes/daljes për 400K metrikë unike.

Tani është e qartë se TimescaleDB po arrin kufirin e saj I/O, kështu që nuk mund të përdorë 12 vCPU-të e mbetura.

Seri kohore unike 4M

Seritë kohore 4M duken paksa sfiduese. Por konkurrentët tanë e kalojnë këtë provim me sukses. Rezultatet e standardeve:

VictoriaMetrics: 2,2 milion pikë të dhënash në sekondë; Përdorimi RAM: 6 GB; Madhësia përfundimtare e të dhënave në disk: 3 GB.
InfluxDB: 330K pika të dhënash për sekondë; Përdorimi RAM: 20,5 GB; Madhësia përfundimtare e të dhënave në disk: 18,4 GB.
TimescaleDB: 480K pika të dhënash për sekondë; Përdorimi i RAM: 2,5 GB; Madhësia përfundimtare e të dhënave në disk: 52 GB.

Performanca e InfluxDB ra nga 1,2 milion pikë të dhënash për sekondë për një seri kohore 400K në 330K pikë të dhënash për sekondë për një seri kohore 4M. 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 për të kuptuar shkakun rrënjësor të kësaj humbjeje:

Më sipër është një pamje e ekranit: VictoriaMetrics - Përdorimi i CPU-së gjatë testit të futjes për një seri unike kohore 4M.

Më sipër është një pamje e ekranit: InfluxDB - Përdorimi i CPU-së gjatë testit të futjes për seritë unike kohore 4M.

Më sipër është një pamje e ekranit: TimescaleDB - Përdorimi i CPU-së gjatë testit të futjes për një seri unike kohore 4M.

VictoriaMetrics përdor pothuajse të gjithë fuqinë e njësisë së përpunimit (CPU). Rënia në fund korrespondon me bashkimet e mbetura LSM pasi të jenë futur të gjitha të dhënat.

InfluxDB përdor vetëm 8 nga 16 vCPU, ndërsa TimsecaleDB përdor 4 nga 16 vCPU. Çfarë kanë të përbashkët grafikët e tyre? Pjesë e lartë iowait, e cila përsëri tregon një pengesë hyrëse/dalëse.

TimescaleDB ka një pjesë të lartë system. Ne supozojmë se fuqia e lartë rezultoi në shumë thirrje sistemore ose shumë gabime të vogla të faqes.

Le të shohim grafikët e xhiros së diskut:

Më sipër është një pamje e ekranit: VictoriaMetrics - Përdorimi i gjerësisë së brezit të diskut për të futur metrikë unike 4M.

Më sipër është një pamje e ekranit: InfluxDB - Përdorimi i gjerësisë së brezit të diskut për të futur metrikë unike 4M.

Më sipër është një pamje e ekranit: TimescaleDB - Përdorimi i gjerësisë së brezit të diskut për të futur metrikë unike 4M.

VictoriaMetrics arriti një kufi prej 120 MB/s në kulmin, ndërsa shpejtësia mesatare e shkrimit ishte 40 MB/s. Ka të ngjarë që disa bashkime të rënda LSM janë kryer gjatë pikut.

InfluxDB përsëri shtrydh një xhiro mesatare shkrimi prej 200 MB/s me maksimum deri në 340 MB/s në një disk me një kufi shkrimi prej 120 MB/s :)

TimescaleDB nuk është më i kufizuar në disk. Duket se kufizohet nga diçka tjetër që lidhet me proporcionin e lartë системной Ngarkesa e CPU-së.

Le të shohim grafikët e përdorimit të IO:

Më sipër është një pamje e ekranit: VictoriaMetrics - Përdorimi i I/O gjatë testit të futjes për një seri unike kohore 4M.

Më sipër është një pamje e ekranit: InfluxDB - Përdorimi i I/O gjatë testit të futjes për një seri unike kohore 4M.

Më sipër është një pamje e ekranit: TimescaleDB - Përdorimi I/O gjatë testit të futjes për seritë unike kohore 4M.

Modelet e përdorimit të IO pasqyrojnë ato të gjerësisë së brezit të diskut - InfluxDB është IO i kufizuar, ndërsa VictoriaMetrics dhe TimescaleDB kanë burime rezervë IO.

40 milion seri unike kohore

40 milion seri unike kohore ishte shumë e madhe për InfluxDB :)

Rezultatet e standardeve:

VictoriaMetrics: 1,7 milion pikë të dhënash në sekondë; Përdorimi RAM: 29 GB; Përdorimi i hapësirës në disk: 17 GB.
InfluxDB: Nuk përfundoi sepse kërkonte më shumë se 60 GB RAM.
TimescaleDB: 330K pikë të dhënash për sekondë, përdorimi RAM: 2,5 GB; Përdorimi i hapësirës në disk: 84 GB.

TimescaleDB tregon përdorim jashtëzakonisht të ulët dhe të qëndrueshëm të RAM-it në 2,5 GB - njësoj si për metrikat unike 4M dhe 400K.

VictoriaMetrics u rrit ngadalë me një shpejtësi prej 100 mijë pika të dhënash në sekondë derisa të përpunoheshin të gjithë emrat metrikë të etiketuar 40 milion. Më pas ai arriti një shkallë të qëndrueshme futjeje prej 1,5-2,0M pikë të dhënash për sekondë, kështu që rezultati përfundimtar ishte 1,7M pikë të dhënash për sekondë.

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

Gjetjet

TSDB-të moderne janë të afta të përpunojnë inserte për miliona seri unike kohore në një server të vetëm. Në artikullin tjetër, ne do të testojmë se sa mirë kryen përzgjedhjen TSDB-të në miliona seri unike kohore.
Përdorimi i pamjaftueshëm i CPU-së zakonisht tregon një pengesë në hyrje/dalje. Mund të tregojë gjithashtu se bllokimi është shumë i trashë, me vetëm disa fije që mund të funksionojnë në të njëjtën kohë.
Gryka e ngushta I/O ekziston, veçanërisht në ruajtjen jo-SSD, siç janë pajisjet e bllokut të virtualizuar të ofruesve të cloud.
VictoriaMetrics ofron optimizimin më të mirë për ruajtjen e ngadaltë dhe të ulët të hyrjes/daljes. Ai siguron shpejtësinë më të mirë dhe raportin më të mirë të kompresimit.

Shkarko Imazhi i VictoriaMetrics me një server dhe provojeni në të dhënat tuaja. Binar statik përkatës është i disponueshëm në GitHub.

Lexoni më shumë rreth VictoriaMetrics në këtë artikull.

Përditësimi: i publikuar artikull që krahason performancën e inserteve të VictoriaMetrics me InfluxDB me rezultate të riprodhueshme.

Përditësimi #2: Lexoni gjithashtu artikull mbi shkallëzueshmërinë vertikale VictoriaMetrics vs InfluxDB vs TimescaleDB.

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

Biseda në telegram: https://t.me/VictoriaMetrics_ru1

Burimi: www.habr.com