View a markdown version of this page

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 orduresExemple 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 met en œuvre une architecture de base de données de contrôle de simultanéité multiversion (MVCC) qui crée de nouvelles versions des documents et des entrées 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. Ces identifiants identifient à quelle transaction appartient une version du document et indiquent si elle a été validée ou annulée. Au fil du temps, ces anciennes versions et leurs identifiants MVCC s'accumulent, ce qui nécessite un nettoyage pour éviter toute dégradation des performances.

Fonctions de collecte des ordures

Le ramasse-miettes remplit trois fonctions essentielles :

  • Récupère de l'espace de stockage — Il supprime les versions obsolètes des documents et des index qui ne sont plus nécessaires pour les requêtes actives, libérant ainsi de l'espace pour les opérations d'écriture futures.

  • Empêche le débordement des ID MVCC — Il empêche le débordement des ID MVCC en gérant le compteur fini d'ID MVCC. Sans cette gestion, le compteur finirait par atteindre ses limites, forçant la base de données à passer temporairement en mode lecture seule jusqu'à ce que les identifiants soient recyclés.

  • Maintient les performances des requêtes — Il maintient des performances de requête optimales en éliminant les versions de documents morts qui s'accumuleraient autrement et ralentiraient le traitement des requêtes.

Processus de collecte des ordures

Le processus GC fonctionne par collection et peut avoir 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 libérer de l'espace de stockage.

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

Lorsque le ramasse-miettes termine le traitement des anciennes versions des documents, il supprime les plus anciens identifiants MVCC du système. Ce nettoyage est essentiel pour empêcher le débordement des identifiants MVCC en recyclant les identifiants MVCC, afin de les rendre disponibles pour de nouvelles opérations d'écriture sur le cluster. Sans ce processus de recyclage, le système finirait par épuiser son compteur d'ID MVCC fini et passerait en mode lecture seule.

Planification de la collecte des déchets

La collecte des déchets s'effectue 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 les métadonnées du document principal. Ce segment stocke :

  • Contenu du document conforme au format de page standard (8 Ko).

  • Métadonnées du document et informations de structure.

  • Les index principaux et leurs entrées.

  • Collection-level statistiques et configuration.

Segment de stockage étendu

Le segment de stockage étendu utilise un magasin d'objets de grande taille spécialisé conçu pour gérer les documents dont la taille de page dépasse la taille de page de stockage standard. Ce segment fournit :

  • Gestion efficace des documents volumineux  : les documents dont la taille dépasse le 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 de 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 intéressant 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 ordures

Métriques de niveau cluster

AvailableMVCCIds

  • Lieu — Amazon CloudWatch

  • Description  : 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 que les identifiants soient récupérés et recyclés. Le compteur diminue à chaque opération d'écriture et augmente à mesure que le ramasse-miettes recycle les anciens identifiants 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 qui seront abordées plus loin.

LongestActiveGCRuntime

  • Lieu — Amazon CloudWatch

  • Description — Durée en secondes du plus long processus de collecte des déchets actif. Met à jour toutes les minutes et suit uniquement les opérations actives, à l'exception des processus qui se terminent dans la fenêtre d'une minute.

  • Recommandation — Comparez 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 des suppressions groupées.

Mesures relatives au niveau de collecte

MVCCIDStats: MVCCIdScale

  • Emplacement  : commande CollStats de la 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 passe en mode lecture seule. Utilisez cette métrique conjointement AvailableMVCCIds pour identifier les collections contenant les plus anciens identifiants MVCC qui font vieillir le cluster.

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

gcRuntimeStats

  • Emplacement  : commande CollStats de la 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 d'une durée supérieure à cinq minutes afin de garantir des statistiques significatives.

storageSizeStats

  • Emplacement  : commande CollStats de la base de données

  • Description  : fournit une ventilation détaillée de l'utilisation du stockage sur 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 comportant un stockage important de documents volumineux et de comprendre les modèles de distribution du stockage.

unusedStorageSize(niveau de collecte)

  • Emplacement  : commande CollStats de la base de données

  • Description  : estime l'espace de stockage inutilisé dans une collection sur la base de statistiques échantillonnées. Il inclut de l'espace pour les documents supprimés et les segments vides. La métrique fournit à la fois des totaux combinés et des ventilations par segment :

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

    • storageSegmentBase— Espace inutilisé, en particulier dans le segment de stockage de base

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

documentFragmentStats

  • Emplacement  : commande CollStats de la base de données

  • Description  : fournit des informations détaillées sur les fragments de documents et les données mortes au sein des 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 mortes

    • deadDocFragmentBytes— Nombre estimé d'octets consommés par les fragments de documents morts

    • Per-segment répartition pour storageSegmentBase et storageSegmentExtended

  • Utilisation — Surveillez cette métrique pour comprendre l'efficacité de la collecte des déchets et identifier les collections 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 que la collecte gagnerait à être optimisée.

Mesures au niveau de l'indice

unusedStorageSize(niveau de l'indice)

  • Emplacement  : commande IndexStats de la base de données

  • Description  : estime l'espace de stockage inutilisé dans un index sur la base de statistiques échantillonnées. Il inclut de l'espace pour les entrées d'index obsolètes et les segments vides.

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

Exemple de sortie CollStats

L'exemple suivant montre une collStats sortie typique avec des mesures 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 la collecte des déchets ne fonctionne pas efficacement ?

Surveillez ces panneaux d'avertissement qui indiquent une collecte des ordures inefficace :

  • Encombrement excessif des collections  : les unusedStorageSize métriques augmentent régulièrement lors d'écritures lourdes ou de suppressions en masse, en particulier pour les index volumineux.

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

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

  • Durée prolongée du GC — Les opérations de collecte des ordures prennent plus de temps que les moyennes historiques engcRuntimeStats.

  • Traitement GC élevé — Élevé LongestActiveGCRuntime indiquant 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, la collecte 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 dus à l'accumulation de documents morts.

  • Performances de requêtes plus lentes en raison d'entrées d'index obsolètes.

  • Mode lecture seule temporaire si les identifiants MVCC sont épuisés.

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

  • Réduction de l'efficacité des opérations de segment de stockage étendu pour les documents volumineux.

Puis-je déclencher manuellement la collecte des déchets ?

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 déchets dans le cadre de ses opérations de maintenance internes.

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

Configurez la surveillance au niveau du cluster et de la collection pour 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 dépasser 1,5 milliard une fois que la collecte des déchets termine ses travaux.

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

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

  • MVCCIdScale— Surveillez les valeurs croissantes qui suggèrent que les identifiants MVCC 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 un retard dans la collecte des déchets.

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

Les collections dont 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. Vérifiez ces indicateurs plus fréquemment pour les collections dont l'activité d'écriture est intense, afin de vous assurer que la collecte des déchets suit votre charge de travail.

Notez que ces recommandations de suivi 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 répondre à vos habitudes d'utilisation et à vos exigences spécifiques.

Que dois-je faire si mes McCID disponibles tombent en dessous de 1,3 milliard ?

Si votre AvailableMVCCIds métrique tombe en dessous de 1,3 milliard, prenez des mesures immédiates pour empêcher votre cluster de passer en mode lecture seule. Tout d'abord, augmentez la taille de votre instance pour fournir au ramasse-miettes davantage de ressources informatiques. Cela 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, envisagez de réduire vos opérations d'écriture. Utilisez cette MVCCIdScale métrique pour identifier les collections spécifiques contenant des identifiants MVCC plus anciens qui nécessitent une attention particulière. En outre, surveillez documentFragmentStats pour identifier les collections présentant des pourcentages élevés de fragments morts qui pourraient 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 sur celles-ci pour permettre à la collecte des déchets de rattraper son retard. Pendant la période de reprise, surveillez de près l'AvailableMVCCIdsindicateur 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 tôt vous agirez après avoir vu la métrique chuter en dessous de 1,3 milliard, plus vous aurez de chances d'éviter tout impact sur vos opérations d'écriture.