Hot/Warm/Cold Speicher

1) Warum die Daten in Hot/Warm/Cold aufteilen

• Kosten optimieren: Eine schnelle und teure Schicht nur für ein „heißes“ Arbeitsset.
• Beachten Sie SLO: p95/throughput für online, längere Fristen für die Geschichte.
• Vereinfachen Sie die Skalierung: Bauen Sie billige Schichten horizontal auf, ohne die „Front“ zu überhitzen.
• Reduzieren Sie Risiken: verschiedene Fehler-/Replikationsdomänen, unabhängige Schutzrichtlinien.

• Hot - neueste, häufiges Lesen/Schreiben, minimale Latenz.
• Warm - ändert sich seltener, viel Lesen über Zeitbereiche.
• Kalt - Archiv, billige Lagerung, hohe TTFB, langsame Erholung.

2) Profile und SLOs nach Level

Hot

Zugriff: Millisekunden (p95 ≤ 5-20 ms auf KV/Indizes; ≤ 100-300 ms auf komplexe Abfragen).
Operationen: häufige Upsert/Append, Indexierung, OLTP/Stream-Ingest.
Medien: NVMe/SSD, Speicher, schnelles Netzwerk.
Replikation: erhöht (z.B. RF = 3) für RPO≈0, RTO Minuten.

Warm

Zugriff: Dutzende bis Hunderte Millisekunden/Sekunde.
Operationen: Lesen „Fenster“, Batchi, OLAP auf frische Geschichte (7-90 Tage).
Medien: SATA SSD/schnelle Festplatten/Objektspeicher mit lokalem Cache.
Replikation: moderat (RF = 2), Kompression inklusive.

Cold

Zugang: Sekunden-Stunden; häufiger Offline-Zugriff, „retrieve-and-scan“.
Operationen: seltene Lesungen, Einhaltung der Vorschriften (Retention in Jahren).
Medien: Objekt/Archiv (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replikation: regional/überregional, WORM/Legal Hold.

3) Typische Technologien nach Schichten

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.
Warm: ClickHouse-Säulenlagerung, BigQuery/Snowflake jüngste Parties, Elasticsearch warm-nodes, S3 + Presto/Trino mit Cache, Tiered-Lagerung (Kafka/Pulsar).
Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, HDFS-Archiv, langfristige Backups.

4) Lebenszyklusrichtlinien (ILM) und Automatisierung

4. 1 Konzepte

Partitionierung nach Zeit (Tag/Woche/Monat) ist der Haupthebel der Übersetzung zwischen den Schichten.
ILM-Regeln: rollover (nach Volumen/Alter), shrink/merge, freeze, delete.
Deduplizierung und Kompression: Aktivieren Sie warm/kalt, um CPU-Engpässe bei hot zu vermeiden.

4. 2 Beispiele

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

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-Partitionen nach Datum

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) Kosten- und Leistungsmodellierung

5. 1 Einfaches TCO-Modell

„TCO = CapEx/OpEx media + network (egress) + CPU pro compression/scans + control + DR/replication“.

5. 2 Balance von Latenz und Preis

Ein Hot Set ≈ 5-20% der Daten liefert 80-95% der Anfragen.
Ziel ist es, das Arbeitsset im Hot/Cache (CPU/RAM/NVMe) zu halten, den Rest nach Warm/Cold zu verlagern.

5. 3 Metriken

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) Partitionierung, Indexierung und Caching

Parties nach Zeit + Sekundär-Indizes für „frische“ Schnitte.
Die goldene Regel der Abfragen: zuerst nach Zeit filtern, dann selektive Schlüssel.
Hierarchischer Cache: in-proc → Redis → edge Pin-Caches für Hot Keys/Aggregate.
Bloom-Filter/Skip-Indizes (ClickHouse, Parkett) zur Reduzierung der Lesungen auf warm/kalt.

7) Replikation, Fehlertoleranz und DR

Hot: synchrone Replikation (Multizone), RPO≈0, schneller Failover.
Warm: asynchrone zonenübergreifende/interregionale Replikation; RPO Minuten.
Cold: überregional mit WORM (Write Once Read Many), Legal Hold für Compliance.
DR-Pläne: Run-Bücher zur Wiederherstellung von „kalten“ Archiven (Stunden), periodische Fire-Drills.

8) Sicherheit und Compliance

PII/PCI: Ruheverschlüsselung (KMS), Schlüsselrichtlinien auf jeder Stufe, Maskierung bei der Übertragung nach unten.
Retention und Löschung: automatische Fristen auf cold, nachweisbare Löschung (erase reports).
Jurisdiktionen: Lagerung in der Region (EU-only, RU-only, BY-region, etc.), Geo-Isolation von Bucket 's.

9) Nutzungsmuster

9. 1 Protokolle und Telemetrie

Heiß: die letzten 24-72 Stunden in Elasticsearch/ClickHouse auf NVMe.
Warm: 30-180 Tage auf SSD/HDD + Parkett in S3.
Kalt:> 180 Tage in Glacier; Anfragen über Trino/Presto „on demand“.

9. 2 Transaktionen/Aufträge

Hot: OLTP-Datenbank (PostgreSQL/MySQL) mit kurzer Historie.
Warm: denormalisierte Schnappschüsse für BI.
Cold: Rechtsarchiv, Export in Objektspeicher.

9. 3 ML-fichestore

Heiß: Online-Fiches in Redis/low-latency DB.
Warm: Offline-Fiktionen in Kolonne/Objekt.
Cold: ursprüngliche Datasets, versioniert (Delta/Iceberg/Hudi).

10) Interaktion mit Clustern und Kubernetes

StorageClass-Markierung nach Tier: 'gold-nvme' (heiß), 'silver-ssd' (warm),' bronze-object'(kalt).
Planen Sie Knoten-Pools (Taints/Labels) unter hot/warm/cold workloads.
Sidecar-Caches (z.B. lokaler SSD-Cache) vor Abfragen im Objektspeicher.

Beispiel PVC

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

11) Beobachtbarkeit

Dashboards: Verteilung von Bytes/Anfragen nach Tier, Latenz pro Tier, Offload auf warm/kalt, Kosten/Monat.
Alerts: Rückgang der Hit-Ratio heiß, Wachstum der Promotion-Rate (ob das heiße Volumen reicht), TTFB-Anstieg auf warm, langsame Erholung kalt (SLO Breach).

12) Anti-Muster

„All in hot“: Mehrkosten, Überhitzung des IO.
„Tiefe Kälte ohne Indizes“: billig zu lagern, teuer zu lesen; Es gibt keine Wege für schnelle Schnitte.
„No ILM“: manuelle Transfers, menschliche Fehler.
Eine „einheitliche Replikationspolitik“ für alle Ebenen: Überzahlungen und ungleichmäßige RPOs.
„Vermischung von prod/archivierten Abfragen“ in einem Pool von Berechnungen: gegenseitige Beeinflussung.
„Uncovered egress“ aus Cold Clouds: Überraschungen auf der Rechnung.

13) Checkliste Umsetzung

• Klassifizieren Sie Datensätze: SLA, Zugriffsfrequenz, Speicheranforderungen.
• Wählen Sie Medien und Engines pro Ebene (NVMe/SSD/HDD/Object/Archive).
• Entwerfen Sie Parties (Zeit/Schlüssel), Indizes und Formate (Parkett/ORC/Delta).
• Definieren Sie ILM-Regeln (rollover/transition/expire) und automatisieren Sie diese.
• Aktivieren Sie die Kompression/Codierung (ZSTD/LZ4; in der Kälte - stärker).
• Definieren Sie Replikation/RPO/RTO und DR-Verfahren.
• Richten Sie die Cache-Hierarchie und den Pin für Hot Units ein.
• Kosten-/Latenzmetriken und Alerts nach Tier.
• Sicherheitsrichtlinien (KMS, Legal Retenches, Geo-Isolation).
• Überweisungsschwellen regelmäßig überprüfen (Saisonalität, Wachstum).

14) FAQ

F: Wie definiere ich die Grenzen zwischen heiß und warm?
A: Nach realen Anfrageverteilungen: „Hot Work Set“ = Top 5-20% der Schlüssel/Parties, die 80-95% der Anfragen liefern. Alles, was es nicht schafft, ist ein Kandidat für warm.

F: Kann ich direkt aus der Kälte lesen?
A: Ja, aber planen Sie SLA unter Minuten/Stunden und Kosten egress; oft ist es günstiger, das Fragment vor der Analyse in warm (staging) zu repatriieren.

Q: Was wählen Sie für 30-180 Tage Analytik?
A: Säulenformate (Parkett/ORC) auf Objekt + Abfrage-Engine (Trino/Presto/ClickHouse) mit Cache; Indizes/Skip-Daten für IO-Einsparungen.

F: Wie vermeide ich „Aufwärmstürme“, wenn ich aus der Kälte wiedergewählt werde?
A: Verwenden Sie Prefetch/Prepare-Jobs, Anfragen mit Limits, Sharding nach Zeit, wenden Sie Request-Coalescing und Pin-Caches auf warm an.

15) Ergebnisse

Die Hot/Warm/Cold-Architektur ist die Übereinstimmung der Kosten mit dem Zugriffsprofil plus automatischem Lifecycle-Management. Klare SLOs nach Schichten, Partitionierung und ILM, intelligente Replikation und Cache-Hierarchie ermöglichen es Ihnen, „heiß“ schnell, „warm“ erschwinglich und „kalt“ billig und sicher zu halten.