أقبية ساخنة/دافئة/باردة

1) لماذا تقسم البيانات على Hot/Warm/Cold

• تحسين التكلفة: طبقة سريعة ومكلفة لمجموعة العمل الساخنة فقط.
• امتثل لـ SLO: p95/الإنتاجية للمواعيد النهائية الأطول للتاريخ عبر الإنترنت.
• تبسيط التحجيم: بناء طبقات رخيصة أفقيًا دون ارتفاع درجة حرارة «الأمام».
• تخفيف المخاطر: مجالات فشل/تكرار مختلفة، سياسات حماية مستقلة.

• ساخنة - أحدث القراءة/الكتابة المتكررة، الحد الأدنى من زمن الكمون.
• دافئ - يتغير بشكل أقل، والكثير من القراءة بمرور الوقت.
• أرشيف بارد، تخزين رخيص، TTFB مرتفع، استرداد بطيء.

2) الملامح والمكاتب المحلية حسب الرتبة

حار

الوصول: مللي ثانية (p95 ≤ 5-20 مللي ثانية على KV/الفهارس ؛ ≤ 100-300 مللي ثانية على الاستفسارات المعقدة).
العمليات: الانزعاج/التذييل المتكرر، الفهرسة، OLTP/stream-infest.
الوسائط: NVMe/SSD، ذاكرة، شبكة سريعة.
التكرار: زيادة (على سبيل المثال RF = 3) لمدة RPO≈0 دقائق، RTO.

دافئ

الوصول: من عشرات إلى مئات المللي ثانية/ثانية.
العمليات: قراءة «النافذة»، الجزار، OLAP على التاريخ الجديد (7-90 يومًا).
الوسائط: SATA SSD/HDD السريع/تخزين الأشياء مع ذاكرة التخزين المؤقت المحلية.
التكرار: معتدل (RF = 2)، تم تمكين الضغط.

بارد

الوصول: ساعات ثانية ؛ الوصول المتكرر دون اتصال بالإنترنت، «استرجاع وفحص».
العمليات: قراءات نادرة، الامتثال للتنظيم (الاحتفاظ بالسنوات).
Media: object/archive (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
النسخ المتماثلة: الإقليمي/الأقاليمي، WORM/Legal Hold.

3) التقنيات النموذجية حسب الطبقة

Hot: PostgreSQL (OLTP، أقسام)، MySQL/InnoDB، Redis/Memcached (кэш)، Elasticsearch/Opensearch hot-nodes، CLLickHO. горячие партиции، سجل كافكا المحلي.
دافئ: تخزين عمود ClickHouse، حفلات BigQuery/Snowflake الأخيرة، عقد دافئة Elasticsearch، S3 + Presto/Trino مع ذاكرة تخزين مؤقتة، تخزين متدرج (كافكا/بولسار).
Cold: S3/Glacier، GCS Nearline/Coldline/Archive، Azure Cool/Archive، أرشيف HDFS، نسخ احتياطية طويلة الأجل.

4) سياسات دورة الحياة (ILM) والأتمتة

4. 1 مفاهيم

التقسيم الزمني (يوم/أسبوع/شهر) هو رافعة الترجمة الرئيسية بين الطبقات.
قواعد ILM: التمديد (حسب الحجم/العمر)، الانكماش/الدمج، التجميد، الحذف.
التفريغ والضغط: تمكين الدفء/البارد، وتجنب اختناقات وحدة المعالجة المركزية الساخنة.

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 (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 media + network (extion) + CPU للضغط/المسح + الإدارة + DR/التكرار'.

5. 2 ميزان زمن الانتقال والسعر

مجموعة ساخنة ≈ 5-20٪ من البيانات تنتج 80-95٪ من الاستفسارات.
الهدف هو الحفاظ على مجموعة العمل في Hot/cache (CPU/RAM/NVMe)، وتحويل الباقي إلى Warm/Cold.

5. 3 مقاييس

، ، ، ، ، ( )، ( ).

6) التقسيم والفهرسة والتخزين المؤقت

الفواصل الزمنية + المؤشرات الثانوية للشرائح «الطازجة».
القاعدة الذهبية للطلبات: المرشح بالمرة أولاً، ثم المفاتيح الانتقائية.
ذاكرة التخزين المؤقت الهرمية: in-proc → Redis → edge; مخابئ الدبوس للمفاتيح الساخنة/الركام.
مرشحات Bloom/تخطي الفهارس (ClickHouse، Parquet) لتقليل القراءات إلى دافئة/باردة.

7) التكرار وتحمل الأخطاء و DR

ساخن: تكرار متزامن (متعدد المناطق)، RPO≈0، سريع.
الدفء: النسخة المتماثلة غير المتزامنة بين المناطق والأقاليم ؛ دقائق RPO.
البرد: أقاليمي مع WORM (اكتب مرة واحدة اقرأ كثيرًا)، عقد قانوني للامتثال.
خطط DR: كتب تشغيل لاستعادة المحفوظات «الباردة» (ساعات)، التدريبات الدورية على الحرائق.

8) السلامة والامتثال

PII/PCI: التشفير عند الراحة (KMS)، السياسات الرئيسية في كل مرحلة، الإخفاء عند التحرك لأسفل.
الاحتفاظ بها وإزالتها: مواعيد نهائية تلقائية للمحو البارد الذي يمكن إثباته (تقارير المحو).
الولايات القضائية: التخزين في المنطقة (الاتحاد الأوروبي فقط، اليورانيوم العادي فقط، منطقة BY، إلخ)، العزل الجغرافي للدلاء.

9) أنماط الاستخدام

9. 1 جذوع الأشجار والقياس عن بُعد

ساخن: آخر 24-72 ساعة في Elasticsearch/ClickHouse على NVMe.
دافئ: 30-180 يومًا على SSD/HDD + Parquet في S3.
بارد:> 180 يومًا في النهر الجليدي ؛ طلبات عبر ترينو/بريستو «عند الطلب».

9. 2 المعاملات/الطلبات

Hot: قاعدة بيانات OLTP (PostgreSQL/MySQL) ذات تاريخ قصير.
دافئ: لقطات غير طبيعية لـ BI.
بارد: أرشيف قانوني، تصدير إلى تخزين الأشياء.

9. 3 ML-ficestore

ساخن: ميزات عبر الإنترنت في Redis/DB منخفض الوقت.
دافئ: ميزات غير متصلة بالإنترنت في العمود/الكائن.
Cold: source datests, versioned (Delta/Iceberg/Hudi).

10) التفاعل مع المجموعات و Kubernetes

Mark StorageClass by tier: «gold-nvme» (ساخن)، «silver-sd» (دافئ)، «كائن برونزي» (بارد).
خطط لعقد البلياردو (tains/labels) لورش العمل الساخنة/الدافئة/الباردة.
مخابئ Sidecar (على سبيل المثال، مخبأ SSD المحلي) قبل طلبات التخزين.

مثال على PVC

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

11) إمكانية الملاحظة

لوحات القيادة: توزيع البايت/الطلبات حسب الطبقة، والكمون لكل طبقة، والتفريغ إلى دافئ/بارد، والتكلفة/الشهر.
التنبيهات: انخفاض في نسبة الإصابة الساخنة، وزيادة في معدل الترويج (هناك حجم ساخن كافٍ)، وزيادة في TTFB عن طريق الدفء، واستعادة بطيئة للبرد (خرق SLO).

12) الأنماط المضادة

«الكل في حالة ساخنة»: تكلفة باهظة، ارتفاع درجة حرارة IO.
«البرد العميق بدون فهارس»: رخيص للتخزين ومكلف للقراءة ؛ لا توجد مسارات شريحة سريعة.
«لا ILM»: نقل يدوي، أخطاء بشرية.
«سياسة تكرار موحدة» لجميع المستويات: المدفوعات الزائدة والمكاتب الإقليمية غير المتكافئة.
امزج استفسارات prod/archive في مجموعة حسابات واحدة - التداخل.
«الخروج المجهول» من السحب الباردة: مفاجآت في الفاتورة.

13) قائمة التنفيذ المرجعية

• تصنيف مجموعات البيانات: جيش تحرير السودان، وتواتر الوصول، ومتطلبات التخزين.
• اختر الوسائط والمحركات لكل طبقة (NVMe/SSD/HDD/Object/Archive).
• وقت التصميم/فواصل المفاتيح والفهارس والأشكال (Parquet/ORC/Delta).
• تعريف قواعد ILM (التمديد/الانتقال/انتهاء الصلاحية) والتشغيل الآلي.
• تمكين الضغط/الترميز (ZSTD/LZ4; في البرد - أقوى).
• تحديد إجراءات التكرار/RPO/RTO و DR.
• قم بتكوين التسلسل الهرمي لذاكرة التخزين المؤقت ودبوس للتجمعات الساخنة.
• مقاييس التكلفة/الكمون وتنبيهات الطبقة.
• السياسات الأمنية (KMS، الاحتفاظ القانوني، العزل الجغرافي).
• استعراض عتبات التحويل بانتظام (الموسمية، النمو).

14) الأسئلة الشائعة

س: كيف تحدد الحدود بين الساخنة والدافئة ؟

ج: وفقًا للتوزيعات الحقيقية للطلبات: «مجموعة العمل الساخنة» = أعلى 5-20٪ من المفاتيح/الأطراف، مما يوفر 80-95٪ من الطلبات. كل ما يفشل هو مرشح دافئ.

س: هل يمكنني القراءة مباشرة من البرد ؟

ج: نعم، لكن التخطيط لاتفاقات الأمن الخاصة أقل من دقائق/ساعات وتكلفة الخروج ؛ وغالبا ما يكون من المربح إعادة جزء إلى وطنه ليكون دافئا (على مراحل) قبل التحليل.

س: ماذا تختار للتحليلات 30-180 يومًا ؟

ج: صيغ الأعمدة (Parquet/ORC) على محرك الكائن + الاستعلام (Trino/Presto/ClickHouse) مع ذاكرة تخزين مؤقت ؛ الفهارس/تخطي البيانات لحفظ IO.

س: كيف تتجنب «عواصف الإحماء» عند إعادة التخلص من البرد ؟

ج: استخدم البادئة/التحضير للوظائف، والحد من الطلبات، والوقت القشري، وطلب الدمج، ومخابئ الدبوس على الدفء.

15) المجاميع

بنية Hot/Warm/Cold هي مطابقة التكلفة مع ملف تعريف الوصول بالإضافة إلى إدارة دورة الحياة التلقائية. تبقي SLOs الواضحة حسب الطبقة والتقسيم و ILM، والتكرار المعقول والتسلسل الهرمي المخبأ «ساخنة» بسرعة، و «دافئة» بأسعار معقولة، و «باردة» رخيصة وآمنة.