Batas Ukuran Item DynamoDB (400 KB)

Sebuah Item DynamoDB tunggal dapat menampung paling banyak 400 KB data. Datang dari MongoDB (dokumen 16 MB) atau baris relasional tanpa batas praktis, plafon itu terasa rendah — dan Anda cenderung menemukannya dengan cara yang sulit, saat sebuah penulisan yang berfungsi berbulan-bulan tiba-tiba gagal dengan ValidationException karena satu Item akhirnya tumbuh terlalu besar.

Batas ini tidak sewenang-wenang, dan ia bukan kuota yang bisa Anda naikkan. Ia adalah kendala pemodelan, dan Item yang menabraknya biasanya memberi tahu Anda bahwa datanya dimodelkan keliru.

Berapa ukuran Item maksimum di DynamoDB?

DynamoDB membatasi satu Item pada 400 KB — sebuah batas keras yang tak dapat Anda naikkan. Ukuran ini menghitung nama atribut beserta nilainya secara bersama-sama, termasuk setiap elemen list, map, dan set yang bersarang. Item biasanya menabraknya akibat pertumbuhan tak terbatas, seperti list tertanam yang membengkak terus-menerus; solusinya adalah pemodelan, memecah koleksi menjadi Item terpisah, bukan kompresi.

• 400 KB per Item, batas keras. Tak dapat disesuaikan, bukan kuota lunak.
• Ukuran = nama atribut + nilai, bersama-sama. Nama atribut panjang ikut dihitung, pada tiap Item.
• Nesting dan set juga dihitung. List, map, dan nilai bersarangnya semua menumpuk.
• Penyebab umumnya adalah pertumbuhan tak terbatas — menanamkan list yang tumbuh tanpa batas pada sebuah Item induk.
• Solusinya pemodelan, bukan kompresi. Pecah koleksi yang tumbuh menjadi Item-nya sendiri di bawah partition key bersama.

Masalahnya: Item yang tumbuh selamanya

Misalkan Anda melacak armada kendaraan, dan Anda memutuskan menyimpan pembacaan telemetri tiap kendaraan sebagai list pada Item kendaraan:

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

Untuk sehari dua hari tak masalah. Tetapi pembacaan tiba tiap beberapa detik dan tak pernah berhenti, jadi list-nya tumbuh tanpa batas. Akhirnya satu Item kendaraan melewati 400 KB dan setiap penulisan ke sana gagal — Anda tak lagi bisa merekam telemetri untuk kendaraan itu sama sekali, karena tiap pembaruan menulis ulang seluruh Item (yang kini kelewat besar).

Bug-nya bukan batas ukuran. Ia adalah memodelkan relasi one-to-many tak terbatas sebagai list tertanam. Itu hanya berfungsi saat sisi "many"-nya terbatas dan kecil.

Apa yang sebenarnya dihitung ke arah 400 KB

DynamoDB mengukur ukuran total Item sebagai jumlah dari:

• Setiap nama atribut, dienkode UTF-8. Nama 20-karakter yang diulang di jutaan Item adalah ukuran sekaligus penyimpanan yang Anda bayar — inilah mengapa pemodel berpengalaman menjaga nama atribut tetap pendek.
• Setiap nilai atribut. String dan binary menurut panjang byte-nya; angka dengan enkode ringkas; boolean dan null dengan biaya tetap yang mungil.
• Struktur bersarang. Sebuah list atau map menghitung overhead-nya sendiri ditambah ukuran tiap elemen dan key di dalamnya, sampai ke dasar.

Tidak ada batas per-atribut terpisah untuk direncanakan — ini soal seluruh Item terhadap garis 400 KB. Service quota AWS merinci akuntansi byte yang persisnya.

Mengapa batas ini ada

Item besar mahal untuk dipindahkan. Pembacaan DynamoDB diukur dalam unit 4 KB, jadi Item 400 KB berbiaya 100 RCU untuk dibaca secara kuat — dan pembacaan, penulisan, serta replikasi semua menjadi lebih lambat dan lebih mahal saat Item membesar. Batas itu mendorong Anda menuju Item kecil dan terfokus dan menjauh dari anti-pola "ambil satu blob raksasa" yang diraih pemula NoSQL karena kebiasaan relasional.

Memodelkan di sekitarnya

Untuk contoh armada, berhenti menanamkan. Beri tiap pembacaan Item-nya sendiri di partition yang sama dengan kendaraan, diurutkan menurut 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

Kini tak ada satu Item pun yang tumbuh, penulisan tak pernah melampaui batas, dan satu Query pada VEHICLE#A1 tetap menarik kembali pembacaan satu kendaraan sebagai satu item collection terurut. Sub-list terbatas (segenggam tag, blok konfig tetap) boleh ditanamkan; yang tak terbatas menjadi Item.

Memeriksa ukuran Item di DynoTable

Sebelum Anda berkomitmen pada sebuah bentuk, timbang Item representatif. Di DynoTable, buka salah satu di Quick View dan Anda akan melihat ukuran byte Item tersebut di samping atribut-atributnya — sehingga Anda menangkap bentuk yang terlalu berat saat menelusuri data nyata, pada saat desain alih-alih saat penulisan gagal.

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

Jebakan dan langkah berikutnya

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

Ingin melihat ukuran Item nyata lintas tabel secara sekilas? Unduh DynoTable dan periksa data Anda secara langsung.