Bisakah DynamoDB menyimpan blob?

Ya, dengan batasan. DynamoDB menyimpan binary large object (BLOB) dalam atribut Binary (B), ter-encode base64 saat melintasi jaringan, selama keseluruhan item tetap di bawah 400 KB. Untuk apa pun yang lebih besar — video, audio, gambar resolusi tinggi — AWS menyarankan menyimpan blob-nya di Amazon S3 dan hanya menyimpan referensi plus metadata di DynamoDB.

Menyimpan blob secara langsung

Taruh byte-nya dalam sebuah atribut Binary. Aplikasi meng-encode nilai biner ke base64 sebelum mengirimnya; DynamoDB menghitung panjang byte mentahnya terhadap ukuran item 400 KB. Blob kecil (tanda tangan, payload ringkas) muat dengan nyaman.

Berapa byte yang sebenarnya muat

400 KB itu untuk item-nya, bukan blob-nya. Mencari batasnya dengan binary search memberi plafon yang persis: item yang tak memuat apa pun selain partition key satu karakter dan satu atribut Binary menampung 409.594 byte blob. Satu byte lagi dan penulisannya gagal:

ValidationException: Item size has exceeded the maximum allowed size

Enam atribut metadata realistis di sampingnya (tipe konten, dimensi, pengunggah, timestamp) memakan 94 byte dan menurunkan plafonnya ke 409.500.

Encoding base64 hanyalah detail jaringan, tak lebih. Put berukuran 409.594 byte itu mengirim 546.128 byte base64 di body request-nya dan DynamoDB menerimanya, jadi gagasan yang luas beredar bahwa base64 memakan sepertiga anggaran Anda itu keliru. Yang memang berbiaya adalah throughput: blob berukuran penuh berarti 400 write unit per put dan 100 read unit per pembacaan strongly consistent, dibanding 1 dan 0,5 untuk item kecil.

Pola objek besar

Ketika sebuah blob melampaui 400 KB:

Simpan objeknya di Amazon S3.
Simpan key S3 plus metadata (nama, ukuran, pemilik, timestamp) di DynamoDB.

Ini memasangkan pencarian terindeks DynamoDB yang cepat dengan penyimpanan objek S3 yang murah dan tanpa batas. Untuk data yang hanya sedikit melewati batas, AWS juga menyarankan mengompresi atribut besar (keluaran GZIP atau LZO disimpan dalam atribut Binary) atau memecahnya ke beberapa item.

Kompresi menyelamatkan teks, bukan media

Saran kompresi itu bekerja tepat pada satu jenis blob. gzip -9 atas berkas lockfile YAML berukuran 614.499 byte mengembalikan 164.302 byte, pemangkasan 73% yang membawanya dari mustahil menjadi nyaman. Perintah yang sama atas PNG berukuran 794.311 byte mengembalikan 785.175 byte, penghematan 1,2%, karena formatnya sudah mengompresi dirinya sendiri. Jadi kompresi membelikan Anda ruang untuk log, payload JSON, dan teks, dan tak membelikan apa pun untuk berkas media yang justru jadi alasan lazim menabrak batas itu.

Sebuah catatan penting

Tak ada transaksi lintas layanan antara DynamoDB dan S3, jadi aplikasi Anda harus menangani sendiri kegagalan parsial dan objek yatim.

Pelajari lebih lanjut

Periksa ukuran dengan kalkulator ukuran item dan baca panduan batas ukuran item. Unduh DynoTable untuk melihat data biner.

Referensi

Terakhir diverifikasi 2026-07-13 terhadap dokumentasi resmi AWS yang ditautkan di atas.

Diukur 2026-07-28 terhadap DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 — kedua plafon byte itu ditemukan lewat binary search alih-alih diturunkan secara hitungan, dan angka gzip-nya berasal dari menjalankan gzip -9 pada dua berkas yang dijelaskan. Mesin produksi AWS mungkin merumuskan penolakannya secara berbeda.