Operasi batch DynamoDB

Saat Anda perlu membaca atau menulis banyak item sekaligus, menembakkan satu GetItem atau PutItem per item berarti satu round trip jaringan per item — lambat dan cerewet. API batch DynamoDB melipat banyak operasi item menjadi satu request: BatchGetItem untuk baca, BatchWriteItem untuk tulis.

Itu kemenangan throughput dan latensi, bukan jaminan konsistensi — dan perbedaan itu tempat orang terbakar. Batch bukan transaksi.

Apa itu operasi batch DynamoDB?

Operasi batch DynamoDB melipat banyak baca atau tulis item menjadi satu request: BatchGetItem mengambil hingga 100 item, BatchWriteItem put atau delete hingga 25, masing-masing dibatasi 16 MB. Mereka menghemat round trip, bukan capacity. Yang kritis: batch bukan transaksi — item berhasil atau gagal secara independen, tanpa rollback.

• BatchGetItem — ambil hingga 100 item (atau 16 MB) lintas satu atau lebih tabel dalam satu panggilan.
• BatchWriteItem — hingga 25 operasi put/delete (atau 16 MB) dalam satu panggilan. Tanpa update — hanya put dan delete.
• Tidak atomik. Item individual bisa berhasil sementara yang lain gagal. Tidak ada rollback.
• Kegagalan parsial itu normal. Item yang di-throttle kembali di UnprocessedItems / UnprocessedKeys — Anda harus me-retry sendiri, dengan backoff.
• Biaya capacity sama dengan panggilan individual — batching menghemat round trip, bukan capacity unit.

Masalahnya: banyak item, satu round trip

Katakan Anda menjalankan support desk. Dashboard perlu memuat 50 tiket by ID untuk merender antrian; job malam mengarsipkan 1.000 tiket yang sudah resolved. Melakukannya satu item per waktu adalah 50 (atau 1.000) round trip berurutan — latensi menumpuk dan job merangkak.

Batching meruntuhkan itu menjadi segelintir panggilan. Baca 50 tiket menjadi satu BatchGetItem; job arsip menjadi stream panggilan BatchWriteItem berisi 25 delete masing-masing. Jauh lebih sedikit round trip, data yang sama dipindahkan.

Cara kerja API batch

BatchGetItem mengambil set primary key (lintas satu atau lebih tabel) dan mengembalikan item yang cocok. Anda bisa meminta baca strongly consistent per tabel. Apa pun yang tidak bisa dibaca — biasanya karena request menyentuh batas throughput — kembali di UnprocessedKeys alih-alih menggagalkan seluruh panggilan.

BatchWriteItem mengambil daftar operasi PutRequest / DeleteRequest. Perhatikan yang hilang: tidak ada update. Write batch mengganti seluruh item (put) atau menghapusnya (delete) — untuk mengubah atribut spesifik Anda tetap butuh UpdateItem. Item yang tidak bisa ditulis kembali di UnprocessedItems.

Batch adalah bundel operasi independen, masing-masing berhasil atau gagal sendiri — bukan satu unit all-or-nothing.

Batch bukan transaksi

Ini jebakannya. Jika batch job arsip menabrak batas throughput di tengah jalan, beberapa tiket terhapus dan beberapa tidak — dan DynamoDB tidak membatalkan yang sudah lewat. Tidak ada rollback, tidak ada isolation, tidak ada «25 semua atau tidak sama sekali».

Kalau Anda butuh semantik all-or-nothing — «pindahkan tiket ke archived dan turunkan counter tiket open, atau jangan lakukan keduanya» — itu TransactWriteItems, bukan batch. Transaksi lebih mahal (setiap operasi ditagih dua kali) dan dibatasi 100 item, tetapi memberi atomisitas yang sengaja tidak dimiliki batch.

Menangani item yang belum diproses

Pemanggil batch yang benar selalu memeriksa set unprocessed dan me-retry-nya. DynamoDB mengembalikan UnprocessedItems/UnprocessedKeys kapan pun request secara keseluruhan diterima tetapi beberapa item tidak bisa dilayani — biasanya throttling sementara.

Kirim ulang hanya item yang belum diproses, dengan exponential backoff dan jitter. Memperlakukan batch sebagai fire-and-forget diam-diam menjatuhkan write — jenis bug yang muncul berbulan-bulan kemudian sebagai data hilang.

Write batch di DynoTable

Perkirakan dulu berapa biaya job bulk dengan kalkulator pricing DynamoDB — batch mengonsumsi capacity yang sama dengan write individual yang dibundelnya, hanya dalam lebih sedikit request.

Di DynoTable, Anda men-stage edit secara lokal dan mereviewnya sebelum commit — perubahan bulk lintas banyak baris keluar sebagai request terkelompok alih-alih satu panggilan API masing-masing. Bulk delete keluar sebagai write batch, dengan retry item unprocessed ditangani untuk Anda.

Jebakan + langkah selanjutnya

• Selalu retry UnprocessedItems/UnprocessedKeys dengan backoff — itu diharapkan, bukan luar biasa.
• Tidak ada rollback kegagalan parsial. Butuh atomisitas? Pakai transaksi.
• Tidak ada update di write batch — BatchWriteItem hanya put/delete; raih UpdateItem untuk mengubah atribut.
• Perhatikan batas per panggilan — 25 write / 100 baca / 16 MB. Melebihinya gagal seluruh panggilan dengan ValidationException (terlalu banyak item di BatchGetItem, di BatchWriteItem). Page job yang lebih besar; lihat pagination.

Ingin menjalankan baca dan tulis bulk tanpa men-script loop retry? Unduh DynoTable dan edit tabel Anda langsung.

Matematika round trip

Panggilan GetItem serial membayar latensi per hop. BatchGetItem membundel hingga 100 key atau 16 MB per request — batas mana yang lebih dulu.

Biaya capacity tidak berubah — batching menghemat wall-clock dan CPU klien, bukan RCU. Untuk write, 1.000 delete pada 25 per batch adalah 40 panggilan BatchWriteItem alih-alih 1.000 delete individual.

Baca batch strongly consistent

BatchGetItem menerima ConsistentRead: true per tabel di map request. Baca kuat tetap berharga 2× RCU baca eventual untuk item yang sama. Mencampur tabel consistent dan eventual dalam satu panggilan batch boleh — setiap entri tabel membawa flag sendiri.

Memecah job besar

Saat mengarsipkan 1.000 item rata-rata 3 KB masing-masing, satu baca batch tetap di bawah batas 100 item tetapi bisa melebihi 16 MB (100 × 3 KB = 300 KB — aman). Arsipkan item 50 KB dan Anda menabrak batas megabyte sekitar 320 item per panggilan meskipun batas hitungan adalah 100.

Page write dengan loop eksplisit:

for each chunk of 25 keys:
  BatchWriteItem
  retry UnprocessedItems with backoff until empty

Commit yang di-stage DynoTable membundel write yang memenuhi syarat dan me-retry item unprocessed secara otomatis — pola yang kalau tidak akan Anda script dengan sleep ber-jitter.

Keputusan batch vs transaksi

Hasilkan payload put/delete dari JSON polos dengan konverter JSON DynamoDB saat men-seed beban batch dari fixture.

Memeriksa capacity yang dikonsumsi

Respons batch bisa menyertakan ConsumedCapacity per tabel saat diminta. Log itu selama backfill — laju throttle yang naik muncul sebagai set unprocessed yang tumbuh sebelum job berhenti total. Silang-cek WCU berkelanjutan dengan kalkulator pricing jika batch berjalan pada jadwal.