DynamoDB TTL: Öğeleri Süreyle Silmenin Eksiksiz Rehberi

Time to Live (TTL), üzerlerinde sakladığın bir zaman damgası geçtiğinde DynamoDB'nin item'ları otomatik olarak silmesini sağlar. Bir Unix-epoch süre sonu tutan bir niteliği adlandırırsın ve DynamoDB, süresi dolan item'ları arka planda biçer — biçme işi yok, ekstra 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ğırlıklı olanlar için 7 yıl tut. TTL, bunu kendi silme süpürmeni çalıştırmadan uygulamanın yoludur.

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

DynamoDB TTL, belirlenmiş bir nitelikte sakladığın bir Unix-epoch (saniye) zaman damgası geçtiğinde item'ları otomatik siler. Tabloda TTL'i etkinleştirir, süre sonu niteliğini adlandırırsın ve DynamoDB, süresi dolan item'ları arka planda biçer — tipik olarak birkaç gün içinde, yazma-kapasitesi maliyeti olmadan. Süresi dolan item'lar, fiziksel olarak silinene kadar okunabilir kalır.

• TTL, bir Unix-epoch (saniye) zaman damgası tutan tek bir niteliktir. O zaman geçtiğinde, item silinmeye uygun hale gelir.
• Silme arka planda ve en iyi çabayla yapılır — tipik olarak süre sonundan sonraki birkaç gün içinde, tam saniyede değil.
• TTL silmeleri bedavadır — yazma kapasitesi tüketmezler, ancak bir global tabloda, çoğaltılan silme diğer her replika bölgesinde bir yazmaya mal olur.
• Süresi dolmuş ama henüz silinmemiş item'lar hâlâ görünür okumalarda, bu yüzden onları hemen gizlemen gerekiyorsa süre sonu niteliği üzerinde filtrele.

Sorun: eski veriyi kendin süresini doldurmak pahalıdır

TTL olmadan, "90 günden eski olayları düşür"ü uygulamak, kendi biçicini çalıştırmak demektir: eski item'lar için bir zamanlamada tara (ya da sorgula) ve her birini DeleteItem yap. O tarama okuma kapasitesi yakar, silmeler yazma kapasitesi yakar ve zamanlamaya, arızalara ve yeniden denemelere sen sahip olursun.

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, bedavaya taşır.

TTL nasıl çalışır

Bir tabloda TTL'i etkinleştirir ve ona hangi niteliğin süre sonunu tuttuğunu söylersin. AWS duyurusuna göre, bir Unix-epoch süre sonu zaman damgası tutan bir item niteliği belirlersin ve DynamoDB, silmeyi tablo performansını etkilemeden arka planda otomatik olarak halleder.

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

• En iyi çabayla yapılır, tam değil. DynamoDB, süresi dolan item'lar için tarar ve onları arka planda siler; silme tipik olarak süre sonundan sonraki birkaç gün içinde gerçekleşir. Bir item, zaman damgasında uygundur ama kısa süre oyalanabilir.
• Süresi dolan item'lar biçilene kadar hâlâ okunabilir. Bir Query, TTL'i geçmiş ama henüz silinmemiş bir item döndürebilir — bu yüzden "süresi dolmuş = hemen görünmez" katı bir gereksinimse, süre sonu niteliği üzerinde bir FilterExpression ekle.

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

İşlenmiş bir örnek: kiracı başına saklama

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

TTL, TTL niteliği olarak expiresAt ile etkinleştirilir. acme'nin 90 günlük olayı 1782259200'ü geçtiğinde, DynamoDB onu yaklaşık iki gün içinde kendi kendine siler. Uyumluluk kiracısının olayları çok uzak-gelecek bir expiresAt taşır, bu yüzden hayatta kalırlar — aynı tablo, aynı mekanizma, item başına farklı saklama.

Yazma tarafı, olayı oluşturduğunda tek bir sayı eklemekten ibarettir. SET expiresAt = :ttl yan tümcesini oluşturabilir ve türlenmiş :ttl değerini DynamoDB Expression Builder'da doğrulayabilirsin.

Süresi dolmuş ama biçilmemiş bir olayı bir okumadan hemen gizlemek için, sorgunun FilterExpression'ına expiresAt > :now ekle — yine de unutma, bir filtre okuma maliyetini azaltmaz (query ve scan).

Bunu DynoTable'da yapın

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

DynoTable, her item'ın niteliklerini DynamoDB türleriyle gösterir; böylece TTL'e gerçek saklamayla güvenmeden önce expiresAt'in bir String değil, milisaniye değil, epoch saniye cinsinden bir Number olduğunu onaylayabilirsin.

Tuzaklar ve sonraki adımlar

• Epoch saniye, bir Number olarak. Bu, açık ara en yaygın TTL hatasıdır. Bir milisaniye değeri süre sonunu ~50.000 yıl ileri iter; bir ISO string tamamen yok sayılır. Türü ve birimi doğrula. Değeri TTL dönüştürücüsüne yapıştır — saniye ile milisaniyeyi otomatik algılar ve tam olarak bu hatayı işaretler.
• Silme zamanlamasına güvenme. Süre sonu ile silme arasında birkaç gün geçebilir. "Süresi dolduğu an gider" önemliyse, okumalarda nitelik üzerinde filtrele; satırın fiziksel olarak gittiğini varsayma.
• TTL silmeleri Streams'te görünür. Bir TTL silmesi, sistem-üretimli olarak işaretlenmiş bir akış kaydı yayar — süresi dolan olayları kaybolmadan önce S3'e arşivlemenin standart kancası. Bkz. DynamoDB Streams.
• TTL silmeleri GSI'lere de çarpar. Bir item'ı kaldırmak, onu içinde bulunduğu herhangi bir ikincil index'ten de kaldırır — amaçlanan temizlik budur, ama bir index bir sayımı yönlendiriyorsa bilmekte fayda var.

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

TTL niteliğinin, TTL'i açmadan önce bir Unix-epoch Number olduğunu doğrulamak ve item'larının nitelik türlerini incelemek için DynoTable'ı indir.