Сховища 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, розумна реплікація і кеш-ієрархія дозволяють тримати «гаряче» швидким, «тепле» - доступним, а «холодне» - дешевим і безпечним.