ApsaraDB for MongoDB:Bonnes pratiques pour les index TTL dans ApsaraDB for MongoDB

Mécanisme de base

Au démarrage d'un processus mongod, un thread d'arrière-plan nommé TTLMonitor se crée. Par défaut, ce thread exécute un cycle de nettoyage TTL toutes les 60 secondes. Chaque cycle effectue les opérations suivantes :

1. Collecte tous les index TTL présents dans la base de données actuelle.

2. Génère un plan d'exécution pour chaque index TTL, l'un après l'autre, puis nettoie les données.

3. Supprime les documents dont la valeur du champ indexé, ajoutée au nombre de secondes défini par expireAfterSeconds, est antérieure à l'heure actuelle.

Le seuil d'expiration se calcule comme suit : on additionne la valeur de date du champ indexé et le nombre de secondes spécifié par expireAfterSeconds. Si le résultat est antérieur à l'heure actuelle, le document est considéré comme expiré.

Comportement dans les ensembles de réplicas

Dans un ensemble de réplicas, le thread d'arrière-plan TTL n'effectue les opérations de suppression que sur le nœud Primary. Les threads TTL des nœuds Secondary restent inactifs et synchronisent les suppressions en répliquant l'oplog depuis le nœud Primary. Cela signifie que les suppressions TTL génèrent des entrées supplémentaires dans l'oplog et peuvent affecter le délai de réplication de l'ensemble de réplicas.

Différences entre versions : optimisation des suppressions par lots (MongoDB 7.0+)

À partir de MongoDB 7.0 (une fonctionnalité initialement introduite dans la version de développement 6,1), la suppression TTL utilise un mécanisme de « suppression équitable » qui répartit le temps de suppression entre chaque index TTL par tranches horaires. Cela empêche les données expirées de certaines collections de ne jamais être nettoyées. Les principales améliorations sont les suivantes :

• ttlMonitorBatchDeletes : active le mode de suppression par lots. Activé par défaut. Lorsqu'il est activé, les suppressions TTL sont réparties plus équitablement entre les collections.

• ttlIndexDeleteTargetTimeMS : limite de temps maximale par cycle de suppression pour chaque index TTL. Valeur par défaut : 1 000 ms.

• ttlIndexDeleteTargetDocs : nombre maximal de documents supprimés par cycle pour chaque index TTL. Valeur par défaut : 50 000.

• ttlMonitorSubPassTargetSecs : limite de temps maximale pour un sous-cycle parcourant les index TTL. Valeur par défaut : 60 secondes.

Ces paramètres apparaissent sous forme d'étape BATCHED_DELETE dans le plan d'exécution et peuvent être consultés à l'aide de la commande explain.

Créer un index TTL

Utilisez la méthode createIndex pour créer un index TTL sur un champ de type Date.

Exemple 1 : créez un index TTL afin que les documents expirent 3 600 secondes après la valeur du champ lastModifiedDate.

db.eventlog.createIndex(
  { "lastModifiedDate": 1 },
  { expireAfterSeconds: 3600 }
)

Exemple 2 : expirez à un instant précis. Définissez expireAfterSeconds sur 0 afin que seule la valeur du champ détermine l'heure d'expiration.

db.sessions.createIndex(
  { "expireAt": 1 },
  { expireAfterSeconds: 0 }
)

Modifier le délai d'expiration d'un index TTL

Utilisez la commande collMod pour modifier la valeur expireAfterSeconds d'un index TTL existant sans reconstruire l'index.

db.runCommand({
  "collMod": "log_events",
  "index": {
    "keyPattern": { "createdAt": 1 },
    "expireAfterSeconds": 600
  }
})

Convertir un index standard en index TTL (MongoDB 6.0+)

À partir de MongoDB 6.0, vous pouvez utiliser la commande collMod pour convertir un index standard mono-champ existant en index TTL, sans avoir à le supprimer ni à le reconstruire au préalable.

db.runCommand({
  "collMod": "tickets",
  "index": {
    "keyPattern": { "lastModifiedDate": 1 },
    "expireAfterSeconds": 100
  }
})

Surveiller l'état TTL

Surveillez les opérations TTL à l'aide des commandes suivantes.

// View the total number of documents deleted by TTL
db.serverStatus().metrics.ttl.deletedDocuments

// View the number of TTL thread passes
db.serverStatus().metrics.ttl.passes

// View the TTL scan interval (default: 60 seconds)
db.runCommand({ getParameter: 1, ttlMonitorSleepSecs: 1 })

// View the TTL delete operations that are currently running
db.currentOp()

Problème 1 : Pics périodiques d'utilisation du processeur causés par les suppressions TTL

Symptôme

L'utilisation du processeur de l'instance affiche des pics nets à intervalles réguliers. En exécutant db.currentOp(), vous constatez que le thread TTL effectue un grand nombre d'opérations de suppression.

Cause

Lorsque l'application insère une grande quantité de données simultanément et que les valeurs du champ TTL sont identiques ou très proches, ces documents expirent dans la même fenêtre temporelle. Le thread TTL doit alors supprimer un grand nombre de documents en une seule analyse, ce qui exerce une pression importante sur le processeur et les E/S.

Solution

• Étaler les heures d'expiration : lors de l'insertion des données, ajoutez un décalage aléatoire au champ TTL afin de répartir les expirations sur une plage horaire et d'éviter les suppressions massives. Par exemple, pour des données expirant dans 24 heures, ajoutez ou soustrayez un décalage aléatoire de quelques minutes à l'heure d'expiration.

• Migrer vers MongoDB 7.0 ou version ultérieure : utilisez les mécanismes de suppression par lots et de suppression équitable pour lisser la charge liée aux suppressions.

• Choisir une spécification d'instance adaptée : assurez-vous que l'instance dispose de suffisamment de ressources processeur et mémoire pour gérer la charge supplémentaire générée par les suppressions TTL.

Exemple : ajouter un décalage d'expiration aléatoire aux données insérées.

// Add a random offset of 0 to 600 seconds on top of 24 hours
var randomOffset = Math.floor(Math.random() * 600);
var expireTime = new Date(Date.now() + (86400 + randomOffset) * 1000);
db.logs.insertOne({
  data: "log content",
  createdAt: expireTime
})

Problème 2 : Les données ne sont pas supprimées après expiration

Symptôme

Les documents ont dépassé leur heure d'expiration prévue mais existent toujours dans la collection.

Étapes de dépannage

1. Vérifier le type de champ : contrôlez si la valeur du champ indexé TTL est bien de type BSON Date. Une erreur fréquente consiste à utiliser un entier d'horodatage UNIX au lieu d'un objet Date.

   // Check the field type
   db.collection.findOne({}, { createdAt: 1 })
   // Correct: ISODate("2024-01-01T00:00:00Z")
   // Wrong: 1704067200 (integer timestamp)

2. Vérifier l'existence du champ : assurez-vous que les documents contiennent bien le champ indexé TTL. Les documents ne contenant pas ce champ ne sont pas supprimés automatiquement.

3. Contrôler la définition de l'index : vérifiez que l'index inclut la propriété expireAfterSeconds.

   db.collection.getIndexes()

4. Vérifier le sens de l'index : assurez-vous que l'index TTL est en ordre croissant (la valeur est 1). Un index décroissant peut empêcher le bon fonctionnement de TTL. Si le sens de l'index est incorrect, supprimez-le et recréez-le.

5. Vérifier si TTL Monitor est activé : assurez-vous que le paramètre ttlMonitorEnabled est défini sur true.

   db.adminCommand({ getParameter: 1, ttlMonitorEnabled: 1 })

Problème 3 : La suppression TTL ne suit pas le rythme d'insertion des données

Symptôme

Le volume de données de la collection augmente continuellement et l'utilisation du disque progresse, malgré la configuration d'un index TTL.

Cause

Le thread TTL est mono-thread et s'exécute toutes les 60 secondes. Lorsque le taux d'insertion des données dépasse largement le taux de nettoyage TTL, les données expirées s'accumulent. De plus, si plusieurs index TTL existent sur une instance, ils sont traités de manière séquentielle, ce qui réduit encore l'efficacité du nettoyage.

Solution

• Ajuster la fréquence d'analyse : réduisez l'intervalle d'analyse en définissant le paramètre ttlMonitorSleepSecs. Notez qu'une fréquence plus élevée accroît la charge système.

  // Set the scan interval to 10 seconds
  db.adminCommand({ setParameter: 1, ttlMonitorSleepSecs: 10 })

• Nettoyer côté application : pour les scénarios avec un volume d'écriture particulièrement élevé, implémentez une suppression par lots planifiée dans votre application plutôt que de compter exclusivement sur les index TTL.

• Envisager des collections partitionnées par temps : pour les scénarios d'écriture extrêmement intenses, partitionnez les données en collections selon le temps et supprimez les collections entières une fois expirées. Cette approche est bien plus efficace que la suppression document par document via un index TTL.

Problème 4 : L'espace disque n'est pas libéré après suppression

Symptôme

TTL a supprimé un grand nombre de documents, mais l'utilisation du disque n'a pas diminué de manière significative.

Solution

MongoDB utilise le moteur de stockage WiredTiger. Lorsque des documents sont supprimés, l'espace est marqué comme réutilisable, mais n'est pas immédiatement restitué au système d'exploitation. Pour récupérer immédiatement l'espace disque, exécutez la commande compact ou reconstruisez les fichiers de données via une synchronisation initiale. Nous vous recommandons d'exécuter compact pendant les heures creuses.

1. Garantir des types de données corrects

Les index TTL ne fonctionnent que sur les champs de type BSON Date. Nous vous recommandons d'imposer le type de date correct pour les champs TTL côté application ou en utilisant la fonctionnalité de validation de schéma de MongoDB.

db.createCollection("sessions", {
  validator: {
    $jsonSchema: {
      properties: {
        expireAt: { bsonType: "date", description: "The TTL field must be of the Date type" }
      },
      required: ["expireAt"]
    }
  }
})

2. Étaler les heures d'expiration pour éviter les suppressions massives

Il s'agit de la méthode la plus efficace pour prévenir les pics d'utilisation du processeur causés par les suppressions TTL. Lors de l'insertion des données, ajoutez un décalage aléatoire à l'heure d'expiration afin qu'un lot de données expire sur une plage de temps. Ainsi, le thread TTL ne supprime qu'un petit nombre de documents par analyse, ce qui réduit considérablement l'impact sur les performances du système.

3. Ajuster expireAfterSeconds avec prudence

Réduire la valeur expireAfterSeconds d'un index TTL existant entraîne l'expiration immédiate de nombreux documents, ce qui peut déclencher des opérations de suppression à grande échelle et affecter sérieusement les performances de l'instance. Nous vous recommandons les actions suivantes :

1. Estimez le nombre de documents qui expireront immédiatement après l'ajustement.

2. Effectuez la modification pendant les heures creuses.

3. Si le nombre de documents expirés est important, supprimez d'abord une partie des données par lots à l'aide d'un script, puis modifiez expireAfterSeconds.

4. Considérations lors de la création d'un nouvel index TTL

La création d'un index TTL sur une collection contenant déjà un grand nombre de documents répondant aux conditions d'expiration peut déclencher des suppressions massives immédiatement après la construction de l'index. Nous vous recommandons les actions suivantes :

• Créez l'index TTL pendant les heures creuses.

• Nettoyez d'abord les données historiques expirées, puis créez l'index TTL.

• Construisez l'index en arrière-plan pour éviter d'affecter les activités métier normales.

5. Ne pas désactiver TTL Monitor pendant une longue période

Bien qu'il soit possible de désactiver temporairement la fonctionnalité TTL en définissant le paramètre ttlMonitorEnabled, nous ne recommandons pas de le laisser désactivé longtemps en production. Le grand nombre de documents expirés accumulés pendant la période de désactivation sera supprimé en bloc lors de la réactivation, ce qui peut provoquer de graves problèmes de performance.

6. Évaluer l'impact de TTL sur l'oplog

Chaque document supprimé par TTL génère une entrée dans l'oplog. Lorsque le volume de suppressions est important, le volume d'écriture de l'oplog augmente considérablement, ce qui peut affecter le délai de réplication de l'ensemble de réplicas. Nous vous recommandons d'évaluer l'impact de la manière suivante :

• Surveillez metrics.ttl.deletedDocuments pour suivre le volume des suppressions TTL.

• Surveillez le délai de réplication de l'ensemble de réplicas afin de vous assurer que les nœuds Secondary peuvent gérer l'oplog supplémentaire généré par TTL.

• Augmentez la taille de l'oplog si nécessaire pour éviter son débordement causé par les suppressions TTL.

7. Alternatives pour les scénarios à fort volume d'écriture

Les index TTL conviennent aux scénarios avec un volume d'écriture modéré. Pour les scénarios avec un volume d'écriture extrêmement élevé, envisagez les alternatives suivantes :

1. Collections partitionnées par temps : partitionnez la collection selon une dimension temporelle (par jour ou par semaine) et supprimez la collection entière une fois expirée. C'est la méthode la plus efficace pour expirer les données.

2. Collections de séries temporelles : MongoDB 5.0+ prend en charge les collections de séries temporelles, qui incluent une expiration des données intégrée et suppriment les données en masse par compartiment. Cette approche est bien plus efficace que la suppression document par document dans une collection standard.

3. Nettoyage planifié côté application : utilisez des tâches planifiées pour effectuer des suppressions par lots pendant les heures creuses, ce qui vous offre un contrôle plus précis sur le rythme et le moment des suppressions.