DynamoDB TTL

Time to Live (TTL), üzerlerinde sakladığınız bir zaman damgası geçtiğinde DynamoDB'nin öğeleri otomatik olarak silmesini sağlar. Bir Unix-epoch süre dolumu tutan tek bir öznitelik adlandırırsınız ve DynamoDB süresi dolmuş öğeleri arka planda biçer — biçici iş yok, ek maliyet yok.

Denetim günlüğü senaryosunda her kiracının bir saklama politikası vardır: olayları 90 gün, ya da 1 yıl, ya da uyumluluk-ağır olanlar için 7 yıl sakla. TTL, bunu kendi silme süpürmenizi çalıştırmadan uygulamanın yoludur.

DynamoDB TTL nasıl çalışır?

DynamoDB TTL, belirlediğiniz bir öznitelikte sakladığınız Unix-epoch (saniye) zaman damgası geçtiğinde öğeleri otomatik olarak siler. Tabloda TTL'i etkinleştirir, süre dolumu özniteliğini adlandırırsınız ve DynamoDB süresi dolmuş öğeleri arka planda biçer — tipik olarak 48 saat içinde, yazma kapasitesi maliyeti olmadan. Süresi dolmuş öğeler fiziksel olarak silinene kadar okunabilir olmaya devam eder.

• TTL, bir Unix-epoch (saniye) zaman damgası tutan tek bir özniteliktir. O zaman geçtiğinde, öğe silinmeye uygun hale gelir.
• Silme arka plan ve best-effort'tur — tipik olarak süre dolumundan birkaç gün içinde, tam saniyede değil. AWS 48 saat içini hedefler.
• TTL silmeleri ücretsizdir — yazma kapasitesi tüketmezler.
• Süresi-dolmuş-ama-henüz-silinmemiş öğeler hâlâ görünür okumalarda, bu yüzden onları hemen gizlemeniz gerekiyorsa süre dolumu özniteliğinde filtreleyin.

Sorun: eski veriyi kendiniz süresi-doldurmak pahalıdır

TTL olmadan, "90 günden eski olayları düşür" uygulamak kendi biçicinizi çalıştırmak demektir: eski öğeler için bir zamanlamada tara (ya da query) ve her birini DeleteItem. O tarama okuma kapasitesi yakar, silmeler yazma kapasitesi yakar ve zamanlamanın, başarısızlıkların ve yeniden denemelerin sahibi sizsiniz.

Yüksek hacimli bir denetim günlüğü için bu, sadece veriyi atmak için sabit, büyüyen bir vergidir. TTL tüm işi DynamoDB'ye, ücretsiz olarak taşır.

TTL nasıl çalışır

Bir tabloda TTL etkinleştirir ve ona hangi özniteliğin süre dolumunu tuttuğunu söylersiniz. AWS duyurusuna göre, "bir Unix epoch süre dolumu zaman damgası içeren bir öğe özniteliği belirtirsiniz ve DynamoDB silmeyi arka planda otomatik olarak yönetir — tablo performansını etkilemeden."

Doğruluk için iki özellik önemlidir:

• Best-effort'tur, tam değil. DynamoDB süresi dolmuş öğeler için tarar ve onları arka planda siler; AWS silmeyi süre dolumundan 48 saat içinde hedefler. Bir öğe zaman damgasında uygundur ama kısa bir süre oyalanabilir.
• Süresi dolmuş öğeler biçilene kadar hâlâ okunabilir. Bir Query, TTL'si geçmiş ama henüz silinmemiş bir öğe döndürebilir — bu yüzden "süresi-dolmuş = hemen görünmez" katı bir gereksinimse süre dolumu özniteliğinde bir FilterExpression ekleyin.

Ve TTL silmeleri yazma kapasitesi tüketmez, ki bu onu kendi-çalıştırılan bir biçiciden kesinlikle daha ucuz kılan şeydir.

Çalışılmış bir örnek: kiracı bazında saklama

Her denetim olayı, olay yazıldığında ayarlanan bir expiresAt özniteliği taşır — şimdi + kiracının saklama penceresi, epoch saniye cinsinden:

TTL, TTL özniteliği olarak expiresAt ile etkinleştirilir. acme'nin 90-günlük olayı 1758873600'ı geçtiğinde, DynamoDB onu kabaca iki gün içinde kendiliğinden siler. Uyumluluk kiracısının olayları çok-uzak-gelecekte bir expiresAt taşır, böylece hayatta kalırlar — aynı tablo, aynı mekanizma, öğe başına farklı saklama.

Yazma tarafı, olayı oluşturduğunuzda yalnızca bir sayı eklemektir. SET expiresAt = :ttl ifadesini oluşturup türlenmiş :ttl değerini DynamoDB Expression Builder'da doğrulayabilirsiniz.

Süresi-dolmuş-ama-biçilmemiş bir olayı bir okumadan hemen gizlemek için, sorgunun FilterExpression'ına expiresAt > :now ekleyin — gerçi bir filtrenin okuma maliyetini azaltmadığını hatırlayın (query ile scan).

DynoTable'da yapın

Klasik TTL hatası yanlış bir expiresAt'tir: saniye yerine milisaniye olarak ya da bir ISO dizesi olarak saklanmış, böylece öğe ya hiç süresi dolmaz ya da hemen kaybolur. Bunu yakalamanın tek yolu, gerçek saklanan değere ve türüne bakmaktır.

DynoTable her öğenin özniteliklerini DynamoDB türleriyle gösterir, böylece TTL'ye gerçek saklama için güvenmeden önce expiresAt'in epoch saniye cinsinden bir Number olduğunu — bir String değil, milisaniye değil — doğrulayabilirsiniz.

Tuzaklar ve sonraki adımlar

• Epoch saniye, bir Number olarak. Bu, en yaygın tek TTL hatasıdır. Bir milisaniye değeri süre dolumunu ~50.000 yıl ileri iter; bir ISO dizesi tamamen yoksayılır. Türü ve birimi doğrulayın.
• Silme zamanlamasına güvenmeyin. Süre dolumu ile silme arasında ~48 saate kadar geçebilir. "Süresi dolduğu an gitti" önemliyse, okumalarda öznitelikte filtreleyin; satırın fiziksel olarak gittiğini varsaymayın.
• TTL silmeleri Streams'te görünür. Bir TTL silmesi, sistem-üretimi olarak işaretlenmiş bir stream kaydı yayar — süresi dolan olayları kaybolmadan önce S3'e arşivlemenin standart kancası. Bkz. DynamoDB Streams.
• TTL silmeleri yine de GSI'leri etkiler. Bir öğeyi kaldırmak, onu içinde bulunduğu herhangi bir ikincil index'ten de kaldırır — ki bu amaçlanan temizliktir, ama bir index bir sayımı yönettiyse bilmeye değer.

TTL bir olayın ömrünün sonunu ucuza yönetir. Sonraki soru, ilk etapta yazmalar için ne ödediğinizdir — On-Demand ile Provisioned kapasite.

Öğelerinizin öznitelik türlerini incelemek ve TTL'yi açmadan önce TTL özniteliğinizin bir Unix-epoch Number olduğunu doğrulamak için DynoTable'ı indirin.