Collecte des déchets dans Amazon DocumentDB - Amazon DocumentDB
Comprendre la collecte des déchets dans Amazon DocumentDBProcessus de collecte des orduresArchitecture de stockage et stockage étenduSurveillance de la collecte des déchetsExemple de sortie CollStatsQuestions fréquentes (FAQ)

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 les transactions, empêchant ainsi les modifications d'une transaction d'apparaître dans une autre.

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. Comme de nombreuses bases de données modernes, l'architecture MVCC d'Amazon DocumentDB crée de nouvelles versions de documents et d'index à chaque mise à jour. Chaque opération d'écriture consomme un identifiant MVCC unique provenant d'un compteur fini. Ils IDs identifient à quelle transaction appartient une version du document et si elle a été validée ou annulée. Au fil du temps, ces anciennes versions et leur MVCC IDs s'accumulent, ce qui nécessite un nettoyage 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 permet de maintenir des performances de requête optimales en éliminant les versions de documents obsolètes 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.

Architecture de stockage et stockage étendu

Amazon DocumentDB utilise une architecture de stockage sophistiquée qui sépare le stockage des documents en deux segments distincts :

Segment de stockage de base

Le segment de stockage de base contient les données et métadonnées du document principal. Ce segment stocke :

  • Contenu du document adapté à la taille de page standard (8 Ko).

  • Informations sur les métadonnées et les structures des documents.

  • Les index principaux et leurs entrées.

  • Statistiques et configuration au niveau de la collection.

Segment de stockage étendu

Le segment de stockage étendu utilise un magasin d'objets de grande taille spécialisé conçu pour traiter les documents dont la taille de page de stockage standard est supérieure à la taille de page de stockage standard. Ce segment fournit :

  • Gestion efficace des documents volumineux — Les documents dont la taille est supérieure au seuil de stockage de base sont automatiquement déplacés vers le segment de stockage étendu.

  • Disposition de stockage optimisée : le segment utilise un format de stockage différent optimisé pour les objets volumineux, ce qui réduit la fragmentation et améliore les modèles d'accès.

  • Collecte indépendante des déchets — Le segment du stockage étendu possède son propre processus de collecte des déchets qui peut être exécuté indépendamment du nettoyage du stockage de base.

  • Accès transparent : les applications accèdent facilement à des documents volumineux sans avoir besoin de savoir quel segment de stockage contient les données.

Le segment du stockage étendu est particulièrement avantageux pour :

  • Collections contenant des documents contenant de grands tableaux intégrés.

  • Documents dotés de structures imbriquées étendues.

  • Collections stockant des données binaires ou de grands champs de texte.

  • Applications avec des tailles de documents mixtes où certains documents dépassent largement la taille moyenne.

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 à partir d'une limite maximale de 1,8 milliard. 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.

LongestActiveGCRuntime

  • 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 — Comparez les données avec les données gcRuntimeStats historiques pour identifier les comportements anormaux de collecte des déchets, tels que les durées d'exécution prolongées lors de suppressions groupées.

Mesures au niveau de la collecte

MVCCIDStats: MVCCIdScale

  • 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.

Important

gcRuntimeStatsdocumentFragmentStats, et la répartition des métriques au niveau de la collection en storageSegmentBase et ne storageSegmentExtended sont disponibles que pour Amazon DocumentDB 8.0.

storageSizeStats

  • Emplacement — Commande CollStats de base de données

  • Description : fournit une ventilation détaillée de l'utilisation du stockage entre les différents segments de stockage :

    • storageSegmentBase— Stockage utilisé par le segment de stockage de base pour les documents standard

    • storageSegmentExtended— Stockage utilisé par le segment de stockage étendu pour les documents volumineux

  • Utilisation : permet d'identifier les collections contenant un volume important de documents et de comprendre les modèles de distribution du stockage.

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. La métrique fournit à la fois des totaux combinés et des ventilations par segment :

    • Combiné unusedBytes et unusedPercent dans tous les segments de stockage

    • storageSegmentBase— Espace inutilisé spécifiquement dans le segment de stockage de base

    • storageSegmentExtended— Espace inutilisé, en particulier dans le segment du stockage étendu

documentFragmentStats

  • Emplacement — Commande CollStats de base de données

  • Description — Fournit des informations détaillées sur les fragments de documents et les données non utilisées dans les collections. Les fragments de document représentent les unités de stockage internes utilisées par le moteur de base de données, tandis que les fragments morts indiquent des données qui ne sont plus accessibles mais qui n'ont pas encore été récupérées. Cette métrique inclut :

    • totalDocFragmentsCount— Nombre total de fragments de documents dans la collection

    • deadDocFragmentsCount— Nombre de fragments contenant des données mortes (inaccessibles)

    • deadDocFragmentsPercent— Pourcentage de fragments contenant des données inactives

    • deadDocFragmentBytes— Estimation du nombre d'octets consommés par les fragments de document morts

    • Répartition par segment pour et storageSegmentBase storageSegmentExtended

  • Utilisation — Surveillez cette métrique pour comprendre l'efficacité de la collecte des déchets et identifier les collectes susceptibles de bénéficier des opérations de maintenance. Des pourcentages élevés de fragments morts indiquent que la collecte des déchets est peut-être en retard ou qu'il serait utile d'optimiser la collecte.

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 de sortie CollStats

L'exemple suivant montre une collStats sortie typique avec des métriques de collecte des déchets et de stockage :

{
    "ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
    "MVCCIdStats" : {
        "MVCCIdScale" : 0.03
    },
    "gcRuntimeStats" : {
        "numRuns" : 1,
        "historicalAvgRuntime" : 3295,
        "historicalMaxRuntime" : 3295,
        "lastRuntime" : 3295,
        "lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
    },
    "documentFragmentStats" : {
        "totalDocFragmentsCount" : 45000000,
        "deadDocFragmentsCount" : 2250000,
        "deadDocFragmentsPercent" : 5.0,
        "deadDocFragmentBytes" : 98304000,
        "storageSegmentBase" : {
            "totalDocFragmentsCount" : 30000000,
            "deadDocFragmentsCount" : 1500000,
            "deadDocFragmentsPercent" : 5.0,
            "deadDocFragmentBytes" : 65536000
        },
        "storageSegmentExtended" : {
            "totalDocFragmentsCount" : 15000000,
            "deadDocFragmentsCount" : 750000,
            "deadDocFragmentsPercent" : 5.0,
            "deadDocFragmentBytes" : 32768000
        }
    },
    "collScans" : 14,
    "count" : 30000000,
    "size" : 1320000000,
    "avgObjSize" : 44,
    "storageSize" : 6461497344,
    "storageSizeStats" : {
        "storageSegmentBase" : 4307664896,
        "storageSegmentExtended" : 2153832448
    },
    "capped" : false,
    "nindexes" : 2,
    "totalIndexSize" : 9649553408,
    "indexSizes" : {
        "_id_" : 1910661120,
        "c_1" : 7738892288
    },
    "unusedStorageSize" : {
        "unusedBytes" : 4201881600,
        "unusedPercent" : 65.05,
        "storageSegmentBase" : {
            "unusedBytes" : 2801254400,
            "unusedPercent" : 65.05
        },
        "storageSegmentExtended" : {
            "unusedBytes" : 1400627200,
            "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)

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 excessive des collections : augmentation constante unusedStorageSize des statistiques lors d'écritures intensives ou de suppressions massives, en particulier pour les index volumineux.

  • Pourcentage élevé de fragments morts : documentFragmentStats affichage constant de deadDocFragmentsPercent valeurs élevées (supérieures à 10 à 15 %).

  • 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 engcRuntimeStats.

  • Traitement GC élevé — Un niveau élevé LongestActiveGCRuntime 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 :

  • Coûts de stockage accrus 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.

  • Utilisation accrue des ressources lors de collectes intensives, en particulier sur les petites instances.

  • Efficacité réduite dans les opérations de segments de stockage étendus pour les documents volumineux.

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 Amazon pour la AvailableMVCCIds 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 cet indicateur peut fluctuer en fonction de vos habitudes d'utilisation spécifiques : certains clients le voient chuter en dessous de 1,3 milliard, puis remonter au-dessus de 1,5 milliard une fois que le ramassage des déchets est terminé.

Il est également important de surveiller la LongestActiveGCRuntime métrique via Amazon CloudWatch. Cette métrique, associée àgcRuntimeStats, vous aide à comprendre l'efficacité de la collecte des déchets dans votre système.

Pour le suivi au niveau de la collection, concentrez-vous sur ces indicateurs clés :

  • MVCCIdScale— Surveillez les valeurs croissantes qui suggèrent que les MVCC IDs vieillissent et peuvent nécessiter une attention particulière.

  • gcRuntimeStats— Identifiez les processus de collecte des déchets qui prennent inhabituellement du temps ou s'étendent sur plusieurs jours.

  • documentFragmentStats— Surveillez deadDocFragmentsPercent les valeurs : des pourcentages constamment élevés (supérieurs à 10 à 15 %) peuvent indiquer que la collecte des déchets est en retard.

  • storageSizeStatset unusedStorageSize — Suivez les modèles d'utilisation du stockage et identifiez les collections présentant un espace inutilisé important dans l'un ou l'autre des segments de stockage.

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 AvailableMVCCIds tombe en dessous de 1,3 milliard ?

Si votre AvailableMVCCIds 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. Il s'agit de notre principale recommandation, car elle permet à votre application de continuer à fonctionner normalement tout en donnant 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 MVCCIdScale métrique pour identifier les collections spécifiques contenant des anciens MVCC IDs qui nécessitent une attention particulière. De plus, surveillez documentFragmentStats pour identifier les collections présentant des pourcentages élevés de fragments morts qui peuvent contribuer à l'inefficacité de la collecte des déchets.

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 AvailableMVCCIds métrique pour vous assurer que vos actions ont l'effet escompté. Votre cluster est considéré comme sain une fois que AvailableMVCCIds 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.