Expiration automatique des données avec expireAfterSeconds

La valeur des données de séries temporelles est presque toujours limitée dans le temps : les mesures d'un capteur datant de 5 ans éclairent rarement les décisions actuelles. Conserver des données obsolètes gaspille de l'espace de stockage, ralentit les sauvegardes et augmente la taille des index. L'option expireAfterSeconds de MongoDB vous permet de déclarer une durée de conservation lors de la création de la collection afin que la base de données gère automatiquement le nettoyage, sans tâches cron ni routines de suppression au niveau de l'application.

Transmettez expireAfterSeconds comme option de premier niveau, au même niveau que l'objet timeseries, lors de l'appel à db.createCollection(). Cette valeur est un entier représentant le nombre de secondes pendant lesquelles conserver les données. Les documents dont la valeur de timeField est antérieure à maintenant − expireAfterSeconds peuvent être supprimés par le processus d'arrière-plan TTL.

Le processus TTL de MongoDB s'exécute environ toutes les 60 secondes. Pour les collections de séries temporelles, il supprime des documents de compartiment entiers plutôt que des mesures individuelles. Un compartiment n'est supprimé que lorsque toutes les mesures qu'il contient sont antérieures au seuil d'expiration. La suppression TTL est ainsi très efficace : la suppression d'un document de compartiment élimine des centaines de mesures en une seule opération.

Vous pouvez modifier à tout moment la durée de conservation d'une collection de séries temporelles existante à l'aide de la commande collMod, sans interruption de service. Augmenter cette valeur permet de conserver les données plus longtemps ; la réduire rend supprimables les données qui n'expiraient pas auparavant lors de la prochaine exécution de TTL. La modification prend effet dans un délai d'environ 60 secondes.

Les collections MongoDB classiques utilisent un index TTL (un index spécial à champ unique sur un champ de date doté d'un attribut expireAfterSeconds) pour faire expirer les documents individuellement. Les collections de séries temporelles utilisent un autre mécanisme : elles font expirer des documents de compartiment entiers plutôt que des documents de mesure individuels. Vous ne pouvez donc pas créer d'index TTL distinct sur une collection de séries temporelles ; l'expiration est gérée uniquement par l'option expireAfterSeconds au niveau de la collection.

Examinez la politique de conservation actuelle en exécutant db.getCollectionInfos() et en inspectant le champ options.expireAfterSeconds. Vous pouvez également vérifier db.sensorReadings.stats(), qui indique la configuration TTL dans son résultat. Cela est utile lors des audits pour confirmer que les collections de production utilisent la durée de conservation correcte.

Un modèle courant en production est la conservation par niveaux : les données brutes à haute fréquence sont stockées dans une collection de séries temporelles avec un TTL court (par exemple, 7 jours), tandis qu'une tâche d'agrégation s'exécute chaque nuit pour calculer des résumés horaires et les écrit dans une seconde collection avec un TTL plus long (par exemple, 2 ans). Cela permet d'équilibrer les coûts de stockage et le besoin d'analyser les tendances historiques.

Le processus d'arrière-plan TTL se réveille toutes les 60 secondes ; l'expiration n'est donc pas instantanée et les données peuvent subsister jusqu'à 60 secondes après avoir dépassé leur seuil. Sur les clusters Atlas fortement sollicités, les suppressions TTL peuvent être encore retardées. Pour les exigences de conformité imposant une suppression exacte à une seconde donnée, des scripts de suppression manuelle ou des déclencheurs Atlas planifiés offrent un contrôle plus prévisible que TTL.

Si vous devez supprimer immédiatement un ensemble de mesures, par exemple pour purger les données d'un capteur défectueux, utilisez deleteMany() avec un filtre sur timeField et metaField. Les collections de séries temporelles prennent en charge les suppressions par plage temporelle et par valeur de metaField depuis MongoDB 5.1. Les filtres complexes sur les champs de mesure lors des suppressions sont pris en charge depuis MongoDB 6.0.

MongoDB expose les métriques de suppression TTL dans l'état du serveur, dans la section metrics.ttl. Le compteur deletedDocuments indique le nombre de documents (des documents de compartiment pour les séries temporelles) supprimés par le processus TTL depuis le démarrage du processus mongod. La surveillance de ce compteur vous aide à confirmer que TTL s'exécute bien et supprime les données comme prévu en production.

Lors de la planification de la conservation, prenez en compte trois facteurs : les exigences de conformité (certaines réglementations imposent de conserver les données pendant plusieurs années), les besoins analytiques (jusqu'à quelle date vos requêtes remontent-elles ?) et le budget de stockage (combien coûte la conservation de N jours de données ?). Modélisez la croissance du stockage en estimant le volume quotidien de documents × la taille moyenne d'un document, puis définissez expireAfterSeconds pour équilibrer ces trois contraintes.

Dans cette leçon, vous avez appris que expireAfterSeconds se définit au niveau de la collection (et non via un index) et contrôle le moment où les compartiments entiers sont purgés, que collMod permet de modifier la durée de conservation d'une collection active sans interruption de service, et que la conservation par niveaux — TTL court pour les données brutes, TTL long pour les résumés préagrégés — constitue la bonne pratique en production pour stocker des séries temporelles à moindre coût. Nous allons maintenant aborder les mécanismes d'authentification dans MongoDB.