Жизненный цикл данных: от горячих к холодным и в удаление

MAATRIX

Через два года после запуска проекта NVMe-диск на боевой базе заполнен на 80%, и половина этого места — заказы трёхлетней давности, логи за прошлый год и версии файлов, которые никто не открывал с момента загрузки. Апгрейд диска стоит денег каждый месяц, а данные, которые его забивают, реально нужны быстро в лучшем случае раз в квартал. Проблема не в объёме — она в том, что для каждой категории данных никто явно не решил, сколько они должны жить на быстром хранилище и что с ними делать дальше. Разберём, как продумать это осознанно, а не полагаться на то, что диск когда-нибудь купят побольше.

Горячие, тёплые и холодные — что на самом деле означают эти слова

Деление данных по температуре — это не про возраст файла, а про частоту и характер обращения к нему прямо сейчас.

Горячие данные — то, что читается и пишется постоянно, в интерактивном режиме: текущие заказы в интернет-магазине, активные сессии пользователей, последние сутки логов, на которые смотрит мониторинг. Здесь важна задержка в единицы миллисекунд, потому что каждое лишнее ожидание конечный пользователь или процесс чувствует напрямую. Место для горячих данных — NVMe или SSD, часто с запасом IOPS, иногда — в оперативной памяти (кэш, буферный пул СУБД).

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

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

Дальше в цепочке — удаление или окончательная архивация: данные, у которых истёк смысл (или срок хранения по закону), либо стираются безвозвратно, либо переносятся в форму, которая переживёт следующие годы без активного сопровождения.

Важно: у одной сущности (например, у заказа в интернет-магазине) части могут иметь разную температуру одновременно. Сам заказ и его статус — горячие первые недели. Скан чека к нему — тёплый через месяц. Полная история изменений заказа для юридического архива — холодная почти сразу после закрытия.

Почему без явной политики данные просто копятся на дорогом хранилище

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

• Удалить страшнее, чем хранить. Если непонятно, точно ли данные больше не нужны, разработчик выберет безопасный вариант — оставить как есть. Явного правила «через N месяцев можно переносить» не существует, решение откладывается бесконечно.
• Перенос — отдельная задача, а не часть основной разработки. Написать функцию, которая сохраняет данные, — часть спринта. Написать job, который через год их архивирует, — «потом, когда будет время». Потом не наступает.
• Рост диска кажется дешевле, чем работа над архивацией. Расширить том или заказать сервер с диском побольше — вопрос одной заявки. Спроектировать перенос данных между уровнями с гарантией, что ничего не потеряется, — требует времени, которое проще потратить на фичи.
• Никто явно не считал стоимость. Сравнение «сколько стоит гигабайт на NVMe против гигабайта в архивном хранилище» никто не делал, переплата остаётся невидимой в общем счёте за инфраструктуру.

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

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

Как определить паттерн использования для конкретной категории данных

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

1. Кто и как часто реально обращается к этим данным сейчас? Не "как часто теоретически могут обратиться", а по факту: смотрите логи доступа к таблице, статистику обращений к файлам (atime, если он не отключён монтированием с noatime), метрики СУБД по количеству чтений конкретных партиций. Часто выясняется, что "важные исторические данные" не открывались полгода.

2. Насколько критична задержка при обращении? Если к архиву обращаются раз в квартал и человек готов подождать 10-30 секунд на первую загрузку из холодного хранилища — это принципиально другие требования, чем для данных, от которых зависит отклик работающего сервиса.

3. Есть ли юридические или регуляторные сроки хранения? Для части данных (бухгалтерская первичка, кадровые документы, некоторые логи по 152-ФЗ) минимальный срок хранения задаётся не архитектурой, а законом — и в это время его нельзя удалить, только можно и нужно переносить между уровнями по стоимости. Подробнее о том, как это применимо к учётным данным, разобрано в статье про сроки хранения бухгалтерских данных.

4. Что произойдёт, если данные будут недоступны 5 минут? Час? Сутки? Это RTO для конкретной категории: если час простоя архива не критичен, объектное хранилище архивного класса с задержкой первого доступа в минуты вполне подходит.

5. Что происходит по истечении срока полезности — архивация или удаление? Не все холодные данные нужно хранить вечно. Для части категорий правильный финал — не "холодное хранилище навсегда", а удаление по истечении срока: старые логи отладки, черновики, временные выгрузки. Держать их бессрочно "на всякий случай" — тот же паттерн накопления, просто на более дешёвом хранилище.

Итог шага — таблица по каждой категории данных: тип, владелец, паттерн обращения по времени, требования к RTO, юридический минимальный срок (если есть), финальное действие.

Технические механизмы переноса между уровнями

Когда политика определена, нужен конкретный технический механизм, который её реализует. Вот основные, от простых к сложным.

Партиционирование по времени в СУБД. Для PostgreSQL — секции по дате (PARTITION BY RANGE (created_at)), где старые партиции лежат в отдельном табличном пространстве на медленном диске:

CREATE TABLE orders (
    id bigint,
    created_at timestamptz,
    payload jsonb
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2026_08 PARTITION OF orders
    FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');

-- старую партицию переносим на медленный tablespace
ALTER TABLE orders_2023_01 SET TABLESPACE cold_storage;

Для автоматизации создания и переноса партиций по расписанию в PostgreSQL удобен pg_partman — он же умеет партиции старше заданного возраста детачить и, если нужно, выгружать во внешний файл перед удалением из основной базы.

TTL на уровне СУБД. MongoDB поддерживает TTL-индексы, которые сами удаляют документы по истечении срока:

db.sessions.createIndex(
  { "createdAt": 1 },
  { expireAfterSeconds: 2592000 } // 30 дней
)

Redis — то же самое через EXPIRE/SET ... EX для данных, которые в принципе не должны жить дольше определённого времени (сессии, кэш, временные токены).

Lifecycle-политики объектных хранилищ. Для S3-совместимого хранилища (в том числе self-hosted, о котором можно почитать в статье про S3-совместимое хранилище у себя) правило переноса между классами хранения задаётся один раз и дальше работает само:

{
  "Rules": [{
    "ID": "tiering-orders-attachments",
    "Status": "Enabled",
    "Filter": { "Prefix": "orders/attachments/" },
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 180, "StorageClass": "GLACIER" }
    ],
    "Expiration": { "Days": 2555 }
  }]
}

Применяется через aws s3api put-bucket-lifecycle-configuration или аналог в CLI вашего провайдера. После 30 дней объект переезжает в более дешёвый класс, после 180 — в архивный, через семь лет удаляется совсем, если таков регламент.

Файловая иерархия на своих серверах. Если объектное хранилище не используется, тот же принцип реализуется вручную — cron-задачей, которая переносит файлы старше N дней с быстрого раздела на медленный:

#!/bin/bash
# перенос вложений старше 90 дней с NVMe на HDD-архив
find /data/hot/attachments -type f -mtime +90 -print0 | \
  while IFS= read -r -d '' f; do
    rel="${f#/data/hot/attachments/}"
    mkdir -p "/data/cold/attachments/$(dirname "$rel")"
    mv "$f" "/data/cold/attachments/$rel"
    ln -s "/data/cold/attachments/$rel" "$f"
  done

Символическая ссылка оставляет приложению прежний путь, если оно не готово знать про два хранилища. Ограничение — она не спасает, если приложение делает stat и ожидает конкретный размер файла именно с быстрого диска; тогда нужен слой абстракции в приложении, который сам решает, с какого хранилища отдавать файл.

Отдельно стоит упомянуть ILM в Elasticsearch/OpenSearch — встроенный механизм hot-warm-cold-delete для индексов логов, который переносит и удаляет индексы по политике внутри самого кластера, без внешних скриптов.

Примеры политик для типичных категорий данных компании

Ниже — ориентировочная таблица политики жизненного цикла для типичных категорий данных среднего проекта. Конкретные сроки и пороги подставляйте свои — это шаблон для рассуждения, а не универсальный стандарт.

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

Автоматизация и контроль соблюдения политики

Политика на бумаге (или в этой статье) не работает сама — без автоматизации она превращается в задачу "не забыть", а такие задачи со временем перестают выполняться.

Перенос должен быть частью инфраструктуры, а не разовым скриптом на память. Для БД — партиционирование с автоматическим созданием и переносом партиций (pg_partman, в MySQL — события EVENT SCHEDULER). Для файлов — cron-задача с логированием каждого переноса (что, куда, сколько байт), чтобы при разборе инцидента было видно, где искать файл. Для объектных хранилищ — lifecycle-правила самого хранилища, не зависящие от того, жив ли сервер, который их когда-то настроил.

Мониторинг должен проверять соблюдение политики, а не только факт переноса: растёт ли объём "горячего" хранилища быстрее, чем должен при работающей архивации (признак, что job перестал запускаться); не превышает ли возраст самой старой записи на горячем уровне заданный порог; успешно ли завершаются задачи переноса (алерт при ошибке, а не молчаливый пропуск).

Удаление — отдельный процесс, не встроенный в перенос. Автоматическое удаление данных с истёкшим сроком стоит отделять от переноса между уровнями политикой подтверждения: флаг "готово к удалению" выставляется автоматически, а фактическое удаление — по отдельному более редкому расписанию или после ручного подтверждения для категорий с юридическими последствиями.

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

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