Archivi Hot/Warm/Cold

1) Perché dividere i dati in Hot/Warm/Cold

• Ottimizzare il costo: livello veloce e costoso solo per il set di lavoro caldo.
• Mantieni SLO: p95/throughput per la linea, deadline più lunghe per la storia.
• Scalabilità più semplice: scalare orizzontalmente gli strati economici senza surriscaldare il fronte.
• Riduzione dei rischi: diversi domini di guasto/replica, regole di protezione indipendenti.

• Hot è il più recente, frequente lettura/scrittura, minimo latitanza.
• Warm - Cambia meno spesso, con molte letture per intervalli di tempo.
• Archivio Cold, stoccaggio economico, TTFB alto, recupero lento.

2) Profili e SLO per livello

Hot

Accesso: millisecondi (p95 5-20 ms su KV/indice; 100-300 ms su richieste complesse).
Operazioni: frequenti upsert/append, indicizzazione, OLTP/stram-ingest.
Supporti NVME/SSD, memoria, rete rapida.
Replica: aumentata (ad esempio RF = 3) per il RPO≈0, RTO minuto.

Warm

Accesso: decine, centinaia di millisecondi/secondi.
Operazioni di lettura «finestra», batch, OLAP di storia recente (7-90 giorni).
Supporti: SATA SSD/HDD veloci/archivio oggetti con cache locale.
Replica moderata (RF = 2), compressione attivata.

Cold

Accesso: secondi-orari; frequente accesso offline, «retrieve-and-scan».
Operazioni: letture rare, regolazione (retensing).
Supporti: oggetto/archivio (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replica regionale/interregionale, WORM/Legale Hold.

3) Tecnologie standard per livello

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.
Warm: deposito di invertebrati, recenti partenze, Elasticsearch warm-nodes, S3 + Preto/Trino con cache, Tiered storage (Kafka/Pulsar).
Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, Archivio HDFS, Bacap a lungo termine.

4) Regole per il ciclo di vita (ILM) e automazione

4. 1 Concetti

La partizione in base al tempo (giorno/settimana/mese) è la principale leva di traduzione tra i livelli.
Regole ILM: rollover (volume/età), shrink/merge, freeze, delete.
Deduplicazione e compressione: includere su warm/cold, evitando i colli di bottiglia CPU su hot.

4. 2 Esempi

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

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 partitella per data

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) Modellazione dei costi e delle prestazioni

5. 1 Modello TCO semplice

«TCO = supporto + rete (egress) + CPU per compressione/scan + controllo + DR/replica».

5. 2 Equilibrio di latitanza e prezzo

Il gruppo caldo 5-20% dei dati fornisce 80-95% delle richieste.
L'obiettivo è mantenere il set di lavoro in Hot/cache (CPU/RAM/NVMe), spostarlo in Warm/Cold.

5. 3 Metriche

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) Partizionamento, indicizzazione e cache

Partizioni per tempo + indici secondari per i tagli «freschi».
Regola d'oro per le richieste: filtro per la prima ora, quindi chiavi selettive.
Cache gerarchica: in-proc → Redis → edge; pin-cache per chiavi hot/unità.
Filtri bloom/skip (ClickHouse, Parket) per ridurre le letture warm/cold.

7) Replica, disponibilità e DR

Hot replica sincrona (multisone), RPO≈0, feelover rapido.
Replica asincrona interzonale/interregionale RPO minuti.
Cold: interregionale con WORM (Write Once Read Many), Legale Hold per la compilazione.
Piani DR: run book per il ripristino degli archivi «freddi» (orologi), fire-drills periodici.

8) Sicurezza e conformità

PII/PCI: crittografia a riposo (KMS), regole chiave su ogni step, occultamento durante il trasferimento verso il basso.
Rimozione e cancellazione: tempi automatici per cold, cancellazione provata (erase reports).
Giurisdizione: conservazione nella regione (EU-only, RU-only, BY-region, ecc.), geo-isolamento bucket'ov.

9) Pattern d'uso

9. 1 Logi e telemetria

Hot: le ultime 24-72 ore nel Elasticsearch/ClickHouse su NVME.
Warm: 30-180 giorni per SSD/HDD + Parcheggio in S3.
Cold:> 180 giorni in Glacier; richieste Trino/Preto «su richiesta».

9. 2 Transazioni/mandati

Hot: un database OLTP (PostgreSQL/MySQL) con una breve storia.
Snapshot denormalizzati per BI.
Archivio legale, esportazione in archivio oggetti.

9. 3 ML-ficestore

Hot: fici online a Redis/low-latency DB.
Warm: fici off-line in colinvertebrato/oggetto.
Cold: dataset originale, versioned (Delta/Iceberg/Hudi).

10) Interazione con cluster e Kubernets

StorageClass segnare per tier: «gold-nvme» (hot), «silver-ssd» (warm), «bronze-object» (cold).
Pianificare i pool sotto hot/warm/cold worcload.
Cache sidecar (ad esempio, cache SSD locale) prima delle richieste di archiviazione degli oggetti.

Esempio di PVC

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

11) Osservabilità

Dashboard: distribuzione di byte/richieste per tier, latency per tier, offload per warm/cold, costo/mese.
Alert: riduzione dell'hit-ratio hot, crescita della promozione-rate (se il volume caldo è sufficiente), aumento del TTFB sul warm, recupero lento del cold (SLO breach).

12) Anti-pattern

«Tutto in hot», costo eccessivo, surriscaldamento dell'IO.
«Freddo profondo senza indici»: conservare, leggere a basso costo; nessun percorso di taglio rapido.
«No ILM», passaggi manuali, errori umani.
Regole di replica unificate per tutti i livelli: sovrapprezzo e RPO ineguagliabili.
Miscelare le query prod/archiviate in un unico pool di calcolo: impatto reciproco.
«Egress non documentato» dalle nuvole cold - sorprese nel punteggio.

13) Assegno-foglio di implementazione

• Classificare i set di dati: SLA, frequenza di accesso, requisiti di conservazione.
• Selezionare i supporti e i motori sul livello (NVME/SSD/HDD/Object/Archive).
• Progettare partizioni (tempo/chiave), indici e formati (Parket/ORC/Delta).
• Definire le regole ILM (rollover/transizione/expire) e automatizzare.
• Attivare compressione/codifica (ZSTD/LZ4; in cold - più forte).
• Definire la replica/RPO/RTO e le procedure DR.
• Impostare la gerarchia cache e il pin per le unità a caldo.
• Metriche di costo/latitanza e alert per tier.
• Criteri di sicurezza (KMS, restrizioni legali, geo-isolamento).
• Rivedere regolarmente le soglie di traduzione (seasonality, crescita).

14) FAQ

Q: Come definire i limiti tra hot e warm?
A: In base alla distribuzione reale delle richieste, «hot set» = il 5-20% superiore delle chiavi/partiture che forniscono 80-95% delle richieste. Tutto ciò che non arriva è un candidato al warm.

Q: Puoi leggere direttamente da cold?
A: Sì, ma pianificare SLA a minuti/ore e costo egress; il più delle volte è più vantaggioso rimpatriare un frammento in warm (staging) prima dell'analisi.

Q: Cosa scegliere per gli analisti di 30-180 giorni?
A: Formati invertebrati (Parket/ORC) su oggetto + motore di query (Trino/Presto/ClickHouse) con cache; indici/skip-data per risparmiare IO.

Q: Come evitare le «tempeste di riscaldamento» in una selezione di cold?
A: Usa prefetch/predare-jobs, query con limiti, chiedi tempo, applica richiest-coalescing e pin-cache sul warm.

15) Riepilogo

L'architettura Hot/Warm/Cold è la corrispondenza dei costi per il profilo di accesso e la gestione automatica del ciclo di vita. Nitidi SLO per livello, partizionamento e ILM, replica intelligente e cache-gerarchia consentono di mantenere «caldo» veloce, «caldo» accessibile e «freddo» a basso costo e sicuro.