DynamoDB'de bir GSI temel tablo yazmalarını neden kısıtlar

Tablonuza yazarsınız. Yazma bir verim istisnasıyla başarısız olur — ama istisna tabloyu değil, bir Global Secondary Index'i adlandırır. Tablonun yedek kapasitesi vardır.

SQL'den geliyorsanız bu saçmadır: bir ikincil indeks bir INSERT'ü engelleyemez. DynamoDB'de engelleyebilir ve mekanizmanın adı GSI geri basıncı (back-pressure)'dır.

Bir DynamoDB GSI'si temel tablo yazmalarını neden kısıtlar?

DynamoDB temel tablo yazmasını kısıtlar çünkü her yazma her GSI'ye de kopyalanır ve bir GSI bölümü kendi payını ememezse, DynamoDB indeksin kalıcı olarak geride kalmasını önlemek için geri basınç uygular. Yani yetersiz sağlanmış ya da düşük kardinaliteli bir GSI anahtarı, temel tablo yazma hızınız için katı bir tavana dönüşür.

• Temel tabloya bir yazma her GSI'ye de yazar. Bir GSI kendi payını ememezse, DynamoDB indeksin kalıcı olarak geride kalmasını önlemek için temel tablo yazmasını kısıtlar. (AWS belgeleri)
• Dengeli bir temel tablo sizi kurtarmaz. GSI kendi anahtarıyla bölümlenir. Düşük kardinaliteli bir GSI anahtarı (status gibi), temel tablo yazmaları kusursuzca yayılmış olsa bile sıcak bir indeks bölümü oluşturur.
• İstisna, kurban hakkında yalan söyler. ResourceArn GSI'yi gösterir; aslında kısıtlanan işlem tabloya yaptığınız yazmadır.
• Çözüm kapasite ya da anahtar tasarımıdır, yeniden deneme döngüleri değil — GSI verimini artırın ya da yayılan bir GSI bölüm anahtarı seçin.

Tek bir yazma indekse nasıl dokunur

Temel tabloda bir PutItem tek bir yazma değildir. DynamoDB, öğenin yansıtılmış (projected) niteliklerini her GSI'ye asenkron olarak, nihai tutarlı bir modelde kopyalar. Bir mantıksal yazma N fiziksel yazmaya açılır — tablo artı her indeks.

Bu kopyalama ne ücretsizdir ne de isteğe bağlıdır. GSI ayak uydurmalı, yoksa indeks her işlemde tablodan daha da uzaklaşır.

Bu kaymayı durdurmak için DynamoDB geri basınç uygular: kaynak yazmayı kısıtlar, böylece indeks asla sınırsızca bayatlamaz.

Yani GSI'nin yazma kapasitesi, doğrudan GSI'ye hiç yazmasanız bile temel tablo yazma hızınızın sabit bir tavanıdır.

İşlenmiş bir örnek: bir siparişler tablosu

Diyelim ki bir siparişler tablosu işletiyorsunuz. Temel öğe:

Temel tablo yazmaları sağlıklı. CUST#... yüksek kardinaliteye sahip, bu yüzden sipariş yazmaları temel bölümlere eşit yayılır. Sıcak anahtar yok, bol kapasite var.

Şimdi "bana belirli bir durumdaki her siparişi göster" sorusunu yanıtlamak için bir GSI eklersiniz:

Dört olası bölüm anahtarı değeri. Bir flaş indirim sırasında, neredeyse her yeni sipariş order_state = "PENDING" durumuna düşer. Bu yazmaların her biri aynı GSI bölümüne çarpar.

O bölümün bölüm başına bir verim sınırı vardır ve tüm yazma fırtınanızı tam ona nişanladınız.

Temel tablo iyidir. PENDING GSI bölümü alev alevdir. DynamoDB, indeksi korumak için temel tablo PutItem'ını kısıtlar.

Sizi ısıran akış

İşte geri basınç yolu — temel yazma dengeli, indeks yazması yoğunlaşmış:

Kısıtlama geriye doğru yolculuk eder: sıcak bir GSI bölümü, kendisini besleyen temel tablo yazmasını reddeder.

İçgüdünüzü değil, istisnayı okuyun

İstisna türü, hangi tavana çarptığınızı tam olarak söyler. ResourceArn GSI'yi adlandırır; kısıtlanan işlem yine de tablo yazmasıdır.

Kaynak: Understanding GSI write throttling and back pressure.

KeyRange nedeni, yukarıdaki sıcak bölüm durumunun belirtisidir: tek bir anahtar aralığı doyduğu hâlde GSI'nin toplam kapasitesi iyi görünebilir.

Nasıl düzeltilir

GSI'ye yer açın. En basit neden yetersiz sağlamadır. Bir GSI'nin tablodan tamamen ayrı kendi okuma ve yazma kapasitesi vardır — bkz. GSI vs LSI.

Tabloyu cömertçe sağlayıp GSI'yi ince bıraktıysanız, GSI'nin yazma kapasitesini (ya da on-demand maksimumunu) artırın.

Bölüm anahtarını düzeltin. Kapasite düşük kardinaliteli bir anahtarı kurtarmaz — tek bir sıcak bölümü aşırı sağlamayla yenemezsiniz. Yayılan bir GSI bölüm anahtarı seçin.

Onu birleştirin: shard'ın küçük rastgele bir sonek olduğu order_state#shard ya da tarihi katlayın (PENDING#2026-06-23). Yazmalar bölümlere yayılır ve siz yine de shard'ları sorgulayarak bir durumu Query ile alırsınız.

Daha az nitelik yansıtın. Her GSI yazması yansıtılan nitelikleri kopyalar. Bir KEYS_ONLY ya da sıkı bir INCLUDE yansıtması, ALL'a göre daha küçük indeks yazmaları ve daha az basınç demektir. İndeksten asla okumayacağınız şeyi yansıtmayın.

Yalnızca raporlama içinse GSI'yi atın. "Duruma göre siparişler" sıcak bir yol değil de ara sıra sorulan bir yönetici sorusuysa, filtreli periyodik bir scan kalıcı olarak sıcak bir indeksi yenebilir — bunu Query vs Scan ile tartın.

O indeksi sorgularken, Expression Builder sizin için KeyConditionExpression'ı yazar — örn. #s = :state AND begins_with(SK, :prefix) — adlar ve değerler doğru kaçışlanmış olarak:

KeyConditionExpression     "#s = :state"
ExpressionAttributeNames   { "#s": "order_state" }
ExpressionAttributeValues  { ":state": { "S": "PENDING" } }

Akılda tutulacak tuzak

İlişkisel içgüdü — "indeksler yazmaları yalnızca biraz yavaşlatır" — buraya aktarılamaz. Bir DynamoDB GSI'si pasif bir yapı değil, bir verim bağımlılığıdır. Onu küçük boyutlandırın ya da kümelenen bir anahtar seçin; hizmet ettiği tabloya geri basınç uygular.

GSI'nin yalnızca tablonun değil, bölüm başına ConsumedWriteCapacityUnits ve ThrottledRequests değerlerini izleyin.

Sonraki adımlar

• GSI vs LSI — bir GSI'nin neden kendi kapasitesine ve farklı bir bölüm anahtarına sahip olduğu.
• Tek tablo tasarımı — sıcak indeksleri çoğaltmadan birçok deseni sunmak için tek bir GSI'yi aşırı yükleme.
• Query vs Scan — bir indeksin yazma maliyetine değmediği durumlar.

Bir indirim onları kırmızıya çevirmeden önce kendi tablolarınıza karşı bir GSI'nin tüketilen kapasitesini ve kısıtlama olaylarını izlemek için DynoTable'ı deneyin.