Временные ряды: пром-наблюдение, TSDB, OLAP

Как хранить метрики — и почему мы выбрали гибрид

Prometheus, InfluxDB и DuckDB решают разные части одной задачи. Ниже — честное сравнение: сильные стороны, ограничения и потенциал каждой технологии, а затем архитектура нашего сервиса.

Войти

Три подхода к хранению временных рядов

Мы сравнили три зрелые технологии. Каждая решает свою задачу — но ни одна не покрывает всё.

Prometheus — мониторинг

CNCF-стандарт наблюдаемости: pull-модель сбора и строгая дисциплина меток.

Преимущества

  • Pull-сбор метрик по HTTP (экспортёры) или push через Pushgateway
  • Многомерная модель: имя метрики + набор меток
  • PromQL — зрелый язык запросов для агрегаций
  • Автономные ноды: работают в сбой в отличие от внешних зависимостей

Ограничения

  • Не гарантирует 100% точности (дискретное scrapping) — не для биллинга
  • Долгосрочное хранение и ретеншн — отдельная инженерия
  • High-кардинальность многого стоит в памяти

Потенциал

  • Экосистема: Alertmanager, Grafana, OpenMetrics, remote write
  • Де-факто стандарт для Kubernetes-observability

InfluxDB — специализированный TSDB

Профильная база временных рядов с упором на скорость записи и кардинальность.

Преимущества

  • Line Protocol: компактная потоковая запись точек
  • Высокая кардинальность тегов без раздувания
  • Ретеншн-политики и даунсемплинг из коробки
  • Поколение 3: Parquet + SQL-интерфейс поверх

Ограничения

  • Ресурсоёмкость и операционная сложность (в3 — кластерный стек)
  • Кривая Flux для не-простых запросов
  • Вендорная парадигма: облако/enterprise-тиражирование

Потенциал

  • InfluxDB 3 Core/Enterprise/Cloud — движки на Parquet и объектном хранилище
  • SQL поверх временных данных возвращается (вместе с InfluxQL и Flux)

DuckDB — колоночный OLAP-движок

Встраиваемая аналитическая база: колонки, сжатие и полный SQL для временных данных.

Преимущества

  • Встраивается прямо в процесс (нет сервера/демона)
  • Колоночное хранение и сильное сжатие
  • Время — родной тип: DATE_BIN, TIME_BUCKET, интервалы
  • Файл = база: копия файла — это бэкап
  • Активная разработка (v1.5.x, официальный Go-драйвер)

Ограничения

  • Не заточен под конкурентную потоковую запись (OLAP, а не ingest)
  • Одна база пишется одним процессом
  • Для высоких частот нужны батчи (Appender), а не поточечные INSERT

Потенциал

  • Аналитика «поверх» метрик без отдельного склада
  • Экспорт в Parquet, партиции, материализованные view
  • Потенциальный вертикальный масштаб: аналитика обрабатывается локально

Почему мы выбрали гибрид: аналитика и OLTP раздельно

Метрики — это аналитическая нагрузка (читаем широко, пишем батчами), а атрибутика сайта — транзакционная. Смешивать их в одном движке — компромисс для обоих сценариев.

SQLite — данные сайта

Транзакционная часть: то, что меняется редко и должно быть консистентным.

  • Пользователи и роли (bcrypt-хеши)
  • Сессии с TTL
  • Реестр метрических баз: имя → путь к файлу DuckDB

DuckDB — метрики

Колоночный слой: один файл на одну метрику, формат samples(ts, val).

  • 1 имя = 1 файл data/<name>.duckdb
  • Батч-запись через Appender (буфер + flush)
  • SQL-чтение диапазонов и последних точек

Готовы посмотреть на метрики вживую?

Email и пароль выдаёт администратор. После входа — выбор метрики и живой график.

Войти в сервис