Gorące/ciepłe/zimne skarbce

1) Dlaczego podzielić dane przez Hot/Warm/Cold

• Optymalizacja kosztów: Szybka i droga warstwa tylko dla gorącego zestawu roboczego.
• Przestrzegaj SLO: p95/przepustowość w Internecie, dłuższe terminy dla historii.
• Uprość skalowanie: poziomo zbudować tanie warstwy bez przegrzania „przód”.
• Ograniczanie ryzyka: różne domeny awarii/replikacji, niezależne zasady ochrony.

• Gorące - najnowsze, częste czytanie/pisanie, minimalna opóźnienie.
• Ciepło - zmiany rzadziej, dużo czytania w przedziałach czasowych.
• Zimno - archiwum, tanie przechowywanie, wysoki TTFB, powolne odzyskiwanie.

2) Profile i SLO według poziomu

Gorące

Dostęp: milisekundy (p95 ≤ 5-20 ms na KV/indeksach, ≤ 100-300 ms na złożonych zapytaniach).
Operacje: częste upsert/append, indeksowanie, OLTP/stream-ingest.
Media: NVMe/SSD, pamięć, szybka sieć.
Replikacja: zwiększona (np. RF = 3) dla RPO ≤ 0, RTO minut.

Ciepło

Dostęp: dziesiątki do setek milisekund/sekundę.
Operacje: czytanie „okno”, masła, OLAP na świeżej historii (7-90 dni).
Nośniki: SATA SSD/szybka pamięć HDD/obiektu z lokalnym buforem.
Replikacja: umiarkowana (RF = 2), włączona kompresja.

Zimno

Dostęp: sekundy-godziny; częsty dostęp offline, „pobierz i skanuj”.
Operacje: rzadkie odczyty, zgodność z przepisami (retencja na lata).
Media: obiekt/archiwum (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replikacja: Regionalny/międzyregionalny, WORM/Legal Hold.

3) Typowe techniki według warstwy

Hot: PostgreSQL (OLTP, przegrody), MySQL/InnoDB, Redis/Memcated (китартибики, Lokalny dziennik Kafka.
Ciepło: Przechowywanie kolumn ClickHouse, • Zapytanie/Płatek śniegu ostatnie przyjęcia, Elastyczne ciepłe węzły S3 + Presto/Trino z pamięci podręcznej, Wielopoziomowe przechowywanie (Kafka/Pulsar).
Zimno: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, Archiwum HDFS, długoterminowe kopie zapasowe.

4) Polityka cyklu życia (ILM) i automatyzacja

4. 1 Pojęcia

Podział czasu (dzień/tydzień/miesiąc) jest główną dźwignią tłumaczenia między warstwami.
Zasady ILM: przewrócenie (według objętości/wieku), skurcz/połączenie, zamrażanie, usuwanie.
Deduplikacja i kompresja: włączyć na ciepło/zimno, unikając wąskich gardeł procesora na gorąco.

4. 2 Przykłady

Elastyczne search ILM (gorące → ciepłe → zimno → usunąć)

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 Cykl życia (Standard → Rzadki → Lodowiec → Wygasa)

json
{
"Rules": [{
"ID": "logs-lifecycle",
"Filter": { "Prefix": "logs/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 7, "StorageClass": "STANDARD_IA" },
{ "Days": 30, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 365 }
}]
}

Kafka wielopoziomowe przechowywanie (szkic)

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

Partycje PostgreSQL według daty

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) Modelowanie kosztów i wydajności

5. 1 Prosty model TCO

„TCO = CapEx/OpEx media + network (egress) + CPU for compression/scans + management + DR/replication”.

5. 2 Saldo opóźnień i ceny

Gorący zestaw 5-20% danych daje 80-95% zapytań.
Celem jest utrzymanie zestawu roboczego w pamięci podręcznej/podręcznej (CPU/RAM/NVMe), przesunięcie reszty na ciepło/zimno.

5. 3 Metryka

hit_ratio_hot, pct_hot_of_total_bytes, cost_per_TB_month{tier}, scan_cost_per_TB, time_to_first_byte{tier}, promotion_rate (zimne → ciepłe), demotion_rate (gorące → ciepłe/zimne).

6) Partycjonowanie, indeksowanie i buforowanie

Przegrody czasowe + indeksy wtórne dla „świeżych” plasterków.
Złota reguła żądań: najpierw filtr według czasu, a następnie selektywne klucze.
Hierarchiczny pamięć podręczna: in-proc → Redis → krawędź; pin caches do kluczy/agregatów.
Filtry Bloom/pomiń indeksy (ClickHouse, Parquet), aby zmniejszyć odczyty do ciepłego/zimnego.

7) Replikacja, tolerancja błędów i DR

Hot: replikacja synchroniczna (multi-zone), RPO ≤ 0, szybka feilover.
Ciepło: asynchroniczny interzone/replika międzyregionalna; RPO minut.
Zimno: międzyregionalny z WORM (Napisz po przeczytaniu wielu), Legalne wstrzymanie zgodności.
DR-plany: rekrutacja „zimnych” archiwów (godzin), okresowe ćwiczenia przeciwpożarowe.

8) Bezpieczeństwo i zgodność

PII/PCI: szyfrowanie w spoczynku (KMS), kluczowe zasady na każdym etapie, maskowanie podczas przesuwania w dół.
Zatrzymywanie i usuwanie: automatyczne terminy na zimno, możliwe do udowodnienia usunięcie (raporty o usunięciu).
Jurysdykcje: składowanie w regionie (tylko UE, tylko RU, region BY itd.), geodizolacja wiader.

9) Wzory użytkowania

9. 1 Dzienniki i telemetria

Hot: Ostatni 24-72 h w Elasticsearch/ClickHouse na NVMe.
Ciepło: 30-180 dni na SSD/HDD + Parkiet w S3.
Zimno:> 180 dni w lodowcu; żądania za pośrednictwem Trino/Presto „na żądanie”.

9. 2 Transakcje/zlecenia

Hot: Baza danych OLTP (PostgreSQL/MySQL) z krótką historią.
Ciepło: denormalizowane migawki dla BI.
Zimno: archiwum prawne, eksport do magazynu obiektów.

9. 3 ML-ficestore

Hot: funkcje online w Redis/low-latency DB.
Ciepło: funkcje offline w kolumnie/obiekcie.
Zimno: zbiory danych źródłowych, w wersji (Delta/Iceberg/Hudi).

10) Interakcje z klastrami i kubernetami

Klasa znaków według poziomu: "złoty-nvme" (gorący), "srebrny-ssd' (ciepły)," obiekt z brązu "(zimny).
Planowanie węzłów basenowych (tains/labels) do warsztatów gorących/ciepłych/zimnych.
Pamięć podręczna sidecar (na przykład lokalny pamięć podręczna SSD) przed żądaniami obiektu.

Przykład PVC

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

11) Obserwowalność

Deski rozdzielcze: rozkład bajtów/żądań według poziomu, opóźnienia na poziomie, odciążenie do ciepłego/zimnego, koszt/miesiąc.
Alerty: spadek współczynnika trafienia na gorąco, wzrost tempa promocji (czy jest wystarczająco gorąca objętość), wzrost TTFB o ciepło, powolne odzyskiwanie zimna (naruszenie SLO).

12) Anty-wzory

„Wszystko na gorąco”: nadmierne koszty, przegrzanie IO.
„Głębokie zimno bez indeksów”: tanie do przechowywania, drogie do odczytu; Nie ma szybkich ścieżek.
"No ILM': manualne transfery, ludzkie błędy.
„Jednolita polityka replikacji” dla wszystkich poziomów: nadpłaty i nierówne RPO.
Wymieszaj zapytania prod/archiwum w jednej puli obliczeń - interferencja.
„Nieznane wyjście” z zimnych chmur: niespodzianki w rachunku.

13) Lista kontrolna wdrażania

• Klasyfikacja zbiorów danych: SLA, częstotliwość dostępu, wymagania dotyczące przechowywania.
• Wybierz media i silniki na warstwę (NVMe/SSD/HDD/Object/Archive).
• Czas projektowania/partycje kluczy, indeksy i formaty (Parkiet/ORC/Delta).
• Zdefiniuj zasady ILM (przewrócenie/przejście/wygaśnięcie) i zautomatyzuj.
• Włącz kompresję/kodowanie (ZSTD/LZ4; w zimnym - silniejszym).
• Zdefiniuj procedury replikacji/RPO/RTO i DR.
• Skonfiguruj hierarchię pamięci podręcznej i pin dla gorących kruszyw.
• Mierniki kosztów/opóźnień i wpisy na poziomie.
• Polityka bezpieczeństwa (KMS, retencja prawna, izolacja geograficzna).
• Regularne przeglądy progów transferu (sezonowość, wzrost).

14) FAQ

P: Jak zdefiniować granice między gorącym i ciepłym?
Odp.: Zgodnie z rzeczywistą dystrybucją zapytań: „hot working set” = top 5-20% kluczy/stron, dostarczając 80-95% żądań. Wszystko, co zawodzi, to ciepły kandydat.

P: Czy mogę czytać bezpośrednio z zimna?
Odp.: Tak, ale planuj SLA poniżej minut/godzin i koszt wyjścia; częściej opłacalne jest repatriowanie fragmentu do ciepłego (postoju) przed analizą.

P: Co wybrać dla analityki 30-180 dni?
Odp.: Formaty kolumn (Parkiet/ORC) na obiekcie + silnik zapytania (Trino/Presto/ClickHouse) z pamięcią podręczną; indeksy/skip-data, aby zapisać IO.

P: Jak uniknąć „burz rozgrzewających się” podczas przerabiania z zimna?
Odp.: Użyj prefetchu/przygotować-zadania, ograniczyć żądania, czas shardy, request-coalescing i pin bufory na ciepłe.

15) Kwoty całkowite

Architektura Hot/Warm/Cold to koszt pasujący do profilu dostępu oraz automatyczne zarządzanie cyklem życia. Wyczyść SLO warstwą, partycjonowanie i ILM, rozsądna replikacja i hierarchia pamięci podręcznej utrzymują „gorące” szybkie „, ciepłe” przystępne i „zimne” tanie i bezpieczne.