Хранилища Hot/Warm/Cold

1) Зачем делить данные на Hot/Warm/Cold

• Оптимизировать стоимость: быстрый и дорогой слой только для «горячего» рабочего набора.
• Соблюдать SLO: p95/throughput для онлайна, более длинные дедлайны для истории.
• Упростить масштабирование: горизонтально наращивать дешевые слои без перегрева «фронта».
• Снизить риски: разные домены отказа/репликации, независимые политики защиты.

• Hot — самые свежие, частые чтение/запись, минимальная латентность.
• Warm — реже изменяется, много чтения по диапазонам времени.
• Cold — архив, дешевое хранение, высокий TTFB, медленное восстановление.

2) Профили и SLO по уровням

Hot

Доступ: миллисекунды (p95 ≤ 5–20 мс на KV/индексах; ≤ 100–300 мс на сложных запросах).
Операции: частые upsert/append, индексация, OLTP/стрим-ингест.
Носители: NVMe/SSD, память, быстрая сеть.
Репликация: повышенная (например, RF=3) для RPO≈0, RTO минуты.

Warm

Доступ: десятки–сотни миллисекунд/секунды.
Операции: чтение «окном», батчи, OLAP по свежей истории (7–90 дней).
Носители: SATA SSD / быстрые HDD / объектное хранилище с локальным кэшем.
Репликация: умеренная (RF=2), компрессия включена.

Cold

Доступ: секунды–часы; частый offline-доступ, «retrieve-and-scan».
Операции: редкие чтения, соответствие регуляторике (ретеншн летами).
Носители: объектное/архивное (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Репликация: региональная/межрегиональная, WORM/Legal Hold.

3) Типовые технологии по слоям

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.
Warm: ClickHouse колоночное хранение, BigQuery/Snowflake недавние партиции, Elasticsearch warm-nodes, S3+Presto/Trino с кэшем, Tiered storage (Kafka/Pulsar).
Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, HDFS архива, долгосрочные бэкапы.

4) Политики жизненного цикла (ILM) и автоматизация

4.1 Концепции

Партиционирование по времени (день/неделя/месяц) — основной рычаг перевода между слоями.
ILM-правила: rollover (по объему/возрасту), shrink/merge, freeze, delete.
Дедупликация и компрессия: включать на warm/cold, избегая CPU-узких мест на hot.

4.2 Примеры

Elasticsearch ILM (hot→warm→cold→delete)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "allocate": { "require": { "box_type": "warm" } }, "forcemerge": { "max_num_segments": 1 } } },
"cold": { "min_age": "30d", "actions": { "allocate": { "require": { "box_type": "cold" } }, "freeze": {} } },
"delete":{ "min_age": "365d", "actions": { "delete": {} } }
}
}
}

S3 Lifecycle (Standard→Infrequent→Glacier→Expire)

json
{
"Rules": [{
"ID": "logs-lifecycle",
"Filter": { "Prefix": "logs/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 7, "StorageClass": "STANDARD_IA" },
{ "Days": 30, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 365 }
}]
}

Kafka Tiered Storage (эскиз)

properties log. segment. bytes=1073741824 log. retention. ms=259200000 tiered. storage. enable=true remote. log. storage. system=s3 remote. log. storage. bucket=topic-archive

PostgreSQL партиции по дате

sql
CREATE TABLE events (
id bigserial, at timestamptz NOT NULL, payload jsonb
) PARTITION BY RANGE (at);

CREATE TABLE events_2025_10 PARTITION OF events
FOR VALUES FROM ('2025-10-01') TO ('2025-11-01')
TABLESPACE ts_hot; -- further ALTER TABLE... SET TABLESPACE ts_warm по ILM

5) Моделирование стоимости и производительности

5.1 Простая модель TCO

`TCO = CapEx/OpEx носителей + сеть (egress) + CPU на компрессию/сканы + управление + DR/репликация`.

5.2 Баланс латентности и цены

Горячий набор ≈ 5–20% данных дает 80–95% запросов.
Цель — удержать рабочий сет в Hot/кэше (CPU/RAM/NVMe), остальное сместить в Warm/Cold.

5.3 Метрики

hit_ratio_hot, pct_hot_of_total_bytes, cost_per_TB_month{tier}, scan_cost_per_TB, time_to_first_byte{tier}, promotion_rate (cold→warm), demotion_rate (hot→warm/cold).

6) Партиционирование, индексация и кэширование

Партиции по времени + secondary-индексы для «свежих» срезов.
Золотое правило запросов: фильтр по времени первым, затем селективные ключи.
Кэш иерархический: in-proc → Redis → edge; pin-кэши для горячих ключей/агрегатов.
Bloom-фильтры/skip-индексы (ClickHouse, Parquet) для снижения чтений на warm/cold.

7) Репликация, отказоустойчивость и DR

Hot: синхронная репликация (мультизона), RPO≈0, быстрый фейловер.
Warm: асинхронная межзонная/межрегиональная реплика; RPO минуты.
Cold: межрегиональная с WORM (Write Once Read Many), Legal Hold для комплаенса.
DR-планы: run-книги на восстановление «холодных» архивов (часы), периодические fire-drills.

8) Безопасность и соответствие

PII/PCI: шифрование в покое (KMS), ключевые политики на каждой ступени, маскирование при переносе вниз.
Ретеншн и удаление: автоматические сроки на cold, доказуемое стирание (erase reports).
Юрисдикции: хранение в регионе (EU-only, RU-only, BY-region и т. п.), гео-изоляция bucket’ов.

9) Паттерны использования

9.1 Логи и телеметрия

Hot: последние 24–72 ч в Elasticsearch/ClickHouse на NVMe.
Warm: 30–180 дней на SSD/HDD + Parquet в S3.
Cold: >180 дней в Glacier; запросы через Trino/Presto «по требованию».

9.2 Транзакции/ордера

Hot: OLTP БД (PostgreSQL/MySQL) с короткой историей.
Warm: денормализованные снапшоты для BI.
Cold: юридический архив, экспорт в объектное хранилище.

9.3 ML-фичestore

Hot: онлайн-фичи в Redis/low-latency DB.
Warm: оффлайн-фичи в колоночном/объектном.
Cold: исходные датасеты, versioned (Delta/Iceberg/Hudi).

10) Взаимодействие с кластерами и Kubernetes

StorageClass помечайте по tier: `gold-nvme` (hot), `silver-ssd` (warm), `bronze-object` (cold).
Планируйте узлы-пулы (taints/labels) под hot/warm/cold ворклоады.
Sidecar-кэши (например, local SSD cache) перед запросами в объектное хранилище.

Пример PVC

yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: { name: db-hot }
spec:
storageClassName: gold-nvme accessModes: [ ReadWriteOnce ]
resources: { requests: { storage: 500Gi } }

11) Наблюдаемость

Дашборды: распределение байтов/запросов по tier, latency per tier, offload на warm/cold, стоимость/месяц.
Алерты: снижение hit-ratio hot, рост promotion-rate (хватает ли горячего объема), увеличение TTFB на warm, медленное восстановление cold (SLO breach).

12) Анти-паттерны

«Все в hot»: излишняя стоимость, перегрев IO.
«Глубокий холод без индексов»: дешево хранить, дорого читать; нет путей быстрых срезов.
«Нет ILM»: ручные переносы, человеческие ошибки.
«Единая репликационная политика» для всех уровней: переплата и неравномерные RPO.
«Смешивание prod/архивных запросов» в одном пуле вычислений: взаимное влияние.
«Неучтенный egress» из cold-облаков: сюрпризы в счете.

13) Чек-лист внедрения

• Классифицируйте наборы данных: SLA, частота доступа, требования хранения.
• Выберите носители и движки на слой (NVMe/SSD/HDD/Object/Archive).
• Спроектируйте партиции (время/ключ), индексы и форматы (Parquet/ORC/Delta).
• Определите ILM-правила (rollover/transition/expire) и автоматизируйте.
• Включите компрессию/кодирование (ZSTD/LZ4; в cold — сильнее).
• Определите репликацию/RPO/RTO и DR-процедуры.
• Настройте кэш-иерархию и pin для горячих агрегатов.
• Метрики стоимости/латентности и алерты по tier.
• Политики безопасности (KMS, юридические ретеншны, гео-изолирование).
• Регулярно пересматривайте пороги переводов (seasonality, рост).

14) FAQ

Q: Как определить границы между hot и warm?
A: По реальным распределениям запросов: «горячий рабочий сет» = верхние 5–20% ключей/партиций, обеспечивающие 80–95% запросов. Все, что не попадает — кандидат на warm.

Q: Можно ли читать напрямую из cold?
A: Да, но планируйте SLA под минуты/часы и стоимость egress; чаще выгоднее репатриировать фрагмент в warm (staging) перед анализом.

Q: Что выбрать для аналитики 30–180 дней?
A: Колоночные форматы (Parquet/ORC) на объектном + движок запросов (Trino/Presto/ClickHouse) с кэшем; индексы/skip-data для экономии IO.

Q: Как избежать «штормов прогрева» при перевыборке из cold?
A: Используйте prefetch/prepare-jobs, запросы с лимитами, шардируйте по времени, применяйте request-coalescing и pin-кэши на warm.

15) Итоги

Архитектура Hot/Warm/Cold — это соответствие стоимости профилю доступа плюс автоматическое управление жизненным циклом. Четкие SLO по слоям, партиционирование и ILM, разумная репликация и кэш-иерархия позволяют держать «горячее» быстрым, «теплое» — доступным, а «холодное» — дешевым и безопасным.