خزانه های گرم/گرم/سرد

1) چرا تقسیم داده ها بر اساس گرم/گرم/سرد

• بهینه سازی هزینه: لایه سریع و گران قیمت فقط برای مجموعه کار گرم.
• مطابق با SLO: p95/توان برای آنلاین، مهلت طولانی تر برای تاریخ.
• ساده سازی مقیاس بندی: به صورت افقی لایه های ارزان قیمت را بدون گرم کردن «جلو» ایجاد کنید.
• کاهش خطرات: دامنه های مختلف شکست/تکرار، سیاست های حفاظت مستقل.

• داغ - جدیدترین، خواندن/نوشتن مکرر، حداقل تاخیر.
• گرم - تغییرات کمتر، مقدار زیادی از خواندن در طول محدوده زمانی.
• سرد - آرشیو، ذخیره سازی ارزان، TTFB بالا، بازیابی آهسته.

2) پروفایل ها و SLO ها بر اساس سطح

داغ شدن

دسترسی: میلی ثانیه (p95 ≤ 5-20 میلی ثانیه در KV/شاخص ؛ ≤ 100-300 میلی ثانیه در نمایش داده شد پیچیده).
عملیات: uppert مکرر/الحاق، نمایه سازی، OLTP/جریان مصرف.
رسانه: NVMe/SSD، حافظه، شبکه سریع.
تکرار: افزایش یافته (به عنوان مثال RF = 3) برای RPO≈0، دقیقه RTO.

گرم

دسترسی: ده ها تا صدها میلی ثانیه/ثانیه.
عملیات: خواندن «پنجره»، butches، OLAP در تاریخ تازه (7-90 روز).
رسانه: SATA SSD/ذخیره سازی سریع HDD/شی با حافظه محلی.
تکرار: متوسط (RF = 2)، فشرده سازی فعال شده است.

سرد

دسترسی: ثانیه ساعت ؛ دسترسی مکرر آفلاین، «بازیابی و اسکن».
عملیات: خواندن نادر، انطباق با مقررات (حفظ سال).
رسانه ها: شی/بایگانی (S3 Glacier/Deep Archive، Azure Archive، GCS Coldline).
تکرار: منطقه ای/بین منطقه ای، WORM/حقوقی نگه دارید.

3) تکنیک های معمول توسط لایه

داغ: PostgreSQL (OLTP، پارتیشن)، MySQL/InnoDB، Redis/Memcached (кэш)، گره های داغ Elasticsearch/Opensearch، ClickHouse горячие партиции، گزارش محلی کافکا.
گرم: ذخیره سازی ستون ClickHouse، احزاب اخیر BigQuery/Snowflake، گره های گرم Elasticsearch، S3 + Presto/Trino با حافظه پنهان، ذخیره سازی Tiered (Kafka/Pulsar).
سرد: S3/Glacier، GCS Nearline/Coldline/Archive، Azure Cool/Archive، بایگانی HDFS، پشتیبان گیری طولانی مدت.

4) سیاست های چرخه عمر (ILM) و اتوماسیون

4. 1 مفاهیم

پارتیشن بندی زمان (روز/هفته/ماه) اهرم اصلی ترجمه بین لایه ها است.
قوانین ILM: رول اور (با حجم/سن)، کوچک/ادغام، انجماد، حذف.
Deduplication و فشرده سازی: فعال در گرم/سرد، اجتناب از تنگناهای CPU در گرم است.

4. 2 مثال ها

Elasticsearch ILM (گرم → گرم → سرد → حذف)

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 چرخه عمر (استاندارد → نادر → یخچال و فریزر → منقضی)

json
{
"Rules": [{
"ID": "logs-lifecycle",
"Filter": { "Prefix": "logs/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 7, "StorageClass": "STANDARD_IA" },
{ "Days": 30, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 365 }
}]
}

ذخیره سازی مخروطی کافکا (طرح)

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 + شبکه (خروج) + CPU برای فشرده سازی/اسکن + مدیریت + DR/تکرار'.

5. 2 تعادل تاخیر و قیمت

یک مجموعه داغ ≈ 5-20٪ از داده ها 80-95٪ از پرس و جو را تولید می کند.
هدف این است که مجموعه کار را در Hot/cache (CPU/RAM/NVMe) نگه دارید، بقیه را به گرم/سرد تغییر دهید.

5. 3 معیارها

، ، ، (سرد → گرم)، (گرم → گرم/سرد).

6) پارتیشن بندی، نمایه سازی و ذخیره سازی

پارتیشن های زمان + شاخص های ثانویه برای برش های «تازه».
قانون طلایی درخواستها: ابتدا زمان را فیلتر کنید، سپس کلیدهای انتخابی.
کش سلسله مراتبی: in-proc → Redis → edge; کش پین برای کلید های داغ/aggregates.
فیلترهای بلوم/شاخص های جست و خیز (ClickHouse، Parquet) برای کاهش خواندن به گرم/سرد.

7) تکرار، تحمل خطا و DR

داغ: تکرار همزمان (چند منطقه)، RPO≈0، سریع feilover.

گرم: بین منطقه ای ناهمزمان/ماکت بین منطقه ای ؛ دقیقه های RPO

سرد: بین منطقه ای با WORM (نوشتن یک بار خواندن بسیاری)، برگزاری قانونی برای انطباق.
DR-طرح: اجرا کتاب برای بازسازی «سرد» آرشیو (ساعت)، دوره آتش سوزی دریل.

8) ایمنی و انطباق

PII/PCI: رمزگذاری در حالت استراحت (KMS)، سیاست های کلیدی در هر مرحله، پوشش در هنگام حرکت به پایین.
نگهداری و حذف: مهلت اتوماتیک برای پاک کردن سرد و قابل اثبات (گزارش های پاک کردن).
حوزه های قضایی: ذخیره سازی در منطقه (فقط اتحادیه اروپا، فقط RU، BY-region و غیره)، جداسازی جغرافیایی سطل ها.

9) الگوهای استفاده

9. 1 سیاهههای مربوط و تله متری

داغ: آخرین 24-72 ساعت در Elasticsearch/ClickHouse در NVMe.
گرم: 30-180 روز در SSD/HDD + پارکت در S3.
سرد:> 180 روز در یخچال ؛ درخواست ها از طریق Trino/Presto «در صورت تقاضا».

9. 2 معاملات/سفارشات

داغ: پایگاه داده OLTP (PostgreSQL/MySQL) با سابقه کوتاه.
گرم: عکس های فوری غیر طبیعی برای BI.
سرد: بایگانی قانونی، صادرات به ذخیره سازی شیء.

9. 3 میلی لیتر

داغ: ویژگی های آنلاین در Redis/DB با تاخیر کم.
گرم: ویژگی های آفلاین در ستون/شی.
سرد: مجموعه داده های منبع، نسخه (Delta/Iceberg/Hudi).

10) تعامل با خوشه ها و Kubernetes

Mark StorageClass با ردیف: 'gold-nvme' (گرم)، 'silver-ssd' (گرم)، 'bronze-object' (سرد).
برنامه ریزی گره های استخر (tains/labels) برای کارگاه های گرم/گرم/سرد.
حافظههای جانبی جانبی (به عنوان مثال، حافظه 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»: انتقال دستی، خطاهای انسانی.
«سیاست تکرار یکنواخت» برای تمام سطوح: پرداخت بیش از حد و RPO های ناهموار.
نمایش داده شد تولید/آرشیو مخلوط در یک استخر محاسبه - تداخل.
«خروج حساب نشده» از ابرهای سرد: شگفتی در لایحه.

13) چک لیست پیاده سازی

• مجموعه داده ها را طبقه بندی کنید: SLA، فرکانس دسترسی، نیازهای ذخیره سازی.
• رسانه ها و موتورها را در هر لایه انتخاب کنید (NVMe/SSD/HDD/Object/Archive).
• زمان طراحی/پارتیشن کلید، شاخص، و فرمت (پارکت/ORC/دلتا).
• تعریف قوانین ILM (رول اور/انتقال/منقضی) و به صورت خودکار.
• فعال کردن فشرده سازی/برنامه نویسی (ZSTD/LZ4 ؛ سرد - قوی تر)
• روش های تکرار/RPO/RTO و DR را تعریف کنید.
• پیکربندی سلسله مراتب کش و پین برای تجمعات داغ.
• معیارهای هزینه/تأخیر و هشدارهای ردیف.
• سیاست های امنیتی (KMS، حفظ قانونی، انزوای جغرافیایی).
• به طور منظم آستانه انتقال (فصلی، رشد) را بررسی کنید.

14) سوالات متداول

س: چگونه مرزهای بین گرم و گرم را تعریف می کنید ؟

A: با توجه به توزیع واقعی درخواست: «مجموعه کار گرم» = 5-20٪ از کلید/احزاب بالا، ارائه 80-95٪ از درخواست. تنها چیزی که شکست می خورد یک نامزد گرم است.

س: آیا می توانم به طور مستقیم از سرما بخوانم ؟

A: بله، اما SLA ها را زیر دقیقه/ساعت و هزینه خروج برنامه ریزی کنید. اغلب سودآور است که یک قطعه را قبل از تجزیه و تحلیل به گرم (مرحله بندی) بازگردانیم.

س: چه چیزی را برای تجزیه و تحلیل 30-180 روز انتخاب کنید ؟

A: فرمت های ستون (Parquet/ORC) در موتور پرس و جو + (Trino/Presto/ClickHouse) با کش ؛ indexes/skip-data برای ذخیره IO.

س: چگونه برای جلوگیری از «طوفان گرم شدن» در هنگام resampling از سرد ؟

A: استفاده از prefetch/prepare-jobs، درخواست محدود، shardy زمان، درخواست-coalescing و پین کش در گرم است.

15) مجموع

معماری Hot/Warm/Cold هزینه ای است که با مشخصات دسترسی به همراه مدیریت چرخه عمر خودکار مطابقت دارد. پاک کردن SLO ها توسط لایه، پارتیشن بندی و ILM، تکرار منطقی و سلسله مراتب حافظه پنهان، «سریع»، «گرم» مقرون به صرفه و «سرد» ارزان و امن است.