🥇Високопродуктивний TSDB benchmark VictoriaMetrics vs TimescaleDB vs InfluxDB

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

Декілька років тому була епоха Zabbix. Кожен bare metal сервер мав трохи більше кількох показників – використання процесора, використання оперативної пам'яті, використання диска та використання мережі. Таким чином метрики з тисяч серверів можуть поміститися в 40 тисяч унікальних часових рядів, а Zabbix може використовувати MySQL як бекенд для даних часових рядів 🙂

В даний час один node_exporter зі стандартними конфігураціями надає більше 500 метрик на середньому хості. Існує безліч експортерів для різних баз даних, веб-серверів, апаратних систем тощо. д. Усі вони надають безліч корисних показників. Усе більше і більше програм починають виставляти різні показники він. Існує Kubernetes з кластерами та pod-ами, що розкривають безліч метрик. Це призводить до того, що сервери виставляють тисячі унікальних метриків на хост. Таким чином, унікальний часовий ряд 40K більше не є високою потужністю. Він стає мейнстримом, який має бути легко оброблений будь-якою сучасною TSDB на одному сервері.

Що таке велика кількість унікальних часових рядів зараз? Напевно, 400К чи 4М? Або 40м? Порівняємо сучасні TSDBs з цими цифрами.

Установка бенчмарку

TSBS – це чудовий інструмент бенчмаркінгу для TSDBs. Він дозволяє генерувати довільну кількість метрик, передаючи необхідну кількість часових рядів, розділених на 10 - прапор -масштаб (колишній -scale-var). 10 – це кількість вимірів (метрик), що генеруються на кожному хості, сервері. Наступні набори даних були створені за допомогою TSBS для бенчмарку:

400K унікальний часовий ряд, 60 секунд інтервал між точками даних, дані охоплюють повні 3 дні, ~1.7B загальна кількість точок даних.
4M унікальний часовий ряд, інтервал 600 секунд, дані охоплюють повні 3 дні, ~1.7B загальна кількість точок даних.
40M унікальний часовий ряд, інтервал 1 годину, дані охоплюють повні 3 дні, ~2.8 B загальна кількість точок даних.

Клієнт та сервер були запущені на виділених екземплярах n1-стандарт-16 у хмарі Google. Ці екземпляри мали такі зміни:

vCPUs: 16
ОЗУ: 60 ГБ
Зберігання: стандартний жорсткий диск місткістю 1 ТБ. Він забезпечує пропускну здатність читання/запису 120 Мбіт/с, 750 операцій читання за секунду та 1,5К операцій запису за секунду.

TSDBs були вилучені з офіційних образів docker та запущені в 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 паралельними потоками.

Ця стаття містить лише результати для контрольних показників вставки. Результати вибіркового бенчмарку буде опубліковано в окремій статті.

400К унікальних часових рядів

Почнемо з простих елементів - 400К. Результати бенчмарку:

VictoriaMetrics: 2,6 М точок даних за секунду; використання оперативної пам'яті: 3 ГБ; Остаточний розмір даних на диску: 965 МБ
InfluxDB: 1.2M точок даних за секунду; використання оперативної пам'яті: 8.5 Гб; Остаточний розмір даних на диску: 1.6 GB
Timescale: 849K точок даних за секунду; використання оперативної пам'яті: 2,5 ГБ; Остаточний розмір даних на диску: 50 ГБ

Як ви можете бачити з наведених вище результатів, VictoriaMetrics виграє у продуктивності вставки та ступеня стиснення. Тимчасова шкала виграє використання оперативної пам'яті, але вона використовує багато дискового простору — 29 байт на точку даних.

Нижче наведено графіки використання процесора (CPU) для кожного з TSDBs під час бенчмарку:

Вище скріншот: VictoriaMetrics — Завантаження CPU при тестуванні вставки для унікальної метрики 400K.

Вище скріншот: InfluxDB — Завантаження CPU при тестуванні вставки для унікальної метрики 400K.

Вище скріншот: TimescaleDB — Завантаження CPU при тестуванні вставки для унікальної метрики 400K.

VictoriaMetrics використовує всі доступні vCPUs, тоді як InfluxDB недостатньо використовує ~2 з 16 vCPUs.

Timescale використовує лише 3-4 з 16 vCPUs. Високі частки iowait і system на TimescaleDB графіку тимчасових масштабів вказують на вузьке місце в підсистемі вводу-виводу (I/O). Давайте подивимося на графіки використання пропускної здатності диска:

Вище скріншот: VictoriaMetrics — Використання пропускної здатності диска під час тестування вставки для унікальних показників 400K.

Вище скріншот: InfluxDB — Використання пропускної здатності диска під час тестування вставки для унікальних показників 400K.

Вище скріншот: TimescaleDB — Використання пропускної здатності диска під час тестування вставки для унікальних показників 400K.

VictoriaMetrics записує дані зі швидкістю 20 Мбіт/с із піками до 45 Мбіт/с. Піки відповідають великим частковим злиттям у дереві LSM.

InfluxDB записує дані зі швидкістю 160 МБ/с, тоді як 1 ТБ диск має бути обмежений пропускну здатність запису 120 МБ/с.

TimescaleDB обмежена пропускною здатністю запису 120 Мбіт/с, але іноді вона порушує цю межу і досягає 220 Мбіт/с у пікових значеннях. Ці вершини відповідають провалам недостатнього завантаження процесора на попередньому графіку.

Давайте подивимося на графіки використання вводу-виводу (I/O):

Вище скріншот: VictoriaMetrics — Використання введення-виводу при тестуванні вставки для 400K унікальних метрик.

Вище скріншот: InfluxDB — Використання вводу-виводу при тестуванні вставки для 400K унікальних метрик.

Вище скріншот: TimescaleDB — Використання вводу-виводу при тестуванні вставки для 400K унікальних метрик.

Тепер ясно, що TimescaleDB досягає межі вводу-виводу, тому він не може використовувати 12 vCPU, що залишилися.

4M унікальні часові ряди

4M тимчасові ряди виглядають трохи зухвало. Але наші конкуренти успішно складають цей іспит. Результати бенчмарку:

VictoriaMetrics: 2,2 М точок даних за секунду; використання оперативної пам'яті: 6 ГБ; остаточний обсяг даних на диску: 3 ГБ.
InfluxDB: 330К точок даних за секунду; використання оперативної пам'яті: 20,5 ГБ; остаточний обсяг даних на диску: 18,4 ГБ.
TimescaleDB: 480K точок даних за секунду; використання оперативної пам'яті: 2,5 ГБ; остаточний обсяг даних на диску: 52 ГБ.

Продуктивність InfluxDB впала з 1,2 млн точок даних за секунду для 400К часового ряду до 330 тис. точок даних за секунду для 4M тимчасового ряду. Це значна втрата продуктивності проти іншими конкурентами. Давайте подивимося на графіки використання процесора, щоб зрозуміти першопричину цієї втрати:

Вище скріншот: VictoriaMetrics — Використання CPU під час тестування вставки для унікального часового ряду 4M.

Вище скріншот: InfluxDB — Використання CPU під час тестування вставки для унікального часового ряду 4M.

Скріншот: TimescaleDB — Використання CPU при тестуванні вставки для унікального часового ряду 4M.

VictoriaMetrics використовує майже всю потужність процесора (CPU). Зниження в кінці відповідає LSM злиттям, що залишилися після вставки всіх даних.

InfluxDB використовує лише 8 із 16 vCPUs, у той час як TimsecaleDB використовує 4 із 16 vCPUs. Що спільного у їхніх графіків? Висока частка iowait, Що, знову ж таки, вказує на вузьке місце введення-виведення.

TimescaleDB має високу частку system. Вважаємо, що висока потужність привела до багатьох системних викликів або до багатьох minor page faults.

Давайте подивимося на графіки пропускної здатності диска:

Скріншот: VictoriaMetrics — Використання смуги пропускання диска для вставки 4M унікальних метрик.

Вище скріншот: InfluxDB — використання смуги пропускання диска для вставки 4M унікальних метрик.

Скріншот вище: TimescaleDB — Використання смуги пропускання диска для вставки 4M унікальних метрик.

VictoriaMetrics досягали межі 120 МБ/с на пік, тоді як середня швидкість запису становила 40 МБ/с. Ймовірно, під час піку було виконано кілька важких злиття LSM.

InfluxDB знову вичавлює середню пропускну здатність запису 200 МБ/с із піками до 340 МБ/с на диску з обмеженням запису 120 МБ/с 🙂

TimescaleDB більше не обмежена диском. Схоже, що він обмежений чимось ще, пов'язаним із високою часткою системной завантаження CPU.

Давайте подивимося на графіки використання IO:

Вище скріншот: VictoriaMetrics — Використання введення-виводу під час тестування вставки для унікального часового ряду 4M.

Вище скріншот: InfluxDB — Використання введення-виводу під час тестування вставки для унікального часового ряду 4M.

Вище скріншот: TimescaleDB — Використання введення-виведення під час тесту вставки для унікального часового ряду 4M.

Графіки використання IO повторюють графіки використання смуги пропускання диска - InfluxDB обмежений IO, тоді як VictoriaMetrics і TimescaleDB мають запасні ресурси введення-виведення IO.

40М унікальні тайм серії

40М унікальні часові ряди були надто великими для InfluxDB 🙁

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

VictoriaMetrics: 1,7 М точок даних за секунду; використання оперативної пам'яті: 29 ГБ; Використання дискового простору: 17 ГБ.
InfluxDB: не закінчив, тому що для цього потрібно більше 60 ГБ оперативної пам'яті.
TimescaleDB: 330К точок даних за секунду, використання оперативної пам'яті: 2,5 ГБ; Використання дискового простору: 84GB.

TimescaleDB показує виключно низьке та стабільне використання оперативної пам'яті – 2,5 ГБ – стільки ж, скільки і для унікальних метрик 4M та 400K.

VictoriaMetrics повільно збільшувалися зі швидкістю 100 тисяч точок даних за секунду, доки були оброблені все 40М метричних імен з мітками. Потім він досяг стійкої швидкості вставки 1,5-2,0М точок даних за секунду, отже кінцевий результат становив 1,7М точок даних за секунду.

Графіки для 40М унікальних часових рядів аналогічні до графіків для 4М унікальних часових рядів, тому давайте їх пропустимо.

Висновки

Сучасні TSDBs здатні обробляти вставки для мільйонів унікальних часових рядів на одному сервері. У наступній статті ми перевіримо, наскільки добре TSDBs виконує вибір мільйонів унікальних часових рядів.
Недостатнє завантаження процесора зазвичай вказує на вузьке місце введення-виводу. Крім того, це може вказувати на занадто грубе блокування, коли одночасно може працювати лише кілька потоків.
Вузьке місце введення-виведення дійсно існує, особливо в сховищах без SSD, таких як віртуалізовані блокові пристрої хмарних провайдерів.
VictoriaMetrics забезпечує найкращу оптимізацію для повільних сховищ із низьким рівнем введення-виведення. Він забезпечує найкращу швидкість та найкращий ступінь стиснення.

завантажте односерверний образ VictoriaMetrics та спробуйте його на своїх даних. Відповідний статичний двійковий файл доступний GitHub.

Докладніше про VictoriaMetrics читайте у цій статті.

Оновлення: опубліковано стаття, що порівнює продуктивність вставки VictoriaMetrics з InfluxDB із відтворюваними результатами.

Оновлення#2: Читайте також статтю про вертикальну масштабованість VictoriaMetrics vs InfluxDB vs TimescaleDB.

Оновлення #3: VictoriaMetrics тепер з відкритим вихідним кодом!

Телеграм чат: https://t.me/VictoriaMetrics_ru1

Джерело: habr.com