Aşırı Yüklü Partition (Hot Partition) Çözümü: Tuzlanmış Anahtarlar (Salted Keys) ve Sentetik Dağıtım

Senior (L5)

⚡ÖZET VE TEKNİK CEVAP

Dağıtık veritabanlarında (DynamoDB, Cassandra, Kafka) veriler bir partition anahtarının hash'ine göre bölünür (partition_key = user_id). Normal şartlarda bu yükü 50 sunucuya eşit dağıtır. Ancak viral bir olayda (ör. 500.000 kullanıcının aynı anda unlu_post_99 gönderisine yorum yapması), tüm isteklerin hash'i TAM OLARAK AYNI sunucuya düşer. Kümedeki 49 sunucu %2 CPU ile boşta yatarken, o tek sunucu %100 CPU ve disk kilitlenmesiyle çöker ('Hot Partition Problemi'). Kesin çözüm Partition Anahtarlarını Tuzlamaktır (Salting): Uygulama anahtarın sonuna rastgele veya deterministik bir ek (unlu_post_99_0, unlu_post_99_1, ..., unlu_post_99_9) ekleyerek yazma yükünü 10 farklı fiziksel sunucuya dağıtır. Okuma yapılırken bu 10 tuzlu anahtar aynı anda paralel sorgulanıp (fan-out) sonuçlar birleştirilir.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Anahtar tuzlama mimarisi 2 temel stratejiyle çalışır:

Yüksek Hacimli Yazma İçin Rastgele Tuzlama: Uygulama tuzlu_anahtar = ana_anahtar + '_' + rand(0, N-1) formülünü işletir (N=20). Yazmalar 20 farklı sunucuya mükemmel yayılır. Okuma yapılırken 20 sunucuya paralel sorgu atılıp sonuçlar birleştirilir.

Deterministik Hesaplanmış Tuzlama: Tuz eki ikincil bir alandan türetilir (tuzlu_anahtar = ana_anahtar + '_' + (hash(izleyici_id) % N)); böylece belirli bir okuma sorgusu tek bir hedeflenmiş shard'dan çekilebilir ve çoklu sorgu maliyeti önlenir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Viral sosyal medya gönderileri, canlı yayın telemetri verileri, dev sensör akışları, dağıtık sayaçlar ve DynamoDB/Cassandra sıcak anahtar optimizasyonu.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Az trafikli anahtarlarda bile N=1.000 gibi devasa tuzlama çarpanları kullanıp okuma sırasında istemcinin 1.000 paralel istek atarak kendi thread'lerini kilitlemesi
✓
partition anahtarını status = 'ACTIVE' veya ulke = 'TR' gibi az değişkenli alanlar seçip kümenin %90 yükünü tek bir sunucuya yıkmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
DynamoDB'de genel kapasite aşılmamışken tek bir partition'da ProvisionedThroughputExceededException alarmlarının patlaması
✓
Cassandra kümesinde diğer sunucular boştayken tek bir sunucunun CPU'sunun %100'e kilitlenmesi

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Yüksek çeşitliliğe sahip birleşik anahtarlar (tenant_id#user_id#timestamp) kullanın
✓
anahtar tuzlamayı sadece aşırı ısınan popüler anahtarlara dinamik olarak uygulayın
✓
okumalarda Go errgroup ile paralel sorgu atıp sonuçları zaman aşımlı birleştirin

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Anahtar tuzlama viral sıcak anahtarlarda sınırsız doğrusal yazma kapasitesi sunar; ancak okuma yapan istemcilerin N adet shard'a paralel sorgu atıp sonuçları birleştirmesini gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir canlı oylama uygulaması, televizyon finalinde saniyede 200.000 oy poll_id = 'final_2026' anahtarına yazıldığı için kilitlendi. DynamoDB tek bir partition'da 1.000 yazma sınırına takıldığı için oyların %85'ini reddetti. Ekip 200 sanal shard'lı rastgele tuzlama (final_2026_0 ... final_2026_199) getirdi. 200.000 yazma sıfır takılmayla 200 partition'a pürüzsüz dağıldı; oy sayımı ise 200 parçanın toplanmasıyla 35 milisaniyede tamamlandı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Dağıtık NoSQL veritabanlarında 'Hot Partition Problemi' nedir?

Aşırı miktarda trafiğin tek bir partition anahtarına (ör. viral bir paylaşım) yüklenmesi ve diğer sunucular boştayken o tek sunucunun kilitlenip istekleri reddetmesidir.

Anahtar Tuzlama (Key Salting) sıcak partition yazma darboğazını nasıl çözer?

Anahtarın sonuna rastgele bir ek (`key_0`, `key_1`, ..., `key_N`) koyarak yazmaları $N$ farklı sunucuya dağıtır ve yazma kapasitesini $N$ katına çıkarır.

Aşırı Yüklü Partition (Hot Partition) Çözümü: Tuzlanmış Anahtarlar (Salted Keys) ve Sentetik Dağıtım — Sıkça Sorulan Sorular

$N$ adet shard'a tuzlanarak yazılmış bir veriyi nasıl okursunuz?

Paralel Scatter-Gather (Dağıt-Topla) kalıbıyla: İstemci $N$ adet tuzlu anahtara aynı anda paralel sorgu atar ve gelen sonuçları bellekte birleştirip sıralar.

Yüksek hacimli bir sistemde ideal tuzlama boyutu ($N$) kaçtır?

Genellikle $N=10$ ila $N=50$ arası. Aşırı büyük tuzlama değerleri ($N=1.000$) okuma sırasında çok fazla paralel istek yükü ve gecikme yaratır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
Hot partitions occur when viral keys concentrate massive load onto a single database node.
▸
Consistent hashing fails when millions of writes share the exact same key.
▸
Salting appends a suffix (key_0..key_N) to spread writes across N physical shards.
▸
Read queries execute parallel scatter-gather requests across all N salted keys.

Yaygın Yanılgılar

✗
Yanılgı: Provisioning more database capacity fixes hot partitions (Gerçek: Capacity is divided per partition; a single hot partition hits the same single-node limit).
✗
Yanılgı: Salting should be applied to every single table key (Gerçek: Apply salting selectively to high-throughput viral entities).

Karar Kılavuzu & Önceliklendirme

Use high-cardinality composite partition keys for default database schema design. Implement random key salting (N=10 ext{--}50) on ultra-hot viral entities with scatter-gather reads.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]AWS DynamoDB Best Practices: Designing Partition Keys to Distribute Workloads Evenly— Amazon Web Services (AWS Architecture Guide)