VPS для TimescaleDB: база временных рядов на PostgreSQL

TimescaleDB — это расширение PostgreSQL для временных рядов: метрик, показаний датчиков, финансовых тиков и логов. Оно даёт производительность специализированной time-series СУБД, сохраняя весь привычный SQL и экосистему Postgres. Развернём его на VPS и настроим гипертаблицы с компрессией.

Что даёт TimescaleDB

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

• Гипертаблицы — прозрачное партиционирование по времени.
• Компрессия — старые данные сжимаются в 10–20 раз.
• Continuous aggregates — предрасчитанные агрегаты, которые обновляются инкрементально.
• Полный SQL — работают JOIN, оконные функции и весь синтаксис Postgres.

Всё это делает TimescaleDB удачным выбором для мониторинга, IoT и аналитики метрик без перехода на экзотические СУБД.

Установка на PostgreSQL

Ставим PostgreSQL и подключаем официальный репозиторий Timescale. Сначала база:

sudo apt update && sudo apt install -y postgresql postgresql-common gnupg curl

Добавляем репозиторий и ставим пакет расширения под вашу версию Postgres:

curl -fsSL https://packagecloud.io/timescale/timescaledb/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/timescale.gpg
echo "deb [signed-by=/usr/share/keyrings/timescale.gpg] https://packagecloud.io/timescale/timescaledb/debian/ $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/timescaledb.list
sudo apt update && sudo apt install -y timescaledb-2-postgresql-16

Утилита timescaledb-tune сама пропишет оптимальные параметры в postgresql.conf под ресурсы сервера:

sudo timescaledb-tune --quiet --yes
sudo systemctl restart postgresql

Создание гипертаблицы

Подключаем расширение к нужной базе и создаём обычную таблицу, а затем превращаем её в гипертаблицу одной функцией.

sudo -u postgres psql -d metrics -c 'CREATE EXTENSION IF NOT EXISTS timescaledb;'

CREATE TABLE readings (
  time        TIMESTAMPTZ NOT NULL,
  sensor_id   INT,
  temperature DOUBLE PRECISION,
  humidity    DOUBLE PRECISION
);
SELECT create_hypertable('readings', 'time');

Вставка данных ничем не отличается от обычного INSERT, а запросы по времени автоматически используют партиционирование по чанкам:

SELECT time_bucket('1 hour', time) AS hour, avg(temperature)
FROM readings
WHERE time > now() - interval '1 day'
GROUP BY hour ORDER BY hour;

Компрессия и хранение

Старые данные редко нужны в исходном виде — их выгодно сжать. Включаем компрессию и задаём политику, которая сжимает чанки старше семи дней автоматически.

ALTER TABLE readings SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'sensor_id'
);
SELECT add_compression_policy('readings', INTERVAL '7 days');

Данные, которые вообще не нужно хранить дольше срока, удаляют политикой ретеншена — это дешевле, чем ручной DELETE:

SELECT add_retention_policy('readings', INTERVAL '1 year');

Компрессия в 10–20 раз ощутимо экономит место на диске, а на быстром NVMe у MAATRIX распаковка нужных чанков при запросе почти не заметна.

Continuous aggregates и проверка

Непрерывные агрегаты хранят предрасчитанные сводки и обновляются инкрементально — идеальны для дашбордов, которые постоянно запрашивают средние за час/день.

CREATE MATERIALIZED VIEW readings_hourly
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS bucket, sensor_id,
       avg(temperature) AS avg_temp
FROM readings GROUP BY bucket, sensor_id;

SELECT add_continuous_aggregate_policy('readings_hourly',
  start_offset => INTERVAL '3 hours',
  end_offset => INTERVAL '1 hour',
  schedule_interval => INTERVAL '1 hour');

• Забыли create_hypertable — данные лягут в обычную таблицу без ускорения.
• Не настроили компрессию — диск быстро заполнится на потоке метрик.
• compress_segmentby выбран неверно — компрессия и запросы работают хуже; берите колонку, по которой чаще фильтруете.

Какой VPS нужен под метрики

TimescaleDB на потоке вставок нагружает и CPU, и диск. AMD EPYC + NVMe у MAATRIX держат высокий темп записи и быстро распаковывают сжатые чанки при аналитике, а локации UK, США и РФ удобны для сбора метрик с зарубежной инфраструктуры. Оплата картой РФ, СБП, криптой или токеном MAAT решает вопрос с иностранными провайдерами, root-доступ нужен для установки расширения, а ежедневные бэкапы страхуют исторические данные.

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