Caducar registros temporales con TTL

Introducción

Los registros temporales de sesión deben dejar de servirse al caducar, aunque todavía no se haya limpiado el almacenamiento. Habilitarás TTL, corregirás un atributo de caducidad con un tipo incorrecto y configurarás una aplicación suministrada para excluir datos caducados mediante lecturas reales del servicio.

Completa primero Crear una tabla de DynamoDB para pedidos y Consultar pedidos con una clave de partición y una clave de ordenación. El entorno nuevo proporciona una tabla de sesiones independiente, tres registros sintéticos y una aplicación base de lectura, listos para configurar TTL y el filtro de lectura. Usa /home/labex/project, la AWS CLI oficial y AWS View. Este laboratorio evalúa la configuración de TTL y las lecturas que tienen en cuenta la caducidad; no promete un plazo para la eliminación en segundo plano de AWS.

Relación con las certificaciones

Vista general del laboratorio

Habilitar la caducidad en la tabla de sesiones preparada

En este paso, configurarás el atributo de caducidad de una tabla. Time to Live (TTL) permite que DynamoDB elimine los elementos caducados con el tiempo. Es una tarea de mantenimiento asíncrona, no un temporizador que elimina cada elemento en el segundo exacto de su caducidad. Las aplicaciones deben seguir rechazando los datos caducados mientras esté pendiente su eliminación por el servicio.

Para este lector de sesiones, poder servir un registro y eliminarlo del almacenamiento son resultados distintos. Revisarás el estado de TTL, repararás el tipo de caducidad y compararás la aplicación con una lectura directa. ENABLED demuestra la configuración; omitir una sesión caducada demuestra la política de lectura, no que el servicio haya eliminado el elemento.

El entorno nuevo contiene una tabla de sesiones con registros sintéticos activos, caducados y permanentes. Inspecciona sus tipos y el estado deshabilitado de TTL antes de habilitar nada.

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

Habilita TTL en expires_at. Cada elemento proporciona su propia hora de caducidad; la configuración de la tabla selecciona qué atributo examina el servicio TTL. Si falta el atributo, ese elemento no tiene caducidad por TTL.

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

Continúa cuando la descripción indique ENABLED y expires_at. En AWS, la habilitación puede tardar; repite el comando de descripción mientras el estado sea ENABLING en lugar de cambiar la configuración repetidamente. Observa AWS View en la parte superior y expande la entrada TTL dentro de la tarjeta de sesiones.

Corregir el tipo de atributo del registro caducado

En este paso, almacenarás un valor de caducidad válido. TTL de DynamoDB requiere un Number que contenga segundos del epoch Unix: segundos desde 1970-01-01 UTC. Los milisegundos representarían una fecha muy lejana en el futuro. Una cadena que parece una marca de tiempo sigue siendo un String, y el proceso TTL la ignora.

Inspecciona el registro de prueba caducado mediante su clave exacta. Su expires_at está codificado deliberadamente con S; habilitar TTL no corrigió su tipo.

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

Calcula una caducidad de hace una hora con el comando date de Linux. +%s imprime segundos Unix, y $(...) guarda esa salida en EXPIRED. El valor cambia cada vez; debe ser anterior al momento actual.

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

Coloca el valor tipado en un pequeño archivo JSON. Este heredoc utiliza un delimitador JSON sin comillas para que el shell sustituya $EXPIRED por tu marca de tiempo; los delimitadores anteriores entre comillas conservaban los valores literalmente. Mantener el JSON en un archivo evita tener que escapar sus comillas.

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

Usa UpdateItem para sustituir únicamente el atributo de caducidad. file:// carga el archivo de valores; la condición de existencia evita recrear un registro si la eliminación asíncrona ya lo ha quitado.

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

El elemento caducado devuelto tiene expires_at: {"N": "..."} en el pasado y conserva su propósito. El elemento activo permanece en el futuro; el permanente sigue sin caducidad. En AWS, si el registro desapareció antes de una lectura o actualización posterior, considéralo una eliminación solo tras una respuesta correcta del servicio, no ante un fallo de conexión.

Excluir datos caducados en la ruta de lectura de la aplicación

En este paso, protegerás las lecturas mientras esté pendiente la limpieza de TTL. La aplicación suministrada session-reader lee la configuración ordinaria de session-reader.json y realiza solicitudes Scan reales. Su configuración predeterminada devuelve deliberadamente también los datos caducados. El código fuente de la aplicación está disponible para inspeccionarlo; no es necesario escribir Python.

./session-reader

En este entorno, el lector sin filtro sigue devolviendo los tres registros, incluido expired. Esto no demuestra que TTL esté mal configurado. La eliminación en segundo plano de AWS puede ocurrir más tarde, y ningún calendario preciso forma parte de la aceptación de este laboratorio.

Habilita el filtro de caducidad de la aplicación. Un heredoc entre comillas escribe el JSON literalmente y sustituye el archivo de configuración.

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

./session-reader

La aplicación utiliza attribute_not_exists(expires_at) OR expires_at > :now con los segundos actuales de tipo Number y sigue las claves de continuación de Scan. Ahora devuelve solo active y permanent, con Count 2 y FilterExpired true. El registro permanente es intencionado porque no tiene una política de caducidad. El filtrado evita servir datos caducados, pero no deshace el trabajo de lectura de un escaneo.

Compara la lectura directa por clave con el resultado de la aplicación.

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

La lectura directa todavía puede contener expired mientras la aplicación lo excluye. Si AWS ya lo ha eliminado, una respuesta GetItem correcta y vacía también es compatible con TTL. AWS View muestra la configuración de TTL y el resultado real de dos elementos del lector sin dar a entender que el filtrado eliminó físicamente el registro almacenado.

Eliminar la tabla de sesiones del laboratorio

En este paso, limpiarás explícitamente la tabla después de comprobar la configuración de caducidad y el comportamiento de la aplicación. No esperes que TTL elimine la tabla completa: TTL elimina elementos, no la tabla en sí. Eliminar esta tabla desechable también elimina su configuración de TTL.

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

Solo permanece la tabla de referencia y su nota es keep unchanged. Las lecturas correctas del inventario y de la referencia demuestran que la conexión sigue funcionando después de la eliminación. AWS View retira la tabla de sesiones y el resultado del lector. La conexión desechable termina con esta VM.

Resumen

Habilitaste TTL en expires_at, sustituiste una marca de tiempo de tipo cadena por segundos epoch numéricos y excluiste sesiones caducadas en una ruta real de lectura de la aplicación. Distinguiste la caducidad lógica de la eliminación física asíncrona y conservaste deliberadamente los registros permanentes. Por último, eliminaste la tabla del laboratorio y preservaste la referencia ajena a él.

Para ampliar este tema, consulta la referencia de AWS: Caducidad TTL y eliminación asíncrona de elementos.