Batas Ukuran Item DynamoDB (400 KB)

Satu Item DynamoDB paling banyak menampung 400 KB data. Datang dari MongoDB (dokumen 16 MB) atau dari baris relasional yang praktis tanpa batas, plafon itu terasa rendah — dan Anda biasanya menemukannya dengan cara yang pahit, ketika penulisan yang bertahun-tahun baik-baik saja tiba-tiba gagal dengan ValidationException karena satu Item akhirnya terlalu besar.

Batas ini bukan sembarang angka, dan bukan kuota yang bisa Anda naikkan. Ia adalah kendala pemodelan, dan Item yang menabraknya biasanya sedang memberi tahu Anda bahwa datanya salah dimodelkan.

Berapa ukuran Item maksimum di DynamoDB?

DynamoDB membatasi satu Item pada 400 KB — batas keras yang tidak bisa Anda naikkan. Ukurannya menghitung nama atribut plus nilainya sekaligus, termasuk setiap elemen list, map, dan set bersarang. Item biasanya menabraknya lewat pertumbuhan tanpa batas, seperti list tertanam yang terus membengkak; perbaikannya adalah pemodelan — memecah koleksinya menjadi Item terpisah, bukan kompresi.

• 400 KB per Item, batas keras. Tidak bisa disetel, bukan kuota lunak.
• Ukuran = nama atribut + nilai, digabung. Nama atribut yang panjang ikut dihitung, di setiap Item.
• Penyarangan dan set juga dihitung. List, map, dan nilai bersarangnya semua menambah.
• Penyebab yang biasa adalah pertumbuhan tanpa batas — menanamkan list yang tumbuh tanpa henti pada Item induk.
• Perbaikannya pemodelan, bukan kompresi. Pecah koleksi yang terus tumbuh menjadi Item tersendiri di bawah satu partition key bersama.

Masalahnya: Item yang tumbuh selamanya

Katakanlah Anda memantau armada kendaraan, dan Anda memutuskan menyimpan bacaan telemetri tiap kendaraan sebagai sebuah list pada Item kendaraan:

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

Sehari dua hari tidak masalah. Tapi bacaan datang tiap beberapa detik dan tidak pernah berhenti, jadi list-nya tumbuh tanpa batas. Akhirnya satu bacaan tambahan akan mendorong Item itu melewati 400 KB, dan DynamoDB menolak penulisannya dengan ValidationException: Item size has exceeded the maximum allowed size — Anda jadi tidak bisa mencatat telemetri untuk kendaraan itu sama sekali, karena setiap update menulis ulang seluruh Item.

Bug-nya bukan pada batas ukuran. Bug-nya adalah memodelkan relasi satu-ke-banyak yang tanpa batas sebagai list tertanam. Itu hanya berhasil kalau sisi "banyak"-nya terbatas dan kecil.

Apa yang sebenarnya dihitung terhadap 400 KB

DynamoDB mengukur total ukuran Item sebagai jumlah dari:

• Setiap nama atribut, dalam encoding UTF-8. Nama sepanjang 20 karakter yang diulang di jutaan Item adalah ukuran sekaligus penyimpanan yang Anda bayar — inilah sebabnya pemodel berpengalaman menjaga nama atribut tetap pendek.
• Setiap nilai atribut. String dan binary sesuai panjang byte-nya; angka lewat encoding yang padat; boolean dan null dengan biaya tetap yang sangat kecil.
• Struktur bersarang. Sebuah list atau map menghitung overhead-nya sendiri plus ukuran setiap elemen dan key di dalamnya, sampai ke lapisan terdalam.

Tidak ada batas per-atribut terpisah yang perlu Anda rencanakan — yang dihadapkan ke garis 400 KB adalah seluruh Item. Dokumentasi ukuran Item AWS menjabarkan perhitungan byte-nya secara persis.

Mengapa batas ini ada

Item besar mahal untuk dipindahkan. Pembacaan DynamoDB ditakar dalam unit 4 KB, jadi Item 400 KB menghabiskan 100 RCU untuk dibaca secara strongly consistent — dan pembacaan, penulisan, maupun replikasi semuanya jadi lebih lambat dan lebih mahal seiring Item membesar. Batas ini mendorong Anda ke arah Item yang kecil dan terarah, menjauh dari anti-pola "ambil satu blob raksasa" yang biasa dipilih pemula NoSQL karena kebiasaan relasional.

Memodelkan di sekitar batas ini

Untuk contoh armada tadi, berhenti menanamkan. Beri setiap bacaan Item-nya sendiri di partisi yang sama dengan kendaraan, diurutkan berdasarkan timestamp pada sort key:

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

Sekarang tidak ada satu Item pun yang membesar, penulisan tidak pernah melampaui batas, dan satu Query pada VEHICLE#A1 tetap menarik kembali bacaan sebuah kendaraan sebagai satu item collection yang terurut. Sub-list yang terbatas (segelintir tag, satu blok konfigurasi tetap) aman untuk ditanamkan; yang tanpa batas menjadi Item.

Memeriksa ukuran Item di DynoTable

Sebelum Anda mengunci sebuah bentuk data, timbang dulu satu Item yang representatif. Di DynoTable, buka sebuah Item di Quick View dan ia menampilkan ukuran byte Item itu di samping atributnya — jadi Anda menangkap bentuk yang terlalu berat sambil menelusuri data nyata, pada saat perancangan alih-alih saat penulisan gagal.

Lebih suka tetap di browser? Kalkulator ukuran Item DynamoDB melakukan hal yang sama dari sampel yang Anda tempel, melaporkan angka KB yang persis serta RCU/WCU yang akan dibebankan tiap pembacaan dan penulisan.

Diverifikasi terhadap DynamoDB

Aturan penghitungan ukuran mudah dinyatakan dan mudah pula salah secara halus, jadi kami memeriksa milik kami terhadap satu-satunya otoritas yang berarti: apa yang benar-benar ditagihkan DynamoDB.

Kuncinya, ConsumedCapacity melaporkan unit alih-alih byte, dan penulisan sebesar N byte menghabiskan ceil(N / 1024) WCU. Kasar secara umum — tapi persis di perbatasan. Item yang dibangun agar mendarat tepat di 1024 byte harus berbiaya 1 WCU, dan yang dibangun agar mendarat di 1025 harus berbiaya 2, jadi galat satu byte saja dalam aritmetikanya akan membalik angka yang teramati.

Enam dari enam cocok, dan pasangan di perbatasanlah yang membawa buktinya: Item 1.024 dan 1.025 byte hanya berbeda satu karakter padding dan DynamoDB menagih keduanya berbeda, persis di tempat perhitungan kami mengatakan tangganya jatuh.

Konsekuensi praktisnya adalah yang berdampak ke biaya. Item yang satu byte melewati satu kilobyte menghabiskan satu WCU ekstra penuh, dan di 4 KB tebing yang sama muncul di sisi baca — jadi memangkas Item dari 1.025 byte ke 1.024 memotong separuh biaya tulisnya, sementara menambahnya dari 1.024 ke 1.025 melipatgandakannya. Nama atribut ikut dihitung ke dalam total, dan itulah sebabnya memendekkan key pada tabel yang sibuk bukan mikro-optimasi.

Jebakan + langkah selanjutnya

• Awasi list tertanam yang tumbuh seiring trafik — mereka adalah bom waktu 400 KB yang klasik. Batasi atau pecah keluar.
• Pendekkan nama atribut pada Item berkardinalitas tinggi — itu ukuran dan penyimpanan yang kembali secara cuma-cuma.
• Nilai besar tempatnya di S3. Simpan blob besar (gambar, dokumen) di S3 dan sisakan hanya key-nya di Item.
• Terkait: denormalisasi dan relasi satu-ke-banyak membahas kapan harus menanamkan vs memecah.

Ingin melihat ukuran Item yang sebenarnya di seluruh tabel sekali pandang? Unduh DynoTable dan periksa data Anda langsung.

Angka kapasitas diverifikasi 2026-07-26 terhadap layanan DynamoDB live di us-east-1 (pnpm content:verify-item-size).