Hot/Warm/Cold saxlama

1) Niyə məlumatları Hot/Warm/Cold-a bölmək lazımdır

• Qiyməti optimallaşdırın: sürətli və bahalı qat yalnız «isti» iş dəsti üçün.
• SLO-ya riayət edin: p95/throughput online, tarix üçün daha uzun müddət.
• Ölçməni sadələşdirin: «ön» həddindən artıq istiləşmədən ucuz təbəqələri üfüqi şəkildə artırın.
• Riskləri azaltın: müxtəlif uğursuzluq/replikasiya domenləri, müstəqil müdafiə siyasətləri.

• Hot - ən yeni, tez-tez oxu/yazma, minimal gecikmə.
• Warm - daha az dəyişən, vaxt diapazonunda çox oxu.
• Cold - arxiv, ucuz saxlama, yüksək TTFB, yavaş bərpa.

2) Səviyyələrə görə profillər və SLO

Hot

Giriş: millisaniyələr (KV/indekslərdə p95 ≤ 5-20 ms; mürəkkəb sorğularda ≤ 100-300 ms).
Əməliyyatlar: tez-tez upsert/append, indeksasiya, OLTP/axın-ingest.
Media: NVMe/SSD, yaddaş, sürətli şəbəkə.
Replikasiya: RPO ≈ 0, RTO dəqiqə üçün artırılmış (məsələn, RF = 3).

Warm

Giriş: on-yüz millisaniyə/saniyə.
Əməliyyatlar: oxu «pəncərə», batchi, OLAP təzə tarix (7-90 gün).
Media: SATA SSD/sürətli HDD/yerli cache ilə obyekt saxlama.
Replikasiya: orta (RF = 2), sıxılma daxildir.

Cold

Giriş: saniyə-saat; tez-tez offline giriş, «retrieve-and-scan».
Əməliyyatlar: nadir oxunmalar, tənzimləyiciyə uyğunluq (illərlə retenshn).
Daşıyıcılar: obyekt/arxiv (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replikasiya: Regional/Regionlararası, WORM/Legal Hold.

3) Laylar üzrə standart texnologiyalar

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.
Warm: ClickHouse sütun saxlama, BigQuery/Snowflake son parties, Elasticsearch warm-nodes, S3 + Presto/Trino cache ilə, Tiered storage (Kafka/Pulsar).
Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, HDFS arxivi, uzunmüddətli arxivlər.

4) Həyat dövrü siyasəti (ILM) və avtomatlaşdırma

4. 1 Konsepsiyalar

Zaman partizanlaşması (gün/həftə/ay) - təbəqələr arasında əsas tərcümə qolu.
ILM qaydaları: rollover (həcminə/yaşına görə), shrink/merge, freeze, delete.
Deuplikasiya və sıxılma: hot CPU-dar yerlərdən qaçaraq warm/cold daxil edin.

4. 2 Nümunələr

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

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 partiya tarixi

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) dəyər və performans modelləşdirilməsi

5. 1 Sadə TCO modeli

'TCO = CapEx/OpEx daşıyıcıları + şəbəkə (egress) + CPU sıxılma/skaner + nəzarət + DR/replikasiya'.

5. 2 Gecikmə və qiymət balansı

5-20% isti ≈ dəsti 80-95% sorğu verir.
Məqsəd iş setini Hot/cache-də (CPU/RAM/NVMe) saxlamaq, qalanını Warm/Cold-a köçürməkdir.

5. 3 Metrika

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) Partiyalaşdırma, indeksləşdirmə və caching

Partisiyalar + «təzə» kəsiklər üçün secondary-indekslər.
Qızıl sorğu qaydası: ilk dəfə filtr, sonra seçici açarlar.
İerarxik cache: in-proc → Redis → edge; isti açarları/aqreqatları üçün pin-caches.
Bloom-filterlər/skip indeksləri (ClickHouse, Parquet) warm/cold oxunuşlarını azaltmaq üçün.

7) Replikasiya, arıza müqaviməti və DR

Hot: sinxron replikasiya (multizon), RPO ≈ 0, sürətli feylover.
Warm: Asinxron zonalararası/regionlararası replika; RPO dəqiqə.
Cold: WORM (Write Once Read Many) ilə regionlararası, uyğunluq üçün Legal Hold.
DR-planları: «soyuq» arxivlərin bərpası üçün run-kitablar (saat), dövri fire-drills.

8) Təhlükəsizlik və uyğunluq

PII/PCI: rahat şifrələmə (KMS), hər mərhələdə əsas siyasətlər, aşağı köçürüldükdə maskalanma.
Retenshn və silmə: avtomatik vaxt cold, sübut silinir (erase reports).
Yurisdiksiyaları: regionda saxlama (EU-only, RU-only, BY-region və s.), geo-izolyasiya bucket's.

9) Istifadə nümunələri

9. 1 Log və telemetriya

Hot: NVMe-də Elasticsearch/ClickHouse-da son 24-72 saat.
Warm: SSD/HDD + S3 Parquet 30-180 gün.
Cold:> 180 gün Glacier; Trino/Presto vasitəsilə sorğular «tələb olunur».

9. 2 Əməliyyatlar/Sifarişlər

Hot: OLTP DB (PostgreSQL/MySQL) qısa tarixi ilə.
Warm: BI üçün denormallaşdırılmış snapshots.
Cold: hüquqi arxiv, obyekt anbarına ixrac.

9. 3 ML-fichestore

Hot: Redis/low-latency DB online ficks.
Warm: sütun/obyekt oflayn fiçalar.
Cold: ilkin datasets, versioned (Delta/Iceberg/Hudi).

10) Klaster və Kubernetes ilə qarşılıqlı əlaqə

StorageClass tier-də qeyd edin: 'gold-nvme' (hot), 'silver-ssd' (warm), 'bronze-object' (cold).
Hot/warm/cold workloads altında hovuz qovşaqlarını (taints/labels) planlaşdırın.
Sidecar cache (məsələn, local SSD cache) obyektin anbarına sorğu verməzdən əvvəl.

PVC nümunəsi

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

11) Müşahidə

Daşbordlar: baytların/sorğuların tier, latency per tier, offload warm/cold, qiymət/ay üzrə paylanması.
Alertlər: hit-ratio hot azalması, promotion-rate artımı (isti həcm var), TTFB artımı warm, yavaş bərpası cold (SLO breach).

12) Anti-nümunələr

«All in hot»: həddindən artıq qiymət, həddindən artıq istilik IO.
«İndeks olmadan dərin soyuq»: ucuz saxlamaq, oxumaq üçün bahalı; sürətli kəsmə yolları yoxdur.
«No ILM»: əl köçürmələri, insan səhvləri.
Bütün səviyyələr üçün «vahid replikasiya siyasəti»: artıq ödəniş və qeyri-bərabər RPO.
Bir hesablama hovuzunda «prod/arxiv sorğularının qarışdırılması»: qarşılıqlı təsir.
cold-buludlardan «nəzərə alınmayan egress»: hesabda sürprizlər.

13) Giriş çek siyahısı

• Məlumat dəstlərini təsnif edin: SLA, giriş tezliyi, saxlama tələbləri.
• Bir qat üçün media və mühərrikləri seçin (NVMe/SSD/HDD/Object/Archive).
• Partisionları (vaxt/açar), indeksləri və formatları (Parquet/ORC/Delta) dizayn edin.
• ILM qaydalarını (rollover/transition/expire) təyin edin və avtomatlaşdırın.
• Sıxılma/kodlaşdırma daxil edin (ZSTD/LZ4; cold - daha güclü).
• Replikasiya/RPO/RTO və DR prosedurlarını təyin edin.
• Cache hiyerarşi və isti aqreqatlar üçün pin konfiqurasiya.
• Qiymət/gecikmə metrikləri və tier ilə alertlər.
• Təhlükəsizlik siyasəti (KMS, hüquqi retenshns, geo-izolyasiya).
• Mütəmadi olaraq transfer həddini nəzərdən keçirin (seasonality, boy).

14) FAQ

Q: Hot və warm arasında sərhədləri necə müəyyən etmək olar?
A: Real sorğu paylanması üçün: «isti iş seti» = 80-95% sorğu təmin üst 5-20% açarları/partiyalar. Düşməyən hər şey warm namizədidir.

S: Birbaşa cold-dan oxuya bilərəmmi?
A: Bəli, lakin dəqiqə/saat və egress dəyəri altında SLA planlaşdırın; analiz etməzdən əvvəl parçanı warm (staging) -ə qaytarmaq daha sərfəlidir.

Q: 30-180 gün analitik üçün nə seçmək lazımdır?
A: Cache ilə obyektdə sütun formatları (Parquet/ORC) + sorğu mühərriki (Trino/Presto/ClickHouse); IO qənaət üçün indekslər/skip-data.

Q: cold-dən yenidən seçilərkən «istilik fırtınalarından» necə qaçmaq olar?
A: prefetch/prepare-jobs istifadə edin, limitlər ilə sorğular, vaxt ayırın, warm-də request-coalescing və pin-cachs tətbiq edin.

15) Nəticələr

Hot/Warm/Cold arxitekturası giriş profilinə və avtomatik həyat dövrünün idarə olunmasına uyğun gəlir. Laylar üzrə aydın SLO, partizan və ILM, ağlabatan replikasiya və cache hiyerarxiyası «isti» sürətli, «isti» - əlçatan və «soyuq» - ucuz və təhlükəsiz saxlamağa imkan verir.