DynamoDB TTL

Time to Live (TTL) memungkinkan DynamoDB menghapus Item secara otomatis begitu sebuah timestamp yang Anda simpan padanya terlewati. Anda menamai satu atribut yang menyimpan kedaluwarsa Unix-epoch, dan DynamoDB memanen Item yang kedaluwarsa di latar belakang — tanpa job reaper, tanpa biaya ekstra.

Dalam skenario audit-log setiap tenant punya kebijakan retensi: simpan event selama 90 hari, atau 1 tahun, atau 7 untuk yang berat-kepatuhan. TTL adalah cara Anda menegakkan itu tanpa menjalankan sapuan penghapusan Anda sendiri.

Bagaimana cara kerja DynamoDB TTL?

DynamoDB TTL menghapus Item secara otomatis begitu timestamp Unix-epoch (detik) yang Anda simpan dalam atribut yang ditentukan terlewati. Anda mengaktifkan TTL pada tabel, menamai atribut kedaluwarsa, dan DynamoDB memanen Item yang kedaluwarsa di latar belakang — biasanya dalam 48 jam, tanpa biaya write capacity. Item yang kedaluwarsa tetap dapat dibaca sampai benar-benar dihapus.

• TTL adalah satu atribut yang menyimpan timestamp Unix-epoch (detik). Saat waktu itu terlewati, Item menjadi memenuhi syarat untuk dihapus.
• Penghapusan bersifat latar belakang dan best-effort — biasanya dalam beberapa hari dari kedaluwarsa, bukan detik persisnya. AWS menargetkan dalam 48 jam.
• Penghapusan TTL gratis — mereka tidak mengonsumsi write capacity.
• Item yang kedaluwarsa-tetapi-belum-dihapus tetap muncul dalam pembacaan, jadi filter pada atribut kedaluwarsa jika Anda perlu menyembunyikannya segera.

Masalahnya: mengakhiri data lama sendiri itu mahal

Tanpa TTL, menegakkan "buang event yang lebih tua dari 90 hari" berarti menjalankan reaper Anda sendiri: scan (atau query) untuk Item lama pada jadwal dan DeleteItem setiap satu. Scan itu membakar read capacity, penghapusan membakar write capacity, dan Anda memiliki jadwal, kegagalan, dan retry-nya.

Untuk audit log bervolume tinggi itu adalah pajak yang konstan dan terus tumbuh hanya untuk membuang data. TTL memindahkan seluruh pekerjaan ke dalam DynamoDB, secara gratis.

Cara kerja TTL

Anda mengaktifkan TTL pada sebuah tabel dan memberi tahu atribut mana yang menyimpan kedaluwarsa. Menurut pengumuman AWS, Anda "menentukan sebuah atribut Item yang berisi timestamp kedaluwarsa Unix epoch, dan DynamoDB menangani penghapusan secara otomatis di latar belakang — tanpa memengaruhi performa tabel."

Dua properti penting untuk kebenaran:

• Ia best-effort, bukan persis. DynamoDB men-scan Item yang kedaluwarsa dan menghapusnya di latar belakang; AWS menargetkan penghapusan dalam 48 jam dari kedaluwarsa. Sebuah Item memenuhi syarat pada timestamp-nya tetapi mungkin berlama-lama sebentar.
• Item yang kedaluwarsa tetap dapat dibaca sampai dipanen. Sebuah Query dapat mengembalikan Item yang TTL-nya sudah terlewati tetapi belum dihapus — jadi tambahkan sebuah FilterExpression pada atribut kedaluwarsa jika "kedaluwarsa = tidak terlihat segera" adalah persyaratan yang keras.

Dan penghapusan TTL tidak mengonsumsi write capacity, yang membuatnya benar-benar lebih murah daripada reaper yang dijalankan sendiri.

Contoh terkerjakan: retensi per-tenant

Setiap event audit membawa sebuah atribut expiresAt yang disetel saat event ditulis — now + jendela retensi tenant, dalam epoch seconds:

TTL diaktifkan dengan expiresAt sebagai atribut TTL. Saat event 90 hari acme melintasi 1758873600, DynamoDB menghapusnya sendiri dalam waktu kira-kira dua hari. Event tenant kepatuhan membawa expiresAt masa-depan-jauh, jadi mereka bertahan — tabel sama, mekanisme sama, retensi berbeda per Item.

Sisi penulisan hanyalah menambahkan satu angka saat Anda membuat event. Anda dapat menyusun klausa SET expiresAt = :ttl dan memverifikasi nilai :ttl bertipe di DynamoDB Expression Builder.

Untuk menyembunyikan event yang kedaluwarsa-tetapi-belum-dipanen dari sebuah pembacaan segera, tambahkan expiresAt > :now ke FilterExpression query — meskipun ingat sebuah filter tidak mengurangi biaya pembacaan (query vs scan).

Lakukan di DynoTable

Bug TTL klasik adalah expiresAt yang salah: disimpan dalam milidetik alih-alih detik, atau sebagai string ISO, sehingga Item entah tidak pernah kedaluwarsa atau lenyap seketika. Satu-satunya cara menangkapnya adalah melihat nilai aktual yang tersimpan dan tipenya.

DynoTable menampilkan atribut setiap Item dengan tipe DynamoDB-nya, jadi Anda dapat mengonfirmasi expiresAt adalah Number dalam epoch seconds — bukan String, bukan milidetik — sebelum Anda memercayakan TTL dengan retensi nyata.

Jebakan dan langkah berikutnya

• Epoch seconds, sebagai Number. Ini adalah kesalahan TTL paling umum. Nilai milidetik mendorong kedaluwarsa ~50.000 tahun ke depan; sebuah string ISO diabaikan sepenuhnya. Verifikasi tipe dan unitnya.
• Jangan mengandalkan waktu penghapusan. Hingga ~48 jam dapat berlalu antara kedaluwarsa dan penghapusan. Jika "hilang saat itu juga ia kedaluwarsa" penting, filter pada atributnya dalam pembacaan; jangan asumsikan barisnya sudah hilang secara fisik.
• Penghapusan TTL muncul di Streams. Sebuah penghapusan TTL mengeluarkan record stream yang ditandai sebagai system-generated — hook standar untuk mengarsipkan event yang kedaluwarsa ke S3 sebelum mereka menghilang. Lihat DynamoDB Streams.
• Penghapusan TTL tetap mengenai GSI. Menghapus sebuah Item juga menghapusnya dari secondary index mana pun yang ia ada di dalamnya — yang merupakan pembersihan yang dimaksudkan, tetapi perlu diketahui jika sebuah index menggerakkan sebuah hitungan.

TTL menangani akhir hidup sebuah event dengan murah. Pertanyaan berikutnya adalah apa yang Anda bayar untuk penulisan di tempat pertama — On-Demand vs Provisioned capacity.

Unduh DynoTable untuk memeriksa tipe atribut Item Anda dan mengonfirmasi atribut TTL Anda adalah Number Unix-epoch sebelum Anda menyalakan TTL.