गर्म/गर्म/ठंडे वाल्ट

1) हॉट/वार्म/कोल्ड द्वारा डेटा क्यों विभाजित करें

• अनुकूलित लागत: केवल गर्म वर्कसेट के लिए तेज और महंगी परत।
• एसएलओ के साथ अनुपालन करें: ऑनलाइन के लिए p95/थ्रूपुट, इतिहास के लिए लंबी समय सीमा।
• स्केलिंग को सरल करें: क्षैतिज रूप से "फ्रंट" को गर्म किए बिना सस्ती परतों का निर्माण करें।
• जोखिम कम करें: विभिन्न विफलता/प्रतिकृति डोमेन, स्वतंत्र सुरक्षा नीतियां।

• गर्म - सबसे हालिया, अक्सर पढ़ ने/लिखने, न्यूनतम विलंबता।
• गर्म - कम बार बदलता है, समय के साथ बहुत अधिक पढ़ ता है।
• शीत - संग्रह, सस्ता भंडारण, उच्च टीटीएफबी, धीमी गति से वसूली।

2) स्तर द्वारा प्रोफाइल और एसएलओ

गर्म

पहुंच: मिलीसेकंड (KV/indexes पर p95 ≤ 5-20 ms; जटिल प्रश्नों पर ≤ 100-300 ms)।

संचालन: अक्सर अपसर्ट/एपेंड, इंडेक्सिंग, OLTP/स्ट्रीम-इनगेस्ट।

मीडिया: एनवीएमई/एसएसडी, मेमोरी, फास्ट नेटवर्क।

प्रतिकृति: वृद्धि (जैसे) RF = 3) RPO≈0 के लिए, आरटीओ मिनट।

गर्म

पहुंच: मिलीसेकंड/सेकंड के सैकड़ों के लिए दसियों।

संचालन: "विंडो", कसाई पढ़ ना, ताजा इतिहास पर OLAP (7-90 दिन)।

मीडिया: स्थानीय कैश के साथ SATA SSD/फास्ट HDD/ऑब्जेक्ट स्टोरेज।

प्रतिकृति: मध्यम (RF = 2), संपीड़न सक्षम।

ठंड

पहुंच: सेकंड-घंटे; लगातार ऑफ़ लाइन एक्सेस, "पुनः प्राप्त करें और स्कैन करें।"

संचालन: दुर्लभ रीडिंग, विनियमन का अनुपालन (वर्षों से प्रतिधारण)।

मीडिया: ऑब्जेक्ट/आर्काइव (एस 3 ग्लेशियर/डीप आर्काइव, एज़्योर आर्काइव, जीसीएस कोल्डलाइन)।

प्रतिकृति: क्षेत्रीय/अंतर्क्षेत्रीय, WORM/कानूनी पकड़।

3) परत द्वारा विशिष्ट तकनीक

गर्म: PostgreSQL (OLTP, विभाजन), MySQL/InnoDB, Redis/Memcacted ( ), Elasticsearch/Opensearch हॉट-नोड्स, Clickhoure, ka स्थानीय लॉग।

वार्म: क्लिकहाउस कॉलम स्टोरेज, BigQuery/Snowflake हालिया पार्टियां, Elasticsearch warm-nodes, 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 (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": {} } }
}
}
}

एस 3 लाइफसाइकिल (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 }
}]
}

काफ्का टायर्ड स्टोरेज (स्केच)

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 = CapEx/OpEx मीडिया + नेटवर्क (egress) + CPU के लिए संपीड़न/स्कैन + प्रबंधन + DR/प्रतिकृति'।

5. 2 विलंबता और कीमत का संतुलन

एक गर्म सेट ≈ 5-20% डेटा 80-95% प्रश्नों की पैदावार करता है।

लक्ष्य हॉट/कैश (CPU/RAM/NVMe) में वर्किंग सेट रखना है, बाकी को वार्म/कोल्ड में स्थानांतरित करना है।

5. 3 मेट्रिक्स

, , , , , ( ), ( )।

6) विभाजन, अनुक्रमण और कैशिंग

"ताजा" स्लाइस के लिए समय विभाजन + द्वितीयक सूचकांक।

अनुरोधों का सुनहरा नियम: पहले समय से फ़िल्टर करें, फिर चयनात्मक कुंजी।

पदानुक्रमित कैश: इन-प्रोक → रेडिस → एज; हॉट कीज ़/एग्रीगेट्स के लिए पिन कैश।

गर्म/ठंडा होने के लिए रीड को कम करने के लिए ब्लूम फिल्टर/स्किप इंडेक्स (क्लिकहाउस, पर्केट)।

7) प्रतिकृति, दोष सहिष्णुता और डीआर

हॉट: सिंक्रोनस प्रतिकृति (मल्टी-ज़ोन), RPO≈0, फास्ट फीलओवर।

गर्म: अतुल्यकालिक इंटरजोन/अंतर प्रतिकृति; RPO मिनट।

ठंड: WORM के साथ परस्पर क्रियाशील (एक बार कई पढ़ें), अनुपालन के लिए कानूनी पकड़।

डीआर-प्लान: "कोल्ड" अभिलेखागार (घंटे), आवधिक फायर-ड्रिल की बहाली के लिए रन-बुक।

8) सुरक्षा और अनुपालन

PII/PCI: आराम (KMS) पर एन्क्रिप्शन, प्रत्येक चरण में प्रमुख नीतियां, नीचे जाते समय मास्किंग।

प्रतिधारण और हटाना: ठंड के लिए स्वचालित समय सीमा, सिद्ध करने योग्य मिटाना (रिपोर्ट मिटाना)।

क्षेत्राधिकार: क्षेत्र में भंडारण (यूरोपीय संघ-केवल, आरयू-केवल, बीवाई-क्षेत्र, आदि), बाल्टी का भू-अलगाव।

9) उपयोग पैटर्न

9. 1 लॉग और टेलीमेट्री

हॉट: NVMe पर Elasticsearch/ClickHouse में अंतिम 24-72 h।

गर्म: SSD/HDD + Parquet पर S3 में 30-180 दिन।

ठंड: > ग्लेशियर में 180 दिन; ट्रिनो/प्रेस्टो के माध्यम से अनुरोध "मांग पर।"

9. 2 लेनदेन/आदेश

हॉट: OLTP डेटाबेस (PostgreSQL/MySQL) एक छोटा इतिहास के साथ।

गर्म: BI के लिए खंडित स्नैपशॉट।

ठंडा: कानूनी संग्रह, वस्तु भंडारण के लिए निर्यात।

9. 3 एमएल-काल्पनिक

हॉट: Redis/लो-लेटेंसी DB में ऑनलाइन फीचर्स।

गर्म: स्तंभ/वस्तु में ऑफ़ लाइन सुविधाएँ.

ठंड: स्रोत डेटासेट, बहुमुखी (डेल्टा/आइसबर्ग/हुडी)।

10) समूहों और कुबर्नेट्स के साथ बातचीत

टियर द्वारा मार्क स्टोरेज क्लास: 'गोल्ड-एनवीएम' (गर्म), 'सिल्वर-एसएसडी' (गर्म), 'कांस्य-वस्तु' (ठंडा)।

गर्म/गर्म/ठंडी कार्यशालाओं के लिए योजना पूल नोड्स (दाब/लेबल)।

सिडकार कैश (उदाहरण के लिए, स्थानीय एसएसडी कैश) वस्तु भंडारण के अनुरोध से पहले।

पीवीसी का उदाहरण

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

11) अवलोकन क्षमता

डैशबोर्ड: टियर द्वारा बाइट्स/अनुरोधों का वितरण, प्रति टियर विलंबता, गर्म/ठंडा करने के लिए ऑफलोड, लागत/महीना।

अलर्ट: हिट-अनुपात गर्म में कमी, पदोन्नति-दर में वृद्धि (पर्याप्त गर्म मात्रा में), गर्म द्वारा टीटीएफबी में वृद्धि, ठंड की धीमी वसूली (एसएलओ उल्लंघन)।

12) एंटी-पैटर्न

"सभी गर्म में": अत्यधिक लागत, आईओ ओवरहीटिंग।

"इंडेक्स के बिना गहरी ठंड": स्टोर करने के लिए सस्ता, पढ़ ने के लिए महंगा; कोई तेजी से टुकड़ा रास्ता नहीं।

"नो आईएलएम": मैनुअल ट्रांसफर, मानव त्रुटियां।

सभी स्तरों के लिए "समान प्रतिकृति नीति": ओवरपेमेंट और असमान आरपीओ।

एक गणना पूल में प्रोड/आर्काइव क्वेरी मिलाएं - हस्तक्षेप।

ठंडे बादलों से "बेहिसाब अहंकार": बिल में आश्चर्य।

13) कार्यान्वयन चेकलिस्ट

• डेटा सेट वर्गीकृत करें: एसएलए, अभिगम आवृत्ति, भंडारण आवश्यकताएं।
• प्रति परत मीडिया और इंजन का चयन करें (एनवीएमई/एसएसडी/एचडीडी/ऑब्जेक्ट/आर्काइव)।
• डिजाइन समय/कुंजी विभाजन, सूचकांक और प्रारूप (Parquet/ORC/Delta)।
• ILM नियमों (रोलओवर/संक्रमण/समाप्ति) को परिभाषित करें और स्वचालित करें।
• संपीड़न/कोडिंग सक्षम करें (ZSTD/LZ4; ठंड में मजबूत)।
• प्रतिकृति/आरपीओ/आरटीओ और डीआर प्रक्रियाओं को परिभाषित करें।
• गर्म समुच्चय के लिए कैश पदानुक्रम और पिन कॉन्फ़िगर करें।
• लागत/विलंबता मेट्रिक्स और टियर अलर्ट।
• सुरक्षा नीतियां (केएमएस, कानूनी प्रतिधारण, भू-अलगाव)।
• नियमित रूप से स्थानांतरण थ्रेसहोल्ड (मौसमी, विकास) की समीक्षा करें।

14) एफएक्यू

प्रश्न: आप गर्म और गर्म के बीच की सीमाओं को कैसे परिभाषित करते हैं?

A: अनुरोधों के वास्तविक वितरण के अनुसार: "हॉट वर्किंग सेट" = शीर्ष 5-20% कुंजी/पार्टियां, 80-95% अनुरोध प्रदान करती हैं। जो कुछ भी विफल होता है वह एक गर्म उम्मीदवार होता

प्रश्न: क्या मैं सीधे ठंड से पढ़ सकता हूं?

A: हाँ, लेकिन मिनटों/घंटों और लागत के तहत SLA की योजना बनाएं; विश्लेषण से पहले गर्म (मंचन) के लिए एक टुकड़े को वापस करना अधिक लाभदायक होता है।

प्रश्न: एनालिटिक्स के लिए 30-180 दिन क्या चुनें?

A: कैश के साथ ऑब्जेक्ट + क्वेरी इंजन (ट्रिनो/प्रेस्टो/क्लिकहाउस) पर स्तंभ प्रारूप (Parquet/ORC); IO को बचाने के लिए सूचकांक/स्किप-डेटा।

प्रश्न: ठंड से फिर से जुड़ ने पर "वार्म-अप तूफान" से कैसे बचें?

A: गर्म पर प्रीफेच/तैयार-नौकरियों, सीमा अनुरोधों, समय शार्डी, अनुरोध-सहवास और पिन कैश का उपयोग करें।

15) कुल

हॉट/वार्म/कोल्ड आर्किटेक्चर एक्सेस प्रोफाइल और स्वचालित जीवनचक्र प्रबंधन से मेल खाता है। परत, विभाजन और आईएलएम द्वारा साफ एसएलओ, उचित प्रतिकृति और कैश पदानुक्रम "गर्म" तेज, "गर्म" सस्ती, और "ठंडा" सस्ता और सुरक्षित रखते हैं।