DynamoDB LSI item collection 10 GB limit

TL;DR — Bir Yerel İkincil İndeksi olan bir tabloda, bir öğe koleksiyonu — bir bölüm anahtarını paylaşan her öğe, artı LSI projeksiyonları — toplamda en fazla 10 GB olabilir. Yalnızca LSI tabloları bu sınıra sahiptir, çünkü her öğe koleksiyonu tek bir bölüme sığmalıdır. Bir koleksiyonu 10 GB'nin üzerine itecek bir yazma, ItemCollectionSizeLimitExceededException ile başarısız olur. ItemCollectionMetrics'i izleyin, büyüyen anahtarı yeniden parçalayın ya da LSI'yi (böyle bir sınırı olmayan) bir GSI ile değiştirin.

Ne anlama gelir

ItemCollectionSizeLimitExceededException: Collection size exceeded.

Bir öğe koleksiyonu, tabloda ve tüm LSI'lerinde aynı bölüm anahtarı değerine sahip tüm öğelerin kümesidir. Bir tablonun bir LSI'si olduğunda, DynamoDB her öğe koleksiyonunu tek bir bölümde saklar, dolayısıyla koleksiyon o bölümün 10 GB kapasitesiyle sınırlanır. Bir LSI'si olmayan bir tablonun koleksiyon başına boyut sınırı yoktur (ve GSI'lerin de yoktur). Bu yüzden bu hata, bir bölüm anahtarının verisinin bir LSI altında sınırsız büyüdüğüne dair bir sinyaldir. Bu bir HTTP 400'dür; AWS onu yeniden denenebilir olarak listeler, ama bir yeniden deneme yalnızca koleksiyon küçüldükten sonra başarılı olur — okumalara ve boyut azaltan yazmalara (silmeler, öznitelikleri kırpma) hâlâ izin verilir.

Neden olur

  • Sınırsız bir bölüm anahtarı — büyük bir kiracı, meşgul bir kullanıcı ya da yalnızca ekleme günlüğü, hepsi tek bir anahtar altında yazıyor.
  • LSI'nin kendisi — 10 GB sınırı yalnızca tablonun bir LSI'si olduğu için vardır (tablo oluşturma zamanında oluşturulur ve kaldırılamaz).
  • Geniş LSI projeksiyonları — LSI'ye birçok özniteliği projelemek koleksiyonu daha hızlı şişirir.
  • Bir yazma sonunda onu geçene kadar sessizce 10 GB'ye yaklaşan istikrarlı büyüme.

Nasıl düzeltilir

  1. Bölüm anahtarını yeniden parçalayın. Aşırı boyutlu varlığı birden çok anahtara bölün (TENANT#42#1, TENANT#42#2, …), böylece tek bir koleksiyon sınırsız büyümesin.
  2. LSI'yi bir GSI ile değiştirin. GSI'lerin kendi bölüm anahtarı vardır ve öğe koleksiyonu boyut sınırı yoktur — çoğu erişim deseni için bir GSI daha iyi uyum sağlar ve tablo oluşturmadan sonra eklenebilir/kaldırılabilir (bir LSI eklenemez).
  3. LSI projeksiyonlarını kırpın — LSI'yi tutmanız gerekiyorsa koleksiyon büyümesini yavaşlatmak için daha az öznitelik projeleyin (KEYS_ONLY/INCLUDE).
  4. Soğuk öğeleri sıcak koleksiyondan ayrı bir tabloya ya da S3'e arşivleyin.
  5. Duvara çarpmadan önce izleyin. Yazmalarda (PutItem, UpdateItem, DeleteItem, BatchWriteItem, TransactWriteItems) ReturnItemCollectionMetrics: SIZE ayarlayın; DynamoDB bir SizeEstimateRangeGB tahmini döndürür ve AWS, 10 GB'den önce harekete geçmeniz için kullanıcı tanımlı bir eşikte (örneğin 8 GB) uyarı vermenizi önerir.

LSI sınırından kaçmak için anahtarları ve indeksleri mi yeniden çalışıyorsunuz? DynoTable masaüstü uygulaması, bölüm anahtarına göre filtrelemenize olanak tanır, böylece yeniden parçalamadan önce hangi koleksiyonun aşırı boyutlu olduğunu görebilirsiniz.

DynoTable'dan

10 GB'a yaklaşan bölüm anahtarını bulun — tabloyu ⌘K ile açın, bölüm anahtarına göre sıralayın ve koleksiyon başına öğeleri sayın. item sana calculator, geniş LSI tahminlerinin koleksiyonları şişirdiği durumlarda büyümeyi tahmin ediyor.

LSI yazma maliyetini GSI geçişle pricing calculator ile karşılaştırın. Profilleri ⌘P ile değiştirin; bkz. Connect to AWS ve Install.

Kaynaklar

İlgili hatalar

Kaynaklar

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.

Console olmadan DynamoDB ile çalış

DynamoDB’nin çalıştıramadığı gerçek SQL’i çalıştıran hızlı bir DynamoDB masaüstü istemcisi — JOINs, GROUP BY, toplamalar — görsel düzenleme ve kendi Bedrock anahtarların üzerinde bir yapay zekâ aracısıyla.

30 günlük ücretsiz deneme, kredi kartı yok — ardından süre sınırı olmayan Ücretsiz plan.