Hay una característica que me gustaría que hubiera existido con RDBMS, y es el soporte incorporado para establecer un valor Time-To-Live para los registros de datos. En las bases de datos NoSQL, el soporte de TTL es muy común. Las bases de datos NoSQL fueron diseñadas para manejar ciertos tipos de datos que a menudo no se encuentran en los casos de uso tradicionales para RDBMS. Estos incluyen la gestión de registros y eventos, donde no sólo debido a la naturaleza no estructurada de los datos, sino también su gran volumen que a menudo puede ser difícil y costoso de gestionar en RDBMS. Es este tipo de datos el que hace que el Time-to-Live (TTL), una función muy popular en las bases de datos NoSQL.
Pero una rápida búsqueda en Google de TTL con RDBMS tradicionales devuelve más de 1MM de visitas, lo que indica que existen numerosos casos de uso en los que los desarrolladores desearían este tipo de soporte en RDBMS. Estos son algunos de los casos de uso que he visto:
- Aplicaciones que generan un gran volumen de datos temporales con fines de cálculo. Por ejemplo, un sistema de compensación de incentivos que permita al administrador del plan diseñar y realizar análisis hipotéticos para ver la eficacia del plan. Luego, cuando se despliegan los planes, los datos temporales para los cálculos también tendrían que conservarse a efectos de validación/consulta del usuario.
- Los sistemas de información de gestión a menudo tienen la necesidad de pregenerar datos agregados a partir de fuentes multigeográficas, lo que a menudo implica complejas reglas de conversión de divisas. A menudo, estos datos agregados sólo son necesarios para el período contable en curso.
- Sistemas que incluyen un proceso de autoarchivado para eliminar los datos antiguos una vez que éstos se han trasladado a un soporte de almacenamiento diferente.
Todos los casos de uso mencionados anteriormente también incluirían los pasos adicionales de la eliminación real de los datos. Pero en muchos casos, el sistema querría desacoplar el proceso para evitar el potencialmente largo proceso de borrado de datos en un RDBMS basado en transacciones.
En este caso, la función Time-to-Live (TTL) permitiría a la aplicación simplemente establecer los registros de datos con el tiempo de caducidad, y aplazar el DELETE real a un proceso de base de datos diferente.
Para Couchbase, el soporte de TTL siempre ha estado disponible con Operaciones clave-valor de Couchbase. Pero de Couchbase 6.5.1Esta función está ahora disponible con N1QL DMLs que permite a los usuarios consultar y establecer el valor de caducidad directamente en las sentencias N1QL.
N1QL TTL con OPTIONS
Para soportar TTL, la sintaxis N1QL se ha ampliado con un parámetro opcional OPTIONS.
|
1 2 |
INSERTAR EN por defecto (CLAVE, VALOR [, OPCIONES]) VALORES (kval, docval [, {"caducidad":evalúe}]); |
Tenga en cuenta que el parámetro OPTIONS es opcional para garantizar la compatibilidad con versiones anteriores.
INSERTAR/UPSERT y configure el documento para que caduque en 10 minutos.
|
1 2 |
INSERTAR EN por defecto (CLAVE, VALOR) VALORES ("k01", {"id":"k01"}, {"caducidad":10*60}); UPSERT EN por defecto (CLAVE, VALOR) VALORES ("k01", {"id":"k01"}, {"caducidad":10*60}); |
INSERTAR/UPSERTAR en SELECT y establecer el tiempo de caducidad del documento en 1 hora
|
1 2 3 4 |
INSERTAR EN por defecto (CLAVE clave, VALOR doc, OPCIONES {"caducidad": 60*60}) SELECCIONE META(t).id AS clave, t AS doc DESDE `viaje-muestra` AS t; UPSERT EN por defecto (CLAVE clave, VALOR doc, OPCIONES {"caducidad": 60*60}) SELECCIONE META(t).id AS clave, t AS doc DESDE `viaje-muestra` AS t; |
Para preservar el TTL durante la actualización/upserción
Antes de Couchbase 6.5.1, la sentencia de actualización N1QL no preservará el valor existente en el documento. Este comportamiento permanecerá sin cambios, y si los usuarios quieren preservar el TTL, la sentencia de actualización N1QL debe establecer explícitamente la expiración al mismo valor.
|
1 |
ACTUALIZACIÓN por defecto AS d SET d.comentario = "xyz" , META(d).caducidad = META(d).caducidad; |
INSERTAR/UPSERT en SELECT y conservar la hora de caducidad del documento
|
1 2 3 4 |
INSERTAR EN por defecto (CLAVE clave, VALOR doc, OPCIONES {"caducidad": exptime}) SELECCIONE META(t).id AS clave, t AS doc, META(t).caducidad AS exptime DESDE `viaje-muestra` AS t; UPSERT EN por defecto (CLAVE clave, VALOR doc, OPCIONES {"caducidad": exptime}) SELECCIONE META(t).id AS clave, t AS doc, META(t).caducidad AS exptime DESDE `viaje-muestra` AS t; |
Fusionar documentos y conservar el tiempo de caducidad.
|
1 2 3 4 5 6 7 8 9 10 11 |
FUSIONAR EN `viaje-muestra` AS ruta USO DE `viaje-muestra` AS aeropuerto EN ruta.fuenteaeropuerto = aeropuerto.faa CUANDO MATCHED ENTONCES ACTUALIZACIÓN SET ruta.equipo_antiguo = ruta.equipo, ruta.equipo = ""797"", ruta.actualizado = verdadero, META(ruta).caducidad = META(ruta).caducidad DONDE aeropuerto.país = ""Francia"" Y ruta.aerolínea = ""BA"" Y CONTIENE(ruta.equipo, ""319"");" |
META().campo caducidad
El campo META().expiration siempre ha estado disponible con N1QL. Pero con N1QL TTL, los usuarios pueden cambiar directamente el valor del campo.
Para seleccionar y utilizar la expiración en un predicado
|
1 |
SELECCIONE META(d).id, META(d).caducidad DESDE por defecto d DONDE META(d).caducidad > 0; |
Para actualizar todos los documentos y fijar el tiempo de comentario y caducidad en 10 minutos.
|
1 |
ACTUALIZACIÓN por defecto AS d SET d.comentario = "xyz" , META(d).caducidad = 10*60; |
Para borrar el tiempo de caducidad, de modo que el documento no se borre.
|
1 |
ACTUALIZACIÓN por defecto AS d SET META(d).caducidad = 0; |
Para eliminar todos los documentos que caducarán en más de un día
|
1 |
BORRAR por defecto d DONDE META(d).caducidad > <span estilo="font-weight: 400">(AHORA_MILLIS()/1000)+ (60*60*24);</span> |
Tenga en cuenta que el valor relativo sólo se utiliza para INSERTAR/ACTUALIZAR/UPSERT. El valor de expiración absoluto debe utilizarse en todos los demás casos.
Valor del plazo de vencimiento
El tiempo de caducidad que es inferior a 30 días en el futuro se puede establecer como el número de segundos. El valor 60*60*24*14 marcará el documento para su eliminación en 14 días. Para 30 días o más en el futuro, el tiempo Unix debe ser utilizado. Para más información sobre el tiempo de expiración de Couchbase, por favor consulte la página Documentación de Couchbase.
Crear un índice sobre el campo caducidad
La capacidad de consultar y indexar la META().expiración siempre ha sido posible en Couchbase.
|
1 2 3 |
CREAR ÍNDICE idx_expir EN `viaje-muestra` ( META().caducidad ); SELECCIONE META().id, META().caducidad DESDE `viaje-muestra` DONDE META().caducidad = 0 PEDIR POR META().id LÍMITE 2; |
Tenga en cuenta que es posible que se produzca un retraso entre el momento en que se elimina el documento y el momento en que la eliminación se propaga al servicio de índices. Por esta razón, las consultas que están totalmente cubiertas por el índice con la expiración pueden devolver datos obsoletos. Pero este comportamiento es sólo temporal.
Consideración del rendimiento
N1QL accede a la información TTL mediante la función SUBDOC api Esta API devolverá el documento completo, y también tiene cierta sobrecarga en el tamaño del paquete de solicitud. La sobrecarga adicional puede incurrir en una latencia de consulta adicional. Sin embargo, la API SUBDOC sólo se utilizará si se hace referencia al campo META().expiration en la consulta.
Recursos adicionales
- Couchbase soporta TTL: https://docs.couchbase.com/server/current/learn/buckets-memory-and-storage/expiration.html
- Cómo fijar la hora de caducidad: https://docs.couchbase.com/server/current/learn/buckets-memory-and-storage/expiration.html
- API SUBDOC de Couchbase: https://docs.couchbase.com/server/5.0/developer-guide/sub-doc-api.html
- Indexación del campo Expiración: https://docs.couchbase.com/server/current/n1ql/n1ql-language-reference/indexing-meta-info.html
