Almacenamiento Hot/Warm/Cold

1) Por qué dividir los datos en Hot/Warm/Cold

• Optimizar el costo: una capa rápida y costosa sólo para el kit de trabajo «caliente».
• Cumplir con SLO: p95/throughput para el en línea, los deduplines más largos para la historia.
• Simplifique el escalado: aumente horizontalmente las capas baratas sin sobrecalentar el «frente».
• Reducir riesgos: diferentes dominios de falla/replicación, políticas de protección independientes.

• Hot - la lectura/escritura más fresca, frecuente, latencia mínima.
• Warm - Es menos probable que cambie, mucha lectura según los rangos de tiempo.
• Cold - archivo, almacenamiento barato, TTFB alto, recuperación lenta.

2) Perfiles y SLO por niveles

Hot

Acceso: milisegundos (p95 ≤ 5-20 ms en KV/índices, ≤ 100-300 ms en solicitudes complejas).
Operaciones: upsert/append frecuente, indexación, OLTP/streaming ingest.
Medios: NVMe/SSD, memoria, red rápida.
Replicación: aumentada (por ejemplo, RF = 3) para RPO≈0, RTO minutos.

Warm

Acceso: decenas a cientos de milisegundos/segundos.
Operaciones: lectura por «ventana», batches, OLAP por historia fresca (7-90 días).
Medios: SATA SSD/almacenamiento de objetos HDD/rápido con caché local.
Replicación: moderada (RF = 2), compresión incluida.

Cold

Acceso: segundos-reloj; acceso fuera de línea frecuente, «retrieve-and-scan».
Operaciones: lecturas raras, conformidad con la regulación (retransmisión por años).
Medios: objeto/archivo (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replicación: regional/interregional, WORM/Legal Hold.

3) Tecnologías estándar por capas

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.

Warm: ClickHouse columna almacenamiento, BigQuery/Snowflake lotes recientes, Elasticsearch warm-nodes, S3 + Presto/Trino con caché, Tiered storage (Kafka/Pulsar)

Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, archivos HDFS, backups a largo plazo.

4) Políticas de ciclo de vida (ILM) y automatización

4. 1 Conceptos

El lote por tiempo (día/semana/mes) es la principal palanca de traducción entre capas.
Reglas ILM: rollover (por volumen/edad), shrink/merge, freeze, delete.
Deduplicación y compresión: incluye en warm/cold, evitando cuellos de botella de CPU en hot.

4. 2 Ejemplos

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

PostgreSQL lotes por fecha

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) Simulación de costo y rendimiento

5. 1 Modelo TCO simple

'TCO = CapEx/OpEx medios + red (egress) + CPU por compresión/escáner + control + DR/replicación'.

5. 2 Equilibrio de latencia y precio

Un conjunto caliente ≈ 5-20% de los datos da 80-95% de las consultas.
El objetivo es mantener el conjunto de trabajo en Hot/caché (CPU/RAM/NVMe), el resto se desplaza a Warm/Cold.

5. 3 Métricas

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) Partición, indexación y almacenamiento en caché

Lotes de tiempo + índices secundarios para cortes «frescos».
Regla de oro de las consultas: filtro de tiempo primero, luego claves selectivas.
La caché es jerárquica: in-proc → Redis → edge; caché pin para teclas/agregados calientes.
Filtros de sangre/índices de movimiento (ClickHouse, Parquet) para reducir las lecturas en warm/cold.

7) Replicación, tolerancia a fallas y DR

Hot: replicación síncrona (multitisona), RPO≈0, fake-over rápido.
Warm: réplica interzonal/interregional asíncrona; RPO minutos.
Cold: interregional con WORM (Write Once Read Many), Legal Hold para el cumplimiento.
Planes de DR: libros run para restaurar archivos «fríos» (relojes), fire-drills periódicos.

8) Seguridad y cumplimiento

PII/PCI: cifrado en reposo (KMS), políticas clave en cada etapa, enmascaramiento cuando se mueve hacia abajo.
Retiro y eliminación: plazos automáticos en cold, borrado probado (erase reports).
Jurisdicciones: almacenamiento en la región (EU-only, RU-only, BY-region, etc.), geo-aislamiento bucket's.

9) Patrones de uso

9. 1 Registros y telemetría

Hot: últimos 24-72 h en Elasticsearch/ClickHouse en NVMe.
Warm: 30-180 días en SSD/HDD + Parquet en S3.
Cold:> 180 días en Glacier; solicitudes a través de Trino/Presto «bajo demanda».

9. 2 Transacciones/Órdenes

Hot: OLTP BD (PostgreSQL/MySQL) con una breve historia.
Warm: snapshots desnormalizados para BI.
Cold: archivo legal, exportación a almacenamiento de objetos.

9. 3 ML-fichestore

Hot: fichas online en Redis/low-latency DB.
Warm: fichas offline en columna/objeto.
Cold: datacets originales, versionados (Delta/Iceberg/Hudi).

10) Interacción con clústeres y Kubernetes

StorageClass marca por tier: 'gold-nvme' (hot), 'silver-ssd' (warm),' bronze-object '(cold).
Planifique los nodos de pools (taints/labels) bajo hot/warm/cold worcload.
Caché sidecar (por ejemplo, caché SSD local) antes de las solicitudes al almacén de objetos.

Ejemplo de PVC

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

11) Observabilidad

Dashboards: distribución de bytes/consultas por tier, latency per tier, offload por warm/cold, costo/mes.
Alertas: reducción de hit-ratio hot, aumento de la tasa de promoción (si el volumen caliente es suficiente), aumento de TTFB por warm, recuperación lenta de cold (SLO breach).

12) Anti-patrones

«Todo en caliente»: costo excesivo, IO sobrecalentamiento.
«Frío profundo sin índices»: barato de almacenar, caro de leer; no hay rutas de corte rápido.
«No ILM»: transferencias manuales, errores humanos.
«Política de replicación única» para todos los niveles: sobrepago y RPO desiguales.
«Mezcla de solicitudes prod/archiving» en un solo grupo de cálculos: influencia mutua.
El «egreso no contabilizado» de las nubes frías: sorpresas en la cuenta.

13) Lista de verificación de implementación

• Clasifique los conjuntos de datos: SLA, frecuencia de acceso, requisitos de almacenamiento.
• Seleccione los medios y motores por capa (NVMe/SSD/HDD/Object/Archive).
• Diseñar lotes (tiempo/clave), índices y formatos (Parquet/ORC/Delta).
• Definir reglas ILM (rollover/transition/expire) y automatizar.
• Habilite la compresión/codificación (ZSTD/LZ4; en cold - más fuerte).
• Defina los procedimientos de replicación/RPO/RTO y DR.
• Configure la jerarquía de caché y el pin para los agregados en caliente.
• Métricas de valor/latencia y alertas por tier.
• Políticas de seguridad (KMS, retenciones legales, geo-aislamiento).
• Revisar regularmente los umbrales de traducción (seasonalidad, crecimiento).

14) FAQ

P: ¿Cómo definir los límites entre hot y warm?
R: Según las distribuciones reales de las solicitudes: «hot workset» = top 5-20% de las claves/lotes que proporcionan 80-95% de las consultas. Todo lo que no llega es un candidato a la guerra.

P: ¿Se puede leer directamente del cold?
R: Sí, pero planifique el SLA bajo minutos/horas y el costo del egress; es más probable que sea más rentable repatriar el fragmento a warm (staging) antes del análisis.

P: ¿Qué elegir para los análisis 30-180 días?
A: Formatos de columna (Parquet/ORC) en objeto + motor de consulta (Trino/Presto/ClickHouse) con caché; índices/skip-data para ahorrar IO.

P: ¿Cómo evitar las «tormentas de calor» al reelegirse de cold?
R: Utilice prefetch/prepare-jobs, consultas con límites, chardee en el tiempo, aplique request-coalescing y cachés pin en warm.

15) Resultados

La arquitectura Hot/Warm/Cold es la conformidad del costo con el perfil de acceso más la administración automática del ciclo de vida. Los SLO claros por capas, el lote y la ILM, la replicación razonable y la jerarquía de caché permiten mantener «caliente» rápido, «cálido» asequible y «frío» barato y seguro.