🥇Referentna vrijednost TSDB visokih performansi VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB i InfluxDB uspoređeni su u prethodni članak na skupu podataka s milijardu podatkovnih točaka koje pripadaju 40K jedinstvenim vremenskim serijama.

Prije nekoliko godina došlo je do ere Zabbixa. Svaki bare metal poslužitelj nije imao više od nekoliko pokazatelja - korištenje CPU-a, korištenje RAM-a, korištenje diska i korištenje mreže. Na ovaj način, metrike s tisuća poslužitelja mogu stati u 40 tisuća jedinstvenih vremenskih serija, a Zabbix može koristiti MySQL kao pozadinu za podatke vremenskih serija :)

Trenutno sama čvor_izvoznik sa zadanim konfiguracijama pruža preko 500 metrika na prosječnom hostu. Ima ih mnogo izvoznici za razne baze podataka, web poslužitelje, hardverske sustave itd. Svi oni pružaju niz korisnih metrika. svi sve više i više aplikacija počinju sebi postavljati razne pokazatelje. Postoji Kubernetes s klasterima i podovima koji otkrivaju mnoge metrike. To rezultira time da poslužitelji izlažu tisuće jedinstvenih metrika po hostu. Dakle, jedinstvena vremenska serija od 40K više nije velika snaga. Postaje mainstream i njime bi trebao lako upravljati svaki moderni TSDB na jednom poslužitelju.

Koji je veliki broj jedinstvenih vremenskih serija u ovom trenutku? Vjerojatno 400K ili 4M? ili 40m? Usporedimo moderne TSDB-ove s ovim brojevima.

Instaliranje mjerila

TSBS izvrstan je alat za usporedbu za TSDB-ove. Omogućuje vam generiranje proizvoljnog broja metrika prosljeđivanjem potrebnog broja vremenskih serija podijeljenih s 10 - zastavica -skala (prijašnji -scale-var). 10 je broj mjerenja (metrika) generiranih na svakom glavnom računalu ili poslužitelju. Sljedeći skupovi podataka generirani su pomoću TSBS-a za referentnu vrijednost:

400K jedinstvene vremenske serije, interval od 60 sekundi između podatkovnih točaka, podaci obuhvaćaju puna 3 dana, ~1.7B ukupni broj podatkovnih točaka.
4M jedinstvene vremenske serije, interval od 600 sekundi, podaci obuhvaćaju 3 puna dana, ~1.7B ukupni broj podatkovnih točaka.
40 milijuna jedinstvenih vremenskih serija, interval od 1 sata, podaci obuhvaćaju 3 puna dana, ~2.8 milijardi ukupnih točaka podataka.

Klijent i poslužitelj radili su na namjenskim instancama n1-standard-16 u Google oblaku. Ove su instance imale sljedeće konfiguracije:

vCPU-ovi: 16
RAM-a: 60 GB
Pohrana: standardni HDD od 1 TB. Omogućuje protok čitanja/pisanja od 120 Mbps, 750 operacija čitanja u sekundi i 1,5 K pisanja u sekundi.

TSDB-ovi su izdvojeni iz službenih docker slika i pokrenuti u dockeru sa sljedećim konfiguracijama:

VictoriaMetrics:

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

Vrijednosti InfluxDB (-e) potrebne su za podršku velike snage. Pogledajte detalje u dokumentacija):

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 (konfiguracija preuzeta iz to datoteka):

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

Učitavač podataka pokrenut je sa 16 paralelnih niti.

Ovaj članak sadrži samo rezultate za referentne vrijednosti umetanja. Rezultati selektivnog benchmarka bit će objavljeni u zasebnom članku.

400K jedinstvene vremenske serije

Počnimo s jednostavnim elementima - 400K. Rezultati usporedne analize:

VictoriaMetrics: 2,6 milijuna podatkovnih točaka u sekundi; Upotreba RAM-a: 3 GB; konačna veličina podataka na disku: 965 MB
InfluxDB: 1.2 milijuna podatkovnih točaka u sekundi; Upotreba RAM-a: 8.5 GB; konačna veličina podataka na disku: 1.6 GB
Vremenska skala: 849K podatkovnih točaka u sekundi; Upotreba RAM-a: 2,5 GB; konačna veličina podataka na disku: 50 GB

Kao što možete vidjeti iz gornjih rezultata, VictoriaMetrics pobjeđuje u performansama umetanja i omjeru kompresije. Timeline pobjeđuje u upotrebi RAM-a, ali koristi puno prostora na disku - 29 bajtova po podatkovnoj točki.

Ispod su grafikoni upotrebe CPU-a za svaki od TSDB-ova tijekom referentne vrijednosti:

Gore je snimak zaslona: VictoriaMetrics - CPU opterećenje tijekom testa umetanja za jedinstvenu metriku od 400K.

Gore je snimak zaslona: InfluxDB - CPU opterećenje tijekom testa umetanja za jedinstvenu metriku 400K.

Gore je snimak zaslona: TimescaleDB - CPU opterećenje tijekom testa umetanja za jedinstvenu metriku od 400 K.

VictoriaMetrics koristi sve dostupne vCPU-e, dok InfluxDB nedovoljno iskorištava ~2 od 16 vCPU-a.

Timescale koristi samo 3-4 od 16 vCPU-a. Visoki udjeli iowaita i sustava u TimescaleDB vremenskom grafikonu ukazuju na usko grlo u ulazno/izlaznom (I/O) podsustavu. Pogledajmo grafikone korištenja propusnosti diska:

Iznad je snimak zaslona: VictoriaMetrics - Upotreba propusnosti diska u testu umetanja za jedinstvene metrike 400K.

Iznad je snimka zaslona: InfluxDB - Upotreba propusnosti diska pri testu umetanja za jedinstvene metrike 400K.

Iznad je snimka zaslona: TimescaleDB - Upotreba propusnosti diska pri testu umetanja za jedinstvenu metriku 400K.

VictoriaMetrics bilježi podatke brzinom od 20 Mbps s vršnim brzinama do 45 Mbps. Vrhovi odgovaraju velikim djelomičnim spajanjima u stablu NVO.

InfluxDB zapisuje podatke brzinom od 160 MB/s, dok disk od 1 TB treba ograničiti propusnost pisanja 120 MB/s.

TimescaleDB ograničen je na protok pisanja od 120 Mbps, ali ponekad probija to ograničenje i doseže 220 Mbps u vršnim vrijednostima. Ovi vrhovi odgovaraju dolinama nedovoljne iskorištenosti CPU-a na prethodnom grafikonu.

Pogledajmo grafikone upotrebe ulaza/izlaza (I/O):

Iznad je snimka zaslona: VictoriaMetrics - Umetanje testnog I/O korištenja za 400K jedinstvenih metrika.

Iznad je snimka zaslona: InfluxDB - Umetanje testnog I/O korištenja za 400K jedinstvenih metrika.

Iznad je snimka zaslona: TimescaleDB - Umetanje testnog I/O korištenja za 400K jedinstvenih metrika.

Sada je jasno da TimescaleDB doseže svoje I/O ograničenje, tako da ne može koristiti preostalih 12 vCPU-a.

4M jedinstvene vremenske serije

4M vremenske serije izgledaju pomalo izazovno. Ali naši natjecatelji ovaj ispit uspješno polažu. Rezultati usporedne analize:

VictoriaMetrics: 2,2 milijuna podatkovnih točaka u sekundi; Upotreba RAM-a: 6 GB; konačna veličina podataka na disku: 3 GB.
InfluxDB: 330K podatkovnih točaka u sekundi; Upotreba RAM-a: 20,5 GB; konačna veličina podataka na disku: 18,4 GB.
TimescaleDB: 480K podatkovnih točaka u sekundi; Upotreba RAM-a: 2,5 GB; konačna veličina podataka na disku: 52 GB.

Performanse InfluxDB-a pale su s 1,2 milijuna podatkovnih točaka u sekundi za 400K vremenske serije na 330K podatkovnih točaka u sekundi za 4M vremenske serije. Ovo je značajan gubitak performansi u usporedbi s drugim konkurentima. Pogledajmo grafikone upotrebe CPU-a da bismo razumjeli glavni uzrok ovog gubitka:

Iznad je snimak zaslona: VictoriaMetrics - upotreba CPU-a tijekom testa umetanja za jedinstvenu vremensku seriju od 4M.

Iznad je snimak zaslona: InfluxDB - upotreba CPU-a tijekom testa umetanja za jedinstvene 4M vremenske serije.

Iznad je snimak zaslona: TimescaleDB - upotreba CPU-a tijekom testa umetanja za jedinstvenu vremensku seriju od 4M.

VictoriaMetrics koristi gotovo svu snagu procesorske jedinice (CPU). Ispuštanje na kraju odgovara preostalim LSM spajanjima nakon što su svi podaci umetnuti.

InfluxDB koristi samo 8 od 16 vCPU-a, dok TimsecaleDB koristi 4 od 16 vCPU-a. Što je zajedničko njihovim grafovima? Visok udio iowait, što opet ukazuje na I/O usko grlo.

TimescaleDB ima visok udio system. Pretpostavljamo da je velika snaga rezultirala mnogim ili mnogim sistemskim pozivima manje greške na stranici.

Pogledajmo grafikone propusnosti diska:

Iznad je snimak zaslona: VictoriaMetrics - korištenje propusnosti diska za umetanje 4 milijuna jedinstvenih metrika.

Gore je snimak zaslona: InfluxDB - korištenje propusnosti diska za umetanje 4 milijuna jedinstvenih metrika.

Gore je snimak zaslona: TimescaleDB - korištenje propusnosti diska za umetanje 4 milijuna jedinstvenih metrika.

VictoriaMetrics je na vrhuncu dosegla granicu od 120 MB/s, dok je prosječna brzina pisanja bila 40 MB/s. Vjerojatno je nekoliko teških LSM fuzija izvedeno tijekom vrhunca.

InfluxDB opet istiskuje prosječni protok pisanja od 200 MB/s s vršnim brzinama do 340 MB/s na disku s ograničenjem pisanja od 120 MB/s :)

TimescaleDB više nije ograničen diskom. Čini se da je ograničen nečim drugim što je povezano s visokim udjelom системной CPU opterećenje.

Pogledajmo grafikone korištenja IO-a:

Gore je snimka zaslona: VictoriaMetrics - korištenje I/O tijekom testa umetanja za jedinstvenu 4M vremensku seriju.

Gore je snimak zaslona: InfluxDB - Korištenje I/O tijekom testa umetanja za jedinstvenu vremensku seriju od 4M.

Iznad je snimka zaslona: TimescaleDB - I/O upotreba tijekom testa umetanja za jedinstvene 4M vremenske serije.

IO obrasci korištenja odražavaju one propusnosti diska - InfluxDB je IO ograničen, dok VictoriaMetrics i TimescaleDB imaju rezervne IO resurse.

40M jedinstvene vremenske serije

40M jedinstvenih vremenskih nizova bilo je preveliko za InfluxDB :)

Rezultati usporedne analize:

VictoriaMetrics: 1,7 milijuna podatkovnih točaka u sekundi; Upotreba RAM-a: 29 GB; Zauzetost prostora na disku: 17 GB.
InfluxDB: nije dovršeno jer je zahtijevalo više od 60 GB RAM-a.
TimescaleDB: 330K podatkovnih točaka u sekundi, upotreba RAM-a: 2,5 GB; Zauzetost prostora na disku: 84 GB.

TimescaleDB pokazuje iznimno nisku i stabilnu upotrebu RAM-a na 2,5 GB - isto kao i za jedinstvenu metriku od 4M i 400K.

VictoriaMetrics se polako povećavao brzinom od 100 tisuća podatkovnih točaka u sekundi dok nije obrađeno svih 40 milijuna označenih naziva metrika. Zatim je postigao stalnu stopu umetanja od 1,5-2,0 milijuna podatkovnih točaka u sekundi, tako da je konačni rezultat bio 1,7 milijuna podatkovnih točaka u sekundi.

Grafikoni za 40M jedinstvene vremenske serije slični su grafovima za 4M jedinstvene vremenske serije, pa ih preskočimo.

Zaključci

Moderni TSDB-ovi sposobni su obraditi umetke za milijune jedinstvenih vremenskih serija na jednom poslužitelju. U sljedećem članku testirat ćemo koliko dobro TSDB-ovi izvode odabir u milijunima jedinstvenih vremenskih serija.
Nedovoljna iskorištenost procesora obično ukazuje na I/O usko grlo. To također može značiti da je blokiranje previše grubo, sa samo nekoliko niti koje se mogu pokrenuti istovremeno.
Ulazno/izlazno usko grlo postoji, posebno u pohrani koja nije SSD, kao što su virtualizirani blok uređaji pružatelja usluga oblaka.
VictoriaMetrics pruža najbolju optimizaciju za sporu I/O pohranu. Omogućuje najbolju brzinu i najbolji omjer kompresije.

Preuzimanje Slika jednog poslužitelja VictoriaMetrics i isprobajte to na svojim podacima. Odgovarajuća statička binarna datoteka dostupna je na GitHub.

Pročitajte više o VictoriaMetrics u ovome članak.

Ažuriranje: objavljeno članak koji uspoređuje performanse umetanja VictoriaMetrics s InfluxDB s ponovljivim rezultatima.

Ažuriranje #2: Pročitajte također članak o vertikalnoj skalabilnosti VictoriaMetrics vs InfluxDB vs TimescaleDB.

Ažuriranje #3: VictoriaMetrics je sada otvorenog koda!

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

Izvor: www.habr.com