TimescaleDB: hypertable вместо ручного партиционирования по датам

Декларативное партиционирование в PostgreSQL требует, чтобы кто-то заранее создавал секции под будущие даты — вручную или крон-скриптом, иначе вставка в несуществующий диапазон просто упадёт с ошибкой. TimescaleDB — это расширение поверх PostgreSQL, которое берёт ровно эту рутину на себя: таблица превращается в hypertable, а партиции («чанки») создаются автоматически по мере поступления данных.

CREATE TABLE metrics (
    time        TIMESTAMPTZ NOT NULL,
    host        TEXT NOT NULL,
    cpu_percent DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time');

Снаружи metrics выглядит как обычная таблица — тот же INSERT, тот же SELECT — но физически строки лежат по чанкам фиксированного временного интервала (по умолчанию 7 дней, меняется через chunk_time_interval в create_hypertable или глобально через timescaledb.default_chunk_time_interval). Новый чанк создаётся сам, как только приходит строка с временем за пределами существующих — никакого аналога CREATE TABLE ... PARTITION OF под будущий месяц заранее.

Второй инструмент, которого в ванильном PostgreSQL просто нет — continuous aggregate: материализованное представление, которое TimescaleDB дообновляет сам по расписанию, а не ждёт ручного REFRESH MATERIALIZED VIEW:

CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS hour,
       host,
       avg(cpu_percent) AS avg_cpu
FROM metrics
GROUP BY hour, host;

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

Политика обновляет только свежий хвост (start_offset/end_offset задают окно), а не весь агрегат целиком — на таблице с историей в сотни миллионов строк это разница между секундной фоновой задачей и многочасовым пересчётом.

Если нужно просто не потерять возможность быстро дропнуть старые месяцы — хватает обычного PARTITION BY RANGE и DETACH/DROP руками, без лишней зависимости в кластере. TimescaleDB имеет смысл тащить, когда к автоматическому чанкованию добавляется реальная потребность в continuous aggregate — дашборд, которому нужны почасовые средние по миллиардам точек без пересчёта на каждый запрос.

#postgresql #sysadmin #database