SQL или собственный язык: TimescaleDB и InfluxDB спорят о запросах

MAATRIX

Если вы копите метрики, показания датчиков или логи ценовых движений и упёрлись в вопрос «какую базу для этого поднимать», выбор обычно сужается до двух: TimescaleDB, которая работает поверх обычного PostgreSQL, или InfluxDB — специализированный движок со своим языком запросов. Разница не в маркетинге, а в том, что вы получаете реально: знакомый SQL и вся экосистема Postgres против узкой заточки под временные ряды и своего диалекта запросов. Ниже — честное сравнение без придуманных цифр, с акцентом на то, что действительно меняется для команды, которая будет это администрировать.

Что это вообще за две разные архитектуры

TimescaleDB — это расширение (extension) для PostgreSQL, а не отдельная СУБД. Вы ставите обычный Postgres, накатываете CREATE EXTENSION timescaledb, и таблицы с временными данными превращаются в гипертаблицы — они физически партиционируются по времени (и опционально по дополнительному ключу), но снаружи выглядят как обычная таблица SQL. Если вы уже устанавливали и настраивали PostgreSQL на VPS, TimescaleDB для вас — это шаг поверх уже знакомой базы, а не новая система с нуля.

InfluxDB — самостоятельный движок, написанный специально под один паттерн нагрузки: постоянная запись точек «метрика + значение + временная метка + теги» и агрегации по времени. У неё собственный формат хранения (TSM-движок), собственная модель данных (bucket, measurement, tag, field) и собственный язык запросов — Flux во второй версии или InfluxQL, если вы держите первую или третью версию с обратной совместимостью. Если InfluxDB у вас ещё не стоит, процесс установки подробно разобран в статье про установку InfluxDB на VPS — там же про пакет vs Docker, организацию и токены.

Ключевая развилка на старте: TimescaleDB просит у вас уже иметь (или завести) реляционную модель с таблицами, схемой, внешними ключами при желании. InfluxDB просит у вас думать в терминах measurement/tag/field — модель более плоская и заточенная именно под временные ряды, без джойнов.

SQL против Flux: одни и те же запросы на практике

Разница ощущается сразу, как только вы пишете первый нетривиальный запрос. Допустим, задача — средняя температура по датчикам за последние 24 часа с шагом в час.

TimescaleDB (обычный SQL с функцией time_bucket):

SELECT
  time_bucket('1 hour', ts) AS bucket,
  sensor_id,
  avg(temperature) AS avg_temp
FROM sensor_data
WHERE ts > now() - interval '24 hours'
GROUP BY bucket, sensor_id
ORDER BY bucket DESC;

Тот же запрос на Flux в InfluxDB:

from(bucket: "sensors")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "temperature")
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: false)
  |> group(columns: ["sensor_id"])

Оба варианта рабочие и по объёму сопоставимы. Разница в другом: SQL-запрос читает любой разработчик или аналитик в команде — синтаксис GROUP BY, WHERE, оконные функции знакомы почти всем. Flux — это функциональный язык с конвейером через |>, он логичен внутри себя, но у него отдельная кривая обучения, и найти человека, который уже писал на Flux, сложнее, чем найти того, кто писал SQL.

Если задача сложнее — например, джойн метрик с таблицей метаданных устройств (модель, версия прошивки, локация) — в TimescaleDB это обычный JOIN по внешнему ключу:

SELECT d.location, avg(s.temperature)
FROM sensor_data s
JOIN devices d ON d.id = s.sensor_id
WHERE s.ts > now() - interval '7 days'
GROUP BY d.location;

В InfluxDB джойнов в привычном смысле нет — есть функция join() во Flux, которая работает по-другому (объединяет два потока данных по общему времени/тегу), и для сложных связей это часто неудобнее, чем реляционный джойн. Если у вас в проекте, помимо метрик, есть обычные справочники и связи между сущностями — это довод в пользу TimescaleDB, потому что вы получаете и то, и другое в одной базе без интеграции двух систем.

InfluxDB же выигрывает там, где запрос — это чистая агрегация по времени и тегам без связей: посчитать перцентили, найти пиковые значения, применить скользящее окно. Функции вроде aggregateWindow, derivative, median заточены под это лучше, чем ручной SQL с оконными функциями, хотя PostgreSQL и TimescaleDB тоже умеют перцентили (percentile_cont) и оконные функции — просто пишутся они многословнее.

Установка и первое знакомство на VPS

Установка TimescaleDB на Ubuntu — это добавление репозитория Timescale поверх уже настроенного PostgreSQL:

sudo sh -c "echo 'deb https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -c -s) main' > /etc/apt/sources.list.d/timescaledb.list"
wget --quiet -O - https://packagecloud.io/timescale/timescaledb/gpgkey | sudo apt-key add -
sudo apt update
sudo apt install timescaledb-2-postgresql-16
sudo timescaledb-tune --quiet --yes
sudo systemctl restart postgresql

После этого в базе:

CREATE EXTENSION IF NOT EXISTS timescaledb;
CREATE TABLE sensor_data (
  ts TIMESTAMPTZ NOT NULL,
  sensor_id INT NOT NULL,
  temperature DOUBLE PRECISION
);
SELECT create_hypertable('sensor_data', 'ts');

Если PostgreSQL на сервере ещё нет — сначала нужна база сама по себе, и только потом расширение поверх неё.

InfluxDB устанавливается как отдельный сервис — либо родным пакетом, либо контейнером:

docker run -d --name influxdb \
  -p 8086:8086 \
  -v influxdb-data:/var/lib/influxdb2 \
  influxdb:2

Дальше — обязательная инициализация через веб-интерфейс или CLI: организация, bucket, токен доступа. Разница на этом этапе не в сложности (обе базы поднимаются за 10–15 минут), а в том, что для InfluxDB это отдельный незнакомый сервис с собственным набором сущностей, а TimescaleDB встраивается в то, с чем вы, скорее всего, уже работали.

Модель данных и приём нагрузки

В TimescaleDB данные пишутся обычным INSERT — построчно или пакетно через COPY, как в любой Postgres-таблице:

INSERT INTO sensor_data (ts, sensor_id, temperature)
VALUES (now(), 42, 23.7);

Для высокой частоты записи имеет смысл батчить вставки на стороне приложения (сотни-тысячи строк за раз через COPY или multi-row INSERT), иначе накладные расходы на транзакцию съедят пропускную способность — это общая особенность PostgreSQL, а не специфика Timescale.

InfluxDB изначально построена под построчную запись в формате line protocol:

temperature,sensor_id=42,location=warehouse value=23.7 1735689600000000000

Формат компактный, легко генерируется из любого языка, и клиентские библиотеки сами буферизуют точки перед отправкой батчами через HTTP API. Для потока с большим числом источников (тысячи датчиков, каждый пишет раз в секунду) это ощущается естественнее — не нужно вручную придумывать батчинг, это часть модели протокола.

Важный нюанс модели данных: в InfluxDB есть разделение на tags (индексируются, используются для фильтрации и группировки) и fields (собственно значения, не индексируются). Если ошибиться и положить в tag поле с высокой кардинальностью — например, уникальный ID запроса вместо ID датчика — легко получить проблему с ростом индекса (series cardinality), которая ощутимо просаживает и запись, и память. В TimescaleDB такой проблемы в том же виде нет, потому что индексы вы создаёте сами и осознанно, как в обычном Postgres — но это и накладывает на вас ответственность за то, чтобы не забыть индекс там, где он нужен.

Где выигрывает специализация InfluxDB

У InfluxDB есть встроенные механизмы, ради которых её и берут:

• Retention policies — данные старше заданного срока удаляются автоматически на уровне bucket, без отдельного cron-задания.
• Continuous queries / tasks — можно настроить фоновую задачу, которая на лету агрегирует сырые данные (например, раз в секунду) в даунсэмплированные (раз в час) и кладёт их в отдельный bucket с более долгим хранением.
• Компрессия под временные ряды — TSM-движок изначально проектировался под то, что соседние точки одной серии похожи по значению, и сжимает это эффективнее, чем универсальный движок хранения.

Всё это в TimescaleDB тоже есть, но требует явной настройки через SQL, а не «из коробки»:

-- политика сжатия старых чанков
ALTER TABLE sensor_data SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'sensor_id'
);
SELECT add_compression_policy('sensor_data', INTERVAL '7 days');

-- политика удаления старых данных
SELECT add_retention_policy('sensor_data', INTERVAL '90 days');

-- непрерывная агрегация (аналог continuous query)
CREATE MATERIALIZED VIEW sensor_hourly
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', ts) AS bucket, sensor_id, avg(temperature)
FROM sensor_data
GROUP BY bucket, sensor_id;

По факту получаются сопоставимые возможности — но в InfluxDB это встроенная часть интерфейса и документации именно для time series, а в TimescaleDB это набор функций, которые нужно найти, понять и правильно применить поверх общей SQL-базы. Если в команде никто раньше не работал с time-series базами вообще, «дорожка из коробки» у InfluxDB короче.

Там, где InfluxDB объективно выигрывает при большом потоке однотипных точек — это соотношение объёма диска к количеству записанных значений: специализированное сжатие под повторяющиеся числовые ряды обычно компактнее, чем универсальные механизмы Postgres, даже с включённой компрессией Timescale. Насколько именно — сильно зависит от характера данных (кардинальность тегов, разброс значений), и приводить точный процент без бенчмарка на ваших реальных данных было бы нечестно.

Где выигрывает знакомая экосистема TimescaleDB

Обратная сторона: если у вас уже есть PostgreSQL с другими данными приложения (пользователи, заказы, конфигурация), TimescaleDB позволяет держать метрики в той же базе — не поднимать отдельный сервис, не тащить вторую систему бэкапов, не разбираться с другим протоколом мониторинга. Одна база — один процесс pg_dump, один pg_basebackup, одна точка отказа вместо двух.

Экосистема инструментов вокруг PostgreSQL несопоставимо шире: ORM почти любого языка программирования говорит с Postgres из коробки, тогда как для InfluxDB нужен отдельный клиент и понимание Flux/InfluxQL на стороне приложения. Инструменты для миграций схемы, репликации, мониторинга самого движка — всё то же, что вы уже используете для основной базы. Если данные из time-series таблицы иногда нужно джойнить с обычными реляционными данными (частый случай — «показать метрики устройства вместе с его паспортными данными»), это одна SQL-строка в TimescaleDB и заметно менее тривиальная операция в InfluxDB.

Grafana одинаково хорошо умеет и в TimescaleDB (через стандартный PostgreSQL datasource), и в InfluxDB (нативный datasource) — так что выбор визуализации на решение не влияет. Если вы уже сравнивали связку хранилищ метрик с другими вариантами, полезно заодно посмотреть на VictoriaMetrics как альтернативу Prometheus — там тот же принцип выбора: совместимость и знакомый инструментарий против узкой специализации.

Ещё один довод в пользу TimescaleDB — это не единственное специализированное расширение поверх Postgres, которое вы, возможно, уже используете. Например, pgvector добавляет векторный поиск прямо в ту же базу — идея та же: не плодить отдельные специализированные сервисы под каждую задачу, а расширять то хранилище, которое уже есть и уже умеете администрировать.

Стоимость администрирования: что реально требует ухода

Здесь разница ощутимее, чем в производительности запросов.

TimescaleDB наследует всё обслуживание PostgreSQL: настройку shared_buffers и work_mem, мониторинг autovacuum (для гипертаблиц он работает по чанкам, что обычно легче, чем на одной гигантской таблице, но vacuum остаётся вашей заботой), резервное копирование через pg_dump/pg_basebackup или WAL-архивирование, настройку репликации при необходимости отказоустойчивости. Если у вас уже есть выстроенный процесс обслуживания Postgres — добавление Timescale почти не увеличивает эксплуатационную нагрузку. Если процесса нет — вы получаете все типовые грабли PostgreSQL, включая рост WAL при активной записи и необходимость следить за bloat.

InfluxDB администрируется отдельно от всего остального: свой процесс бэкапов (influx backup/influx restore), свои метрики для мониторинга самого движка, отдельная политика доступа через токены и организации. Кластерная версия с высокой доступностью в InfluxDB — платная (Enterprise/Cloud), тогда как открытая версия работает в один узел без встроенной репликации; если нужна отказоустойчивость на уровне самой базы, это отдельный вопрос архитектуры, который стоит продумать заранее, а не после первого падения сервера.

С точки зрения человеко-часов на поддержку: если в команде уже есть DBA или инженер, плотно знающий PostgreSQL, добавление TimescaleDB — это несколько дней на изучение специфичных функций (гипертаблицы, политики сжатия, continuous aggregates), а не новая профессия. InfluxDB требует отдельного погружения — новый язык запросов, новая модель прав доступа, новый набор операционных практик, даже если сама установка была быстрой.

Частые вопросы