Hot/Warm/Cold сақтау орны

1) Деректерді Hot/Warm/Cold-ке бөлудің қажеті

• Құнын оңтайландыру: жылдам және қымбат қабат «ыстық» жұмыс жиынтығы үшін ғана.
• SLO сақтаңыз: p95/throughput онлайн үшін, тарих үшін ұзағырақ мерзім.
• Масштабтауды оңайлату: «фронттың» қызып кетуінсіз арзан қабаттарды көлденең өсіру.
• Тәуекелдерді төмендету: бас тартудың/репликалаудың әртүрлі домендері, тәуелсіз қорғау саясаты.

• Hot - ең жаңа, жиі оқу/жазу, ең төменгі жасырындылық.
• Warm - сирек өзгереді, уақыт ауқымы бойынша көп оқу.
• Cold - мұрағат, арзан сақтау, жоғары TTFB, баяу қалпына келтіру.

2) Деңгейлер бойынша профильдер мен SLO

Hot

Қолжетімділік: миллисекундтар (KV/индекстерде p95 ≤ 5-20 мс; күрделі сұрау салуларда 100-300 мс ≤).
Операциялар: жиі upsert/append, индекстеу, OLTP/стрим-ингест.
Тасымалдаушылар: NVMe/SSD, жады, жылдам желі.
Репликация: RPO ≈ 0, RTO минут үшін жоғарылатылған (мысалы, RF = 3).

Warm

Қатынау: ондаған-жүздеген миллисекунд/сек.
Операциялар: «терезе», батчи, жаңа тарих бойынша OLAP оқу (7-90 күн).
Жеткізгіштер: SATA SSD/жылдам HDD/жергілікті кэші бар объекті сақтау орны.
Репликация: орташа (RF = 2), компрессия қосылған.

Cold

Қатынау: секунд-сағат; жиі offline-қол жеткізу, «retrieve-and-scan».
Операциялар: сирек оқулар, реттегішке сәйкестігі (ретеншн жылдар).
Тасымалдаушылар: объектілік/мұрағаттық (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Репликация: өңірлік/өңіраралық, WORM/Legal Hold.

3) Қабаттар бойынша типтік технологиялар

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, HDFS мұрағаты, ұзақ мерзімді бэкаптар.

4) Өмірлік цикл саясаты (ILM) және автоматтандыру

4. 1 Тұжырымдамалар

Уақыт бойынша партиялану (күн/апта/ай) - қабаттар арасындағы аударманың негізгі тетігі.
ILM-ережелер: rollover (көлемі/жасы бойынша), shrink/merge, freeze, delete.
Дедупликация және компрессия: hot-тегі CPU-тар жерлерді болдырмай, warm/cold қосыңыз.

4. 2 Мысалдар

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 (эскиз)

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 күні бойынша

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) Құн мен өнімділікті модельдеу

5. 1 Қарапайым TCO моделі

'TCO = CapEx/OpEx + желі (egress) + CPU компрессияға/сканерлерге + басқару + DR/репликация'.

5. 2 Жасырындылық пен бағаның теңгерімі

5-20% деректер ≈ ыстық жиынтығы 80-95% сұрау береді.
Мақсаты - жұмыс жиынтығын Hot/кэште (CPU/RAM/NVMe) ұстап тұру, қалғанын Warm/Cold-ке жылжыту.

5. 3 Өлшемдері

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) Партияландыру, индекстеу және кэштеу

Уақыт бойынша партиялар + secondary-индекстер «жаңа» тіліктер үшін.
Сұраулардың алтын ережесі: уақыт бойынша сүзгі бірінші, содан кейін таңдаулы кілттер.
Иерархиялық кэш: in-proc → Redis → edge; ыстық кілттер/агрегаттар үшін pin-кэштер.
Bloom сүзгілері/skip индекстері (ClickHouse, Parquet) warm/cold оқуларды азайту үшін.

7) Репликация, істен шығуға төзімділік және DR

Hot: синхронды репликалау (мультизона), RPO ≈ 0, жылдам фейловер.
Warm: асинхронды аймақаралық/өңіраралық реплика; RPO минут.
Cold: WORM (Write Once Read Many) бар өңіраралық, комплаенс үшін Legal Hold.
DR-жоспарлар: «суық» мұрағаттарды қалпына келтіруге арналған run-кітаптар (сағаттар), мерзімді fire-drills.

8) Қауіпсіздік және сәйкестік

PII/PCI: тыныштық шифрлау (KMS), әрбір сатыдағы негізгі саясат, төмен жылжыту кезінде бүркемелеу.
Ретеншн және жою: автоматты мерзімі cold, дәлелденген өшіру (erase reports).
Юрисдикциялар: аймақта сақтау (EU-only, RU-only, BY-region және т.б.), bucket's гео-оқшаулау.

9) Пайдалану үлгілері

9. 1 Логи және телеметрия

Hot: соңғы 24-72 сағат Elasticsearch/ClickHouse NVMe.
Warm: SSD/HDD + Parquet S3 30-180 күн.
Cold:> Glacier 180 күн; Trino/Presto арқылы сұраулар «талап ету бойынша».

9. 2 Транзакциялар/ордерлер

Hot: OLTP БД (PostgreSQL/MySQL) қысқа тарихы бар.
Warm: BI үшін денолданбаған снапшоттар.
Cold: заңды мұрағат, нысанды қоймаға экспорттау.

9. 3 ML-fichestore

Hot: Redis/low-latency DB онлайн-фичи.
Warm: бағанды/нысанды оффлайн-фичи.
Cold: бастапқы датасеттер, versioned (Delta/Iceberg/Hudi).

10) Кластерлермен және Kubernetes-пен өзара іс-қимыл

StorageClass tier бойынша белгілеңіз: 'gold-nvme' (hot), 'silver-ssd' (warm), 'bronze-object' (cold).
Торап-пулдарды (taints/labels) hot/warm/cold workload деп жоспарлаңыз.
Sidecar кэштері (мысалы, local SSD cache) нысанды сақтау орнына сұрау алдында.

Мысалы ПВХ

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

11) Бақылау

Дашбордтар: байттарды/сұрауларды tier, latency per tier, offload бойынша warm/cold, құны/айы бойынша бөлу.
Алерталар: hit-ratio hot төмендеуі, promotion-rate өсуі (ыстық көлемнің жетуі), TTFB-ның warm өсуі, cold-дің баяу қалпына келуі (SLO breach).

12) Қарсы үлгілер

«Барлығы hot»: артық құн, IO қызып кеткен.
«Индекстерсіз терең суық»: арзан сақтау, қымбат оқу; жылдам кесу жолдары жоқ.
«ILM жоқ»: қолмен тасымалдау, адамның қателері.
Барлық деңгейлер үшін «бірыңғай репликациялық саясат»: артық төлеу және біркелкі емес RPO.
Бір есептеу пулында «prod/мұрағаттық сұрауларды араластыру»: өзара әсер ету.
cold-бұлттардан «ескерілмеген egress»: есептегі тосын сый.

13) Енгізу чек-парағы

• Деректер жиынтығын жіктеңіз: SLA, қолжетімділік жиілігі, сақтау талаптары.
• (NVMe/SSD/HDD/Object/Archive).
• Партияларды (уақыт/кілт), индекстерді және пішімдерді (Parquet/ORC/Delta) жобалаңыз.
• ILM ережелерін анықтаңыз (rollover/transition/expire) және автоматтандырыңыз.
• Компрессияны/кодтауды қосыңыз (ZSTD/LZ4; cold - күштірек).
• /RPO/RTO репликациясын және DR-процедураларын анықтаңыз.
• Ыстық агрегаттар үшін кэш иерархиясы мен pin параметрлерін теңшеңіз.
• Құн/жасырындылық өлшемдері және tier бойынша алерталар.
• Қауіпсіздік саясаты (KMS, заңды ретеншн, гео-оқшаулау).
• Аударма шегін (seasonality, өсу) үнемі қайта қараңыз.

14) FAQ

Q: Hot және warm арасындағы шекараны қалай анықтауға болады?
A: Сұраулардың нақты бөлінуі бойынша: «ыстық жұмыс жиынтығы» = сұраулардың 80-95% қамтамасыз ететін жоғарғы 5-20% кілттер/партиялар. Warm-қа үміткер келмейді.

Q: Тікелей cold-тен оқуға бола ма?
A: Иә, бірақ SLA минутына/сағатына және egress құнын жоспарлаңыз; талдау алдында фрагментті warm (staging) -ке қайтару жиі тиімді.

Q: 30-180 күндік талдау үшін не таңдау керек?
А: Объектідегі баған форматтары (Parquet/ORC) + кэшпен сұрау қозғалтқышы (Trino/Presto/ClickHouse); IO үнемдеуге арналған индекстер/skip-data.

Q: cold-тен қайта іріктеу кезінде «қызу дауылынан» қалай құтылуға болады?
A: prefetch/prepare-jobs, лимитті сұрауларды пайдаланыңыз, уақыт бойынша шардалаңыз, request-coalescing және warm-дегі pin-кэштерді қолданыңыз.

15) Қорытынды

Hot/Warm/Cold архитектурасы - бұл қол жеткізу профиліне және өмірлік циклді автоматты басқаруға сәйкес келеді. Қабаттар бойынша анық SLO, партиялану және ILM, ақылға қонымды репликация және кэш-иерархия «ыстық» жылдам, «жылы» - қолжетімді, ал «суық» - арзан және қауіпсіз ұстауға мүмкіндік береді.