Seifuri calde/calde/reci

1) De ce împărțiți datele la Hot/Warm/Rece

• Optimizați costul: Strat rapid și scump numai pentru setul de lucru la cald.
• Respectați SLO: p95/debit pentru termene mai lungi pentru istorie.
• Simplificați scalarea: construiți pe orizontală straturi ieftine fără supraîncălzirea „frontală”.
• Atenuarea riscurilor: diferite domenii de eșec/replicare, politici de protecție independente.

• Hot - cea mai recentă, frecventă lectură/scriere, latență minimă.
• Cald - se schimbă mai rar, o mulțime de lectură în intervale de timp.
• Rece - arhivă, depozitare ieftină, TTFB ridicat, recuperare lentă.

2) Profiluri și SLO-uri în funcție de nivel

Fierbinte

Acces: milisecunde (p95 ≤ 5-20 ms pe KV/indici; ≤ 100-300 ms pe interogări complexe).
Operații: upsert/append frecvent, indexare, OLTP/stream-ingest.
Media: NVMe/SSD, memorie, rețea rapidă.
Replicare: creştere (de ex. RF = 3) pentru RPO≈0, minute RTO.

Cald

Acces: Zeci până la sute de milisecunde/secundă.
Operațiuni: citirea „ferestrei”, butches, OLAP pe istorie proaspătă (7-90 zile).
Media: SATA SSD/stocare rapidă HDD/obiect cu memorie cache locală.
Replicare: moderată (RF = 2), compresie activată.

Rece

Acces: secunde-ore; acces offline frecvent, „preluare-și-scanare”.
Operațiuni: lecturi rare, respectarea regulamentului (reținerea cu ani).
Media: object/archive (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replicare: Regional/Interregional, WORM/Legal Hold.

3) Tehnici tipice pe straturi

Hot: PostgreSQL (OLTP, partiții), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-noduri, ClickHouse горячие партиции, jurnal local Kafka.
Cald: depozitarea coloanelor ClickHouse, petrecerile recente BigQuery/Snowflake, nodurile calde Elasticsearch, S3 + Presto/Trino cu memorie cache, depozitarea pe niveluri (Kafka/Pulsar).
Rece: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, arhivă HDFS, backup pe termen lung.

4) Politicile ciclului de viață (ILM) și automatizare

4. 1 Concepte

Partiționarea timpului (zi/săptămână/lună) este pârghia principală de traducere între straturi.
Reguli ILM: rollover (după volum/vârstă), psihiatru/îmbinare, congela, șterge.
Eliminarea duplicatelor și a compresiei: activați pe cald/rece, evitând blocajele CPU la cald.

4. 2 Exemple

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": {} } }
}
}
}

Ciclul de viață S3 (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 }
}]
}

Depozitare pe niveluri Kafka (schiță)

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

Partiții PostgreSQL după dată

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) Modelarea costurilor și a performanței

5. 1 Model simplu TCO

'TCO = CapEx/OpEx media + rețea (ieșire) + procesor pentru comprimare/scanare + management + DR/replicare'.

5. 2 Balanța de latență și preț

Un set fierbinte ≈ 5-20% din date produce 80-95% din interogări.
Scopul este de a păstra setul de lucru în Hot/cache (CPU/RAM/NVMe), trecerea restul la Warm/Cold.

5. 3 Măsurători

, , , , , .

6) Partiționarea, indexarea și cachingul

Partiții de timp + indici secundari pentru felii „proaspete”.
Regula de aur a cererilor: filtrați mai întâi timpul, apoi tastele selective.
Memorie cache ierarhică: in-prof → Redis → edge; pini cache pentru chei fierbinți/agregate.
Filtre Bloom/sari peste indici (ClickHouse, Parchet) pentru a reduce citirile la cald/rece.

7) Replicare, toleranță la erori și DR

Hot: replicare sincronă (multi-zone), RPO≈0, feilover rapid.
Cald: asincron interzonă/replica interregională; Minute RPO.
Rece: interregional cu WORM (Scrie o dată citit multe), Legal Hold pentru conformitate.
Planuri DR: cărți pentru restaurarea arhivelor „reci” (ore), exerciții periodice de incendiu.

8) Siguranță și conformitate

PII/PCI: criptare în repaus (KMS), politici cheie în fiecare etapă, mascare atunci când se deplasează în jos.
Retenție și îndepărtare: termene limită automate pentru ștergerea la rece, doveditoare (rapoarte de ștergere).
Jurisdicții: depozitarea în regiune (numai în UE, numai în RU, regiunea BY etc.), geo-izolarea găleților.

9) Modele de utilizare

9. 1 Busteni si telemetrie

Hot: Ultimele 24-72 h la Elasticsearch/ClickHouse pe NVMe.
Cald: 30-180 zile pe SSD/HDD + Parchet în S3.
Rece:> 180 zile în Ghețar; cereri prin Trino/Presto „la cerere”.

9. 2 Tranzacții/comenzi

Hot: Baza de date OLTP (PostgreSQL/MySQL) cu un scurt istoric.
Cald: instantanee denormalizate pentru BI.
Rece: arhivă legală, export pentru depozitarea obiectelor.

9. 3 ML-ficestore

Hot: caracteristici online în Redis/latență redusă DB.
Cald: caracteristici offline în coloană/obiect.
Rece: seturi de date sursă, versionate (Delta/Iceberg/Hudi).

10) Interacțiunea cu clusterele și Kubernetes

Mark StorageClass pe niveluri: 'gold-nvme' (fierbinte), 'silver-ssd' (cald), 'bronze-object' (rece).
Planificați nodurile de piscină (cauciucuri/etichete) pentru ateliere calde/calde/reci.
Cache-uri Sidecar (de exemplu, cache SSD local) înainte de cererile de stocare obiect.

Exemplu de PVC

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

11) Observabilitate

Tablouri de bord: distribuția de octeți/cereri pe niveluri, latență pe niveluri, descărcare la cald/rece, cost/lună.
Alerte: o scădere a ratei de lovire fierbinte, o creștere a ratei de promovare (există un volum suficient de fierbinte), o creștere a TTFB cu cald, o recuperare lentă a frigului (încălcarea SLO).

12) Anti-modele

„All in hot”: costuri excesive, supraîncălzire IO.
„Adânc rece fără indici”: ieftin de depozitat, scump de citit; fără căi rapide.
„Nu ILM”: transferuri manuale, erori umane.
„Politică uniformă de replicare” pentru toate nivelurile: plăți excesive și OPR inegale.
Se amestecă interogările prod/arhivă într-un singur bazin de calcul - interferențe.
„Ieșirea neînregistrată” din norii reci: surprize în proiect de lege.

13) Lista de verificare a implementării

• Clasificați seturile de date: SLA, frecvența de acces, cerințele de stocare.
• Selectați suporturi și motoare pe strat (NVMe/SSD/HDD/Object/Archive).
• Timp de proiectare/partiții cheie, indici, și formate (Parchet/ORC/Delta).
• Definiți regulile ILM (rollover/tranziție/expirare) și automatizați.
• Activați compresia/codificarea (ZSTD/LZ4; în frig - mai puternic).
• Definirea procedurilor de replicare/RPO/RTO și DR.
• Configurați ierarhia cache și pin pentru agregate fierbinți.
• Măsurători de cost/latență și alerte de nivel.
• Politici de securitate (KMS, retenție legală, geo-izolare).
• Revizuirea periodică a pragurilor de transfer (sezonalitate, creștere).

14) ÎNTREBĂRI FRECVENTE

Î: Cum definiți limitele dintre cald și cald?
R: În funcție de distribuțiile reale ale cererilor: "set de lucru la cald' = top 5-20% din chei/părți, oferind 80-95% din cereri. Tot ce eșuează este un candidat cald.

Î: Pot citi direct de la rece?
R: Da, dar planul SLA sub minute/ore și costul de ieșire; este mai adesea profitabil să se repatrieze un fragment la cald (punerea în scenă) înainte de analiză.

Î: Ce să alegeți pentru analiză 30-180 zile?
A: Formate de coloane (Parchet/ORC) pe obiect + motor de interogare (Trino/Presto/ClickHouse) cu memorie cache; indexuri/skip-data pentru a salva IO.

Î: Cum să evitați „furtunile de încălzire” atunci când reeșantionați de la frig?
R: Utilizați prefetch/pregătiți-locuri de muncă, cereri limită, timp shardy, cerere-coalescing și cache pin pe cald.

15) Totaluri

Arhitectura Hot/Warm/Cold se potrivește costurilor cu profilul de acces plus gestionarea automată a ciclului de viață. Ștergeți SLO-urile după strat, partiționarea și ILM, replicarea rezonabilă și ierarhia cache păstrează "fierbinte" rapid, "cald' accesibil și" rece "ieftin și sigur.