DynamoDB TTL: la guida completa alla scadenza degli item

Time to Live (TTL) permette a DynamoDB di eliminare automaticamente gli item una volta che un timestamp che memorizzi su di essi è trascorso. Nomini un attributo che contiene una scadenza Unix-epoch, e DynamoDB rimuove gli item scaduti in background — nessun job di reaper, nessun costo aggiuntivo.

Nello scenario dell'audit-log ogni tenant ha una policy di conservazione: mantieni gli eventi per 90 giorni, o 1 anno, o 7 per quelli con requisiti di compliance pesanti. Il TTL è il modo in cui applichi questo senza eseguire il tuo delete sweep.

Come funziona il TTL di DynamoDB?

Il TTL di DynamoDB elimina automaticamente gli item una volta che un timestamp Unix-epoch (secondi) che memorizzi in un attributo designato è trascorso. Abiliti il TTL sulla tabella, nomini l'attributo di scadenza e DynamoDB rimuove gli item scaduti in background — di solito entro qualche giorno, senza alcun costo di capacità di scrittura. Gli item scaduti restano leggibili finché non vengono fisicamente eliminati.

• Il TTL è un attributo che contiene un timestamp Unix-epoch (secondi). Quando quel momento passa, l'item diventa idoneo all'eliminazione.
• L'eliminazione è in background e best-effort — di solito entro qualche giorno dalla scadenza, non al secondo esatto.
• Le delete di TTL sono gratuite — non consumano capacità di scrittura, anche se su una global table la delete replicata costa una scrittura in ogni altra regione di replica.
• Gli item scaduti ma non ancora eliminati compaiono comunque nelle letture, quindi filtra sull' attributo di scadenza se hai bisogno di nasconderli immediatamente.

Il problema: far scadere i vecchi dati da soli è costoso

Senza TTL, applicare "elimina gli eventi più vecchi di 90 giorni" significa eseguire il tuo reaper: scansiona (o interroga) gli item vecchi a intervalli e fai DeleteItem su ciascuno. Quello scan brucia capacità di lettura, le delete bruciano capacità di scrittura e possiedi tu la schedulazione, i fallimenti e i retry.

Per un audit log ad alto volume è una tassa costante e crescente solo per buttare via i dati. Il TTL sposta l'intero lavoro dentro DynamoDB, gratis.

Come funziona il TTL

Abiliti il TTL su una tabella e le dici quale attributo contiene la scadenza. Secondo l' annuncio AWS, designi un attributo dell'item che contiene un timestamp di scadenza Unix-epoch, e DynamoDB gestisce l'eliminazione automaticamente in background senza intaccare le prestazioni della tabella.

Due proprietà contano per la correttezza:

• È best-effort, non esatto. DynamoDB scansiona gli item scaduti e li elimina in background; l'eliminazione di solito avviene entro qualche giorno dalla scadenza. Un item è idoneo al suo timestamp ma può attardarsi brevemente.
• Gli item scaduti sono ancora leggibili finché non vengono rimossi. Una Query può restituire un item il cui TTL è passato ma che non è ancora stato eliminato — quindi aggiungi una FilterExpression sull'attributo di scadenza se "scaduto = invisibile immediatamente" è un requisito rigido.

E le delete di TTL non consumano capacità di scrittura, il che è ciò che lo rende strettamente più economico di un reaper eseguito da te.

Un esempio pratico: conservazione per-tenant

Ogni evento di audit porta un attributo expiresAt impostato quando l'evento è scritto — ora + la finestra di conservazione del tenant, in secondi epoch:

Il TTL è abilitato con expiresAt come attributo TTL. Quando l'evento a 90 giorni di acme supera 1782259200, DynamoDB lo elimina da solo entro circa due giorni. Gli eventi del tenant di compliance portano un expiresAt molto lontano nel futuro, quindi sopravvivono — stessa tabella, stesso meccanismo, conservazione diversa per item.

Il lato scrittura consiste semplicemente nell'aggiungere un numero quando crei l'evento. Puoi comporre la clausola SET expiresAt = :ttl e verificare il valore tipizzato :ttl nel DynamoDB Expression Builder.

Per nascondere immediatamente da una lettura un evento scaduto ma non rimosso, aggiungi expiresAt > :now alla FilterExpression della query — anche se ricorda che un filtro non riduce il costo di lettura (query vs scan).

Fallo in DynoTable

Il classico bug del TTL è un expiresAt sbagliato: memorizzato in millisecondi invece che in secondi, o come stringa ISO, così che l'item o non scade mai o svanisce immediatamente. L'unico modo per intercettarlo è guardare il valore effettivamente memorizzato e il suo tipo.

DynoTable mostra gli attributi di ciascun item con i loro tipi DynamoDB, così puoi confermare che expiresAt sia un Number in secondi epoch — non una String, non millisecondi — prima di affidare al TTL una conservazione reale.

Insidie e passaggi successivi

• Secondi epoch, come Number. Questo è l'errore di TTL più comune in assoluto. Un valore in millisecondi spinge la scadenza a ~50.000 anni nel futuro; una stringa ISO viene ignorata del tutto. Verifica il tipo e l'unità. Incolla il valore nel convertitore TTL — rileva automaticamente se sono secondi o millisecondi e segnala esattamente questo errore.
• Non affidarti alla tempistica dell'eliminazione. Possono passare alcuni giorni tra la scadenza e l'eliminazione. Se conta "sparito nell'istante in cui scade", filtra sull'attributo nelle letture; non assumere che la riga sia fisicamente sparita.
• Le delete di TTL compaiono in Streams. Un'eliminazione di TTL emette un record di stream marcato come generato dal sistema — l'hook standard per l'archiviazione degli eventi in scadenza su S3 prima che spariscano. Vedi DynamoDB Streams.
• Le delete di TTL colpiscono comunque le GSI. Rimuovere un item lo rimuove anche da qualsiasi indice secondario in cui si trovava — che è la pulizia prevista, ma vale la pena saperlo se un indice guidava un conteggio.

Il TTL gestisce la fine della vita di un evento in modo economico. La prossima domanda è cosa paghi per le scritture in primo luogo — capacità On-Demand vs Provisioned.

Scarica DynoTable per ispezionare i tipi degli attributi dei tuoi item e confermare che il tuo attributo TTL sia un Number Unix-epoch prima di attivare il TTL.