Batas dan Kuota DynamoDB, Diverifikasi Terhadap Layanan Live

Apa saja batas DynamoDB?

Sebuah item dibatasi 400 KB, kunci partisi 2,048 byte, dan kunci sort 1,024 byte. Batch write mengambil 25 item, batch get 100 key, transaksi 100 aksi. Sebuah tabel mendapat 20 global dan 5 local secondary index. Setiap angka di halaman ini ditetapkan dengan mengirim request ke Amazon DynamoDB dan membaca apa yang kembali.

Bagaimana angka-angka ini ditetapkan

AWS menerbitkan kuotanya tanpa bukti, dan itu biasanya tidak masalah — sampai sebuah angka menjadi tumpuan keputusan desain dan Anda ingin tahu apakah artinya 400,000 byte atau 409,600, apakah ia menghitung nama atribut Anda, dan apa persisnya yang dikatakan layanan saat Anda melewatinya.

Jadi kami mengujinya. Untuk setiap batas di tabel pertama di bawah, sebuah request dibangun agar duduk tepat pada nilai yang terdokumentasi dan dikirim ke layanan live di us-east-1; lalu request kedua, satu unit melewatinya. Yang pertama harus diterima dan yang kedua ditolak — pasangan itu yang menentukan letak batasnya, bukan mempercayai kata-kata dokumentasi begitu saja. Pesan penolakan di kolom terakhir adalah kalimat layanan itu sendiri, diambil verbatim dan tidak pernah diketik ulang.

Empat baris hanya bisa ditetapkan dari sisi penolakan. Itu adalah batas CreateTable yang sisi penerimaannya berarti membangun tabel dengan dua puluh index dan menunggu masing-masing menjadi aktif, untuk sebuah angka yang sudah dinyatakan langsung oleh pesan penolakannya. Kolom Bagaimana ditetapkan menyebutkan mana yang mana; itu bukan hiasan.

Batas yang diverifikasi

Lingkungan: Amazon DynamoDB, layanan live, us-east-1, diuji 2026-08-27 dengan AWS SDK for JavaScript v3.

Apa yang ditemukan probe-nya

400 KB berarti 409,600 byte, dan itu menghitung nama atribut Anda. Item yang berukuran tepat 409,600 byte diterima; 409,601 ditolak. Pengukuran ini menghitung panjang UTF-8 dari setiap nama atribut ditambah setiap nilai, yang merupakan cara hitung yang sama seperti yang diimplementasikan kalkulator ukuran item kami — probe-nya membangun payload-nya dengan library itu, jadi keduanya cocok karena konstruksinya, bukan karena klaim. Masalah pemodelan yang lebih dalam di belakang batas ini punya panduannya sendiri: batas ukuran item DynamoDB.

Batas atribut yang diproyeksikan yang dikutip semua orang adalah yang salah. Halaman Kuota AWS mendokumentasikan satu angka — "up to 100 attributes combined for all of a table's local and global secondary indexes" — dan tidak pernah menyebut plafon per-index. Plafon itu ada, dan besarnya 20. Sebuah CreateTable yang memproyeksikan 21 atribut non-key ke dalam satu index ditolak jauh sebelum total per-tabelnya mendekati 100. Angka 20 itu terdokumentasi, tapi hanya di halaman Projection pada API Reference, sebagai batasan anggota array: "Maximum number of 20 items". Jika Anda merancang sebuah index hanya berdasarkan halaman Kuota, API akan menolak skema yang menurut halaman Kuota baik-baik saja. Kedua angka ada di tabel di atas, masing-masing dengan penolakan yang membuktikannya.

Dua dari pesan itu mengandung typo AWS sendiri, direproduksi di sini alih- alih diam-diam dibetulkan — maximum size limit of2048 bytes kehilangan satu spasi, dan number of projected attributes:120 kehilangan satu lagi. Jika Anda meng-grep log untuk string ini, grep untuk apa yang dikirim layanan, bukan untuk apa yang terbaca benar.

Kunci sort diukur secara agregat. Pesan penolakan kunci sort mengatakan "Aggregated size of all range keys", bukan "the sort key", karena anggaran 1,024-byte yang sama mencakup kunci sort tabelnya dan kunci sort setiap local secondary index yang menampung item itu.

Halaman 1 MB, yang sama sekali tidak memicu apa pun

Setiap batas di atas mengumumkan dirinya dengan menolak Anda. Batas halaman Query dan Scan tidak. Melewatinya dan DynamoDB mengembalikan halaman yang pendek dan sebuah LastEvaluatedKey, tanpa error dan tanpa peringatan — itu sebabnya "Scan saya hanya mengembalikan sebagian tabel" adalah kejutan yang begitu umum, dan itu sebabnya pagination bukan hal opsional.

Itu juga berarti tidak ada pesan error untuk dikutip, jadi ia diukur alih-alih dipancing:

Pada 1,000 byte per item, sebuah halaman menampung 1,029 item dan mengembalikan LastEvaluatedKey — 1,029,000 byte data item, dengan item ke-1,030 disisakan untuk request berikutnya. Pada 5,000 byte per item, sebuah halaman menampung 208 item dan mengembalikan LastEvaluatedKey — 1,040,000 byte data item, dengan item ke-209 disisakan untuk request berikutnya.

Tidak ada satu pun halaman yang menampung 1 MiB data item — yang pertama kurang sekitar 19,576 byte. Jadi anggaran halaman menagih lebih banyak per item daripada byte item itu sendiri.

Dua probe pada ukuran item yang berbeda sudah cukup untuk memastikan itu. Dengan memperlakukan sebuah halaman sebagai item × (byte item + overhead per item) ≤ anggaran, hanya 7 overhead byte-bulat yang konsisten dengan kedua pengukuran, dan tepat satu di antaranya menaruh anggarannya pada megabyte biner yang bulat: overhead 19 byte per item, dengan anggaran antara 1,048,551 dan 1,048,971 byte — rentang yang mengandung 1,048,576. "1 MB" DynamoDB itu biner, seperti yang dinyatakan halaman kuotanya sendiri, dan ia dihabiskan untuk byte item ditambah overhead per item. Anggarkan sekitar 19 byte darinya untuk setiap item.

Kuota yang tidak kami uji

Batas di bawah dikutip dari AWS, bukan diukur. Itu adalah kuota level-akun: kebanyakan bisa dinaikkan atas permintaan, dan mencapainya berarti memprovisikan throughput yang tertagih per jam, membuat ribuan tabel, atau berkomitmen pada kapasitas reserved selama setahun. Tidak satu pun dari itu adalah probe, jadi tidak satu pun disajikan sebagai probe. Sumber untuk setiap baris adalah halaman AWS Kuota di Amazon DynamoDB.

Batas mana yang harus Anda rancang di sekitarnya

Kebanyakan dari ini tidak akan pernah Anda temui. Segelintir yang membentuk desain nyata:

• 400 KB per item adalah batasan pemodelan, bukan kuota. Item yang mendekatinya biasanya adalah relasi satu-ke-banyak tak terbatas yang disimpan sebagai list yang di-embed. Lihat batas ukuran item.
• Halaman 1 MB mengatur setiap Query dan Scan yang Anda tulis. Kode yang mengabaikan LastEvaluatedKey diam-diam salah pada hari data Anda tumbuh melebihi satu halaman.
• 25 item per batch write dan 100 per batch get membentuk loop bulk-load Anda. Lihat operasi batch.
• 100 aksi per transaksi adalah yang orang temui saat mencoba membuat DynamoDB berperilaku relasional. Lihat transaksi.
• 20 GSI, 5 LSI, 100 atribut yang diproyeksikan membatasi desain pola akses jauh lebih sering daripada kuota throughput, dan jumlah LSI dikunci pada saat tabel dibuat. Lihat proyeksi index dan GSI vs LSI.

Kebanyakan penolakan yang dikutip di atas juga punya halamannya sendiri di bawah error DynamoDB, beserta request yang menghasilkan masing-masing. Empat penolakan CreateTable tidak — itu ditangkap khusus untuk halaman ini.

Untuk memeriksa satu item terhadap batas 400 KB tanpa menulisnya, kalkulator ukuran item berjalan di browser Anda. Untuk melihat item di tabel Anda sendiri, DynoTable adalah klien desktop DynamoDB.