DynamoDB Item Boyutu Sınırı (400 KB)

Tek bir DynamoDB item'ı en fazla 400 KB veri tutabilir. MongoDB'den (16 MB belgeler) ya da pratik bir üst sınırı olmayan ilişkisel bir satırdan geliyorsanız, o tavan düşük hissettirir — ve onu genellikle zor yoldan keşfedersiniz, aylarca çalışan bir yazma birden bir ValidationException ile başarısız olduğunda, çünkü bir item nihayet fazla büyümüştür.

Sınır keyfî değildir ve yükseltebileceğiniz bir kota değildir. Bir modelleme kısıtıdır ve ona çarpan item'lar genellikle size verinin yanlış modellendiğini söylüyordur.

DynamoDB'de maksimum item boyutu nedir?

DynamoDB tek bir item'ı 400 KB ile sınırlar — yükseltemeyeceğiniz sert bir sınır. Boyut, attribute adlarını artı değerleri birlikte, her iç içe list, map ve set elemanı dahil olmak üzere sayar. Item'lar ona genellikle sınırsız büyümeyle çarpar, sürekli genişleyen gömülü bir liste gibi; çözüm modellemedir, koleksiyonu ayrı item'lara bölmektir, sıkıştırma değil.

• Item başına 400 KB, sert üst sınır. Ayarlanabilir değil, esnek bir kota değil.
• Boyut = attribute adları + değerler, birlikte. Uzun attribute adları her item'da sayılır.
• İç içe geçme ve set'ler de sayılır. List'ler, map'ler ve iç içe değerlerinin hepsi toplanır.
• Olağan sebep sınırsız büyümedir — bir ebeveyn item'a sınırsız büyüyen bir listeyi gömmek.
• Çözüm modellemedir, sıkıştırma değil. Büyüyen koleksiyonu, paylaşılan bir bölüm anahtarı altında kendi item'larına bölün.

Sorun: sonsuza dek büyüyen item

Diyelim ki bir araç filosunu takip ediyorsunuz ve her aracın telemetri okumalarını araç item'ında bir liste olarak depolamaya karar veriyorsunuz:

PK: VEHICLE#A1   readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]

Bir iki gün için iyidir. Ama okumalar her birkaç saniyede gelir ve asla durmaz, bu yüzden liste sınırsız büyür. Sonunda bir okuma daha item'ı 400 KB'ın ötesine iter ve DynamoDB yazmayı bir ValidationException: Item size has exceeded the maximum allowed size ile reddeder — o araç için artık hiç telemetri kaydedemezsiniz, çünkü her güncelleme tüm item'ı yeniden yazar.

Hata boyut sınırı değildir. Sınırsız bir bire-çok ilişkisini gömülü bir liste olarak modellemektir. Bu yalnızca "çok" tarafı sınırlı ve küçük olduğunda işe yarar.

400 KB'a gerçekte neyin sayıldığı

DynamoDB item'ın toplam boyutunu şunların toplamı olarak ölçer:

• Her attribute adı, UTF-8 kodlanmış. Milyonlarca item'da tekrarlanan 20 karakterlik bir ad, hem boyut hem de ödediğiniz depolamadır — deneyimli modelleyicilerin attribute adlarını kısa tutmasının nedeni budur.
• Her attribute değeri. String'ler ve binary bayt uzunluklarına göre; sayılar kompakt bir kodlamayla; boolean'lar ve null'lar küçük bir sabit maliyetle.
• İç içe yapı. Bir list ya da map kendi ek yükünü artı içindeki her elemanın ve anahtarın boyutunu, en aşağıya kadar sayar.

Etrafında plan yapılacak ayrı bir attribute başına üst sınır yoktur — 400 KB çizgisine karşı olan tüm item'dır. AWS item boyutu dokümantasyonu tam bayt muhasebesini açıklar.

Sınır neden var

Büyük item'ları taşımak pahalıdır. DynamoDB okumaları 4 KB birimlerinde ölçülür, bu yüzden 400 KB'lık bir item'ı güçlü tutarlı okumak 100 RCU'ya mal olur — ve okumalar, yazmalar ve replikasyon, item'lar büyüdükçe hepsi yavaşlar ve pahalılaşır. Üst sınır sizi küçük, hedefli item'lara doğru iter ve NoSQL yeni başlayanlarının ilişkisel alışkanlıktan uzandığı "tek dev bir blob getir" anti-deseninden uzaklaştırır.

Etrafında modelleme

Filo örneği için gömmeyi bırakın. Her okumaya, araçla aynı bölümde, sıralama anahtarında zaman damgasına göre sıralanmış kendi item'ını verin:

PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:05Z   lat, lng, fuel
PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:10Z   lat, lng, fuel

Artık hiçbir tek item büyümez, yazmalar üst sınırı asla aşmaz ve VEHICLE#A1 üzerindeki tek bir Query yine bir aracın okumalarını tek bir sıralı item koleksiyonu olarak geri çeker. Sınırlı alt listeler (bir avuç etiket, sabit bir yapılandırma bloğu) gömmek için gayet iyidir; sınırsız olanlar item olur.

DynoTable'da item boyutunu kontrol etme

Bir biçime bağlanmadan önce temsili bir item'ı tartın. DynoTable'da birini Quick View'da açın ve item'ın bayt boyutunu attribute'larının yanında gösterir — böylece fazla ağır bir biçimi, başarısız yazmada değil, tasarım zamanında, gerçek veriye göz atarken yakalarsınız.

Tarayıcıda kalmayı mı tercih edersiniz? DynamoDB item boyutu hesaplayıcısı aynısını yapıştırılmış bir örnekten yapar, tam KB'ı ve her okuma ve yazmanın maliyet çıkaracağı RCU/WCU'yu raporlar.

DynamoDB'ye karşı doğrulandı

Boyutlandırma kuralları söylemesi kolay, ince ayrıntılarda yanlış yapması da kolaydır; bu yüzden bizimkileri önemli olan tek otoriteye karşı denetledik: DynamoDB'nin gerçekte neyi faturalandırdığına.

İşin püf noktası şu: ConsumedCapacity bayt değil birim raporlar ve N baytlık bir yazma ceil(N / 1024) WCU'ya mal olur. Genel olarak kaba — ama bir sınırda tam isabetli. Tam 1024 bayta oturacak şekilde kurulmuş bir item 1 WCU'ya, 1025 bayta oturacak şekilde kurulmuş biri ise 2 WCU'ya mal olmak zorundadır; yani aritmetikteki tek baytlık bir hata gözlenen sayıyı değiştirir.

Altıda altısı uyuşuyor ve kanıtı taşıyanlar sınır çiftleri: 1.024 ve 1.025 baytlık item'lar tek bir dolgu karakteriyle ayrılıyor ve DynamoDB onları farklı ücretlendiriyor — tam da hesabımızın basamağın düştüğünü söylediği yerde.

Pratik sonuç, para maliyeti olanı. Bir kilobaytı bir bayt aşan item, tam bir WCU daha maliyet çıkarır ve 4 KB'da aynı uçurum okuma tarafında belirir — yani bir item'ı 1.025 bayttan 1.024 bayta kırpmak yazma maliyetini yarıya indirir, 1.024'ten 1.025'e doldurmak ise ikiye katlar. Attribute adları toplama sayılır; sıcak bir tabloda anahtarları kısaltmanın mikro-optimizasyon olmamasının nedeni de budur.

Tuzaklar ve sonraki adımlar

• Trafikle büyüyen gömülü listelere dikkat edin — klasik 400 KB'lık saatli bombadır. Onları sınırlayın ya da ayırın.
• Attribute adlarını kısaltın yüksek kardinaliteli item'larda — bedava boyut ve depolama geri kazandırır.
• Büyük değerler S3'e aittir. Büyük blob'ları (resimler, belgeler) S3'te depolayın ve item'da yalnızca anahtarı tutun.
• İlgili: denormalizasyon ve bire-çok ilişkiler ne zaman gömüp ne zaman böleceğinizi kapsar.

Bir tablodaki gerçek item boyutlarını bir bakışta görmek mi istiyorsunuz? DynoTable'ı indirin ve verilerinizi doğrudan inceleyin.

Kapasite rakamları 2026-07-26 tarihinde us-east-1'deki canlı DynamoDB hizmetine karşı doğrulandı (pnpm content:verify-item-size).