DynamoDB throttled on a hot partition despite capacity
TL;DR — Tablonuzun genel olarak bol miktarda kullanılmamış RCU/WCU'su var ama yine de kısıtlanıyorsunuz çünkü tek bir bölüm anahtarı sıcak. Her fiziksel bölüm, tablonun ne kadar kapasitesi olursa olsun, saniyede en fazla 3.000 okuma birimi ve 1.000 yazma birimi sunacak şekilde tasarlanmıştır. Tek bir anahtara yığılan trafik o tek bölümü tüketir. Onu düzeltmek için istekleri daha fazla ayrı bölüm anahtarına yayın (yazma parçalama).
Ne anlama gelir
ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.
# ...yet CloudWatch shows consumed capacity well below provisioned.DynamoDB bir tabloyu birçok fiziksel bölüme yayar ve bir tablonun kapasitesi onlar arasında bölünür. Tek bir bölüm, her iki kapasite modunda da saniyede en fazla 3.000 okuma birimi ve 1.000 yazma birimi sunacak şekilde tasarlanmıştır. Erişim deseniniz trafiği bir bölüm anahtarında yoğunlaştırırsa, o anahtarın bölümü kendi tavanına çarpar ve kısıtlar — tablo geneli metrikler az kullanılmış görünse bile (hatanın ThrottlingReason alanları, örneğin TableReadKeyRangeThroughputExceeded, çarpılan tam sınırı adlandırır). Uyarlanabilir kapasite yardımcı olur, ama gerçekten dengesiz bir anahtarı kurtaramaz.
Neden olur
- Düşük kardinaliteli bölüm anahtarı — bir durum bayrağı, bir boolean, bir "geçerli tarih" ya da çoğu trafiği alan tek bir kiracı.
- Viral / ünlü bir öğe — popüler bir bölüm anahtarı (trend olan bir ürün, sıcak bir kullanıcı) orantısız yük çeker.
- "Bugün" anahtarlı zaman serisi — her yazma aynı tarih tabanlı bölüm anahtarına iner.
- Yazmaların en yeni bölümde kümelenmesine yol açan sıralı veya monoton bir anahtar.
- Temel tablonun yazmalarını kısıtlayan, düşük kardinaliteli bölüm anahtarlı bir GSI.
Nasıl düzeltilir
- Anahtar kardinalitesini artırın. Bölüm anahtarını, istekler birçok değere yayılacak şekilde tasarlayın — bu en etkili tek çözümdür.
- Sıcak anahtarı yazma-parçalayın. Bir sonek ekleyin (
USER#42#1…USER#42#N), böylece bir mantıksal varlık birden çok bölüme yayılsın; okumaları parçalara dağıtın. - Zaman serisi anahtarlarına rastgelelik ya da hesaplanmış bir sonek ekleyin, böylece "bugünün" yazmaları hepsi çakışmasın.
- Sıcak bölümden okuma baskısını azaltmak için sıcak okumaları önbelleğe alın (DAX ya da bir uygulama önbelleği).
- Üstel geri çekilme yeniden denemelerini koruyun — bu hata yeniden denenebilirdir ve SDK varsayılan olarak geri çekilir.
- Düşük kardinaliteli GSI anahtarlarını düzeltin — kısıtlanan bir GSI temel tabloyu kısıtlar.
Yeniden tasarlarken anahtar dağılımını incelemek ister misiniz? DynoTable masaüstü uygulaması, bölüm anahtarına göre filtrelemenize ve sıralamanıza olanak tanır, böylece aşırı yüklü bir anahtar, yeniden parçalamadan önce bellidir.
DynoTable'da boyutu kontrol edin
Sıcak bölüm anahtarını bulun — ⌘K ile tabloyu açın, bölüm anahtarına göre sıralayın ve komşularından çok daha fazla öğe taşıyan bir anahtar arayın. Bu anahtara göre filtreleyin ve yeniden parçalamadan önce yazma modellerini inceleyin.
Query Builder'da yazma-parçası son eklerini modelleyin ve pricing calculator ile yeniden deneme trafiğini tahmin edin. Profilleri ⌘P ile değiştirin; bkz. Connect to AWS ve Install.
Kaynaklar
- Best practices for designing partition keys (2026-07-13 tarihinde doğrulandı)
- Troubleshooting throttling in Amazon DynamoDB (2026-07-13 tarihinde doğrulandı)
SSS
Tablonun yedek kapasitesi varken DynamoDB beni neden kısıtlıyor? Çünkü tek bir bölüm anahtarı sıcak. Her fiziksel bölümün, tablo düzeyi kapasitesinden bağımsız olarak saniyede yaklaşık 3.000 okuma birimi ve 1.000 yazma birimi tavanı vardır, dolayısıyla tek bir anahtara yığılan trafik, tablo geneli metrikler az kullanılmış görünürken o tek bölümü tüketir.
DynamoDB'de sıcak bir bölümü nasıl düzeltirim? İstekler birçok değere yayılsın diye bölüm anahtarı kardinalitesini artırın, sıcak anahtarı bir sonekle yazma-parçalayın, zaman serisi anahtarlarına hesaplanmış bir sonek ekleyin ve sıcak okumaları önbelleğe alın. Üstel geri çekilme yeniden denemeleri kısa ani artışları atlatmaya yardımcı olur ama dengesiz bir anahtarı düzeltmez.
İlgili hatalar
- ProvisionedThroughputExceededException — genel kısıtlama hatası ve kapasite çözümleri.
- ThrottlingException — hesap/kontrol düzlemi hız sınırları.
- Öğrenin: Hot partitions · How partition keys work
Kaynaklar
- Best practices for designing and using partition keys effectively in DynamoDB — Amazon DynamoDB Developer Guide
- Using write sharding to distribute workloads evenly in your DynamoDB table — Amazon DynamoDB Developer Guide
- Troubleshooting throttling in Amazon DynamoDB — Amazon DynamoDB Developer Guide
- Error handling with DynamoDB — Amazon DynamoDB Developer Guide
En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.