Expiración automática de datos con expireAfterSeconds

El valor de los datos de series temporales casi siempre es limitado: las lecturas de sensores de hace 5 años rara vez sirven para tomar decisiones actuales. Conservar datos obsoletos desperdicia almacenamiento, ralentiza las copias de seguridad y aumenta el tamaño de los índices. La opción expireAfterSeconds de MongoDB le permite declarar un periodo de retención al crear la colección, para que la base de datos gestione la limpieza automáticamente, sin tareas cron ni rutinas de eliminación en la aplicación.

Pase expireAfterSeconds como una opción de nivel superior junto al objeto timeseries al llamar a db.createCollection(). El valor es un entero que representa el número de segundos durante los que se conservarán los datos. Los documentos cuyo valor de timeField sea anterior a ahora − expireAfterSeconds podrán ser eliminados por el subproceso en segundo plano de TTL.

El subproceso TTL de MongoDB se ejecuta aproximadamente cada 60 segundos. En las colecciones de series temporales, elimina documentos bucket completos en lugar de mediciones individuales. Un bucket solo se elimina cuando todas las mediciones que contiene son anteriores al umbral de caducidad. Esto hace que la eliminación mediante TTL sea muy eficiente: eliminar un documento bucket permite borrar cientos de mediciones en una sola operación.

Puede modificar en cualquier momento el periodo de retención de una colección de series temporales existente mediante el comando collMod, sin necesidad de tiempo de inactividad. Aumentar el valor permite conservar los datos durante más tiempo; reducirlo hace que los datos que antes no caducaban puedan eliminarse durante la siguiente ejecución de TTL. El cambio surte efecto aproximadamente en 60 segundos.

Las colecciones normales de MongoDB utilizan un índice TTL (un índice especial de un solo campo sobre un campo de fecha, con un atributo expireAfterSeconds) para hacer caducar documentos individuales. Las colecciones de series temporales utilizan un mecanismo diferente: hacen caducar documentos bucket completos en lugar de documentos de mediciones individuales. Por este motivo, no puede crear un índice TTL independiente en una colección de series temporales; la caducidad se gestiona exclusivamente mediante la opción expireAfterSeconds de la colección.

Consulte la política de retención actual ejecutando db.getCollectionInfos() y examinando el campo options.expireAfterSeconds. También puede comprobar db.sensorReadings.stats(), que incluye la configuración de TTL en sus resultados. Esto resulta útil durante las auditorías para confirmar que las colecciones de producción tienen establecido el periodo de retención correcto.

Un patrón habitual en producción es la retención por niveles: los datos sin procesar y de alta frecuencia se almacenan en una colección de series temporales con un TTL corto (por ejemplo, 7 días), mientras que una tarea de canalización de agregación se ejecuta cada noche para calcular resúmenes por hora y escribirlos en una segunda colección con un TTL más largo (por ejemplo, 2 años). Esto equilibra los costes de almacenamiento con la necesidad de analizar tendencias históricas.

El subproceso TTL en segundo plano se activa cada 60 segundos, por lo que la caducidad no es instantánea: los datos pueden permanecer hasta 60 segundos después de alcanzar el umbral. En clústeres de Atlas sometidos a una carga elevada, las eliminaciones mediante TTL pueden retrasarse aún más. Si los requisitos de cumplimiento exigen una eliminación exacta en un segundo determinado, los scripts de eliminación manual o los Atlas Triggers programados ofrecen un control más determinista que TTL.

Si necesita eliminar inmediatamente un bloque de mediciones —por ejemplo, para purgar los datos de un sensor defectuoso—, utilice deleteMany() con un filtro sobre timeField y metaField. Las colecciones de series temporales admiten eliminaciones por intervalo de tiempo y por valor de metaField desde MongoDB 5.1. Las eliminaciones con filtros complejos sobre campos de medición son compatibles desde MongoDB 6.0.

MongoDB expone métricas de eliminación mediante TTL en server status, dentro de la sección metrics.ttl. El contador deletedDocuments registra cuántos documentos (documentos bucket en el caso de las series temporales) ha eliminado el subproceso TTL desde que se inició el proceso mongod. Supervisar este contador le ayuda a confirmar que TTL se está ejecutando y eliminando los datos según lo previsto en producción.

Al planificar la retención, tenga en cuenta tres factores: los requisitos de cumplimiento (algunas normativas exigen conservar los datos durante años), las necesidades analíticas (¿hasta cuánto tiempo atrás abarcan sus consultas?) y el presupuesto de almacenamiento (¿cuánto cuesta conservar N días de datos?). Modele el crecimiento del almacenamiento estimando el volumen diario de documentos × el tamaño medio de los documentos y, a continuación, establezca expireAfterSeconds para equilibrar las tres limitaciones.

En esta lección ha aprendido lo siguiente: expireAfterSeconds se establece en el nivel de la colección (no mediante un índice) y controla cuándo se purgan los buckets completos; collMod permite actualizar el periodo de retención de una colección activa sin tiempo de inactividad; y la retención por niveles —TTL corto para los datos sin procesar y TTL largo para los resúmenes preagregados— es la práctica recomendada en producción para almacenar series temporales de forma rentable. A continuación, trataremos los mecanismos de autenticación de MongoDB.