TSDB бенчмарк с висока производителност VictoriaMetrics срещу TimescaleDB срещу InfluxDB

VictoriaMetrics, TimescaleDB и InfluxDB бяха сравнени в предишна статия върху набор от данни с милиард точки от данни, принадлежащи към 40K уникални времеви серии.

Преди няколко години беше ерата на Zabbix. Всеки гол сървър имаше не повече от няколко показателя - използване на процесора, използване на RAM, използване на диск и използване на мрежа. По този начин показателите от хиляди сървъри могат да се поберат в 40 хиляди уникални времеви серии, а Zabbix може да използва MySQL като бекенд за данни от времеви серии 🙂

В момента един node_exporter с конфигурации по подразбиране предоставя над 500 показателя на среден хост. Има много износители за различни бази данни, уеб сървъри, хардуерни системи и т.н. Всички предоставят много полезни показатели. всичко все повече и повече приложения започват да показват различни признаци върху себе си. Има Kubernetes с клъстери и модули, които разкриват много показатели. Това кара сървърите да излагат хиляди уникални показатели на хост. Така че уникалната времева серия от 40K вече не е с висока мощност. Това се превръща в мейнстрийм, което би трябвало лесно да се обработва от всеки модерен TSDB на един сървър.

Какво представлява голям брой уникални времеви редове в момента? Вероятно 400K или 4M? Или 40м? Нека сравним съвременните TSDB с тези числа.

Бенчмарк инсталация

TSBS е отличен инструмент за сравнителен анализ за TSDB. Тя ви позволява да генерирате произволен брой показатели чрез предаване на необходимия брой времеви серии, разделени на 10 - флаг - мащаб (бивш -scale-var). 10 е броят на измерванията (метрики), генерирани на всеки хост, сървър. Следните набори от данни са създадени с помощта на TSBS за сравнителен анализ:

• 400K уникални времеви серии, интервал от 60 секунди между точките от данни, данните обхващат цели 3 дни, ~1.7B общи точки от данни.
• 4 милиона уникални времеви серии, интервал от 600 секунди, данните обхващат пълни 3 дни, ~1.7 милиарда общи точки от данни.
• 40 милиона уникални времеви серии, интервал от 1 час, данните обхващат 3 пълни дни, ~2.8 милиарда общ брой точки от данни.

Клиентът и сървърът работеха на специални инстанции n1-стандарт-16 в облака на Google. Тези екземпляри имаха следните конфигурации:

• vCPU: 16
• RAM: 60 GB
• Съхранение: Стандартен 1TB HDD. Той осигурява 120 Mbps пропускателна способност за четене/запис, 750 операции за четене в секунда и 1,5K записи в секунда.

TSDB бяха извлечени от официални докер изображения и се изпълняват в докер със следните конфигурации:

• 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 GB; окончателен размер на данните на диска: 965 MB
• InfluxDB: 1.2 милиона точки данни в секунда; Използване на RAM: 8.5 GB; окончателен размер на данните на диска: 1.6 GB
• Времева скала: 849K точки данни в секунда; Използване на RAM: 2,5 GB; окончателен размер на данните на диска: 50 GB

Както можете да видите от резултатите по-горе, VictoriaMetrics печели в производителността на вложката и съотношението на компресия. Времевата линия печели при използване на RAM, но използва много дисково пространство - 29 байта на точка от данни.

По-долу има графики на използването на процесора за всяка от TSDB по време на бенчмарка:

По-горе има екранна снимка: VictoriaMetrics - натоварване на процесора по време на тест за вмъкване за уникален показател от 400K.

Екранна снимка по-горе: InfluxDB - използване на процесора при тест за вмъкване за 400K уникален показател.

Екранна снимка по-горе: TimescaleDB - използване на процесора при тест за вмъкване за 400K уникален показател.

VictoriaMetrics използва всички налични vCPU, докато InfluxDB използва недостатъчно ~2 от 16 vCPU.

Timescale използва само 3-4 от 16 vCPU. Високите пропорции на iowait и system в графиката на времевата скала на TimescaleDB показват тясно място в подсистемата за вход/изход (I/O). Нека да разгледаме графиките за използване на честотната лента на диска:

По-горе има екранна снимка: VictoriaMetrics - Използване на честотната лента на диска при тест за вмъкване за уникални показатели 400K.

По-горе има екранна снимка: InfluxDB - Използване на честотната лента на диска при тест за вмъкване за уникални показатели 400K.

Екранна снимка по-горе: TimescaleDB - Вмъкване на използване на честотна лента на тестов диск за 400K уникални показатели.

VictoriaMetrics записва данни при 20Mbps с пикове до 45Mbps. Пиковете съответстват на големи частични сливания в дървото LSM.

InfluxDB записва данни със 160MB/s, докато 1TB диск трябва да бъдат ограничени честотна лента на запис от 120 MB/s.

TimescaleDB е ограничен до 120Mbps пропускателна способност при запис, но понякога нарушава това ограничение и достига пик при 220Mbps. Тези пикове съответстват на спадовете на недостатъчното използване в предишната графика.

Нека да разгледаме графиките за използване на I/O:

По-горе има екранна снимка: VictoriaMetrics - Вмъкване на тестово I/O използване за 400K уникални показатели.

Екранна снимка по-горе: InfluxDB - Вмъкване на тестово I/O използване за 400K уникални показатели.

Екранна снимка по-горе: TimescaleDB - Вмъкване на тестово I/O използване за 400K уникални показатели.

Сега е ясно, че TimescaleDB достига I/O лимита, така че не може да използва останалите 12 vCPU.

4M уникални времеви серии

4M времеви серии изглеждат малко предизвикателно. Но нашите състезатели издържат успешно този изпит. Резултати от бенчмарк:

• VictoriaMetrics: 2,2 милиона точки данни в секунда; Използване на RAM: 6 GB; окончателен размер на данните на диска: 3 GB.
• InfluxDB: 330K точки данни в секунда; Използване на RAM: 20,5 GB; окончателен размер на данните на диска: 18,4 GB.
• TimescaleDB: 480K точки данни в секунда; Използване на RAM: 2,5 GB; окончателен размер на данните на диска: 52 GB.

Производителността на InfluxDB спадна от 1,2 милиона точки данни в секунда за 400K времеви серии до 330K точки данни в секунда за 4 милиона времеви серии. Това е значителна загуба на производителност в сравнение с други конкуренти. Нека да разгледаме графиките за използване на процесора, за да разберем основната причина за тази загуба:

По-горе има екранна снимка: VictoriaMetrics - използване на процесора по време на тест за вмъкване за уникална 4M времева серия.

Екранна снимка по-горе: InfluxDB - Вмъкване на тестово използване на процесора за 4 милиона уникални времеви серии.

Екранна снимка по-горе: TimescaleDB - Вмъкване на тестово използване на процесора за уникални 4M времеви серии.

VictoriaMetrics използва почти цялата мощност на процесора (CPU). Капката в края съответства на оставащите LSM сливания след вмъкването на всички данни.

InfluxDB използва само 8 от 16 vCPU, докато TimsecaleDB използва 4 от 16 vCPU. Какво е общото между техните класации? висок дял iowait, което отново показва входно/изходно затруднение.

TimescaleDB има висок дял system. Вярваме, че високата мощност е довела до много системни повиквания или до много незначителни грешки на страницата.

Нека да разгледаме графиките на пропускателната способност на диска:

Екранна снимка по-горе: VictoriaMetrics - Използване на честотната лента на диска за вмъкване на 4 милиона уникални показатели.

Екранна снимка по-горе: InfluxDB - Използване на честотната лента на диска за вмъкване на 4 милиона уникални показатели.

Екранна снимка по-горе: TimescaleDB - Използване на честотната лента на диска за вмъкване на 4 милиона уникални показатели.

VictoriaMetrics достигна своя връх от 120MB/s, докато средната скорост на запис беше 40MB/s. Вероятно е имало няколко тежки LSM сливания, извършени по време на пика.

InfluxDB отново изстисква средна пропускателна способност за запис от 200MB/s с пикове до 340MB/s на диск с ограничение за запис от 120MB/s :)

TimescaleDB вече не е дисково ограничен. Изглежда, че е ограничен от нещо друго, свързано с високия дял системной натоварване на процесора.

Нека да разгледаме графиките за използване на IO:

Екранна снимка по-горе: VictoriaMetrics - I/O използване по време на тест за вмъкване за 4M уникални времеви серии.

Екранна снимка по-горе: InfluxDB - I/O използване по време на тест за вмъкване за 4 милиона уникални времеви серии.

Екранна снимка по-горе: TimescaleDB - I/O използване по време на тест за вмъкване за 4 милиона уникални времеви серии.

Графиките за използване на IO отразяват графиките за използване на честотната лента на диска - InfluxDB е ограничен IO, докато VictoriaMetrics и TimescaleDB имат резервни IO IO ресурси.

40 милиона уникални времеви серии

40 милиона уникални времеви серии бяха твърде големи за InfluxDB :)

Резултати от бенчмарк:

• VictoriaMetrics: 1,7 милиона точки данни в секунда; Използване на RAM: 29 GB; използване на дисково пространство: 17 GB.
• InfluxDB: Не завърши, защото изискваше над 60 GB RAM.
• TimescaleDB: 330K точки данни в секунда, използване на RAM: 2,5 GB; използване на дисково пространство: 84GB.

TimescaleDB показва изключително ниско и стабилно използване на RAM при 2,5 GB - същото като за уникалните показатели 4M и 400K.

VictoriaMetrics бавно нарастваше със скорост от 100 40 точки данни в секунда, докато всичките 1,5 милиона етикетирани имена на показатели бяха обработени. След това постигна постоянна скорост на вмъкване от 2,0-1,7 милиона точки данни в секунда, така че крайният резултат беше XNUMX милиона точки данни в секунда.

Графиките за 40 милиона уникални времеви серии са подобни на тези за 4 милиона уникални времеви серии, така че нека ги пропуснем.

Данни

• Съвременните TSDB са в състояние да обработват вмъквания за милиони уникални времеви серии на един сървър. В следващата статия ще тестваме колко добре TSDB извършват избор върху милиони уникални времеви серии.
• Недостатъчното използване на процесора обикновено показва I/O пречка. Може също да означава, че блокирането е твърде грубо, като само няколко нишки могат да се изпълняват наведнъж.
• I/O пречките наистина съществуват, особено в не-SSD хранилища, като виртуализирани блокови устройства на облачни доставчици.
• VictoriaMetrics осигурява най-добрата оптимизация за бавно, ниско I/O съхранение. Той осигурява най-добрата скорост и най-доброто съотношение на компресия.

Изтегли Изображение на един сървър на VictoriaMetrics и го опитайте на вашите данни. Съответният статичен двоичен файл е достъпен на GitHub.

Прочетете повече за VictoriaMetrics в това Статия.

Актуализация: публикувана статия, сравняваща производителността на вмъкване на VictoriaMetrics с InfluxDB с възпроизводими резултати.

Актуализация #2: Прочетете също статия за вертикална мащабируемост VictoriaMetrics срещу InfluxDB срещу TimescaleDB.

Актуализация #3: VictoriaMetrics вече е с отворен код!

Чат в Telegram: https://t.me/VictoriaMetrics_ru1

Източник: www.habr.com