Armazéns Hot/Warm/Cold

1) Por que dividir dados em Hot/Warm/Cold

• Otimizar custo: camada rápida e cara apenas para o conjunto de trabalho «quente».
• Cumpra SLO: p95/throughput para online, deadline mais longos para história.
• Simplifique a escala: aumente as camadas baratas horizontalmente sem superaquecer a frente.
• Reduzir riscos: domínios de falha/replicação diferentes, políticas de proteção independentes.

• Hot é o mais recente, leitura/gravação frequente, latência mínima.
• Warm - É menos alterado, com muitas leituras por intervalo de tempo.
• Cold - arquivo, armazenamento barato, alta TTFB, recuperação lenta.

2) Perfis e SLO por nível

Hot

Acesso: milissegundos (p95 ≤ 5-20 ms em KV/índice; ≤ 100-300 ms em solicitações complexas).
Operações: upsert/append frequentes, indexação, OLTP/estrim-ingest.
Mídia: NVMe/SSD, memória, rede rápida.
Replicação: alta (RF = 3, por exemplo) para RPO≈0, RTO minuto.

Warm

Acesso: Dezenas a centenas de milissegundos/segundo.
Operações: leitura «janela», batch, OLAP história recente (7-90 dias).
Mídia: SATA SSD/HDD rápido/armazenamento de objetos com armazenamento local.
Replicação: moderado (RF = 2), compressão ativada.

Cold

Acesso: segundos-relógio; Acesso offline frequente, «retrieve-and-scan».
Operações: leitura rara, conformidade com regulação (retensas de voo).
Mídia: objeto/arquivo (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replicação regional/interregional, WORM/Legal Hold.

3) Tecnologias típicas por camadas

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.
Warm: ClickHouse de armazenamento invertebrado, BigQuery/Snowflake partituras recentes, Elasticsearch warm-nodes, S3 + Presto/Trino com dinheiro, armazenamento Tiered (Kafka/Pulsar).
Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, arquivo HDFF, bacapes de longo prazo.

4) Políticas de ciclo de vida (ILM) e automação

4. 1 Conceitos

A partilha por hora (dia/semana/mês) é a principal alavanca de tradução entre camadas.
Regras ILM: rollover (em volume/idade), shrink/merge, freeze, delete.
Deduplicação e compressão: incluir em warm/cold, evitando estreitos CPU em hot.

4. 2 Exemplos

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 Armazenamento (esboço)

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 da partição por 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) Modelagem de custo e desempenho

5. 1 Modelo TCO simples

'TCO = CapEx/OpEx mídia + rede (egress) + CPU para compressão/scan + controle + DR./replicação'.

5. 2 Equilíbrio de latência e preços

Um conjunto quente de 5 a 20% dos dados dá 80 a 95% das solicitações.
O objetivo é manter o set de trabalho em Hot/dinheiro (CPU/RAM/NVMe), deslocar o resto para 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) Particionamento, indexação e cachê

Partições de tempo + secundary-índice para cortes «frescos».
A regra de ouro da consulta é o filtro de horário primeiro, depois as chaves seletivas.
O dinheiro é hierárquico: in-proc → Redis → edge; capas pin para chaves quentes/equipamentos.
Filtros bloom/índice skip (ClickHouse, Parquet) para reduzir a leitura em warm/cold.

7) Replicação, resistência a falhas e DR

Hot: replicação sincronizada (multissona), RPO≈0, feelover rápido.
Warm: réplica asíncrona interzonal/interregional; RPO minutos.
Cold: interregional com WORM (Write Once Read Many), Legal Hold para complacência.
Planos de run: livros de recuperação de arquivos «frios» (relógios), fire-drills periódicos.

8) Segurança e conformidade

PII/PCI: Criptografia em paz (KMS), políticas-chave em cada estágio, camuflagem na transferência para baixo.
Retensna e remoção: prazo automático para cold, apagagem comprovada (erase reports).
Jurisdição: armazenamento na região (EU-only, RU-only, BY-region etc.), geo-isolamento bucket 'ov.

9) Pattern de uso

9. 1 Logos e telemetria

Hot: as últimas 24-72 horas no Elasticsearch/ClickHouse na NVMe.
Warm: 30-180 dias para SSD/HDD + Parquet em S3.
Cold:> 180 dias no Glacier; solicitações via Trino/Pró «sob demanda».

9. 2 Transações/mandados

Hot: OLTP BD (PostgreSQL/MySQL) com uma história curta.
Warm: Snapshots denormalizados para BI.
Cold: Arquivo jurídico, exportação para armazenamento de objetos.

9. 3 ML-fichestore

Hot: Fici online em Redis/low-latency DB.
Warm: fies off-line em colinvertebrado/objeto.
Cold: Datasets originais, versioned (Delta/Iceberg/Hudi).

10) Interação com clusters e Kubernetes

Selecione «gold-nvme» (hot), «silver-ssd' (warm),» bronze-object' (cold).
Planeje nódulos-pula (taants/labels) sob hot/warm/cold worcloades.
Caciques Sidecar (por exemplo, local SSD cachê) antes de solicitar no armazenamento de objetos.

Exemplo de PVC

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

11) Observabilidade

Dashboard: distribuição de bytes/consultas por tier, latency per tier, offload em warm/cold, custo/mês.
Alerts: redução do hit-ratio hot, crescimento da promoção-rate (se o volume quente é suficiente), aumento do TTFB em warm, recuperação lenta do cold (SLO breach).

12) Anti-pattern

«Tudo em hot», valor excedente, superaquecimento de IO.
«Frio profundo sem índices»: é barato guardar, é caro ler; não há caminhos de corte rápido.
«Não ao ILM», transferências manuais, erros humanos.
Política de replicação unificada para todos os níveis: sobrepreço e RPO desigual.
Mesclar consultas de arquivo/prod em um pool de computação: influência mútua.
«Egress não contabilizado» em nuvens cold: surpresas na conta.

13) Folha de cheque de implementação

• Classifique os conjuntos de dados: SLA, taxa de acesso, requisitos de armazenamento.
• Selecione mídias e motores por camada (NVMe/SSD/HDD/Object/Archive).
• Projete partituras (tempo/chave), índices e formatos (Parquet/ORC/Delta).
• Defina as regras ILM (rollover/transição/expire) e automatize.
• Ative a compressão/codificação (ZSTD/LZ4; em cold - mais forte).
• Defina a replicação/RPO/RTO e os procedimentos DR.
• Configure a hierarquia em dinheiro e pin para as unidades quentes.
• Métricas de custo/latência e alertas por tier.
• Políticas de segurança (KMS, retalhos legais, geo-isolamento).
• Reveja regularmente os limites de tradução (seasonality, crescimento).

14) FAQ

Q: Como definir os limites entre hot e warm?
A: Na distribuição real de solicitações: «hot set» = 5% a 20% superiores de chaves/partituras que fornecem 80% a 95% das solicitações. Tudo o que não chega é candidato a warm.

Q: Pode ler diretamente a partir de cold?
A: Sim, mas planeje o SLA para minutos/relógio e valor egress; é mais vantajoso repatriar uma fatia em warm (estaging) antes de analisar.

O que escolher para os analistas de 30 a 180 dias?
A: Formatos invertebrados (Parquet/ORC) em objeto + motor de solicitação (Trino/Presto/ClickHouse) com dinheiro; índice/skip-data para economizar o IO.

Como evitar «tempestades de aquecimento» quando se transbordam de cold?
A: Use o prefetch/predare-jobs, consultas com limites, dê um tempo, aplique o request-coalescing e pin-cachês no warm.

15) Resultado

A arquitetura Hot/Warm/Cold é a adequação do custo ao perfil de acesso, além de gerenciamento automático do ciclo de vida. O SLO claro por camadas, partitização e ILM, replicação inteligente e hierarquia em dinheiro permitem manter o «quente» rápido, «quente» disponível e «frio» barato e seguro.