GH GambleHub

Hot/Warm/Cold сактоо

1) Эмне үчүн маалыматтарды Hot/Warm/Cold бөлүү

Бир кластерде ар кандай жеткиликтүүлүк үлгүлөрү бар: жаңы маалыматтарга интерактивдүү суроо-талаптар, акыркы мезгилдердеги аналитика жана архивге сейрек кирүү. Деңгээлдерге бөлүнүү төмөнкүлөргө мүмкүндүк берет:
  • наркы оптималдаштыруу: тез жана кымбат катмары гана "ысык" жумушчу топтому үчүн.
  • SLO сактоо: p95/throughput үчүн онлайн, узун мөөнөтү үчүн тарых.
  • Масштабды жөнөкөйлөтүү: "фронттун" ысып кетүүсүз арзан катмарды горизонталдуу көбөйтүү.
  • Тобокелдиктерди азайтуу: ар кандай баш тартуу/репликация домендери, көз карандысыз коргоо саясаты.
Кыскача:
  • Hot - жаңы, көп окуу/жазуу, минималдуу жашыруун.
  • Warm - азыраак өзгөрөт, убакыт диапазондорунда көп окуу.
  • Cold - архив, арзан сактоо, жогорку TTFB, жай калыбына келтирүү.

2) деңгээл боюнча Profiles жана SLO

Hot

Кирүү: миллисекунддар (KV/индекстерде p95 ≤ 5-20 мс; татаал суроо-талаптарда 100-300 мс ≤).
Операциялар: тез-тез upsert/append, индекстөө, OLTP/агым-ингест.
Медиа: NVMe/SSD, эс, тез тармак.
Replication: жогорулатылган (мисалы, RF = 3) үчүн RPO ≈ 0, RTO мүнөт.

Warm

Кирүү: ондогон жана жүздөгөн миллисекунд/секунд.
Операциялар: "терезе", батчи, жаңы тарых боюнча OLAP окуу (7-90 күн).
Медиа: SATA SSD/тез HDD/жергиликтүү кэш менен объект сактоо.
Replication: орточо (RF = 2), кысуу кирет.

Cold

Кирүү: секунд-саат; "retrieve-and-scan".
Операциялар: сейрек окуулар, жөнгө салуучу органдарга шайкештик (retenshn жылдар).
Медиа: объект/архив (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 Archive, узак мөөнөттүү backup.

4) Жашоо саясаты (ILM) жана автоматташтыруу

4. 1 түшүнүктөр

Убакыт боюнча партиялаштыруу (күн/жума/ай) - катмарлардын ортосундагы которуунун негизги рычагы.
ILM эрежелери: rollover (көлөмү/жашы боюнча), shrink/merge, freeze, delete.
Deduplication жана кысуу: 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 Латенттүүлүк жана баа балансы

Hot маалымат ≈ 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 Filters/Skip индекстери (ClickHouse, Parquet) warm/cold боюнча окууларды азайтуу үчүн.

7) Репликация, бузулууга туруктуулук жана DR

Hot: синхрондуу репликация (мультизона), RPO ≈ 0, тез фейловер.
Warm: асинхрондук зоналар аралык/аймактар ​ ​ аралык реплика; RPO мүнөт.
Cold: WORM менен аймактар ​ ​ аралык (Write Once Read Many), комплаенс үчүн мыйзамдуу кармап.
DR-пландар: "муздак" архивдерди калыбына келтирүү үчүн run-китептер (саат), мезгил-мезгили менен fire-drills.

8) Коопсуздук жана шайкештик

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

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

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

Hot: NVMe боюнча Elasticsearch/ClickHouse акыркы 24-72 саат.
Warm: S3 боюнча SSD/HDD + Parquet боюнча 30-180 күн.
Cold:> 180 күн Glacier; Trino/Presto аркылуу суроо-талап ".

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

Hot: OLTP DD (PostgreSQL/MySQL) кыска тарыхы менен.
Warm: BI үчүн Денормалдаштырылган Snapshot.
Cold: Юридикалык архив, объект сактоо экспорттоо.

9. 3 ML-fichestore

Hot: Redis/low-latency DB онлайн чүчүкулак.
Warm: колонка/объект менен offline ficking.
Cold: баштапкы маалыматтар, versioned (Delta/Iceberg/Hudi).

10) кластерлер жана Kubernetes менен өз ара

StorageClass 'gold-nvme' (hot), 'silver-ssd' (warm), 'bronze-object' (cold).
Hot/warm/cold workloads үчүн пул түйүндөрүн (taints/labels) пландаштырыңыз.
Sidecar кэштер (мисалы, local SSD кэш) объект сактагычка суроо алдында.

PVC мисал

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

11) Байкоо

Dashboard: Байт/тир боюнча суроо бөлүштүрүү, latency per тир, warm/cold боюнча offload, баасы/ай.
Alerty: hit-ratio hot төмөндөшү, өсүш promotion-rate (ысык көлөмүн жетиштүү болобу), TTFB көбөйүшү warm, жай калыбына келтирүү cold (SLO breach).

12) Анти-үлгүлөрү

"Бардык Hot": ашыкча наркы, ысып IO.
"Индекстери жок терең суук": арзан сактоо, кымбат окуу; тез кесүү жолдору жок.
"ILM жок": кол которуулар, адамдын каталары.
"Бирдиктүү репликациялык саясат" бардык деңгээлдер үчүн: ашыкча төлөө жана бирдей эмес RPO.
бир эсептөө көлмөгө "аралаштыруу прод/архив суроо": өз ара таасири.
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, юридикалык retenshn, гео-изоляция).
  • Дайыма которуулардын босогосун карап чыгуу (seasonality, өсүү).

14) FAQ

Q: Hot жана warm ортосундагы чектерди кантип аныктоо керек?
A: Чыныгы суроо бөлүштүрүү боюнча: "ысык жумушчу топтому" = жогорку 5-20% ачкычтар/партиялар, 80-95% суроо-талаптарды камсыз кылуу. Баары эмес, - warm талапкер.

Q: Мен түздөн-түз cold окуй аласызбы?
A: Ооба, бирок SLA мүнөт/саат жана egress наркы боюнча пландаштыруу; көп учурда талдоо алдында warm (staging) бир үзүндү кайтып пайдалуу.

Q: аналитика 30-180 күн үчүн эмне тандоо керек?
A: Колон форматтары (Parquet/ORC) объектте + суроо кыймылдаткычы (Trino/Presto/ClickHouse) кэш менен; IO сактоо үчүн индекстер/skip-маалыматтар.

Q: cold кайра тандоодо "бороон-чапкын" качуу үчүн кантип?
A: prefetch/prepare-jobs колдонуу, лимиттери менен суроо-талап, убакыт, request-coalescing жана warm боюнча pin-кэш колдонуу.

15) натыйжалары

Hot/Warm/Cold архитектурасы - бул кирүү профилине жана автоматтык жашоо циклин башкарууга ылайыкташуу. Так SLO катмарлары, партиялаштыруу жана ILM, акылга сыярлык репликация жана кэш иерархиясы "ысык" тез, "жылуу" - жеткиликтүү, ал эми "муздак" - арзан жана коопсуз болууга мүмкүндүк берет.

Contact

Биз менен байланышыңыз

Кандай гана суроо же колдоо керек болбосун — бизге кайрылыңыз.Биз дайым жардам берүүгө даярбыз!

Telegram
@Gamble_GC
Интеграцияны баштоо

Email — милдеттүү. Telegram же WhatsApp — каалооңузга жараша.

Атыңыз милдеттүү эмес
Email милдеттүү эмес
Тема милдеттүү эмес
Билдирүү милдеттүү эмес
Telegram милдеттүү эмес
@
Эгер Telegram көрсөтсөңүз — Emailден тышкары ошол жактан да жооп беребиз.
WhatsApp милдеттүү эмес
Формат: өлкөнүн коду жана номер (мисалы, +996XXXXXXXXX).

Түшүрүү баскычын басуу менен сиз маалыматтарыңыздын иштетилишине макул болосуз.