Sıcak/Sıcak/Soğuk Tonozlar

1) Neden verileri Sıcak/Sıcak/Soğuk olarak bölün

• Maliyeti optimize edin: Yalnızca sıcak iş seti için hızlı ve pahalı katman.
• Çevrimiçi için SLO: p95/throughput, geçmiş için daha uzun son tarihler ile uyumludur.
• Ölçeklemeyi basitleştirin: yatay olarak "ön" aşırı ısınmadan ucuz katmanlar oluşturun.
• Riskleri azaltın: Farklı arıza/çoğaltma etki alanları, bağımsız koruma politikaları.

• Sıcak - en yeni, sık okuma/yazma, minimum gecikme.
• Sıcak - daha az sıklıkta değişir, zaman aralıklarında çok fazla okuma.
• Soğuk - arşiv, ucuz depolama, yüksek TTFB, yavaş kurtarma.

2) Seviyeye göre profiller ve SLO'lar

Sıcak

Erişim: milisaniye (KV/dizinlerde p95 ≤ 5-20 ms; karmaşık sorgularda ≤ 100-300 ms).
İşlemler: sık uppert/append, indeksleme, OLTP/stream-ingest.
Medya: NVMe/SSD, bellek, hızlı ağ.
Çoğaltma: artırılmış (örn. RF = 3) RPO≈0 için, RTO dakika.

Sıcak

Erişim: Onlarca ila yüzlerce milisaniye/saniye.
İşlemler: okuma "pencere", butches, taze geçmişi OLAP (7-90 gün).
Ortam: Yerel önbelleğe sahip SATA SSD/hızlı HDD/nesne depolama.
Çoğaltma: orta (RF = 2), sıkıştırma etkin.

Soğuk

Erişim: saniye-saat; Sık sık çevrimdışı erişim, "al ve tara".
Operasyonlar: nadir okumalar, düzenlemeye uygunluk (yıllara göre tutma).
Medya: nesne/arşiv (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
Çoğaltma: Bölgesel/Bölgelerarası, WORM/Yasal Bekletme.

3) Katmana göre tipik teknikler

Sıcak: PostgreSQL (OLTP, bölümler), MySQL/InnoDB, Redis/Memcached (кэш), Elasticsearch/Opensearch sıcak düğümleri, ClickHouse горячие партиции, Kafka yerel günlüğü.
Sıcak: ClickHouse sütun depolama, BigQuery/Snowflake son partiler, Elasticsearch sıcak düğümleri, S3 + Presto/Trino önbellekli, Katmanlı depolama (Kafka/Pulsar).
Cold: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, HDFS arşivi, uzun süreli yedeklemeler.

4) Yaşam Döngüsü Politikaları (ILM) ve Otomasyon

4. 1 Kavramlar

Zaman bölümleme (gün/hafta/ay) katmanlar arasındaki ana çeviri koludur.
ILM kuralları: rollover (hacme/yaşa göre), shrink/merge, freeze, delete.
Veri tekilleştirme ve sıkıştırma: sıcakta/soğukta etkinleştir, sıcakta CPU darboğazlarını önle.

4. 2 Örnekler

Elasticsearch ILM (sıcak, sıcak, soğuk, sil)

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 Yaşam Döngüsü (Standart, Seyrek, Buzul, Süresi dolmuş)

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

Kafka Katmanlı Depolama (eskiz)

properties log. segment. bytes=1073741824 log. retention. ms=259200000 tiered. storage. enable=true remote. log. storage. system=s3 remote. log. storage. bucket=topic-archive

Tarihe göre postgreSQL bölümleri

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) Maliyet ve performans modellemesi

5. 1 Basit TCO modeli

'TCO = CapEx/OpEx ortamı + ağ (çıkış) + sıkıştırma/taramalar için CPU + yönetim + DR/çoğaltma'.

5. 2 Gecikme ve fiyat dengesi

Verilerin %5-20'sini ≈ bir sıcak küme, sorguların %80-95'ini verir.
Amaç, çalışma kümesini Sıcak/önbellekte (CPU/RAM/NVMe) tutmak, gerisini Sıcak/Soğuk'a kaydırmaktır.

5. 3 Metrikler

, , , , , soğuk (sıcak), (sıcak).

6) Bölümleme, dizinleme ve önbelleğe alma

Zaman bölümleri + "taze" dilimler için ikincil indeksler.
İsteklerin altın kuralı: önce zamana göre filtrele, sonra seçici anahtarlar.
Hiyerarşik önbellek: in-proc - Redis - edge; Hot keys/aggregates için pin önbellekleri.
Bloom, okumaları sıcak/soğuk olarak azaltmak için indeksleri (ClickHouse, Parquet) filtreler/atlar.

7) Replikasyon, hata toleransı ve DR

Sıcak: senkron çoğaltma (çok bölgeli), RPO≈0, hızlı feilover.
Sıcak: Asenkron interzone/bölgelerarası çoğaltma; RPO dakikaları.
Soğuk: WORM (Write Once Read Many) ile bölgeler arası, Uyumluluk için Yasal Bekletme.
DR-planları: "soğuk" arşivlerin (saatler) restorasyonu için çalışma kitapları, periyodik yangın tatbikatları.

8) Güvenlik ve uyumluluk

PII/PCI: dinlenme sırasında şifreleme (KMS), her aşamada anahtar ilkeleri, aşağı doğru hareket ederken maskeleme.
Tutma ve kaldırma: Soğuk, kanıtlanabilir silme (raporları silme) için otomatik son tarihler.
Yargı bölgeleri: bölgede depolama (yalnızca AB, yalnızca RU, BY bölgesi vb.), Kovaların coğrafi izolasyonu.

9) Kullanım kalıpları

9. 1 Günlükler ve telemetri

Sıcak: NVMe'de Elasticsearch/ClickHouse'da son 24-72 saat.
Sıcak: S3'te SSD/HDD + Parkede 30-180 gün.
Soğuk:> Buzulda 180 gün; Talepler Trino/Presto aracılığıyla "talep üzerine".

9. 2 İşlemler/Siparişler

Sıcak: OLTP veritabanı (PostgreSQL/MySQL) kısa bir geçmişi ile.
Sıcak: BI için denormalize anlık görüntüler.
Soğuk: yasal arşiv, nesne depolamaya dışa aktarma.

9. 3 ML-ficestore

Sıcak: Redis/düşük gecikme DB çevrimiçi özellikler.
Sıcak: sütun/nesne içinde çevrimdışı özellikler.
Soğuk: kaynak veri kümeleri, sürüm (Delta/Iceberg/Hudi).

10) Kümeler ve Kubernetes ile etkileşim

Mark StorageClass'a göre katman: 'gold-nvme' (sıcak), 'silver-ssd' (sıcak), 'bronze-object' (soğuk).
Sıcak/sıcak/soğuk atölyeler için havuz düğümleri (karıncalar/etiketler) planlayın.
Nesne depolama isteğinden önce Sidecar önbellekleri (örneğin, yerel SSD önbelleği).

PVC örneği

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

11) Gözlemlenebilirlik

Panolar: baytların/isteklerin katmanlara göre dağılımı, katman başına gecikme, sıcak/soğuğa aktarım, maliyet/ay.
Uyarılar: sıcak isabet oranındaki azalma, promosyon oranındaki artış (yeterince sıcak hacim var mı), sıcak tarafından TTFB'de bir artış, soğuğun yavaş iyileşmesi (SLO ihlali).

12) Anti-desenler

"Hepsi sıcak": aşırı maliyet, IO aşırı ısınma.
"Endekssiz derin soğuk": saklanması ucuz, okunması pahalı; Hızlı dilim yolları yok.
"ILM yok": manuel transferler, insan hataları.
Her seviye için'tek tip çoğaltma politikası ": fazla ödeme ve eşit olmayan RPO'lar.
Prod/arşiv sorgularını bir hesaplama havuzunda karıştırın - girişim.
Soğuk bulutlardan "hesapsız çıkış": faturada sürprizler.

13) Uygulama kontrol listesi

• Veri kümelerini sınıflandırın: SLA, erişim frekansı, depolama gereksinimleri.
• Katman başına ortam ve motor seçin (NVMe/SSD/HDD/Nesne/Arşiv).
• Tasarım zamanı/anahtar bölümleri, indeksler ve formatlar (Parquet/ORC/Delta).
• ILM kurallarını tanımlayın (rollover/transition/expire) ve otomatikleştirin.
• Sıkıştırma/kodlamayı etkinleştir (ZSTD/LZ4; soğukta - daha güçlü).
• Çoğaltma/RPO/RTO ve DR prosedürlerini tanımlayın.
• Sıcak kümeler için önbellek hiyerarşisini ve pin'i yapılandırın.
• Maliyet/gecikme metrikleri ve katman uyarıları.
• Güvenlik politikaları (KMS, yasal saklama, coğrafi izolasyon).
• Transfer eşiklerini düzenli olarak gözden geçirin (mevsimsellik, büyüme).

14) SSS

S: Sıcak ve sıcak arasındaki sınırları nasıl tanımlarsınız?
C: Taleplerin gerçek dağılımlarına göre: "sıcak çalışma seti" = anahtarların/tarafların ilk %5-20'si, taleplerin %80-95'ini sağlar. Başarısız olan tek şey sıcak bir aday.

S: Doğrudan soğuktan okuyabilir miyim?
C: Evet, ancak SLA'ları dakikalar/saatler ve çıkış maliyeti altında planlayın; Analizden önce bir parçayı ısıtmak (evreleme) için geri göndermek daha kârlıdır.

S: 30-180 gün analitik için ne seçilir?
A: Nesne + sorgu motorunda (Trino/Presto/ClickHouse) önbellekli sütun formatları (Parke/ORC); IO kaydetmek için indeksler/atlama verileri.

S: Soğuktan yeniden örnekleme yaparken "ısınma fırtınaları" nasıl önlenir?
C: Prefetch/prepare-jobs, limit requests, time shardy, request-coalescing ve pin önbelleklerini sıcak olarak kullanın.

15) Toplam

Sıcak/Sıcak/Soğuk mimarisi, erişim profiline ve otomatik yaşam döngüsü yönetimine uygun maliyettir. Katman, bölümleme ve ILM, makul çoğaltma ve önbellek hiyerarşisine göre açık SLO'lar "sıcak" hızlı, "sıcak" uygun fiyatlı ve "soğuk" ucuz ve güvenli tutar.