Stockage Hot/Warm/Cold

1) Pourquoi partager les données en Hot/Warm/Cold

• Optimiser le coût : une couche rapide et coûteuse uniquement pour un ensemble de travail « chaud ».
• Respecter SLO : p95/throughput pour online, plus long deadlines pour l'histoire.
• Simplifiez la mise à l'échelle : agrandissez horizontalement les couches bon marché sans surchauffer le « front ».
• Réduire les risques : différents domaines de défaillance/réplication, stratégies de protection indépendantes.

• Hot est le plus frais, lecture/écriture fréquente, latence minimale.
• Warm - change moins souvent, beaucoup de lecture par plage de temps.
• Cold - archive, stockage bon marché, TTFB élevé, récupération lente.

2) Profils et SLO par niveau

Hot

Accès : millisecondes (p95 ≤ 5-20 ms sur KV/index ; ≤ 100-300 ms sur requêtes complexes).
Opérations : upsert/append fréquents, indexation, OLTP/stream-ingest.
Médias : NVMe/SSD, mémoire, réseau rapide.
Réplication : élevée (par exemple, RF = 3) pour les minutes de RPO≈0, RTO.

Warm

Accès : des dizaines à des centaines de millisecondes/seconde.
Opérations : lecture « fenêtre », batchi, OLAP sur l'histoire fraîche (7-90 jours).
Médias : SATA SSD/HDD rapide/stockage objet avec cache local.
Réplication : modérée (RF = 2), compression incluse.

Cold

Accès : secondes-heures ; accès fréquent hors ligne, « retrieve-and-scan ».
Opérations : lectures rares, conformité à la réglementation (rétention par les étés).
Médias : objet/archive (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Réplication : régionale/interrégionale, WORM/Legal Hold.

3) Technologies types par couches

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.
Warm : ClickHouse colonic storage, BigQuery/Snowflake récents lots, Elasticsearch warm-nodes, S3 + Presto/Trino avec cache, Tiered storage (Kafka/Pulsar).
Cold : S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, archives HDFS, backups à long terme.

4) Politiques de cycle de vie (ILM) et automatisation

4. 1 Concepts

Le lot horaire (jour/semaine/mois) est le principal levier de traduction entre les couches.
Règles ILM : rollover (en volume/âge), shrink/merge, freeze, delete.
Déduplication et compression : incluez sur warm/cold en évitant les goulots d'étranglement CPU sur hot.

4. 2 Exemples

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 (croquis)

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

Lots PostgreSQL par date

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) Modélisation du coût et de la performance

5. 1 Simple modèle TCO

« TCO = CapEx/OpEx médias + réseau (egress) + CPU pour compression/scan + contrôle + DR/réplication ».

5. 2 Équilibre de latence et prix

L'ensemble chaud ≈ 5-20 % des données donne 80-95 % des demandes.
L'objectif est de maintenir le set de travail dans Hot/Cache (CPU/RAM/NVMe), le reste étant déplacé vers Warm/Cold.

5. 3 Métriques

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) Lot, indexation et mise en cache

Lots temporels + index secondaires pour les tranches « fraîches ».
Règle d'or des requêtes : premier filtre temporel, puis clés sélectives.
Cache hiérarchique : in-proc → Redis → edge ; pin-cache pour clés/unités chaudes.
Bloom filtres/skip index (ClickHouse, Parquet) pour réduire les lectures sur warm/cold.

7) Réplication, tolérance aux pannes et DR

Hot : réplication synchrone (multishone), RPO≈0, faussaire rapide.
Warm : réplique interzonale/interrégionale asynchrone ; RPO minute.
Cold : interrégionale avec WORM (Write Once Read Many), Legal Hold pour Complaens.
DR-plans : run-livres pour restaurer les archives « froides » (heures), fire-drills périodiques.

8) Sécurité et conformité

PII/PCI : cryptage au repos (KMS), politiques clés à chaque étape, masquage lors de la migration vers le bas.
Rétention et suppression : délais automatiques par cold, effacement avéré (erase reports).
Juridictions : stockage dans la région (EU-only, RU-only, BY-region, etc.), géo-isolement bucket 'ov.

9) Modèles d'utilisation

9. 1 Logs et télémétrie

Hot : les dernières 24-72 h à Elasticsearch/ClickHouse sur NVMe.
Warm : 30-180 jours sur SSD/HDD + Parquet en S3.
Cold :> 180 jours à Glacier ; demandes via Trino/Presto « à la demande ».

9. 2 Transactions/mandats

Hot : OLTP OBD (PostgreSQL/MySQL) avec un historique court.
Warm : snapshots dénormalisés pour BI.
Cold : archives juridiques, exportation vers le stockage d'objets.

9. 3 ML-fichestore

Hot : fiches en ligne dans Redis/low-latency DB.
Warm : fiches hors ligne en colonne/objet.
Cold : datacets originaux, convertis (Delta/Iceberg/Hudi).

10) Interaction avec les clusters et les Kubernetes

StorageClass marque par tier : 'gold-nvme' (hot), 'silver-ssd' (warm),' bronze-object '(cold).
Planifiez les nœuds de pool (taints/labels) sous hot/warm/cold workloades.
Cache sidecar (par exemple, cache SSD local) avant les requêtes vers le stockage objet.

Exemple de PVC

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

11) Observabilité

Dashboards : répartition des octets/requêtes par tier, latency per tier, offload sur warm/cold, coût/mois.
Alertie : baisse de hit-ratio hot, augmentation du taux de promotion (s'il y a assez de volume chaud), augmentation du TTFB par warm, récupération lente du cold (SLO breach).

12) Anti-modèles

« Tout est dans le chaud » : coût excessif, surchauffe IO.
« Froid profond sans indices » : bon marché à stocker, cher à lire ; Il n'y a aucun moyen de couper rapidement.
« Pas d'ILM » : transferts manuels, erreurs humaines.
Une « politique de réplication unique » pour tous les niveaux : paiements excédentaires et RPO inégaux.
« Mélange de requêtes prod/archivées » dans un seul pool de calcul : influence réciproque.
« Egress non comptabilisé » des nuages cold : surprises dans la facture.

13) Chèque de mise en œuvre

• Classer les ensembles de données : SLA, fréquence d'accès, exigences de stockage.
• Sélectionnez les médias et les moteurs par couche (NVMe/SSD/HDD/Object/Archive).
• Concevoir des lots (temps/clé), des index et des formats (Parquet/ORC/Delta).
• Définissez les règles ILM (rollover/transition/expire) et automatisez.
• Activer la compression/codage (ZSTD/LZ4 ; en cold - plus fort).
• Définir la réplication/RPO/RTO et les procédures DR.
• Configurez la hiérarchie cache et le pin pour les agrégats chauds.
• Métriques de valeur/latence et alerties par tier.
• Politiques de sécurité (KMS, rétentions juridiques, géo-isolement).
• Réexaminer régulièrement les seuils de transfert (seasonality, croissance).

14) FAQ

Q : Comment définir les limites entre hot et warm ?
R : Selon les distributions réelles des demandes : « hot workset » = top 5-20 % des clés/lots fournissant 80-95 % des demandes. Tout ce qui n'arrive pas est un candidat de warm.

Q : Puis-je lire directement à partir du cold ?
R : Oui, mais prévoyez un SLA sous les minutes/heures et le coût de l'egress ; plus souvent, il est plus rentable de rapatrier un fragment dans la warm (staging) avant l'analyse.

Q : Que choisir pour les analyses de 30-180 jours ?
A : Formats de colonne (Parquet/ORC) sur le moteur de requête objet + (Trino/Presto/ClickHouse) avec cache ; index/skip-data pour économiser IO.

Q : Comment éviter les « tempêtes d'échauffement » en cas de rééchelonnement du cold ?
R : Utilisez prefetch/prepare-jobs, requêtes avec limites, chardonnez-vous dans le temps, appliquez request-coalescing et pin-cache sur warm.

15) Résultats

L'architecture Hot/Warm/Cold correspond au coût du profil d'accès et à la gestion automatique du cycle de vie. Des SLO clairs par couches, des lots et des ILM, une réplication intelligente et une hiérarchie cache vous permettent de rester « chaud » rapide, « chaud » abordable et « froid » bon marché et sûr.