Гнев, торг и депрессия при работе с InfluxDB / Хабр https://habr.

com/ru/post/449028/

Все потоки Разработка Администрирование Дизайн Менедж мент Маркетинг Науч поп Войти Регистрация

jekatigr 22 апреля 2019 в 17:51

Гнев, торг и депрессия при работе с InfluxDB

Разработка веб-сайтов, SQL, Администрирование баз данных, Хранилища данных

Из песочницы

Если использовать БД временных рядов (timeseries db, wiki) как основное хранилище для сайта со статистикой, то вместо
реш ения задачи можно получить много головной боли. Я работаю над проектом, где используется такая база, и иногда InfluxDB,
о которой пойдет речь, преподносила вообще неожиданные сюрпризы.

Disclaimer: приведенные проблемы относятся к версии InfluxDB 1.7.4.

Почему time series?

Проект заключается в отслеживании транзакций в различных блокчейнах и отображении статистики. Конкретно — смотрим
эмиссию и сжигание стэйбл-коинов (wiki). На основе этих транзакций нужно строить графики и показывать сводные таблицы.

При анализе транзакций приш ла идея: использовать базу данных временных рядов InfluxDB как основное хранилище. Транзакции
являются точками во времени и в модель временного ряда они хорош о вписываются.

Еще функции агрегации выглядели весьма удобно — для обработки графиков с больш им периодом идеально подходят.
Пользователю нужен график за год, а в базе лежит набор данных с таймфреймом в пять минут. Все сто тысяч точек ему
отправлять бессмысленно — кроме долгой обработки, они и на экране не поместятся. Можно написать свою реализацию
увеличения таймфрейма, либо воспользоваться встроенными в Influx функциями агрегации. С их помощью можно
сгруппировать данные по дням и отправить нужные 365 точек.

Немного смущало то, что обычно такие базы используют с целью сбора метрик. Мониторинг серверов, iot-устройства, все, с
чего «льются» миллионы точек вида: [<время> — <значение метрики>]. Но если база хорош о работает с больш им потоком
данных, то почему маленький объем должен вызывать проблемы? С этой мыслью взяли InfluxDB в работу.

Что еще удобного в InfluxDB

Кроме упомянутых функций агрегации есть еще одна замечательная вещь — continuous queries (doc). Это встроенный в БД
планировщик, который может обрабатывать данные по расписанию. Например, можно каждые 24 часа группировать все записи
за день, считать среднее и записывать одну новую точку в другую таблицу без написания собственных велосипедов.

Также есть retention policies (doc) — настройка удаления данных после какого-то периода. Полезно, когда например, нужно
хранить нагрузку на CPU за неделю с измерениями раз в секунду, а на дистанции в пару месяцев такая точность не нужна. В такой

Стр. 1 из 2 19.05.2020, 11:49

Гнев, торг и депрессия при работе с InfluxDB / Хабр https://habr.com/ru/post/449028/

Стр. 2 из 2 19.05.2020, 11:49