🥇Өндөр гүйцэтгэлтэй TSDB жишиг VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB болон InfluxDB-г харьцуулсан өмнөх нийтлэл 40К өвөрмөц цагийн цувралд хамаарах тэрбум өгөгдлийн цэг бүхий өгөгдлийн багц дээр.

Хэдэн жилийн өмнө Zabbix-ийн эрин үе байсан. Нүцгэн металл сервер бүр цөөн хэдэн үзүүлэлттэй байсан - CPU-ийн хэрэглээ, RAM-ийн хэрэглээ, дискний хэрэглээ, сүлжээний хэрэглээ. Ингэснээр мянга мянган серверийн хэмжигдэхүүнүүд 40 мянган өвөрмөц цагийн цувралд багтах боломжтой бөгөөд Zabbix MySQL-г хугацааны цувааны өгөгдлийн арын хэсэг болгон ашиглах боломжтой болно :)

Одоогоор ганцаараа зангилаа_экспортлогч өгөгдмөл тохиргоотой нь дундаж хост дээр 500 гаруй хэмжигдэхүүнийг өгдөг. Олон бий экспортлогчид төрөл бүрийн өгөгдлийн сан, вэб сервер, техник хангамжийн систем гэх мэт. Тэд бүгдээрээ төрөл бүрийн хэрэгцээтэй хэмжүүрүүдийг өгдөг. Бүгд илүү олон програмууд өөрсөддөө янз бүрийн үзүүлэлтүүдийг тогтоож эхэлдэг. Олон хэмжигдэхүүнийг харуулсан кластер, подволтой Кубернетес байдаг. Үүний үр дүнд серверүүд нэг хост бүрт олон мянган өвөрмөц хэмжигдэхүүнүүдийг ил гаргадаг. Тиймээс өвөрмөц 40K цагийн цуврал нь өндөр хүч байхаа больсон. Энэ нь түгээмэл болж байгаа бөгөөд орчин үеийн ямар ч TSDB нэг сервер дээр хялбархан зохицуулагдах ёстой.

Одоогийн байдлаар олон тооны өвөрмөц цагийн цуваа хэд байна вэ? Магадгүй 400К эсвэл 4М? Эсвэл 40 м? Орчин үеийн ХХБ-уудыг эдгээр тоонуудтай харьцуулж үзье.

Жишиг шалгуурыг суулгаж байна

TSBS нь ХХБ-ыг харьцуулах маш сайн хэрэгсэл юм. Энэ нь шаардлагатай тооны цагийн цувааг 10-д хуваах замаар дурын тооны хэмжигдэхүүнийг үүсгэх боломжийг олгодог - туг - масштаб (хуучин -scale-var). 10 нь хост эсвэл сервер тус бүр дээр үүсгэгдсэн хэмжилтийн тоо (хэмжих) юм. Жишиг туршилтын хувьд TSBS ашиглан дараах өгөгдлийн багцыг үүсгэсэн.

400K өвөрмөц цагийн цуваа, өгөгдлийн цэгүүдийн хоорондох 60 секундын интервал, өгөгдөл нь бүтэн 3 өдөр, өгөгдлийн цэгүүдийн нийт тоо ~1.7B байна.
4M өвөрмөц цагийн цуврал, 600 секундын интервал, өгөгдөл нь бүтэн 3 өдөр, өгөгдлийн цэгүүдийн нийт тоо ~1.7B.
40 сая өвөрмөц цагийн цуваа, 1 цагийн интервал, өгөгдөл нь бүтэн 3 өдөр, өгөгдлийн цэгүүдийн нийт тоо ~2.8B байна.

Үйлчлүүлэгч болон сервер нь тусгайлсан тохиолдлууд дээр ажиллаж байсан n1-стандарт-16 Google үүлэн дээр. Эдгээр тохиолдлууд дараах тохиргоотой байсан:

vCPU: 16
RAM: 60 ГБ
Хадгалах: Стандарт 1TB HDD. Энэ нь секундэд 120 Mbps унших/бичих чадвар, секундэд 750 унших үйлдэл, секундэд 1,5К бичих чадварыг хангадаг.

TSDB-г албан ёсны докерын зургуудаас гаргаж аваад дараах тохиргоотой docker-д ажиллуулсан:

VictoriaMetrics:

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

Өндөр хүчийг дэмжихийн тулд InfluxDB (-e) утгууд шаардлагатай. Дэлгэрэнгүйг эндээс үзнэ үү баримт бичиг):

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 (тохиргоог энэ нь файл):

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

Өгөгдөл дуудагчийг 16 зэрэгцээ урсгалтай ажиллуулсан.

Энэ нийтлэлд зөвхөн оруулах шалгуур үзүүлэлтийн үр дүнг агуулна. Сонгон шалгаруулалтын үр дүнг тусдаа нийтлэлд нийтлэх болно.

400K өвөрмөц цагийн цуврал

Энгийн элементүүдээс эхэлье - 400K. Жишиг үр дүн:

VictoriaMetrics: секундэд 2,6 сая өгөгдлийн цэг; RAM ашиглалт: 3 ГБ; Диск дээрх эцсийн өгөгдлийн хэмжээ: 965 MB
InfluxDB: секундэд 1.2 сая өгөгдлийн цэг; RAM ашиглалт: 8.5 ГБ; Диск дээрх эцсийн өгөгдлийн хэмжээ: 1.6 ГБ
Цагийн хуваарь: секундэд 849К өгөгдлийн цэг; RAM ашиглалт: 2,5 ГБ; Диск дээрх эцсийн өгөгдлийн хэмжээ: 50 ГБ

Дээрх үр дүнгээс харахад VictoriaMetrics нь оруулах гүйцэтгэл болон шахалтын харьцаагаар ялсан. Он цагийн хэлхээс нь RAM-ийн хэрэглээнд ялдаг боловч энэ нь маш их дискний зай ашигладаг - өгөгдлийн цэг бүрт 29 байт.

Жишиг туршилтын явцад TSDB тус бүрийн CPU ашиглалтын графикуудыг доор харуулав.

Дээрх нь дэлгэцийн агшин юм: VictoriaMetrics - өвөрмөц 400K хэмжигдэхүүнийг оруулах туршилтын явцад CPU ачаалал.

Дээрх дэлгэцийн агшин: InfluxDB - Өвөрмөц хэмжигдэхүүн 400K-д оруулах туршилтын явцад CPU ачаалал.

Дэлгэцийн агшин дээр: TimescaleDB - 400K өвөрмөц хэмжигдэхүүнийг оруулах туршилтын явцад CPU ачаалал.

VictoriaMetrics нь боломжтой бүх vCPU-г ашигладаг бол InfluxDB нь 2 vCPU-с ~16-ыг нь дутуу ашигладаг.

Цагийн хуваарь нь 3 vCPU-ийн 4-16-ийг л ашигладаг. TimescaleDB цагийн хуваарийн график дахь iowait болон системийн өндөр хувь хэмжээ нь оролт/гаралтын (I/O) дэд системд гацаа байгааг харуулж байна. Дискний зурвасын өргөн хэрэглээний графикуудыг харцгаая.

Дээрх нь дэлгэцийн агшин юм: VictoriaMetrics - Өвөрмөц хэмжигдэхүүн 400K-д зориулсан оруулах тест дэх дискний зурвасын өргөнийг ашиглах.

Дээрх нь дэлгэцийн агшин юм: InfluxDB - Өвөрмөц хэмжигдэхүүн 400K-д зориулсан оруулах тестийн дискний зурвасын өргөнийг ашиглах.

Дээрх нь дэлгэцийн агшин юм: TimescaleDB - Өвөрмөц хэмжигдэхүүн 400K-д зориулсан оруулах тестийн дискний зурвасын өргөнийг ашиглах.

VictoriaMetrics нь өгөгдлийг 20 Mbps хурдтай, 45 Mbps хүртэл дээд хурдаар бүртгэдэг. Оргилууд нь модны том хэсэгчилсэн нэгдэлд нийцдэг ТББ.

InfluxDB нь 160 TB дисктэй байхад 1 MB/s хурдаар өгөгдөл бичдэг хязгаарлагдмал байх ёстой бичих чадвар 120 MB/s.

TimescaleDB нь 120 Mbps бичих чадвараар хязгаарлагддаг боловч заримдаа энэ хязгаарыг зөрчиж, оргил утгаараа 220 Mbps хүрдэг. Эдгээр оргилууд нь өмнөх график дээрх CPU-ийн хангалтгүй ашиглалтын хөндийтэй тохирч байна.

Оролт/гаралтын (оролт/гаралтын) ашиглалтын графикуудыг харцгаая:

Дээрх нь дэлгэцийн агшин юм: VictoriaMetrics - 400K өвөрмөц хэмжигдэхүүнд зориулсан туршилтын I/O хэрэглээг оруулах.

Дээрх нь дэлгэцийн агшин юм: InfluxDB - 400K өвөрмөц хэмжигдэхүүнд зориулсан туршилтын I/O хэрэглээг оруулах.

Дээрх нь дэлгэцийн агшин юм: TimescaleDB - 400K өвөрмөц хэмжигдэхүүнд зориулсан туршилтын I/O хэрэглээг оруулах.

Одоо TimescaleDB нь I/O хязгаартаа хүрч байгаа нь тодорхой болсон тул үлдсэн 12 vCPU-г ашиглах боломжгүй байна.

4M өвөрмөц цагийн цуврал

4M цагийн цуврал нь бага зэрэг хэцүү харагдаж байна. Гэхдээ манай өрсөлдөгчид энэ шалгалтыг амжилттай давдаг. Жишиг үр дүн:

VictoriaMetrics: секундэд 2,2 сая өгөгдлийн цэг; RAM ашиглалт: 6 ГБ; Диск дээрх эцсийн өгөгдлийн хэмжээ: 3 ГБ.
InfluxDB: секундэд 330K өгөгдлийн цэг; RAM ашиглалт: 20,5 ГБ; Диск дээрх эцсийн өгөгдлийн хэмжээ: 18,4 ГБ.
TimescaleDB: секундэд 480К өгөгдлийн цэг; RAM ашиглалт: 2,5 ГБ; Диск дээрх эцсийн өгөгдлийн хэмжээ: 52 ГБ.

InfluxDB-ийн гүйцэтгэл 1,2К хугацааны цувралын хувьд секундэд 400 сая өгөгдлийн цэгээс 330М цагийн цувралын хувьд секундэд 4К өгөгдөл болж буурсан. Энэ нь бусад өрсөлдөгчидтэй харьцуулахад гүйцэтгэлийн мэдэгдэхүйц алдагдал юм. Энэхүү алдагдлын үндсэн шалтгааныг ойлгохын тулд CPU-ийн хэрэглээний графикуудыг харцгаая.

Дэлгэцийн агшин дээр: VictoriaMetrics - өвөрмөц 4M цагийн цувралыг оруулах туршилтын үед CPU-ийн хэрэглээ.

Дэлгэцийн агшин дээр: InfluxDB - өвөрмөц 4M цагийн цувралын туршилтын явцад CPU-ийн хэрэглээ.

Дээрх дэлгэцийн агшин: TimescaleDB - Өвөрмөц 4M цагийн цувралын туршилтын явцад CPU-ийн хэрэглээ.

VictoriaMetrics нь боловсруулах нэгжийн (CPU) бараг бүх хүчийг ашигладаг. Төгсгөлд байгаа уналт нь бүх өгөгдлийг оруулсны дараа үлдсэн LSM нэгтгэлүүдтэй тохирч байна.

InfluxDB нь 8 vCPU-ийн ердөө 16-ыг нь ашигладаг бол TimsecaleDB нь 4 vCPU-ийн 16-ийг нь ашигладаг. Тэдний графикууд юугаараа нийтлэг байдаг вэ? Өндөр хувь iowait, энэ нь дахин оролт/гаралтын бөглөрөл байгааг илтгэнэ.

TimescaleDB нь өндөр хувьтай байдаг system. Өндөр хүчин чадал нь системийн олон дуудлага эсвэл олон дуудлагад хүргэсэн гэж бид таамаглаж байна хуудасны жижиг алдаа.

Дискний дамжуулалтын графикийг харцгаая:

Дээрх нь дэлгэцийн агшин юм: VictoriaMetrics - 4M өвөрмөц хэмжигдэхүүнийг оруулахын тулд дискний зурвасын өргөнийг ашиглах.

Дээрх нь дэлгэцийн агшин юм: InfluxDB - 4M өвөрмөц хэмжигдэхүүнийг оруулахын тулд дискний зурвасын өргөнийг ашиглах.

Дээрх нь дэлгэцийн агшин юм: TimescaleDB - 4M өвөрмөц хэмжигдэхүүнийг оруулахын тулд дискний зурвасын өргөнийг ашиглах.

VictoriaMetrics оргил үедээ 120 MB/s-ийн хязгаарт хүрсэн бол бичих дундаж хурд 40 MB/s байв. Оргил үед хэд хэдэн хүнд LSM хайлуулсан байх магадлалтай.

InfluxDB нь 200 МБ/с бичих хязгаартай дискэн дээр 340 МБ/с хүртэл дээд тал нь 120 МБ/с бичих дундаж хурдыг дахин шахаж байна :)

TimescaleDB нь дискээр хязгаарлагдахаа больсон. Энэ нь өндөр хувьтай холбоотой өөр зүйлээр хязгаарлагдаж байх шиг байна системной CPU ачаалал.

IO хэрэглээний графикуудыг харцгаая:

Дэлгэцийн агшин дээр: VictoriaMetrics - 4M цаг хугацааны өвөрмөц цувралд оруулах туршилтын явцад I/O-г ашиглах.

Дээрх нь дэлгэцийн агшин юм: InfluxDB - Өвөрмөц 4M цагийн цувралд оруулах туршилтын явцад I/O-г ашиглах.

Дээрх нь дэлгэцийн агшин юм: TimescaleDB - Өвөрмөц 4M цагийн цувааг оруулах туршилтын үеийн I/O ашиглалт.

IO ашиглалтын загвар нь дискний зурвасын өргөнийг тусгадаг - InfluxDB нь IO хязгаарлагдмал байдаг бол VictoriaMetrics болон TimescaleDB нь нөөц IO нөөцтэй.

40 сая өвөрмөц цагийн цуврал

40 сая өвөрмөц цагийн цуврал InfluxDB-д хэтэрхий том байсан :)

Жишиг үр дүн:

VictoriaMetrics: секундэд 1,7 сая өгөгдлийн цэг; RAM ашиглалт: 29 ГБ; Дискний зай ашиглалт: 17 ГБ.
InfluxDB: 60 ГБ-аас дээш RAM шаардсан тул дуусгаж чадсангүй.
TimescaleDB: секундэд 330К өгөгдлийн цэг, RAM ашиглалт: 2,5 ГБ; Дискний зай ашиглалт: 84 ГБ.

TimescaleDB нь 2,5 ГБ-д маш бага, тогтвортой RAM-ийн хэрэглээг харуулдаг бөгөөд энэ нь өвөрмөц 4M болон 400K хэмжигдэхүүнтэй адил юм.

VictoriaMetrics нь секундэд 100 мянган өгөгдлийн цэгийн хурдтайгаар 40 сая тэмдэглэгээтэй хэмжигдэхүүний нэрсийг боловсруулах хүртэл аажмаар нэмэгдэв. Дараа нь тэрээр секундэд 1,5-2,0 сая өгөгдлийн цэгийн тогтмол оруулах хурдтай болсон тул эцсийн үр дүн нь секундэд 1,7 сая мэдээллийн цэг болсон.

40М өвөрмөц цагийн цувралын графикууд нь 4М өвөрмөц цагийн цувааны графиктай төстэй тул алгасацгаая.

үр дүн нь

Орчин үеийн TSDB нь нэг сервер дээр сая сая давтагдашгүй цагийн цувралын оруулгыг боловсруулах чадвартай. Дараагийн өгүүллээр бид TSDB нь сая сая давтагдашгүй цаг хугацааны цувралын сонголтуудыг хэр сайн гүйцэтгэдэг болохыг шалгах болно.
CPU-ийн хангалтгүй хэрэглээ нь ихэвчлэн оролт/гаралтын бөглөрөл байгааг илтгэнэ. Энэ нь мөн блоклох нь хэтэрхий бүдүүлэг, нэг удаад хэдхэн утас ажиллах боломжтой байгааг илтгэж магадгүй юм.
Оролт/гаралтын түгжрэл ялангуяа үүлэн үйлчилгээ үзүүлэгчдийн виртуалчлагдсан блок төхөөрөмж гэх мэт SSD бус санах ойд байдаг.
VictoriaMetrics нь удаан, бага I/O хадгалахад хамгийн сайн оновчлолоор хангадаг. Энэ нь хамгийн сайн хурд, хамгийн сайн шахалтын харьцааг өгдөг.

Татаж авах VictoriaMetrics нэг серверийн зураг мөн үүнийг өөрийн өгөгдөл дээр туршиж үзээрэй. Харгалзах статик хоёртын файлыг эндээс авах боломжтой GitHub.

VictoriaMetrics-ийн талаар дэлгэрэнгүй уншина уу нийтлэл.

Шинэчлэлт: нийтлэгдсэн VictoriaMetrics-ийн оруулгын гүйцэтгэлийг InfluxDB-тэй харьцуулсан нийтлэл давтагдах боломжтой үр дүнтэй.

Шинэчлэлт №2: Мөн уншина уу VictoriaMetrics vs InfluxDB vs TimescaleDB хоёрын босоо өргөтгөлийн тухай нийтлэл.

Шинэчлэлт №3: VictoriaMetrics одоо нээлттэй эх сурвалж болсон!

Telegram чат: https://t.me/VictoriaMetrics_ru1

Эх сурвалж: www.habr.com