Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Müllabfuhr in Amazon DocumentDB

Amazon DocumentDB implementiert eine MVCC-Datenbankarchitektur (Multi-Version Concurrency Control), die für jeden Aktualisierungsvorgang neue Versionen von Dokument- und Indexeinträgen erstellt. Diese Architektur ermöglicht die Isolierung von Transaktionen und verhindert so, dass die Änderungen einer Transaktion in einer anderen erscheinen.

Grundlegendes zur Müllabfuhr in Amazon DocumentDB

Garbage Collection (GC) ist ein automatisierter Hintergrundprozess, der eine optimale Systemleistung und Verfügbarkeit in Amazon DocumentDB gewährleistet. Wie viele moderne Datenbanken erstellt auch die MVCC-Architektur von Amazon DocumentDB mit jeder Aktualisierung neue Dokument- und Indexversionen. Jeder Schreibvorgang verbraucht eine eindeutige MVCC-ID aus einem endlichen Zähler. Diese IDs geben an, zu welcher Transaktion eine Dokumentversion gehört und ob sie festgeschrieben oder zurückgesetzt wurde. Im Laufe der Zeit IDs häufen sich diese alten Versionen und ihr MVCC an, sodass eine Bereinigung erforderlich ist, um Leistungseinbußen vorzubeugen.

Funktionen der Müllabfuhr

Der Müllsammler erfüllt drei wesentliche Funktionen:

Prozess der Müllabfuhr

Der GC-Prozess wird pro Sammlung ausgeführt und es können mehrere Prozesse gleichzeitig in verschiedenen Sammlungen ausgeführt werden. Der Prozess besteht aus vier aufeinanderfolgenden Phasen:

Wenn die Garbage-Collection die Verarbeitung alter Dokumentversionen abgeschlossen hat, entfernt es das älteste MVCC IDs aus dem System. Diese Bereinigung ist entscheidend, um einen MVCC-ID-Überlauf zu verhindern IDs, indem MVCC recycelt und für neue Schreibvorgänge im gesamten Cluster verfügbar gemacht werden. Ohne diesen Recyclingprozess würde das System irgendwann seinen begrenzten MVCC-ID-Zähler erschöpfen und in einen schreibgeschützten Zustand übergehen.

Planung der Müllabfuhr

Die Müllabfuhr wird in regelmäßigen Abständen automatisch im Hintergrund ausgeführt. Das Timing und die Frequenz passen sich dynamisch an die Systemlast, die verfügbaren Ressourcen, das Schreibvolumen und den MVCC-ID-Verbrauch an. Bei hoher Schreibaktivität wird der GC-Prozess häufiger ausgeführt, um die erhöhte Anzahl von Dokumentversionen zu bewältigen.

Speicherarchitektur und erweiterter Speicher

Amazon DocumentDB verwendet eine ausgeklügelte Speicherarchitektur, die den Dokumentenspeicher in zwei unterschiedliche Segmente unterteilt:

Basisspeichersegment

Das Basisspeichersegment enthält die primären Dokumentdaten und Metadaten. In diesem Segment wird Folgendes gespeichert:

Erweitertes Speichersegment

Das erweiterte Speichersegment verwendet einen speziellen Objektspeicher für große Dokumente, der für die Verarbeitung von Dokumenten konzipiert ist, die die Standardspeicherseitengröße überschreiten. Dieses Segment bietet:

Das erweiterte Speichersegment ist besonders vorteilhaft für:

Überwachung der Müllabfuhr

Metriken auf Clusterebene

AvailableMVCCIds

LongestActiveGCRuntime

Kennzahlen auf Erfassungsebene

MVCCIDStats: MVCCIdScale

gcRuntimeStats

storageSizeStats

unusedStorageSize(Sammlungsebene)

documentFragmentStats

Kennzahlen auf Indexebene

unusedStorageSize(Indexebene)

Beispiel für eine CollStats-Ausgabe

Das folgende Beispiel zeigt eine typische collStats Ausgabe mit Metriken zur Garbage-Collection und Speicherung:

{
    "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)
}

Häufig gestellte Fragen

Wie erkenne ich, ob die Müllabfuhr nicht effizient funktioniert?

Achten Sie auf diese Warnzeichen, die auf eine ineffiziente Müllabfuhr hinweisen:

Beeinträchtigt die Garbage-Collection die Leistung meiner Datenbank?

Unter normalen Bedingungen hat die Garbage-Collection nur minimale Auswirkungen auf die Leistung. Wenn die Müllabfuhr jedoch ins Hintertreffen gerät, kann es zu folgenden Problemen kommen:

Kann ich die Müllabfuhr manuell auslösen?

Nein, die Garbage-Collection in Amazon DocumentDB kann nicht manuell ausgelöst werden. Das System verwaltet die Müllabfuhr im Rahmen seiner internen Wartungsarbeiten automatisch.

Welche Alarme sollte ich als bewährte Methode für den Betrieb einrichten?

Wir empfehlen, die Überwachung sowohl auf Cluster- als auch auf Sammlungsebene einzurichten, um eine optimale Leistung Ihres Amazon DocumentDB-Systems sicherzustellen.

Für die Überwachung auf Clusterebene erstellen Sie zunächst einen CloudWatch Amazon-Alarm für die AvailableMVCCIds Metrik mit einem Schwellenwert von 1,3 Milliarden. Auf diese Weise haben Sie ausreichend Zeit, um Maßnahmen zu ergreifen, bevor die Metrik Null erreicht. Ab diesem Zeitpunkt würde Ihr Cluster in den schreibgeschützten Modus wechseln. Denken Sie daran, dass diese Kennzahl je nach Ihren spezifischen Nutzungsmustern schwanken kann. Manche Kunden gehen davon aus, dass sie unter 1,3 Milliarden fällt und sich dann wieder auf über 1,5 Milliarden erholt, sobald die Garbage-Collection ihre Arbeit abgeschlossen hat.

Es ist auch wichtig, die LongestActiveGCRuntime Metrik über Amazon zu überwachen CloudWatch. Diese Metrik hilft IhnengcRuntimeStats, zu verstehen, wie effizient die Speicherbereinigung in Ihrem gesamten System funktioniert.

Konzentrieren Sie sich bei der Überwachung auf Sammlungsebene auf die folgenden wichtigen Kennzahlen:

Sammlungen mit häufigen Schreibvorgängen erfordern besondere Aufmerksamkeit, da sie mehr Arbeit für den Garbage-Collector bedeuten. Wir empfehlen, diese Metriken bei Sammlungen mit starker Schreibaktivität häufiger zu überprüfen, um sicherzustellen, dass die Garbage-Collection mit Ihrer Arbeitslast Schritt hält.

Beachten Sie, dass diese Überwachungsempfehlungen als Ausgangspunkt dienen. Wenn Sie mit dem Verhalten Ihres Systems besser vertraut sind, sollten Sie diese Schwellenwerte möglicherweise anpassen, um sie besser an Ihre spezifischen Nutzungsmuster und Anforderungen anzupassen.

Was sollte ich tun, wenn mein Wert unter 1,3 Milliarden AvailableMVCCIds fällt?

Wenn Ihre AvailableMVCCIds Metrik unter 1,3 Milliarden fällt, empfehlen wir, sofort Maßnahmen zu ergreifen, um zu verhindern, dass Ihr Cluster in den schreibgeschützten Modus wechselt. Wir empfehlen, zunächst Ihre Instance-Größe zu vergrößern, um dem Garbage Collector mehr Rechenressourcen zur Verfügung zu stellen. Dies ist unsere wichtigste Empfehlung, da es Ihrer Anwendung ermöglicht, den normalen Betrieb fortzusetzen und gleichzeitig dem Garbage Collector die zusätzliche Leistung zu geben, die er zum Aufholen benötigt.

Wenn eine Skalierung allein die Situation nicht verbessert, empfehlen wir, eine Reduzierung Ihrer Schreibvorgänge in Betracht zu ziehen. Identifizieren Sie anhand der MVCCIdScale Metrik, welche spezifischen Sammlungen ältere MVCCs enthalten IDs , die bearbeitet werden müssen. Überwachen Sie außerdem Sammlungen mit einem hohen Prozentsatz documentFragmentStats an toten Fragmenten, die möglicherweise zur Ineffizienz der Müllsammlung beitragen.

Sobald Sie diese Sammlungen identifiziert haben, müssen Sie möglicherweise vorübergehend die Schreibvorgänge auf sie reduzieren, damit die Garbage-Collection aufholen kann. Während der Erholungsphase empfehlen wir, die AvailableMVCCIds Metrik genau zu beobachten, um sicherzustellen, dass Ihre Maßnahmen die gewünschte Wirkung haben. Ihr Cluster gilt als fehlerfrei, sobald der AvailableMVCCIds Wert wieder 1,5 Milliarden oder höher erreicht.

Denken Sie daran, dass es sich bei diesen Schritten um vorbeugende Maßnahmen handelt, mit denen Ihr System wiederhergestellt werden kann, bevor es einen kritischen Zustand erreicht. Je früher Sie Maßnahmen ergreifen, nachdem der Wert unter 1,3 Milliarden gesunken ist, desto wahrscheinlicher ist es, dass Sie jegliche Auswirkungen auf Ihre Schreibvorgänge vermeiden.