Temporäre Datensätze mit TTL ablaufen lassen

Einführung

Temporäre Sitzungsdatensätze sollten nach ihrem Ablauf nicht mehr ausgegeben werden, auch wenn die Speicherbereinigung noch nicht stattgefunden hat. Du aktivierst TTL, korrigierst ein Ablaufattribut mit falschem Datentyp und konfigurierst eine bereitgestellte Anwendung so, dass sie abgelaufene Daten bei echten Lesevorgängen im Dienst ausschließt.

Schließe zuerst „Eine DynamoDB-Tabelle für Bestellungen erstellen“ und „Bestellungen mit einem Partitions- und Sortierschlüssel abfragen“ ab. Die neue Umgebung stellt eine unabhängige Sitzungstabelle, drei synthetische Datensätze und ein Lesegerüst bereit, damit du TTL und den Lesefilter konfigurieren kannst. Verwende /home/labex/project, die offizielle AWS CLI und AWS View. Dieses Lab bewertet die TTL-Konfiguration und Lesevorgänge, die den Ablauf berücksichtigen; es verspricht keine Frist für die Hintergrundlöschung in AWS.

Bezug zu Zertifizierungen

Lab-Überblick

Den Ablauf für die vorbereitete Sitzungstabelle aktivieren

In diesem Schritt konfigurierst du das Ablaufattribut einer Tabelle. Time to Live (TTL) ermöglicht DynamoDB, abgelaufene Elemente zu einem späteren Zeitpunkt zu entfernen. Es handelt sich um eine asynchrone Bereinigung, nicht um einen Timer, der jedes Element genau in seiner Ablaufsekunde löscht. Anwendungen müssen abgelaufene Daten weiterhin zurückweisen, solange die Löschung durch den Dienst aussteht.

Bei diesem Sitzungsleser sind die Freigabe eines Datensatzes für die Anwendung und seine Entfernung aus dem Speicher getrennte Ergebnisse. Du prüfst den TTL-Status, korrigierst den Ablaufdatentyp und vergleichst dann Anwendung und direkten Lesezugriff. ENABLED belegt die Konfiguration; das Auslassen einer abgelaufenen Sitzung belegt die Leseregel, nicht die Löschung durch den Dienst.

Die neue Umgebung enthält eine Sitzungstabelle mit aktiven, abgelaufenen und permanenten synthetischen Datensätzen. Prüfe ihre Typen und den deaktivierten TTL-Zustand, bevor du etwas aktivierst.

cd /home/labex/project

aws dynamodb scan --table-name labex-d05-sessions --consistent-read

aws dynamodb describe-time-to-live --table-name labex-d05-sessions

Aktiviere TTL für expires_at. Jedes Element liefert seine eigene Ablaufzeit; die Tabellenkonfiguration wählt aus, welches Attribut der TTL-Dienst prüft. Fehlt das Attribut, hat dieses Element keinen TTL-Ablauf.

aws dynamodb update-time-to-live \
  --table-name labex-d05-sessions \
  --time-to-live-specification Enabled=true,AttributeName=expires_at

aws dynamodb describe-time-to-live --table-name labex-d05-sessions

Fahre fort, wenn die Beschreibung ENABLED und expires_at meldet. In AWS kann die Aktivierung Zeit benötigen; wiederhole den describe-Befehl während ENABLING, statt die Konfiguration wiederholt zu ändern. Betrachte AWS View oben und klappe den TTL-Eintrag in der Sitzungskarte auf.

Den Attributtyp des abgelaufenen Datensatzes korrigieren

In diesem Schritt speicherst du einen gültigen Ablaufwert. DynamoDB-TTL verlangt einen Wert vom Typ Number, der Unix-Epochensekunden enthält: Sekunden seit dem 01.01.1970 UTC. Millisekunden würden einen Zeitpunkt in ferner Zukunft ergeben. Eine Zeichenkette, die wie ein Zeitstempel aussieht, bleibt vom Typ String, und der TTL-Prozess ignoriert sie.

Prüfe den abgelaufenen Beispieldatensatz anhand seines genauen Schlüssels. Sein expires_at ist absichtlich mit S kodiert; die Aktivierung von TTL hat seinen Typ nicht korrigiert.

aws dynamodb get-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --consistent-read

Berechne mit dem Linux-Befehl date eine Ablaufzeit eine Stunde in der Vergangenheit. +%s gibt Unix-Sekunden aus, und $(...) speichert diese Ausgabe in EXPIRED. Der Wert ändert sich bei jeder Ausführung; er muss vor dem jetzigen Zeitpunkt liegen.

EXPIRED=$(date -u -d '1 hour ago' +%s)
echo "$EXPIRED"

Trage den typisierten Wert in eine kleine JSON-Datei ein. Dieses Heredoc verwendet das Trennwort JSON ohne Anführungszeichen, damit die Shell $EXPIRED durch deinen Zeitstempel ersetzt; frühere Trennwörter mit Anführungszeichen ließen die Werte unverändert. JSON in einer Datei zu speichern erspart das Maskieren seiner Anführungszeichen.

cat > expiry-values.json <<JSON
{":expires":{"N":"$EXPIRED"}}
JSON

Verwende UpdateItem, um nur das Ablaufattribut zu ersetzen. file:// lädt die Wertedatei; die Existenzbedingung verhindert, dass ein Datensatz erneut erstellt wird, falls die asynchrone Löschung ihn bereits entfernt hat.

aws dynamodb update-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --update-expression 'SET expires_at = :expires' \
  --condition-expression 'attribute_exists(session_id)' \
  --expression-attribute-values file://expiry-values.json \
  --return-values ALL_NEW

Das zurückgegebene abgelaufene Element hat expires_at: {"N": "..."} in der Vergangenheit und behält seinen Zweck bei. Das aktive Element bleibt in der Zukunft; das permanente Element hat weiterhin keine Ablaufzeit. Falls der Datensatz in AWS vor einem späteren Lese- oder Aktualisierungsvorgang entfernt wurde, betrachte dies erst nach einer erfolgreichen Dienstantwort als Löschung, nicht bei einem Verbindungsfehler.

Abgelaufene Daten im Leseweg der Anwendung ausschließen

In diesem Schritt schützt du Lesevorgänge, während die TTL-Bereinigung aussteht. Eine bereitgestellte Anwendung session-reader liest gewöhnliche Einstellungen aus session-reader.json und führt tatsächliche Scan-Anfragen aus. Ihre Standardkonfiguration gibt absichtlich auch abgelaufene Daten zurück. Der Quellcode der Anwendung steht zur Einsicht bereit; du musst kein Python schreiben.

./session-reader

In dieser Umgebung gibt die ungefilterte Leseanwendung weiterhin alle drei Datensätze zurück, einschließlich expired. Dies belegt keine fehlerhafte TTL-Konfiguration. Die Hintergrundlöschung in AWS kann später stattfinden, und kein genauer Zeitplan gehört zu den Abnahmekriterien dieses Labs.

Aktiviere den Ablauffilter der Anwendung. Ein Heredoc mit Anführungszeichen schreibt JSON unverändert und ersetzt die Einstellungsdatei.

cat > session-reader.json <<'JSON'
{
  "table": "labex-d05-sessions",
  "filter_expired": true
}
JSON

./session-reader

Die Anwendung verwendet attribute_not_exists(expires_at) OR expires_at > :now mit aktuellen Sekunden vom Typ Number und folgt den Scan-Fortsetzungsschlüsseln. Sie gibt jetzt nur active und permanent mit Count 2 und FilterExpired true zurück. Der permanente Datensatz ist beabsichtigt, weil für ihn keine Ablaufregel gilt. Das Filtern verhindert die Ausgabe abgelaufener Daten, macht aber die Lesearbeit eines Scans nicht rückgängig.

Vergleiche den direkten Lesevorgang anhand des Schlüssels mit dem Anwendungsergebnis.

aws dynamodb get-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --consistent-read

Der direkte Lesevorgang kann weiterhin expired enthalten, während die Anwendung es ausschließt. Falls AWS es bereits gelöscht hat, ist ein erfolgreicher leerer GetItem-Aufruf ebenfalls mit TTL vereinbar. AWS View zeigt die TTL-Konfiguration und das tatsächliche Leseergebnis mit zwei Elementen, ohne vorzutäuschen, dass das Filtern den gespeicherten Datensatz physisch gelöscht hätte.

Die eigene Sitzungstabelle entfernen

In diesem Schritt bereinigst du die Tabelle ausdrücklich, nachdem du die Ablaufkonfiguration und das Anwendungsverhalten geprüft hast. Warte nicht darauf, dass TTL die gesamte Tabelle entfernt: TTL löscht Elemente, nicht die Tabelle selbst. Beim Löschen dieser temporären Tabelle wird auch ihre TTL-Konfiguration entfernt.

aws dynamodb delete-table --table-name labex-d05-sessions

aws dynamodb wait table-not-exists --table-name labex-d05-sessions

aws dynamodb list-tables

aws dynamodb get-item \
  --table-name labex-d05-reference \
  --key '{"id":{"S":"platform"}}' \
  --consistent-read

Nur die Referenztabelle bleibt erhalten, und ihre Notiz lautet keep unchanged. Erfolgreiche Bestands- und Referenzabfragen belegen, dass die Verbindung nach der Löschung weiterhin funktioniert. AWS View entfernt die Sitzungstabelle und das Leseergebnis. Die temporäre Verbindung endet mit dieser VM.

Zusammenfassung

Du hast TTL für expires_at aktiviert, einen Zeichenketten-Zeitstempel durch numerische Epochensekunden ersetzt und abgelaufene Sitzungen in einem echten Anwendungsleseweg ausgeschlossen. Du hast den logischen Ablauf von der asynchronen physischen Löschung unterschieden und permanente Datensätze bewusst erhalten. Abschließend hast du die eigene Tabelle gelöscht und die unbeteiligte Referenz bewahrt.

Weitere Informationen bietet die AWS-Dokumentation: TTL-Ablauf und asynchrones Löschen von Elementen.