DynamoDB Streams: Panduan Lengkap (dengan Contoh)

DynamoDB Streams adalah log change-data-capture: setiap insert, update, dan delete pada sebuah tabel ditangkap, secara terurut, sebagai sebuah stream record yang bisa Anda reaksikan. Inilah cara Anda mengubah sebuah tabel menjadi sumber event tanpa melakukan polling padanya.

Dalam skenario audit-log Anda ingin bereaksi saat sebuah event sensitif mendarat — memicu alert ketika seseorang mengekspor invoice atau memberi peran admin — tanpa men-scan tabel dengan timer. Streams adalah sisi push dari itu.

Bagaimana cara kerja DynamoDB Streams?

DynamoDB Streams menangkap setiap insert, update, dan delete pada sebuah tabel sebagai log record yang terurut-waktu dan ter-dedup, disimpan hingga 24 jam. Anda memilih apa yang dibawa setiap record dengan StreamViewType (key, image baru, image lama, atau keduanya), lalu mengonsumsi stream dengan sebuah Lambda trigger untuk bereaksi terhadap perubahan Item tanpa polling.

• Streams menangkap perubahan tingkat-Item sebagai log yang terurut-waktu dan ter-dedup, disimpan hingga 24 jam.
• Anda memilih apa yang dibawa setiap record melalui StreamViewType: hanya key, image baru, image lama, atau baik lama maupun baru.
• Record terurut per Item — perubahan pada satu Item tiba dalam urutan saat mereka ditulis — dan sebuah stream di-shard dengan cara yang sama seperti tabel-nya.
• Consumer native-nya adalah Lambda — sebuah trigger yang berjalan per batch record baru, dengan Kinesis Data Streams sebagai alternatif untuk fan-out lebih kaya.

Masalahnya: bereaksi tanpa polling

Anda butuh "beri saya alert ketika sebuah event role.granted ditulis." Pendekatan naif adalah sebuah pekerjaan terjadwal yang men-scan event baru setiap menit — yang membaca seluruh partisi terkini setiap kali, memakan kapasitas, dan selalu setidaknya terlambat satu menit.

Yang sebenarnya Anda inginkan adalah sebuah push: DynamoDB memberi tahu Anda saat sebuah Item berubah. Itulah persis yang disediakan Streams, dengan change record dikirim ke kode Anda alih-alih Anda memburunya.

Cara kerja Streams

Menurut dokumen AWS, DynamoDB Streams menyimpan log perubahan yang ter-dedup dan terurut-waktu hingga 24 jam, dengan integrasi Lambda native (change data capture untuk DynamoDB). Setiap record menggambarkan satu modifikasi tingkat-Item.

Ketika Anda mengaktifkan sebuah stream Anda memilih sebuah StreamViewType, yang mengontrol seberapa banyak dari Item yang berubah dibawa setiap record:

Record terurut per Item — perubahan pada satu Item tunggal muncul dalam urutan saat mereka ditulis — dan stream di-shard sepanjang struktur partisi yang sama seperti tabel. Retensi adalah 24 jam — Streams adalah buffer reaksi, bukan histori permanen. Untuk histori durabel Anda menyimpan event itu sendiri (yang persis apa adanya tabel audit-log kita).

Consumer native-nya adalah sebuah Lambda trigger: DynamoDB memanggil fungsi Anda dengan sebuah batch stream record baru saat mereka tiba.

Contoh dikerjakan: alert pada event audit sensitif

Tabel audit-log mendapat sebuah stream dengan NEW_IMAGE, sehingga setiap record membawa event baru penuh. Sebuah Lambda mengonsumsi batch dan meneruskan hanya record yang penting:

Fungsi tidak pernah menyentuh tabel — ia bereaksi murni terhadap apa yang diserahkan stream padanya. Tanpa polling, tanpa scan, dan alert menyala dalam hitungan detik dari penulisan. Stream record terurut per Item, jadi perubahan berturut-turut pada Item event yang sama tiba dalam urutan saat mereka ditulis.

Ini juga cara standar untuk memelihara salinan downstream: sebuah stream consumer bisa mem-project setiap event ke OpenSearch untuk pencarian audit teks-penuh, atau mengagregasi hitungan — semuanya diturunkan dari log perubahan yang sama.

Lakukan di DynoTable

Sebelum Anda menyambungkan sebuah stream consumer, Anda perlu tahu bentuk persis Item yang akan diterima Lambda Anda — atribut mana yang ada, bagaimana map dan list bersarang terlihat, apa yang akan benar-benar dikandung sebuah record NEW_IMAGE.

Untuk mengonversi sebuah Item contoh antara JSON biasa dan bentuk attribute-value yang dipakai sebuah stream record, DynamoDB JSON Converter melakukannya di browser Anda. Dan di DynoTable, Anda bisa menginspeksi Item penuh — termasuk bentuk DynamoDB-JSON-nya — sehingga Anda memodelkan record NEW_IMAGE terhadap data nyata alih-alih menebak bentuk field.

Jika Anda menguji sebuah consumer secara lokal, jalankan tabel terhadap DynamoDB Local dan inspeksi dengan cara yang sama — lihat connect ke DynamoDB Local.

Jebakan dan langkah selanjutnya

• 24 jam bukan sebuah backlog. Jika consumer Anda mati selama sehari, record menua keluar dan hilang. Streams adalah untuk reaksi mendekati-real-time, bukan replay durabel — simpan event itu sendiri untuk histori.
• Pilih StreamViewType terkecil yang Anda butuhkan. NEW_AND_OLD_IMAGES menggandakan payload; jika Anda hanya butuh key untuk membaca ulang Item, KEYS_ONLY lebih murah.
• Pengurutan per Item, bukan per partition key atau global. DynamoDB menjamin urutan hanya untuk perubahan berturut-turut pada Item yang sama; tidak ada jaminan pengurutan lintas Item berbeda, bahkan dalam satu partition key.
• Penghapusan TTL muncul sebagai stream record dengan penanda system-attribute, yang itulah cara Anda mengarsipkan Item yang kedaluwarsa — lihat DynamoDB TTL.

Streams mengubah audit log menjadi sumber event. Perhatian operasional berikutnya adalah ujung berlawanan dari umur sebuah Item — mengedaluwarsakan event lama secara otomatis dengan DynamoDB TTL.

Unduh DynoTable untuk menginspeksi bentuk Item persis yang akan diterima stream consumer Anda sebelum Anda menulis satu baris kode Lambda.