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

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

Блог MAATRIX · 2026-07-07

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

Содержание

  1. Что даёт TimescaleDB
  2. Установка на PostgreSQL
  3. Создание гипертаблицы
  4. Компрессия и хранение
  5. Continuous aggregates и проверка
  6. Какой VPS нужен под метрики

Что даёт TimescaleDB

['TimescaleDB превращает обычную таблицу в гипертаблицу — она автоматически бьётся на чанки по времени. За счёт этого запросы по диапазону дат и вставка свежих данных работают на порядки быстрее, чем в плоской таблице на миллиарды строк.', '
  • Гипертаблицы — прозрачное партиционирование по времени.
  • Компрессия — старые данные сжимаются в 10–20 раз.
  • Continuous aggregates — предрасчитанные агрегаты, которые обновляются инкрементально.
  • Полный SQL — работают JOIN, оконные функции и весь синтаксис Postgres.
', 'Всё это делает TimescaleDB удачным выбором для мониторинга, IoT и аналитики метрик без перехода на экзотические СУБД.']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для TimescaleDB

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

['Ставим PostgreSQL и подключаем официальный репозиторий Timescale. Сначала база:', '
sudo apt update && sudo apt install -y postgresql postgresql-common gnupg curl
', 'Добавляем репозиторий и ставим пакет расширения под вашу версию Postgres:', '
curl -fsSL https://packagecloud.io/timescale/timescaledb/gpgkey \\\n  | sudo gpg --dearmor -o /usr/share/keyrings/timescale.gpg\necho "deb [signed-by=/usr/share/keyrings/timescale.gpg] https://packagecloud.io/timescale/timescaledb/debian/ $(lsb_release -cs) main" \\\n  | sudo tee /etc/apt/sources.list.d/timescaledb.list\nsudo apt update && sudo apt install -y timescaledb-2-postgresql-16
', 'Утилита timescaledb-tune сама пропишет оптимальные параметры в postgresql.conf под ресурсы сервера:', '
sudo timescaledb-tune --quiet --yes\nsudo systemctl restart postgresql
']

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

['Подключаем расширение к нужной базе и создаём обычную таблицу, а затем превращаем её в гипертаблицу одной функцией.', "
sudo -u postgres psql -d metrics -c 'CREATE EXTENSION IF NOT EXISTS timescaledb;'
", "
CREATE TABLE readings (\n  time        TIMESTAMPTZ NOT NULL,\n  sensor_id   INT,\n  temperature DOUBLE PRECISION,\n  humidity    DOUBLE PRECISION\n);\nSELECT create_hypertable('readings', 'time');
", 'Вставка данных ничем не отличается от обычного INSERT, а запросы по времени автоматически используют партиционирование по чанкам:', "
SELECT time_bucket('1 hour', time) AS hour, avg(temperature)\nFROM readings\nWHERE time > now() - interval '1 day'\nGROUP BY hour ORDER BY hour;
"]

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

['Старые данные редко нужны в исходном виде — их выгодно сжать. Включаем компрессию и задаём политику, которая сжимает чанки старше семи дней автоматически.', "
ALTER TABLE readings SET (\n  timescaledb.compress,\n  timescaledb.compress_segmentby = 'sensor_id'\n);\nSELECT 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\nWITH (timescaledb.continuous) AS\nSELECT time_bucket('1 hour', time) AS bucket, sensor_id,\n       avg(temperature) AS avg_temp\nFROM readings GROUP BY bucket, sensor_id;\n\nSELECT add_continuous_aggregate_policy('readings_hourly',\n  start_offset => INTERVAL '3 hours',\n  end_offset => INTERVAL '1 hour',\n  schedule_interval => INTERVAL '1 hour');
", '
  • Забыли create_hypertable — данные лягут в обычную таблицу без ускорения.
  • Не настроили компрессию — диск быстро заполнится на потоке метрик.
  • compress_segmentby выбран неверно — компрессия и запросы работают хуже; берите колонку, по которой чаще фильтруете.
']

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

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для TimescaleDB

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

Чем TimescaleDB лучше обычного PostgreSQL для метрик?

Гипертаблицы автоматически партиционируют данные по времени, а компрессия и continuous aggregates ускоряют запросы и экономят диск. На больших временных рядах разница в скорости кратная.

Можно ли использовать привычный SQL?

Да, полностью. TimescaleDB — расширение PostgreSQL, поэтому работают JOIN, оконные функции, индексы и весь остальной синтаксис без изменений.

Сколько места экономит компрессия?

На типичных временных рядах сжатие достигает 10–20 раз в зависимости от структуры данных и выбора столбца segmentby. Старые чанки сжимаются политикой автоматически.

Читайте также