DynamoDB TTL: Panduan Lengkap Kedaluwarsa Item

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 menuai Item kedaluwarsa di latar belakang — tanpa pekerjaan reaper, tanpa biaya ekstra.

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

Bagaimana cara kerja DynamoDB TTL?

DynamoDB TTL menghapus-otomatis Item begitu sebuah timestamp Unix-epoch (detik) yang Anda simpan dalam sebuah atribut yang ditunjuk terlewati. Anda mengaktifkan TTL pada tabel, menamai atribut kedaluwarsa, dan DynamoDB menuai Item kedaluwarsa di latar belakang — biasanya dalam beberapa hari, tanpa biaya kapasitas-tulis. Item kedaluwarsa tetap dapat dibaca hingga secara fisik dihapus.

• TTL adalah satu atribut yang menyimpan timestamp Unix-epoch (detik). Ketika waktu itu terlewati, Item menjadi memenuhi syarat untuk penghapusan.
• Penghapusan bersifat latar belakang dan best-effort — biasanya dalam beberapa hari dari kedaluwarsa, bukan pada detik persisnya.
• Penghapusan TTL gratis — mereka tidak mengonsumsi kapasitas-tulis, meski pada global table delete ter-replikasi menelan sebuah penulisan di setiap region replika lainnya.
• Item yang kedaluwarsa-tapi-belum-dihapus tetap muncul dalam pembacaan, jadi filter pada atribut kedaluwarsa jika Anda perlu menyembunyikannya segera.

Masalahnya: mengedaluwarsakan data lama sendiri itu mahal

Tanpa TTL, menegakkan "buang event lebih tua dari 90 hari" berarti menjalankan reaper Anda sendiri: scan (atau query) untuk Item lama secara terjadwal dan DeleteItem satu per satu. Scan itu membakar kapasitas-baca, delete membakar kapasitas-tulis, dan Anda memiliki jadwal, kegagalan, dan retry-nya.

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

Cara kerja TTL

Anda mengaktifkan TTL pada sebuah tabel dan memberitahunya atribut mana yang menyimpan kedaluwarsa. Menurut pengumuman AWS, Anda menunjuk sebuah atribut Item yang menyimpan timestamp kedaluwarsa Unix-epoch, dan DynamoDB menangani penghapusan secara otomatis di latar belakang tanpa memengaruhi performa tabel.

Dua properti penting untuk kebenaran:

• Ini best-effort, bukan persis. DynamoDB men-scan Item kedaluwarsa dan menghapus mereka di latar belakang; penghapusan biasanya terjadi dalam beberapa hari dari kedaluwarsa. Sebuah Item memenuhi syarat pada timestamp-nya tetapi mungkin bertahan sebentar.
• Item kedaluwarsa tetap dapat dibaca hingga dituai. Sebuah Query bisa mengembalikan sebuah Item yang TTL-nya telah terlewati tetapi yang belum dihapus — jadi tambahkan sebuah FilterExpression pada atribut kedaluwarsa jika "kedaluwarsa = tak-terlihat segera" adalah kebutuhan keras.

Dan penghapusan TTL tidak mengonsumsi kapasitas-tulis, yang itulah yang membuatnya sungguh lebih murah dari sebuah reaper yang Anda jalankan sendiri.

Contoh dikerjakan: retensi per-tenant

Setiap event audit membawa sebuah atribut expiresAt yang di-set saat event ditulis — sekarang + jendela retensi tenant, dalam detik epoch:

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

Sisi penulisan hanya menambahkan satu angka saat Anda membuat event. Anda bisa menyusun klausa SET expiresAt = :ttl dan memverifikasi nilai :ttl bertipe di Pembuat Ekspresi DynamoDB.

Untuk menyembunyikan event kedaluwarsa-tapi-belum-dituai dari sebuah pembacaan segera, tambahkan expiresAt > :now ke FilterExpression query — meski ingat sebuah filter tidak mengurangi biaya baca (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 segera. Satu-satunya cara menangkapnya adalah melihat nilai yang benar-benar tersimpan dan tipenya.

DynoTable menampilkan atribut setiap Item dengan tipe DynamoDB-nya, sehingga Anda bisa mengonfirmasi expiresAt adalah Number dalam detik epoch — bukan String, bukan milidetik — sebelum Anda mempercayai TTL dengan retensi nyata.

Jebakan dan langkah selanjutnya

• Detik epoch, sebagai Number. Ini adalah kesalahan TTL paling umum. Sebuah nilai milidetik mendorong kedaluwarsa ~50.000 tahun keluar; sebuah string ISO diabaikan sepenuhnya. Verifikasi tipe dan unitnya. Tempel nilainya ke konverter TTL — ia mendeteksi detik vs milidetik secara otomatis dan menandai persis kesalahan ini.
• Jangan mengandalkan timing penghapusan. Beberapa hari bisa berlalu antara kedaluwarsa dan penghapusan. Jika "hilang seketika ia kedaluwarsa" penting, filter pada atribut dalam pembacaan; jangan asumsikan baris telah hilang secara fisik.
• Penghapusan TTL muncul di Streams. Sebuah penghapusan TTL memancarkan sebuah stream record 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 indeks sekunder mana pun ia berada — yang merupakan pembersihan yang dimaksudkan, tetapi patut diketahui jika sebuah indeks menggerakkan sebuah hitungan.

TTL menangani akhir umur sebuah event dengan murah. Pertanyaan berikutnya adalah apa yang Anda bayar untuk penulisan itu sejak awal — Kapasitas On-Demand vs Provisioned.

Unduh DynoTable untuk menginspeksi tipe atribut Item Anda dan mengonfirmasi atribut TTL Anda adalah sebuah Number Unix-epoch sebelum Anda mengaktifkan TTL.