Skip to main content

> aşırı_yüklü_partition_(hot_partition)_çözümü:_tuzlanmış_anahtarlar_(salted_keys)_ve_sentetik_dağıtım

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

Ünlü bir kullanıcı tek bir partition anahtarına saniyede 100.000 yazma ürettiğinde standart tutarlı hash (consistent hashing) neden çöker ve tuzlanmış anahtarlar (salted keys) yazma yükünü kümedeki sunuculara nasıl dağıtır?

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

1. Temel Çalışma Mekanizması

Anahtar tuzlama mimarisi 2 temel stratejiyle çalışır: (1) 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. (2) 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

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ı

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

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

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)

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 Örneği)

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
Q1

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.
Q2

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