DynamoDB Kısıtlaması (Throttling) — Neden Olur ve Nasıl Düzeltilir

Kısıtlama, DynamoDB'nin size bir sınıra çarpıldığını söylemesidir — ama dört farklı sınır, üç farklı exception vardır ve bir sebep için işe yarayan çözüm bir diğerini kötüleştirir. Tablo kapasitesini artırmak sıcak bir anahtar için hiçbir şey yapmaz; on-demand'e geçmek de sıcak bir anahtar için hiçbir şey yapmaz ve kendi kurallarıyla yine kısıtlayabilir. Bu rehber şemsiyedir: gerçekte hangi sınıra çarptığınız, metriklerin bunları nasıl ayırt ettiği ve her sebebe uyan çözüm.

DynamoDB isteklerimi neden kısıtlıyor?

Belgelenmiş dört sebepten biri: tek bir bölüm, saniyede 3.000 okuma birimi ya da 1.000 yazma birimlik sabit bölüm başına sınırını aştı (sıcak bir anahtar — her iki kapasite modunda da olur); tablo, provisioned RCU/WCU'sunu aştı (Provisioned mod); hesap, bölge düzeyindeki verimlilik kotasını aştı; ya da bir on-demand tablo 30 dakika içinde önceki zirvesinin iki katından daha hızlı büyüdü. Çözüm hangisi olduğuna bağlıdır, bu yüzden herhangi bir şeyi yeniden boyutlandırmadan önce teşhis edin.

Dört kısıtlama senaryosu

AWS'nin kendi sorun giderme sayfası kısıtlamayı tam olarak dört duruma ayırır:

Anahtar aralığı (bölüm) verimliliği aşıldı — her iki mod. Her bölüm, saniyede 3.000 okuma birimi ve 1.000 yazma birimi maksimumu için tasarlanmıştır (bölüm anahtarı belgeleri) ve item boyutu da buna sayılır. Hiçbir tablo düzeyi ayar bunu yükseltmez; onu yalnızca anahtar tasarımı yayar. Bu, sıcak bölüm durumudur ve tablo kısıtlanırken devasa ölçüde az kullanılmış görünebilir.
Provisioned verimlilik aşıldı — Provisioned mod. Tüketim, tablonun (ya da bir GSI'nin) provisioned RCU/WCU'sunu geçti ve ~5 dakikalık burst kapasitesi yastığı tükendi. Çözüm merdiveni kapasite tarafındadır: otomatik ölçekleme, daha yüksek bir provision ya da bir mod değişimi.
Hesap düzeyi kota aşıldı. Bölgesel hesap kotaları toplam verimliliği sınırlar — varsayılan olarak tablo başına 40.000 okuma ve 40.000 yazma birimi, Provisioned mod için de hesap başına 80.000 RCU ve 80.000 WCU (kotalar); bunlar başlangıç varsayılanlarıdır, Service Quotas üzerinden ayarlanabilir ve on-demand tabloların hesap düzeyinde verimlilik kotası yoktur.
On-demand maksimum verimlilik aşıldı. On-demand, önceki zirvenin iki katına kadar olanı anında karşılar; 30 dakika içinde iki katının ötesine büyüyün, kısıtlayabilir (on-demand belgeleri). Yeni on-demand tablolar kutudan çıktığı gibi saniyede 4.000 yazma ve 12.000 okumayı sürdürür. Planlı bir basamak artışı için (lansman, indirim, migrasyon), rampanın kademeli olmasını ummak yerine tabloyu warm throughput ile önceden ısıtın.

Üç exception ve sebebi adlandıran alan

ProvisionedThroughputExceededException — Provisioned mod kapasite kısıtlaması: "bir tablo ya da bir veya daha fazla global secondary index için izin verilen maksimum provisioned verimliliğinizi aştınız". Ayrıntılar özel hata sayfasında.
ThrottlingException — çok hızlı yayınlanan control-plane işlemleri ve on-demand tablolarda hızı çok yüksek olan herhangi bir data-plane işlemi (iki-kat-zirve kuralının ardındaki exception budur — bkz. on-demand hata sayfası ve ThrottlingException).
RequestLimitExceeded — hesap düzeyi verimlilik sınırları: "AWS Support ile iletişime geçin" bölgesi, kendi hata sayfasında ele alınıyor.

Üçü de retryable olarak işaretlidir ve üçü de artık kaynak + işlem + sınır biçiminde yapılandırılmış ThrottlingReason değerleri taşır — TableReadProvisionedThroughputExceeded, IndexWriteKeyRangeThroughputExceeded, TableWriteAccountLimitExceeded ve benzeri (hata referansı). Yalnızca exception sınıfını değil, reason'ı okuyun: kaynağı (tablo ya da index), işlem yönünü ve dört sınırdan hangisine çarptığınızı adlandırır — teşhisin ta kendisi budur. Belgelerin kendisinin dayattığı bir çekince: AWS sayfaları, hesap sınırı kısıtlamasının RequestLimitExceeded olarak mı yoksa AccountLimitExceeded reason'lı bir ThrottlingException olarak mı yüzeye çıktığı konusunda ayrışıyor, bu yüzden işleyişinizi reason dizesine göre kurun.

Kısıtlanmadan önce yükü ne emer

İki yerleşik mekanizma sınırları yumuşatır ve kenarlarını bilmek "dün çalışıyordu"yu açıklar:

Burst kapasitesi, ani artışlar için kullanılmamış okuma ve yazma kapasitesinin beş dakikasına (300 saniye) kadarını saklar — ama DynamoDB bunu "önceden haber vermeksizin" arka plan bakımı için de tüketebilir ve AWS ayrıntıların değişebileceğini açıkça belirtir. Burst'e göre tasarım yapmayın; onu şans olarak görün.
Uyarlanabilir kapasite verimliliği otomatik ve anında sıcak bölümlere doğru kaydırır ve sık erişilen bir item'ı kendi bölümüne izole edebilir — ama yalnızca "trafiğin tablonuzun toplam provisioned kapasitesini ya da bölüm maksimum kapasitesini aşmaması koşuluyla". Çarpıklığı yeniden dengeler; bölüm başına 3.000/1.000 tavanını asla kaldırmaz ve tablonun bir LSI'si olduğunda item koleksiyonlarını bölmez. Güncel AWS sorun giderme sayfaları split-for-heat'e — sürekli ısı altında bölümlerin bölünmesine — yaslanır, ki bu zaman alır ve tek bir sıcak anahtara yardım etmez.

Metriklerden teşhis edin

CloudWatch istekleri olaylardan ayırır ve teşhisi bu ayrım yapar (metrik referansı):

ThrottledRequests, içindeki herhangi bir olay kısıtlandıysa bir isteği bir kez sayar — üç GSI'li bir tabloda bir PutItem tek bir istektir ama dört yazma olayıdır. Bir batch'te yalnızca her item kısıtlanırsa artar.
ReadThrottleEvents / WriteThrottleEvents kısıtlanan her olayı sayar — 10 item'lık bir BatchGetItem 10 GetItem olayıdır. Bir GSI'nin yazma kısıtlamalarını görmek için metriği hem TableName hem de GlobalSecondaryIndexName ile sorgulamanız gerekir — GSI back-pressure tablo düzeyi panolardan böyle saklanır.
Daha yeni sebebe özgü olay metrikleri (WriteProvisionedThroughputThrottleEvents, ReadKeyRangeThroughputThrottleEvents, …AccountLimitThrottleEvents, …MaxOnDemandThroughputThrottleEvents) sayımları aynı dört sebebe göre ayırır — bölgeniz bunları gösteriyorsa "hangi sınır" sorusunu doğrudan yanıtlarlar.

Bir tuzak: SDK'lar kısıtlanan istekleri otomatik olarak yeniden dener — standart yeniden deneme modu varsayılan olarak toplam 3 deneme yapar (2026 opt-in yeniden deneme dağıtımı, DynamoDB istemcilerini daha sıkı gecikmelerle 4 denemeye taşır). Dolayısıyla hafif kısıtlama hata olarak değil gecikme olarak görünür; yalnızca exception loglarınızı değil, kısıtlama metriklerini izleyin.

GSI back-pressure: yanlış tabloyu gösteren kısıtlama

Herhangi bir GSI yazma amplifikasyonunu ememezse, "DynamoDB veri tutarlılığını korumak için temel tabloya yapılan yazmaları kısıtlar" (GSI kısıtlama belgeleri) — temel tablonun ayıracak kapasitesi olsa bile. Exception'ın ResourceArn'ı index'i gösterir, ama başarısız olan işlem sizin temel tablo yazmanızdır. Her index'in kendi kapasite planına (ve kendi otomatik ölçekleme politikasına) ihtiyacı vardır; bir GSI temel tablo yazmalarını neden kısıtlar mekaniği adım adım anlatır.

Çözümü sebeple eşleştirin

Sebep	Ne düzeltir	Ne düzeltmez
Sıcak anahtar / bölüm	Yükü yayan anahtar tasarımı (sıcak bölümler); split-for-heat için zaman	Tablo kapasitesini artırmak, on-demand'e geçmek
Provisioned kapasite	Otomatik ölçekleme, daha yüksek bir minimum ya da on-demand	Tek başına yeniden denemeler — yük eklerler
GSI back-pressure	Index'i ölçekleyin; sparse index ya da projeksiyon değişiklikleri	Temel tabloyu ölçeklemek
Hesap kotası	Service Quotas artışı	Tablo düzeyi ayarlar
On-demand basamak artışı	Önceden ısıtma (warm throughput); rampayı 30+ dakikaya yayın	Beklemek — iki-kat-zirve yavaş sıfırlanır

DynoTable'da yapın

Kendi kendine yol açılan kısıtlamanın çoğu, göründüğünden pahalıya mal olan okumalarla başlar: filtrelenmiş bir Scan okumanın tamamını her hâlükârda tüketir. DynoTable'ın çalıştırma öncesi maliyet önizlemesi, bir ifadenin Query mi yoksa Scan mi olduğunu, hangi index'e çarptığını ve harcamadan önce tahmini bir okuma maliyetini gösterir — en ucuz kısıtlama çözümü, çalıştırmadığınız pahalı okumadır. Scan ile Query rehberi farkı kapsar; ücretsiz item boyutu hesaplayıcısı gerçek bir item'ı, yukarıdaki sınırların ölçüldüğü RCU/WCU rakamlarına çevirir.

Tuzaklar ve sonraki adımlar

Yeniden denemeler aşırı yükü büyütür. Backoff SDK'lara yerleşiktir, ama SDK yeniden denemelerinin üzerine binen sıkı bir uygulama düzeyi yeniden deneme döngüsü, tam da zorlanan bölümün üzerindeki baskıyı katlar.
Batch'ler kısmi kısıtlamayı gizler. Bir BatchWriteItem, herhangi bir item başarılı olduğu sürece hata fırlatmak yerine işlenmemiş item'ları döndürür — yalnızca exception'lara değil, UnprocessedItems'a bakın.
Tablo düzeyi görünüm GSI'ler hakkında yalan söyler. Kısıtlama olaylarını her zaman index başına grafikleyin; back-pressure sırasında temel tablo panoları temiz görünür.
Kapasite çözümleri dakikalar alır; anahtar tasarımı kalıcıdır. Otomatik ölçekleme ~5 dakikada tepki verir, kota artışları bir destek talebi gerektirir, ama sıcak bir anahtar sizi her kapasite moduna kadar takip eder — emeği katlanarak karşılığını verdiği yere harcayın: bölüm anahtarları nasıl çalışır.

Her sorgunun Scan-Query planını ve okuma maliyetini kapasitenize karşı çalışmadan önce görmek için DynoTable'ı indirin.