Что такое база временных рядов: TimescaleDB, InfluxDB и другие

Коротко

База временных рядов (TSDB) хранит измерения, привязанные ко времени: показания датчиков, загрузку CPU серверов, курсы валют, число заказов в минуту. У таких данных предсказуемая форма, и TSDB построены вокруг неё: быстрая запись новых точек, быстрые запросы по интервалам времени, автоматическое удаление старых данных и заранее посчитанные агрегаты.

С первого дня она не нужна. Хорошо проиндексированная таблица PostgreSQL выдерживает многое. TSDB окупается, когда данные постоянно растут, сырые точки нужно хранить ограниченное время, а дашбордам нужны агрегаты по минутам, часам и дням.

Чем особенны временные ряды

• Только дописывание. Новые точки поступают постоянно, старые почти не меняются.
• Запросы по времени. Почти каждый запрос — «для этого устройства или метрики, за этот период, с группировкой по интервалу».
• Срок хранения (retention). Сырые данные со временем теряют ценность. Хранить посекундные показания годами дорого и часто бесполезно.
• Прореживание (downsampling). Старые данные хранят в виде агрегатов: среднее, минимум и максимум за минуту или час вместо каждой точки.
• Риск высокой кардинальности. Каждая уникальная комбинация меток (устройство, регион, клиент) создаёт отдельный ряд. Слишком много комбинаций замедляет большинство TSDB.

Когда хватает обычной таблицы PostgreSQL

Если устройств или метрик умеренное количество, а запросы простые, начните так:

CREATE TABLE readings (
  device_id  integer      NOT NULL,
  ts         timestamptz  NOT NULL,
  temperature numeric(5,2),
  PRIMARY KEY (device_id, ts)
);
-- для данных, которые пишутся по порядку времени, компактный BRIN-индекс ускоряет выборки по диапазону
CREATE INDEX readings_ts_brin ON readings USING brin (ts);

Когда таблица вырастет, добавьте декларативное секционирование по времени (например, по месяцам): удалить старую секцию намного дешевле, чем выполнить большой DELETE. Признаки, что вы переросли такую схему: управление секциями превращается в ручную работу, агрегирующие запросы тормозят, хранилище растёт быстрее бюджета.

Основные варианты

TimescaleDB

Расширение PostgreSQL. Таблицы становятся гипертаблицами, которые автоматически делятся на временные чанки. Добавляются сжатие, политики хранения и непрерывные агрегаты (материализованные сводки, обновляемые инкрементально). Остаются полный SQL, JOIN с обычными бизнес-таблицами и привычные инструменты PostgreSQL. Часть функций распространяется под собственной лицензией вендора — проверьте условия для своего варианта хостинга.

InfluxDB

Специализированная TSDB со своей моделью данных: measurements, tags (индексируемые метки) и fields (значения). Запись простая, срок хранения встроен, есть большая экосистема сборщиков, прежде всего Telegraf. Язык запросов менялся между мажорными версиями, поэтому перед тем как строить на нём систему, уточните, какой язык у вашей версии.

ClickHouse

Колоночная аналитическая СУБД — формально не TSDB, но очень сильная на больших объёмах событий и метрик. Секционирование по времени, правила TTL для удаления и материализованные представления для агрегатов закрывают типичные задачи временных рядов. Отлично сканирует и агрегирует миллиарды строк; частые обновления и точечные удаления — не её сильная сторона.

Prometheus

Система мониторинга со встроенной TSDB. Сама забирает метрики у сервисов, хранит их локально и отвечает на запросы на PromQL; алертинг — часть экосистемы. Локальное хранилище рассчитано на оперативный срок хранения, долгосрочное обычно выносят в remote-write-бэкенды. Собственная документация не рекомендует использовать его там, где нужны абсолютно точные данные по каждому событию, например для биллинга.

Как выбрать под задачу

Деньги храните в точных десятичных типах, а эталонный реестр операций держите в транзакционной базе; в TSDB — аналитическая копия.

Частые ошибки

• ID пользователей или запросов в метках — взрыв кардинальности.
• Хранение сырых данных вечно, без плана хранения и прореживания.
• Отдельная TSDB там, где на самом деле нужен один дополнительный индекс в PostgreSQL.
• Отношение к метрикам Prometheus как к точным бизнес-записям.