Collecte des déchets dans Amazon DocumentDB

Amazon DocumentDB implémente une architecture de base de données MVCC (Multiversion Concurrency Control) qui crée de nouvelles versions des entrées de document et d'index pour chaque opération de mise à jour. Cette architecture permet d'isoler la lecture en permettant aux requêtes de lecture d'utiliser des documents versionnés sans les verrouiller.

Comprendre la collecte des déchets dans Amazon DocumentDB

La collecte des déchets (GC) est un processus d'arrière-plan automatisé qui garantit des performances et une disponibilité optimales du système dans Amazon DocumentDB. Contrairement aux bases de données traditionnelles qui remplacent les données sur place, l'architecture MVCC d'Amazon DocumentDB crée de nouvelles versions de documents et d'entrées d'index à chaque opération de mise à jour. Chaque opération d'écriture qui aboutit à une nouvelle version du document consomme un identifiant MVCC unique issu d'un compteur limité, ce qui rend un nettoyage efficace essentiel. Au fil du temps, ces anciennes versions s'accumulent et doivent être nettoyées pour éviter toute dégradation des performances.

Fonctions de collecte des ordures

Le collecteur de déchets remplit trois fonctions essentielles :

• Récupère de l'espace de stockage : il supprime les versions de documents et d'index obsolètes dont les requêtes actives n'ont plus besoin, libérant ainsi de l'espace pour les futures opérations d'écriture.

• Empêche le dépassement d'ID MVCC — Il empêche le débordement d'ID MVCC en gérant le compteur fini de MVCC. IDs Sans cette gestion, le compteur finirait par atteindre ses limites, forçant la base de données à passer en mode lecture seule temporaire jusqu'à ce IDs qu'elle soit recyclée.

• Maintient les performances des requêtes : il maintient des performances de requête optimales en éliminant les versions de documents inutilisées qui, autrement, s'accumuleraient et ralentiraient le traitement des requêtes.

Processus de collecte des ordures

Le processus GC fonctionne par collection et peut comporter plusieurs processus exécutés simultanément sur différentes collections. Le processus comprend quatre phases séquentielles :

1. Identification — Le système identifie les versions des documents et des index qui ne sont plus référencées par les transactions ou requêtes actives.

2. Chargement de la mémoire — Les anciens documents et entrées d'index sont chargés en mémoire s'ils ne sont pas déjà présents.

3. Suppression — Les versions obsolètes sont définitivement supprimées pour récupérer de l'espace de stockage.

4. Recyclage des identifiants MVCC — Le système recycle le MVCC à IDs partir des versions supprimées pour de nouvelles opérations.

Lorsque la collecte des déchets termine le traitement des anciennes versions de documents, elle supprime le MVCC le plus ancien IDs du système. Ce nettoyage est crucial pour empêcher le débordement des identifiants MVCC en recyclant les MVCC IDs et en les rendant disponibles pour de nouvelles opérations d'écriture dans le cluster. Sans ce processus de recyclage, le système finirait par épuiser son compteur d'identifiants MVCC limité et passer en mode lecture seule.

Planification de la collecte des ordures

La collecte des déchets s'exécute automatiquement en arrière-plan à intervalles réguliers. La synchronisation et la fréquence s'ajustent dynamiquement en fonction de la charge du système, des ressources disponibles, du volume d'écriture et des niveaux de consommation des identifiants MVCC. En cas d'activité d'écriture intense, le processus GC s'exécute plus fréquemment pour gérer le nombre accru de versions de documents.

Surveillance de la collecte des déchets

Métriques au niveau du cluster

AvailableMVCCIds

• Emplacement — Amazon CloudWatch

• Description — Un compteur qui indique le nombre d'opérations d'écriture restantes disponibles avant d'atteindre zéro. Lorsque ce compteur atteint zéro, votre cluster passe en mode lecture seule jusqu'à ce IDs qu'il soit récupéré et recyclé. Le compteur diminue à chaque opération d'écriture et augmente à mesure que la collecte des déchets recycle l'ancien IDs MVCC.

• Recommandation — Réglez une alarme lorsque la valeur tombe en dessous de 1,3 milliard. Cette alerte précoce vous permet de prendre les mesures recommandées dont il sera question ultérieurement.

LongestRunningGCProcess

• Emplacement — Amazon CloudWatch

• Description — Durée en secondes du plus long processus actif de collecte des déchets. Il est mis à jour toutes les minutes et suit uniquement les opérations actives, à l'exception des processus terminés dans le délai d'une minute.

• Recommandation —

Mesures au niveau de la collecte

MVCCIDStats: MvccIdAgeScale

• Emplacement — Commande CollStats de base de données

• Description — Mesure l'âge de l'identifiant MVCC sur une échelle de 0 à 1, où 1 indique l'âge maximum avant qu'un cluster ne passe en mode lecture seule. Utilisez cette métrique en parallèle AvailableMVCCIds pour identifier les collections contenant les plus anciens MVCC IDs qui vieillissent le cluster.

• Recommandation — Maintenir les valeurs inférieures à 0,3 pour chaque collection.

GCRuntimeStats

• Emplacement — Commande CollStats de base de données

• Description — Fournit un historique sur deux mois des indicateurs de collecte des déchets, y compris le nombre total de cycles, la durée moyenne et la durée maximale. Inclut uniquement les opérations de collecte des ordures de plus de cinq minutes afin de garantir des statistiques significatives.

UnusedStorageSize(niveau de collecte)

• Emplacement — Commande CollStats de base de données

• Description — Estime l'espace de stockage inutilisé dans une collection sur la base de statistiques échantillonnées. Il inclut l'espace réservé aux documents supprimés et aux segments vides.

Mesures au niveau de l'indice

UnusedStorageSize(niveau de l'indice)

• Emplacement — Commande IndexStats de base de données

• Description — Estime l'espace de stockage inutilisé dans un index sur la base de statistiques échantillonnées. Il inclut l'espace réservé aux entrées d'index obsolètes et aux segments vides.

• Recommandation — Utilisez la reIndex commande pour reconstruire les index sans interruption et récupérer l'espace inutilisé. Reportez-vous à la section Gestion des index pour plus de détails.

Exemple collStats de sortie

{
    "ns": "xid_consumption_test_db.xid_test_collection",
    "MVCCIdStats": {
        "MVCCIdScale": 0.03
    },
    "gcRuntimeStats": {
        "numRuns": 1,
        "historicalAvgRuntime": 3295,
        "historicalMaxRuntime": 3295,
        "lastRuntime": 3295,
        "lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
    },
    "collScans": 14,
    "count": 30000000,
    "size": 1320000000,
    "avgObjSize": 44,
    "storageSize": 6461497344,
    "capped": false,
    "nindexes": 2,
    "totalIndexSize": 9649553408,
    "indexSizes": {
        "_id_": 1910661120,
        "c_1": 7738892288
    },
    "unusedStorageSize": {
        "unusedBytes": 4201881600,
        "unusedPercent": 65.05
    },
    "cacheStats": {
        "collBlksHit": 171659016,
        "collBlksRead": 754061,
        "collHitRatio": 99.5627,
        "idxBlksHit": 692563636,
        "idxBlksRead": 1177921,
        "idxHitRatio": 99.8303
    },
    "idxScans": 41823984,
    "opCounter": {
        "numDocsIns": 0,
        "numDocsUpd": 20911992,
        "numDocsDel": 0
    },
    "lastReset": "2025-06-24 05:57:08.219711+00",
    "ok": 1,
    "operationTime": Timestamp(1750968826, 1)
}

Questions fréquentes (FAQ)

Rubriques

• Comment savoir si le ramassage des ordures ne fonctionne pas efficacement ?

• Le ramassage des déchets affecte-t-il les performances de ma base de données ?

• Puis-je déclencher manuellement le ramassage des ordures ?

• Quelles alarmes dois-je configurer en tant que meilleure pratique opérationnelle ?

• Que dois-je faire si mon revenu AvailableMVCCId tombe en dessous de 1,3 milliard ?

Comment savoir si le ramassage des ordures ne fonctionne pas efficacement ?

Surveillez ces panneaux d'avertissement qui indiquent un ramassage inefficace des déchets :

• Surcharge de collection excessive : augmentation constante UnusedStorageSize des statistiques lors d'écritures intensives ou de suppressions massives, en particulier avec des index volumineux

• Latence des requêtes dégradée : latence des requêtes accrue en raison de l'accumulation de documents morts

• Durée prolongée du GC — Les opérations de collecte des déchets prennent plus de temps que les moyennes historiques en GCRuntimeStats

• Traitement GC élevé — Un niveau élevé LongestRunningGCProcess indique que le ramasse-miettes ne peut pas répondre aux demandes du système

Le ramassage des déchets affecte-t-il les performances de ma base de données ?

Dans des conditions normales, le ramassage des déchets a un impact minimal sur les performances. Cependant, lorsque la collecte des ordures prend du retard, vous pouvez rencontrer :

• augmentation des coûts de stockage en raison de l'accumulation de documents morts.

• ralentissement des performances des requêtes en raison d'entrées d'index obsolètes.

• mode lecture seule temporaire si les MVCC IDs sont épuisés.

• augmentation de l'utilisation des ressources lors de collectes intensives, en particulier sur les petites instances.

Puis-je déclencher manuellement le ramassage des ordures ?

Non, la collecte des déchets dans Amazon DocumentDB ne peut pas être déclenchée manuellement. Le système gère automatiquement la collecte des ordures dans le cadre de ses opérations de maintenance internes.

Quelles alarmes dois-je configurer en tant que meilleure pratique opérationnelle ?

Nous vous recommandons de configurer la surveillance au niveau du cluster et de la collecte afin de garantir des performances optimales de votre système Amazon DocumentDB.

Pour la surveillance au niveau du cluster

Commencez par créer une CloudWatch alarme pour la AvailableMVCCId métrique avec un seuil de 1,3 milliard. Cela vous laisse suffisamment de temps pour agir avant que la métrique n'atteigne zéro, date à laquelle votre cluster passe en mode lecture seule. N'oubliez pas que cette métrique peut fluctuer en fonction de vos habitudes d'utilisation spécifiques. Certains clients le voient chuter en dessous de 1,3 milliard, puis en récupérer au-dessus de 1,5 milliard à mesure que le ramassage des ordures complète son travail.

Il est également important de surveiller la LongestRunningGCProcess métrique jusqu'au bout CloudWatch. Cette métrique, associée àGCRuntimeStats, vous aide à comprendre l'efficacité de la collecte des déchets dans votre système.

Pour la surveillance au niveau de la collection

Concentrez-vous sur deux indicateurs clés. Tout d'abord, nous vous recommandons de surveiller la MvccIdAgeScale valeur de chaque collection. Des valeurs croissantes suggèrent que les MVCC IDs vieillissent et peuvent nécessiter une attention particulière. Ensuite, surveillez GCRuntimeStats pour identifier les processus de collecte des déchets qui prennent anormalement longtemps ou s'étendent sur plusieurs jours. Les collections où les opérations d'écriture sont fréquentes nécessitent une attention particulière, car elles génèrent plus de travail pour le ramasse-miettes. Nous vous recommandons de vérifier ces indicateurs plus fréquemment pour les collections présentant une forte activité d'écriture afin de vous assurer que le ramassage des déchets correspond à votre charge de travail.

Notez que ces recommandations de surveillance servent de point de départ. Au fur et à mesure que vous vous familiariserez avec le comportement de votre système, vous souhaiterez peut-être ajuster ces seuils pour mieux correspondre à vos habitudes d'utilisation et à vos exigences spécifiques.

Que dois-je faire si mon revenu AvailableMVCCId tombe en dessous de 1,3 milliard ?

Si votre AvailableMVCCId indicateur tombe en dessous de 1,3 milliard, nous vous recommandons de prendre des mesures immédiates pour empêcher votre cluster de passer en mode lecture seule. Nous vous recommandons d'abord d'augmenter la taille de votre instance afin de fournir au ramasse-miettes davantage de ressources informatiques. Cela permet à votre application de continuer à fonctionner normalement tout en fournissant au ramasse-miettes la puissance supplémentaire dont il a besoin pour rattraper son retard.

Si la mise à l'échelle à elle seule n'améliore pas la situation, nous vous recommandons d'envisager de réduire vos opérations d'écriture. Utilisez la MvccIdAgeScale métrique pour identifier les collections spécifiques contenant des anciens MVCC IDs qui nécessitent une attention particulière. Une fois que vous aurez identifié ces collections, vous devrez peut-être réduire temporairement les opérations d'écriture pour permettre à la collecte des déchets de rattraper son retard. Pendant la période de reprise, nous vous recommandons de surveiller de près la AvailableMVCCId métrique pour vous assurer que vos actions ont l'effet escompté. Votre cluster est considéré comme sain une fois que AvailableMVCCId sa valeur revient à 1,5 milliard ou plus.

N'oubliez pas que ces étapes sont des mesures préventives destinées à aider votre système à se rétablir avant qu'il n'atteigne un état critique. Plus vous agissez rapidement après avoir vu le chiffre passer en dessous de 1,3 milliard, plus vous avez de chances d'éviter tout impact sur vos opérations d'écriture.