Hot/Warm/Cold saqlash joylari

1) Nima uchun ma’lumotlarni Hot/Warm/Cold ga bo’lish kerak

• Narxni optimallashtirish: tezkor va qimmat qatlam faqat «issiq» ish qabuli uchun.
• SLOga rioya qilish: p95/throughput onlayn, tarix uchun uzoqroq muddatlar.
• Ko’lamni soddalashtirish: «front» ni qizdirmasdan arzon qatlamlarni gorizontal ravishda ko’paytirish.
• Xavflarni kamaytirish: turli rad etish/replikatsiya domenlari, mustaqil himoya siyosati.

• Hot - eng yangi, tez-tez oʻqish/yozish, minimal latentlik.
• Warm - kamroq o’zgaradi, vaqt oralig’ida ko’p o’qish.
• Cold - arxiv, arzon saqlash, yuqori TTFB, sekin tiklanish.

2) Darajalar bo’yicha profillar va SLO

Hot

Kirish: millisekundlar (KV/indekslarda p95 ≤ 5-20 ms; murakkab so’rovlarda 100-300 ms ≤).
Operatsiyalar: tez-tez upsert/append, indeksatsiya, OLTP/strim-ingest.
Tashuvchilar: NVMe/SSD, xotira, tezkor tarmoq.
Replikatsiya: RPO ≈ 0, RTO daqiqalari uchun yuqori (masalan, RF = 3).

Warm

Kirish: o’nlab-yuzlab millisekund/soniya.
Operatsiyalar: «deraza», batchi, yangi tarix bo’yicha OLAP o’qish (7-90 kun).
Tashuvchilar: SATA SSD/tezkor HDD/lokal keshli obyekt saqlovchisi.
Replikatsiya: oʻrtacha (RF = 2), kompresssiya yoqilgan.

Cold

Kirish: soniya-soat; tez-tez offline-kirish, «retrieve-and-scan».
Operatsiyalar: kamdan-kam o’qish, tartibga soluvchiga muvofiqlik (retenshn yillari).
Tashuvchilar: obyekt/arxiv (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Replikatsiya: mintaqaviy/mintaqalararo, WORM/Legal Hold.

3) Qatlamlar bo’yicha namunaviy texnologiyalar

Hot: PostgreSQL (OLTP, partitions), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch hot-nodes, ClickHouse горячие партиции, Kafka local log.
Warm: ClickHouse, BigQuery/Snowflake, Elasticsearch warm-nodes, S3 + Presto/Trino, Tiered storage (Kafka/Pulsar).
Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, arxivning HDFS, uzoq muddatli arxivlar.

4) Hayot sikli siyosati (ILM) va avtomatlashtirish

4. 1. Konsepsiyalar

Vaqt bo’yicha partiyalashtirish (kun/hafta/oy) - qatlamlar o’rtasida o’tkazishning asosiy dastagi.
ILM qoidalari: rollover (hajmi/yoshi bo’yicha), shrink/merge, freeze, delete.
Deduplikatsiya va siqish: hot-dagi CPU tor joylaridan qochib, warm/cold-da yoqish.

4. 2 Misollar

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 partiyasi sana bo’yicha

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) Qiymat va unumdorlikni modellashtirish

5. 1 Oddiy TCO modeli

’TCO = CapEx/OpEx tashuvchilar + tarmoq (egress) + CPU siqish/skaner + boshqaruv + DR/replikatsiya’.

5. 2 Latentlik va narx balansi

Ma’lumotlarning 5-20% ≈ issiq to’plami so’rovlarning 80-95% ni beradi.
Maqsad - ish toʻplamini Hot/keshda (CPU/RAM/NVMe) ushlab turish, qolganlarini Warm/Cold ga koʻchirishdir.

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) Partiyalashtirish, indeksatsiya qilish va keshlash

Vaqt bo’yicha partiyalar + «yangi» kesimlar uchun secondary-indekslar.
So’rovlarning oltin qoidasi: filtr birinchi, so’ngra selektiv kalitlar.
Ierarxik kesh: in-proc → Redis → edge; issiq kalitlar/agregatlar uchun pin-keshlar.
Bloom-filtrlar/skip-indekslar (ClickHouse, Parquet) warm/cold oʻqishni kamaytirish uchun.

7) Replikatsiya, nosozlikka chidamlilik va DR

Hot: sinxron replikatsiya (multizona), RPO ≈ 0, tezkor faylover.
Warm: zonalararo/mintaqalararo asinxron nusxa; RPO daqiqa.
Cold: WORM (Write Once Read Many), Legal Hold bilan mintaqalararo.
DR-rejalar: «sovuq» arxivlarni tiklash uchun run-kitoblar (soatlar), davriy fire-drills.

8) Xavfsizlik va muvofiqlik

PII/PCI: tinch shifrlash (KMS), har bir bosqichdagi asosiy siyosatlar, pastga ko’chirishda niqoblash.
Retenshn va oʻchirish: avtomatik muddatlar cold, isbotlanadigan oʻchirish (erase reports).
Yurisdiksiyalar: mintaqada saqlash (EU-only, RU-only, BY-region va h.k.), bucketlarni geo-izolyatsiya qilish.

9) Foydalanish patternlari

9. 1 Logi va telemetriya

Hot: Elasticsearch/ClickHouse’da NVMe’da oxirgi 24-72 soat.
Warm: S3 da SSD/HDD + Parquet uchun 30-180 kun.
Cold:> 180 kun Glacier; «talab bo’yicha» Trino/Presto orqali so’rovlar.

9. 2 Tranzaksiya/order

Hot: OLTP DB (PostgreSQL/MySQL) qisqa tarixga ega.
Warm: BI uchun denormallashtirilgan snapshotlar.
Cold: yuridik arxiv, obʼekt omboriga eksport qilish.

9. 3 ML-fichestore

Hot: Redis/low-latency DB onlayn fichlari.
Warm: ustunli/obʼektli oflayn fichlar.
Cold: dastlabki datasetlar, versioned (Delta/Iceberg/Hudi).

10) Klastyerlar va Kubernetes bilan o’zaro hamkorlik

StorageClass’gold-nvme’(hot),’silver-ssd’(warm),’bronze-object’(cold).
Pool tugunlarini (taints/labels) hot/warm/cold workloadlar uchun rejalashtirish.
Obyekt omboriga soʻrashdan oldin sidecar-keshlar (masalan, local SSD cache).

PVC misoli

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

11) Kuzatish

Dashbordlar: baytlar/so’rovlarni tier, latency per tier, offload uchun warm/cold, narxi/oyi bo’yicha taqsimlash.
Alertlar: hit-ratio hot pasayishi, promotion-rate o’sishi (issiq hajm etarli bo’ladimi), TTFB ning warm ko’payishi, cold (SLO breach) ning sekin tiklanishi.

12) Anti-patternlar

«Hamma hot-da»: ortiqcha qiymat, IOni haddan tashqari qizdirish.
«Indekssiz chuqur sovuq»: arzon saqlash, qimmat o’qish; Tezkor kesish yoʻllari yoʻq.
«ILM yo’q»: qo’lda ko’chirish, inson xatolari.
Barcha darajalar uchun «Yagona replikatsiya siyosati»: ortiqcha to’lov va notekis RPO.
Bir hisoblash hovuzida «prod/arxiv so’rovlarini aralashtirish»: o’zaro ta’sir.
Cold-bulutlardan olingan «hisobga olinmagan egress»: hisobdagi kutilmagan hodisalar.

13) Joriy etish chek-varaqasi

• Ma’lumotlar to’plamlarini tasniflang: SLA, kirish chastotasi, saqlash talablari.
• (NVMe/SSD/HDD/Object/Archive).
• Partiyalar (vaqt/kalit), indekslar va formatlarni (Parquet/ORC/Delta) loyihalashtiring.
• ILM qoidalarini (rollover/transition/expire) aniqlang va avtomatlashtiring.
• Siqish/kodlashni yoqing (ZSTD/LZ4; cold - kuchliroq).
• RPO/RTO replikatsiyasini va DR-protseduralarini aniqlang.
• Issiq agregatlar uchun kesh ierarxiyasi va pin moslamalarini oʻrnating.
• Qiymat/latentlik metrikasi va tier bo’yicha alertlar.
• Xavfsizlik siyosati (KMS, yuridik retenshnlar, geo-izolyatsiya).
• Tarjimalar chegarasini (seasonality, oʻsish) muntazam ravishda qayta koʻrib chiqing.

14) FAQ

Q: Hot va warm chegaralarini qanday aniqlash mumkin?
A: So’rovlarning haqiqiy taqsimoti bo’yicha: «issiq ish to’plami» = 80-95% so’rovlarni ta’minlaydigan yuqori 5-20% kalitlar/partiyalar. Hamma narsa - warm uchun nomzod.

Q: To’g’ridan-to’g’ri cold dan o’qish mumkinmi?
A: Ha, lekin SLAni daqiqa/soat va egress qiymatida rejalashtiring; ko’pincha tahlil qilishdan oldin parchani warm (staging) ga qaytarish foydaliroq.

Q: Tahlilchi uchun 30-180 kun nimani tanlash kerak?
A: Obʼektdagi ustunli formatlar (Parquet/ORC) + kesh bilan soʻrov dvigateli (Trino/Presto/ClickHouse); IOni tejash uchun indekslar/skip-data.

Q: cold dan qayta tanlashda qanday qilib «isinish boʻronlaridan» qochish mumkin?
A: prefetch/prepare-jobs, limitli so’rovlardan foydalaning, vaqt bo’yicha shard qiling, warm uchun request-coalescing va pin-keshlardan foydalaning.

15) Yakunlar

Hot/Warm/Cold arxitekturasi - bu foydalanish profiliga va avtomatik hayot siklini boshqarishga mos keladi. Qatlam bo’yicha aniq SLO, partizatsiya va ILM, oqilona replikatsiya va kesh-ierarxiya «issiq» tezkor, «issiq» - arzon, «sovuq» - arzon va xavfsiz saqlash imkonini beradi.