Operasi Batch DynamoDB: BatchGetItem & BatchWriteItem

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 ke dalam satu request: BatchGetItem untuk pembacaan, BatchWriteItem untuk penulisan.

Mereka adalah kemenangan throughput-dan-latensi, bukan jaminan konsistensi — dan distingsi itulah tempat orang terbakar. Sebuah batch bukan transaksi.

Apa itu operasi batch DynamoDB?

Operasi batch DynamoDB melipat banyak pembacaan atau penulisan Item ke dalam satu request: BatchGetItem mengambil hingga 100 Item, BatchWriteItem melakukan put atau delete hingga 25, masing-masing dibatasi 16 MB. Mereka menghemat round trip, bukan kapasitas. Yang krusial, sebuah 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. Tak ada rollback.
• Kegagalan parsial itu normal. Item yang ter-throttle kembali dalam UnprocessedItems / UnprocessedKeys — Anda harus me-retry-nya sendiri, dengan backoff.
• Biaya kapasitas sama dengan panggilan individual — batching menghemat round trip, bukan capacity unit.

Masalahnya: banyak Item, satu round trip

Misalkan Anda menjalankan meja dukungan. Sebuah dashboard perlu memuat 50 tiket berdasarkan ID untuk merender antrean; sebuah job semalaman mengarsipkan 1.000 tiket terselesaikan. Melakukan itu satu Item demi satu adalah 50 (atau 1.000) round trip berurutan — latensi menumpuk dan job-nya merangkak.

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

Cara kerja API batch

BatchGetItem mengambil sehimpunan primary key (lintas satu atau lebih tabel) dan mengembalikan Item yang cocok. Anda dapat meminta pembacaan strongly consistent per tabel. Apa pun yang tak bisa ia baca — biasanya karena request menyenggol batas throughput — kembali dalam UnprocessedKeys alih-alih menggagalkan seluruh panggilan.

BatchWriteItem mengambil daftar operasi PutRequest / DeleteRequest. Perhatikan apa yang hilang: tak ada update. Sebuah batch write entah mengganti seluruh Item (put) atau menghapusnya (delete) — untuk memodifikasi atribut spesifik Anda masih butuh UpdateItem. Item yang tak bisa ia tulis kembali dalam UnprocessedItems.

Model mental kuncinya: sebuah batch adalah bundel operasi independen, masing-masing berhasil atau gagal sendiri — bukan satu unit semua-atau-tak-sama-sekali.

Batch bukan transaksi

Inilah jebakannya. Jika batch job arsip Anda menabrak batas throughput di tengah jalan, sebagian tiket terhapus dan sebagian tidak — dan DynamoDB tidak membatalkan yang sudah lewat. Tak ada rollback, tak ada isolasi, tak ada "ke-25 atau tidak sama sekali".

Jika Anda butuh semantik semua-atau-tak-sama-sekali — "pindahkan tiket ke terarsip dan kurangi penghitung tiket-terbuka, atau tidak keduanya" — itu TransactWriteItems, bukan batch. Transaksi berbiaya lebih (tiap operasi ditagih ganda) dan dibatasi pada 100 Item, tetapi mereka memberi Anda atomisitas yang sengaja tak diberikan batch.

Menangani unprocessed item

Pemanggil batch yang benar selalu memeriksa himpunan unprocessed dan me-retry-nya. DynamoDB mengembalikan UnprocessedItems/UnprocessedKeys setiap kali request secara keseluruhan diterima tetapi sebagian Item tak bisa dilayani — biasanya throttling sementara.

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

Batch write di DynoTable

Estimasi dulu berapa biaya sebuah job massal dengan kalkulator harga DynamoDB — sebuah batch mengonsumsi kapasitas yang sama dengan penulisan individual yang dibundelnya, hanya dalam lebih sedikit request.

Di DynoTable, Anda men-stage editan secara lokal dan meninjaunya sebelum meng-commit-nya sebagai batch write yang efisien — perubahan massal lintas banyak baris keluar dalam request terkelompok alih-alih satu panggilan API per perubahan, dengan retry unprocessed-item ditangani untuk Anda.

Jebakan dan langkah berikutnya

• Selalu retry UnprocessedItems/UnprocessedKeys dengan backoff — mereka diharapkan, bukan pengecualian.
• Tak ada rollback kegagalan-parsial. Butuh atomisitas? Gunakan transaksi.
• Tak ada update dalam batch write — BatchWriteItem hanya put/delete; raih UpdateItem untuk mengubah atribut.
• Perhatikan batas per-panggilan — 25 write / 100 read / 16 MB. Halaman-i job yang lebih besar; lihat paginasi.

Ingin menjalankan pembacaan dan penulisan massal tanpa men-skrip loop retry? Unduh DynoTable dan edit tabel Anda secara langsung.