El tiempo de actividad (TTL) te permite establecer políticas para borrar de forma periódica los datos de las tablas de Spanner. Quita los datos innecesarios:
- Disminuye los costos de almacenamiento y copias de seguridad.
- Reduce la cantidad de filas que la base de datos debe analizar para algunas consultas, lo que podría aumentar el rendimiento de la consulta.
- Ayuda a cumplir con las reglamentaciones o los lineamientos de la industria que limitan el tiempo de retención de ciertos tipos de datos.
El TTL es ideal para actividades de limpieza habituales. Se ejecuta de forma continua en segundo plano y borra periódicamente los datos aptos en lotes. Por lo general, los datos se borran en un plazo de 72 horas después de su fecha de vencimiento. El TTL no invalida los datos de inmediato ni los oculta de las consultas cuando se vuelve apto para su eliminación. El TTL tampoco verifica los datos mientras se insertan, por lo que no te impide insertar una fila con una marca de tiempo vencida.
El TTL está diseñado para minimizar el impacto en otras actividades de la base de datos. Paraleliza el trabajo de manera más eficiente que las consultas de usuario final y, además, incluye la lógica de reintento para garantizar la limpieza de extremo a extremo.
Otro proceso de compactación en segundo plano recupera el almacenamiento de las filas borradas, por lo general, en un plazo de siete días.
¿Cómo funciona el TTL?
Puedes configurar el TTL en las tablas de Spanner si defines una política de eliminación de filas en el esquema de la base de datos, lo que le permite a Spanner borrar de forma periódica los datos innecesarios. Cada tabla puede tener su propia política. Solo se puede especificar una política de TTL por tabla. Configura el TTL de manera diferente para las bases de datos con dialectos de GoogleSQL y las bases de datos PostgreSQL.
TTL con GoogleSQL
Con GoogleSQL, puedes definir una política de eliminación de filas mediante la especificación de una marca de tiempo y un intervalo a fin de determinar cuándo una fila es apta para su eliminación; por ejemplo, la fecha de la última actualización más 30 días.
Un proceso de sistema en segundo plano verifica a diario las filas aptas. Paraleliza las eliminaciones reales en lotes que se ejecutan cerca de donde se almacenan los datos internamente. Cada lote se ejecuta en su propia transacción en una marca de tiempo coherente. Por lo tanto, se garantiza que las filas en un lote determinado, junto con los índices y los elementos secundarios intercalados, se borrarán de forma atómica. Sin embargo, las eliminaciones entre lotes ocurren en transacciones diferentes.
Dado que este es un proceso en segundo plano asíncrono, hay un retraso entre la elegibilidad y la eliminación. Por lo general, la demora es menor a 72 horas. Como resultado, las filas pueden permanecer en tu tabla hasta tres días después del vencimiento de su TTL; por ejemplo, una tabla con una política de eliminación de filas que borra filas de más de cuatro días podría incluir filas de hasta siete días, así como filas más antiguas que no se pueden borrar.
Si deseas obtener instrucciones paso a paso para crear una política de eliminación de filas de GoogleSQL, consulta Crea una política de TTL.
TTL con PostgreSQL
Con PostgreSQL, el propietario de la base de datos puede usar una cláusula TTL INTERVAL en la instrucción CREATE TABLE o ALTER TABLE para definir una política de eliminación de filas.
Para establecer una política de eliminación de filas en una tabla de PostgreSQL, la tabla debe tener una columna con el tipo de datos TIMESTAMPTZ. La cláusula TTL INTERVAL usa esta columna para establecer una especificación de intervalo de cuándo una fila es apta para eliminación.
La cláusula debe evaluarse como un número entero de días. Por ejemplo, se permite '3
DAYS', '4 DAYS 2 MINUTES - 2 MINUTES', pero '4 DAYS 3
MINUTES' no se permite, y se muestra un error. No puedes usar números negativos.
La recolección de elementos no utilizados del TTL borra las filas aptas de forma continua y en segundo plano. Debido a que este es un proceso en segundo plano asíncrono, hay un retraso entre la elegibilidad y la eliminación. La tabla puede contener filas que sean aptas para la eliminación del TTL, pero para las que aún no se completó el TTL. Por lo general, el retraso es de menos de 72 horas.
Si quieres obtener instrucciones para crear una política de eliminación de filas de PostgreSQL, consulta Crea una política de TTL.
Copias de seguridad y TTL
Restablecer una copia de seguridad
Cuando restableces una base de datos a partir de una copia de seguridad, todas las políticas de eliminación de filas que se configuraron en la base de datos de origen se descartan de forma automática. Esto evita que Spanner pueda borrar los datos vencidos en cuanto se restablezca la copia de seguridad. Por lo tanto, deberás volver a configurar el TTL de forma manual.
Coherencia de los datos
Una copia de seguridad es una instantánea coherente de tus datos en un
momento determinado (version_time). La copia de seguridad puede contener filas que
podrían ser aptas para la eliminación del TTL, pero para las que el TTL aún no se ha completado.
De manera similar, los trabajos de exportación de Dataflow leen toda la tabla en una marca de tiempo fija.
Auditoría
El TTL admite la auditoría de sus eliminaciones a través de flujos de cambios. Los registros de datos de transmisiones de cambios que realizan un seguimiento de los cambios de TTL en una base de datos tienen el
campo transaction_tag establecido en RowDeletionPolicy y el campo
is_system_transaction establecido en true. Los lectores de transmisiones de cambios pueden
filtrar todos los registros TTL o todos los registros, excepto los TTL, según su caso de uso. Consulta un ejemplo sobre cómo usar Beam para filtrar por etiquetas de transacción.