Управление жизненным циклом данных в Tantor Postgres 18: практическое руководство по pg_ilm

Управление жизненным циклом данных в Tantor Postgres 18: практическое руководство по pg_ilm

С ростом объема информации базы данных сталкиваются с проблемой: хранить терабайты архивных данных на быстрых SSD экономически нецелесообразно, а ручной перенос таблиц на медленные диски отнимает время у DBA и создает риски. В отечественной СУБД Tantor Postgres 18 на базе PostgreSQL эту задачу решает встроенный инструмент управления жизненным циклом данных (Information Lifecycle Management, ILM) — расширение pg_ilm.

Главная особенность pg_ilm заключается в том, что размещение данных управляется не на основе статических дат создания записей, а исходя из реальной интенсивности обращений к таблицам и секциям за настраиваемый период. При этом расширение спроектировано безопасно: оно собирает статистику и формирует рекомендации, но никогда не выполняет перемещения без явного вызова со стороны администратора.

Архитектурная модель и состояния данных

Работа pg_ilm строится вокруг концепции температурных зон данных. В СУБД выделяются четыре ключевых состояния, представляющие собой комбинацию физического метода доступа к данным (Access Method) и табличного пространства (Tablespace), размещенного на накопителях разного типа:

1. Hot Row (горячие строки) — исходное состояние. Данные хранятся в классическом строчном формате (Heap) на быстрых накопителях (NVMe SSD). Это зона активной OLTP-нагрузки.
2. Warm Row (теплые строки) — данные остаются в строчном формате, но перемещаются на более дешевые и медленные диски. Режим подходит для данных, которые перестали активно обновляться, но участвуют в транзакционных запросах.
3. Warm Columnar (теплые колонки) — данные переводятся в эффективный колоночный формат, оптимизированный для аналитического чтения и сжатия, но остаются на быстрых дисках для построения отчетов.
4. Cold Columnar (холодные колонки) — финальная стадия. Максимально сжатые колоночные данные, физически размещенные на дешевых накопителях (HDD).

Жизненный цикл описывается в виде направленного графа переходов. Важным правилом pg_ilm является последовательность: расширение не допускает «прыжков» через состояния (из hot_row сразу в cold_columnar), если промежуточные этапы не могут быть пройдены. Если целевое холодное состояние требует смены формата доступа, система сначала порекомендует сжатие в колоночный формат, а затем — физическое перемещение в холодную зону.

Для обычных несекционированных таблиц правила применяются только целиком. Охладить или сжать отдельные строки внутри одной плоской таблицы невозможно. Поэтому для эффективного управления жизненным циклом данных критически важно использовать секционирование таблиц, где правила ILM применяются к каждой секции независимо.

Пошаговое руководство по настройке pg_ilm

Рассмотрим сценарий перевода таблицы test.sensors размером более 5 ГБ (содержащей 100 миллионов строк) из горячего состояния в холодное колоночное хранилище cold_ts при отсутствии активности.

Шаг 1. Подготовка каталогов и табличных пространств

Необходимо создать каталог на холодном диске, назначить права доступа и объявить табличное пространство в СУБД. Все операции в ОС выполняются от имени суперпользователя и пользователя postgres:

# Подготовка каталога под root
mkdir -p /path/to/tablespace/cold_ts
chown -R postgres:postgres /path/to/tablespace/cold_ts
chmod 700 /path/to/tablespace/cold_ts

После этого зарегистрируйте его в СУБД:

CREATE TABLESPACE cold_ts LOCATION '/path/to/tablespace/cold_ts';

Шаг 2. Настройка параметров ядра СУБД в postgresql.conf

Откройте postgresql.conf и добавьте необходимые библиотеки в параметр shared_preload_libraries. Это требует перезапуска службы для инициализации фоновых процессов (Background Workers):

shared_preload_libraries = 'pg_archive_bgw, pg_cron, pg_partman_bgw'

Шаг 3. Создание схем и расширений

После перезапуска подключитесь к целевой базе данных и выполните SQL-команды для развертывания инфраструктуры:

CREATE SCHEMA IF NOT EXISTS partman;
CREATE SCHEMA IF NOT EXISTS archive;

CREATE EXTENSION IF NOT EXISTS pg_cron CASCADE;
CREATE EXTENSION IF NOT EXISTS pg_partman SCHEMA partman;
CREATE EXTENSION IF NOT EXISTS pg_archive SCHEMA archive CASCADE;
CREATE EXTENSION IF NOT EXISTS pg_ilm CASCADE;

Шаг 4. Объявление правил жизненного цикла данных

Создайте правило архивации для таблицы test.sensors. Зададим тестовые лимиты: перевод в «теплое» состояние при отсутствии активности более 20 минут и последующий перевод в «холодное» состояние через 10 минут после этого:

SELECT ilm.archive_rule_upsert(
    p_relation        := 'test.sensors'::regclass,
    p_idle_threshold  := '20 minutes'::interval,
    p_cold_after      := '10 minutes'::interval,
    p_target_tablespace := 'cold_ts'
);

Шаг 5. Сбор статистики и анализ рекомендаций

Сбор информации происходит в фоне, однако администратор может принудительно зафиксировать снимок текущего состояния активности:

SELECT ilm.collect_stats_snapshot();

Чтобы проанализировать запланированные действия без их физического запуска, выполните диагностический запрос:

SELECT * FROM ilm.recommend_archive_actions(
    p_relation   := 'test.sensors'::regclass,
    p_check_time := now(),
    p_force      := FALSE
);

Если критерии неактивности еще не выполнены, поле status примет значение skip с указанием причины. Как только критерии будут выполнены, статус изменится на recommend, а в поле prepared_call_sql появится SQL-запрос для миграции.

Шаг 6. Применение изменений

Перед физическим переносом данных выполните сухой запуск (dry run) для проверки готовности:

SELECT * FROM ilm.execute_recommendations(p_target_table := 'test.sensors'::regclass, p_dry_run := TRUE);

Если проверка прошла успешно, запустите физический процесс перемещения и колоночного сжатия данных:

SELECT * FROM ilm.execute_recommendations(p_target_table := 'test.sensors'::regclass, p_dry_run := FALSE);

Анализ рисков и эксплуатационные ограничения

Внедрение механизмов ILM в промышленных базах данных требует глубокого понимания внутренних процессов СУБД и осторожности. Перенос таблиц объемом в сотни гигабайт — это тяжелая дисковая и процессорная операция.

Основные риски и способы их минимизации:

• Блокировки и доступность приложений. Физическое перемещение данных и изменение метода доступа требуют монопольного доступа к объектам на определенных этапах. Это может привести к задержкам выполнения транзакций. Проводить операции рекомендуется строго в запланированные технологические окна.
• Изменение профиля производительности запросов. Колоночный формат хранения дает прирост производительности при выполнении аналитических запросов и агрегаций, а также обеспечивает высокую степень сжатия на диске. Однако для транзакционной нагрузки (OLTP) с частыми точечными чтениями и обновлениями полей колоночный формат противопоказан, так как он приведет к падению скорости операций.
• Анализ рисков перед миграцией. Каждая сформированная рекомендация в pg_ilm содержит важные диагностические риск-поля: blocking_constraints, query_compatibility_risk, access_risk и restore_risk. Администратор обязан проанализировать эти поля перед подтверждением выполнения. Наличие уникальных индексов может накладывать ограничения на смену метода доступа.

Если дисковое разделение в вашей инфраструктуре отсутствует, возможности pg_ilm все равно можно использовать для оптимизации расходов: в этом случае настраиваются правила только для сжатия таблиц без их перемещения. И наоборот: если нельзя менять метод доступа, можно настроить правила исключительно для переноса данных на более дешевые накопители с сохранением строчного формата хранения.

Чек-лист для внедрения pg_ilm в производственной среде

Для успешного запуска системы выполните следующие шаги:

1. Проведите аудит данных. Определите таблицы-кандидаты, объем которых превышает десятки гигабайт, и выясните характер запросов к ним (OLTP или OLAP).
2. Настройте секционирование. Переведите таблицы на секционированную структуру с помощью pg_partman. Это позволит перемещать старые интервалы данных покомпонентно, не блокируя всю таблицу.
3. Создайте температурные зоны. Подготовьте дисковые накопители разного класса, настройте права доступа для пользователя postgres на уровне ОС и зарегистрируйте новые tablespaces.
4. Протестируйте конфигурацию на staging-среде. Разверните копию базы данных, настройте тестовые правила с короткими интервалами и убедитесь, что процессы переноса и сжатия проходят без ошибок.
5. Настройте регулярный сбор статистики. Добавьте вызов функции ilm.collect_stats_snapshot() в планировщик pg_cron. Частота запуска должна соответствовать интенсивности вашей нагрузки.