Hot/Warm/Cold საცავი

1) რატომ გავაზიაროთ მონაცემები Hot/Warm/Cold

• ფასის ოპტიმიზაცია: სწრაფი და ძვირადღირებული ფენა მხოლოდ „ცხელი“ სამუშაო ნაკრებისთვის.
• დაიცავით SLO: p95/throughput ინტერნეტით, უფრო გრძელი ვადა ისტორიისთვის.
• სკალირების გამარტივება: ჰორიზონტალურად გაზარდეთ იაფი ფენები „ფრონტის“ გადახურების გარეშე.
• რისკების შემცირება: სხვადასხვა უარის/რეპლიკაციის დომენები, დამოუკიდებელი დაცვის პოლიტიკოსები.

• ცხელი არის უახლესი, ხშირი კითხვა/ჩაწერა, მინიმალური ლატენტობა.
• Warm - ნაკლებად ხშირად იცვლება, ბევრი კითხვა დროის დიაპაზონის მიხედვით.
• ცივი არის არქივი, იაფი შენახვა, მაღალი TTFB, ნელი აღდგენა.

2) პროფილები და SLO დონეზე

Hot

წვდომა: მილიწამები (p95-5-20 ms KV/ინდექსებზე; 100-300 ms რთულ მოთხოვნებზე).
ოპერაციები: ხშირი upsert/append, ინდექსაცია, OLTP/strim ingest.
მატარებლები: NVMe/SSD, მეხსიერება, სწრაფი ქსელი.
რეპლიკაცია: გაზრდილი (მაგალითად, RF = 3) RPO-0, RTO წუთებისთვის.

Warm

წვდომა: ათეულობით ასეული მილიწამი/წამი.
ოპერაციები: „ფანჯრის“ კითხვა, ბრძოლები, OLAP უახლესი ისტორიის შესახებ (7-90 დღე).
მატარებლები: SATA SSD/სწრაფი HDD/ობიექტის საცავი ადგილობრივი ქეშით.
რეპლიკაცია: ზომიერი (RF = 2), კომპრესია შედის.

Cold

წვდომა: წამები-საათი; ხშირი ოფლაინ წვდომა, „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 სცენა (KafKafkafKafka/psar).
ცივი: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, HDFS არქივი, გრძელვადიანი ზურგჩანთები.

4) სასიცოცხლო ციკლის პოლიტიკა (ILM) და ავტომატიზაცია

4. 1 კონცეფცია

დროის განლაგება (დღე/კვირა/თვე) არის ფენებს შორის თარგმანის მთავარი ბერკეტი.
ILM წესები: rollover (მოცულობის/ასაკის მიხედვით), shrink/merge, freeze, delete.
დედუპლიკაცია და შეკუმშვა: ჩართეთ 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% -ს.
მიზანია სამუშაო სეტის შენარჩუნება ცხელი/ქეში (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) განაწილება, ინდექსაცია და ქეშირება

დროის წვეულებები + საშუალო ინდექსები „ახალი“ ჭრისთვის.
შეკითხვის ოქროს წესი: ფილტრი დროულად, შემდეგ შერჩევითი გასაღებები.
კეში იერარქიული: in-proc-Redis-edge; pin ქეში ცხელი გასაღებების/აგრეგატებისთვის.
Bloom ფილტრები/skip ინდექსები (ClickHouse, Parquet) კითხვების შემცირების მიზნით warm/cold.

7) რეპლიკაცია, წინააღმდეგობა და DR

ცხელი: სინქრონული რეპლიკაცია (მულტიზონი), RPO-0, სწრაფი ყალბი.
Warm: ასინქრონული ინტერრეგიონალური/ინტერრეგიონალური რეპლიკა; RPO წუთი.
Cold: რეგიონთაშორისი WORM (Write Once Read Many), Legal Hold for Complaens.
DR გეგმები: run წიგნები „ცივი“ არქივების (საათების) აღდგენისთვის, პერიოდული fire-drills.

8) უსაფრთხოება და შესაბამისობა

PII/PCI: დაშიფვრა დასვენებაში (KMS), საკვანძო პოლიტიკოსები თითოეულ ეტაპზე, შენიღბვა ქვევით გადასვლისას.
Retenshne და მოცილება: ავტომატური ვადები cold, დადასტურებული წაშლა (erase reports).
იურისდიქცია: შენახვა რეგიონში (EU-only, RU-only, BY-region და ა.შ.), ბუკეტის გეო იზოლაცია.

9) გამოყენების ნიმუშები

9. 1 ლოგიკა და ტელემეტრია

ცხელი: ბოლო 24-72 საათი Elasticsearch/ClickHouse NVMe- ზე.
Warm: 30-180 დღე SSD/HDD + Parquet S3- ში.
ცივი:> 180 დღე Glacier- ში; მოთხოვნა Trino/Presto- ს მეშვეობით „მოთხოვნით“.

9. 2 გარიგებები/შეკვეთები

ცხელი: OLTP BD (PostgreSQL/MySQL) მოკლე ისტორიით.
Warm: დენორმალიზებული სნაიპშოტები BI- სთვის.
ცივი: იურიდიული არქივი, ექსპორტი ობიექტის საცავში.

9. 3 ML ფიჩესტორი

ცხელი: ონლაინ ფიჩები Redis/დაბალი დონის DB- ში.
Warm: ოფლაინ ფიჩები სვეტში/ობიექტში.
ცივი: საწყისი datasets, versioned (Delta/Iceberg/Hudi).

10) თანამშრომლობა მტევნებთან და კუბერნეტებთან

StorageClass ჩაანაცვლეთ tier: 'gold-nvme' (ცხელი), 'silver-ssd' (warm), 'bronze-object' (ცივი).
დაგეგმეთ taints/labels კვანძები ცხელი/warm/cold workloads.
Sidecar ქეში (მაგალითად, ადგილობრივი SSD cache) ობიექტის საცავის მოთხოვნით.

მაგალითი PVC

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- ის დაქვეითება, პრომოაქციების ზრდა (საკმარისია თუ არა ცხელი მოცულობა), TTFB- ის ზრდა warm- ზე, ცივი ნელი აღდგენა (SLO breach).

12) ანტი შაბლონები

„ყველაფერი ცხელი“: ზედმეტი ღირებულება, გადახურება IO.
„ღრმა სიცივე ინდექსების გარეშე“: იაფი შენახვა, ძვირი კითხვა; სწრაფი ჭრის ბილიკები არ არის.
„არა ILM“: სახელმძღვანელო გადაცემები, ადამიანის შეცდომები.
„ერთიანი რეპლიკაციის პოლიტიკა“ ყველა დონისთვის: გადახდა და არათანაბარი RPO.
„შერევა/საარქივო მოთხოვნების შესახებ“ გამოთვლების ერთ აუზში: ურთიერთგამომრიცხავი გავლენა.
ცივი ღრუბლებიდან „ამოუცნობი“: სიურპრიზები ანგარიშში.

13) განხორციელების შემოწმების სია

• კლასიფიკაციის მონაცემთა ნაკრები: SLA, დაშვების სიხშირე, შენახვის მოთხოვნები.
• შეარჩიეთ მატარებლები და ძრავები ფენით (NVMe/SSD/HDD/Object/Archive).
• შეიმუშავეთ ნაწილები (დრო/გასაღები), ინდექსები და ფორმატები (Parquet/ORC/Delta).
• განსაზღვრეთ ILM წესები (rollover/transtion/expire) და ავტომატიზაცია.
• ჩართეთ შეკუმშვა/კოდირება (ZSTD/LZ4; ცივი - უფრო ძლიერი).
• განსაზღვრეთ რეპლიკაცია/RPO/RTO და DR პროცედურები.
• კონფიგურაცია ქეშის იერარქიისა და პინის ცხელი აგრეგატებისთვის.
• ფასების/ლატენტობის მეტრიკა და ალერტები ტიერის მიხედვით.
• უსაფრთხოების პოლიტიკა (KMS, იურიდიული ჭრილობები, გეო იზოლაცია).

რეგულარულად გადახედეთ გადარიცხვების ბარიერებს (seasonality, ზრდა).

14) FAQ

Q: როგორ დავადგინოთ საზღვრები ცხელსა და warm- ს შორის?
A: მოთხოვნის რეალური განაწილების მიხედვით: „ცხელი სამუშაო ნაკრები“ = კლავიშების/წვეულებების ზედა 5-20%, რაც უზრუნველყოფს მოთხოვნის 80-95% -ს. ყველაფერი, რაც არ შედის, არის warm კანდიდატი.

Q: შეგიძლიათ პირდაპირ წაიკითხოთ cold- დან?
A: დიახ, მაგრამ დაგეგმეთ SLA წუთების/საათის განმავლობაში და egress- ის ღირებულება; უფრო ხშირად მომგებიანია ანალიზის დაწყებამდე ფრაგმენტის დაბრუნება.

Q: რა უნდა აირჩიოთ ანალიტიკისთვის 30-180 დღის განმავლობაში?
A: სვეტების ფორმატები (Parquet/ORC) ობიექტში + მოთხოვნის ძრავა (Trino/Presto/ClickHouse) ქეშით; ინდექსები/skip მონაცემები IO- ს დაზოგვისთვის.

Q: როგორ ავიცილოთ თავიდან „დათბობის ქარიშხალი“, როდესაც გადალახულია ცივი?
A: გამოიყენეთ prefetch/prepare-jobs, მოთხოვნები limites, shardire დროულად, გამოიყენეთ request-coalescing და pin ქეში warm.

15) შედეგები

Hot/Warm/Cold არქიტექტურა არის წვდომის პროფილის ღირებულების შესაბამისობა და ცხოვრების ციკლის ავტომატური კონტროლი. მკაფიო SLO ფენებში, წვეულება და ILM, გონივრული რეპლიკაცია და ქეშის იერარქია საშუალებას გაძლევთ შეინარჩუნოთ „ცხელი“ სწრაფი, „თბილი“ - ხელმისაწვდომი, ხოლო „ცივი“ - იაფი და უსაფრთხო.