Müllabfuhr in Amazon DocumentDB

Amazon DocumentDB implementiert eine MVCC-Datenbankarchitektur (Multiversion 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, dass die Änderungen einer Transaktion in einer anderen erscheinen.

Grundlegendes zur Speicherbereinigung in Amazon DocumentDB

Garbage Collection (GC) ist ein automatisierter Hintergrundprozess, der die optimale Systemleistung und Verfügbarkeit in Amazon DocumentDB gewährleistet. Wie viele moderne Datenbanken erstellt die MVCC-Architektur von Amazon DocumentDB bei jedem Update neue Dokument- und Indexversionen. Jeder Schreibvorgang benötigt eine eindeutige MVCC-ID von einem endlichen Zähler. Diese IDs identifizieren, zu welcher Transaktion eine Dokumentversion gehört und ob sie festgeschrieben oder zurückgesetzt wurde. Im Laufe der Zeit häufen sich diese alten Versionen und ihre MVCC-IDs an und müssen bereinigt werden, um Leistungseinbußen zu verhindern.

Funktionen der Garbage-Collection

Der Garbage Collector erfüllt drei wesentliche Funktionen:

• Gewinnt Speicherplatz zurück — Er entfernt veraltete Dokument- und Indexversionen, die für aktive Abfragen nicht mehr benötigt werden, und gibt so Speicherplatz für zukünftige Schreibvorgänge frei.

• Beugt einem MVCC-ID-Überlauf vor — Es verhindert einen MVCC-ID-Überlauf, indem der endliche Zähler von MVCC-IDs verwaltet wird. Ohne diese Verwaltung würde der Zähler irgendwann sein Limit erreichen, sodass die Datenbank in einen temporären Lesemodus versetzt wird, bis die IDs wiederverwendet werden.

• Beibehaltung der Abfrageleistung — Es sorgt für eine optimale Abfrageleistung, indem tote Dokumentversionen entfernt werden, die sich sonst ansammeln und die Abfrageverarbeitung verlangsamen würden.

Prozess der Müllabfuhr

Der GC-Prozess wird pro Sammlung ausgeführt und kann mehrere Prozesse gleichzeitig in verschiedenen Sammlungen ausführen. Der Prozess besteht aus vier aufeinanderfolgenden Phasen:

1. Identifizierung — Das System identifiziert Dokument- und Indexversionen, auf die durch aktive Transaktionen oder Abfragen nicht mehr verwiesen wird.

2. Laden des Speichers — Alte Dokumente und Indexeinträge werden in den Speicher geladen, sofern sie nicht bereits vorhanden sind.

3. Löschen — Veraltete Versionen werden dauerhaft gelöscht, um Speicherplatz freizugeben.

4. MVCC-ID-Recycling — Das System recycelt MVCC-IDs aus gelöschten Versionen für neue Operationen.

Wenn die Garbage Collection die Verarbeitung alter Dokumentversionen abgeschlossen hat, werden die ältesten MVCC-IDs aus dem System entfernt. Diese Bereinigung ist entscheidend, um einen Überlauf der MVCC-IDs zu verhindern, indem MVCC-IDs 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 läuft in regelmäßigen Abständen automatisch im Hintergrund. Der Zeitpunkt und die Häufigkeit passen sich dynamisch an die Systemlast, die verfügbaren Ressourcen, das Schreibvolumen und den Verbrauch der MVCC-ID an. Bei hoher Schreibaktivität wird der GC-Prozess häufiger ausgeführt, um die gestiegene Anzahl von Dokumentversionen zu bewältigen.

Speicherarchitektur und erweiterter Speicher

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

Basis-Speichersegment

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

• Dokumentinhalt, der in die Standardseitengröße (8 KB) passt.

• Metadaten und Strukturinformationen des Dokuments.

• Primärindizes und ihre Einträge.

• Collection-level Statistik und Konfiguration.

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:

• Effizienter Umgang mit großen Dokumenten — Dokumente, die den Basisspeicherschwellenwert überschreiten, werden automatisch in das erweiterte Speichersegment verschoben.

• Optimiertes Speicherlayout — Das Segment verwendet ein anderes Speicherformat, das für große Objekte optimiert ist. Dadurch wird die Fragmentierung reduziert und die Zugriffsmuster verbessert.

• Unabhängige Speicherbereinigung — Das erweiterte Speichersegment verfügt über einen eigenen Garbage-Collection-Prozess, der unabhängig von der grundlegenden Speicherbereinigung ausgeführt werden kann.

• Transparenter Zugriff — Anwendungen greifen nahtlos auf große Dokumente zu, ohne wissen zu müssen, welches Speichersegment die Daten enthält.

Das erweiterte Speichersegment ist besonders vorteilhaft für:

• Sammlungen mit Dokumenten, die große eingebettete Arrays enthalten.

• Dokumente mit umfangreichen verschachtelten Strukturen.

• Sammlungen, in denen Binärdaten oder große Textfelder gespeichert werden.

• Anwendungen mit gemischten Dokumentgrößen, bei denen einige Dokumente die Durchschnittsgröße deutlich überschreiten.

Überwachung der Müllabfuhr

Metriken auf Clusterebene

AvailableMVCCIds

• Standort — Amazon CloudWatch

• Beschreibung — Ein Zähler, der die Anzahl der verbleibenden Schreibvorgänge anzeigt, die ab einer Höchstgrenze von 1,8 Milliarden verfügbar sind. Wenn dieser Zähler Null erreicht, wechselt Ihr Cluster in den schreibgeschützten Modus, bis die IDs abgerufen und wiederverwendet werden. Der Zähler sinkt mit jedem Schreibvorgang und steigt, wenn die Garbage Collection alte MVCC-IDs wiederverwendet.

• Empfehlung — Stellen Sie einen Alarm ein, wenn der Wert unter 1,3 Milliarden fällt. Diese Frühwarnung ermöglicht es Ihnen, die empfohlenen Maßnahmen zu ergreifen, die später besprochen werden.

LongestActiveGCRuntime

• Standort — Amazon CloudWatch

• Beschreibung — Dauer des längsten aktiven Garbage-Collection-Vorgangs in Sekunden. Wird jede Minute aktualisiert und verfolgt nur aktive Vorgänge, ausgenommen Prozesse, die innerhalb des Zeitfensters von einer Minute abgeschlossen werden.

• Empfehlung — Vergleichen Sie mit gcRuntimeStats historischen Daten, um abnormales Garbage-Collection-Verhalten zu identifizieren, z. B. längere Laufzeiten bei Massenlöschungen.

Metriken auf Sammelebene

MVCCIDStats: MVCCIdScale

• Standort — Befehl CollStats für die Datenbank

• Beschreibung — Misst das MVCC-ID-Alter auf einer Skala von 0 bis 1, wobei 1 das Höchstalter angibt, bevor ein Cluster in den schreibgeschützten Zustand übergeht. Verwenden Sie diese Metrik zusammenAvailableMVCCIds, um Sammlungen zu identifizieren, die die ältesten MVCC-IDs enthalten, die den Cluster altern lassen.

• Empfehlung — Behalten Sie für jede Sammlung Werte unter 0,3 bei.

gcRuntimeStats

• Standort — Befehl CollStats für die Datenbank

• Beschreibung — Stellt einen zweimonatigen Verlauf der Garbage Collection-Metriken bereit, einschließlich der Gesamtzahl der Durchläufe, der durchschnittlichen Dauer und der maximalen Dauer. Schließt nur Garbage Collection-Vorgänge ein, die länger als fünf Minuten dauern, um aussagekräftige Statistiken zu gewährleisten.

storageSizeStats

• Standort — Befehl CollStats für die Datenbank

• Beschreibung — Bietet eine detaillierte Aufschlüsselung der Speichernutzung in den verschiedenen Speichersegmenten:

  • storageSegmentBase— Speicher, der vom Basisspeichersegment für Standarddokumente genutzt wird

  • storageSegmentExtended— Speicher, der vom erweiterten Speichersegment für große Dokumente genutzt wird

• Nutzung — Hilft bei der Identifizierung von Sammlungen mit sehr großem Dokumentenspeicher und beim Verständnis der Speicherverteilungsmuster.

unusedStorageSize(Sammlungsebene)

• Standort — Befehl CollStats für die Datenbank

• Beschreibung — Schätzt den ungenutzten Speicherplatz in einer Sammlung auf der Grundlage von Stichprobenstatistiken. Es beinhaltet Speicherplatz aus gelöschten Dokumenten und leeren Segmenten. Die Metrik liefert sowohl kombinierte Gesamtwerte als auch Aufschlüsselungen pro Segment:

  • Kombiniert unusedBytes und für unusedPercent alle Speichersegmente

  • storageSegmentBase— Ungenutzter Speicherplatz, insbesondere im Basisspeichersegment

  • storageSegmentExtended— Ungenutzter Speicherplatz, insbesondere im erweiterten Speichersegment

documentFragmentStats

• Standort — Befehl CollStats für die Datenbank

• Beschreibung — Bietet detaillierte Informationen zu Dokumentfragmenten und toten Daten in Sammlungen. Dokumentfragmente stellen die internen Speichereinheiten dar, die von der Datenbank-Engine verwendet werden, und tote Fragmente weisen auf Daten hin, auf die nicht mehr zugegriffen werden kann, die aber noch nicht abgerufen wurden. Diese Metrik beinhaltet:

  • totalDocFragmentsCount— Gesamtzahl der Dokumentfragmente in der Sammlung

  • deadDocFragmentsCount— Anzahl der Fragmente, die tote (unzugängliche) Daten enthalten

  • deadDocFragmentsPercent— Prozentsatz der Fragmente, die tote Daten enthalten

  • deadDocFragmentBytes— Geschätzter Byteverbrauch durch tote Dokumentfragmente

  • Per-segment Aufschlüsselung für storageSegmentBase und storageSegmentExtended

• Nutzung — Überwachen Sie diese Kennzahl, um zu verstehen, wie effektiv die Müllabfuhr ist, und um zu ermitteln, welche Sammlungen von Wartungsarbeiten profitieren könnten. Ein hoher Prozentsatz toter Fragmente deutet darauf hin, dass die Müllabfuhr möglicherweise ins Hintertreffen gerät oder dass die Müllabfuhr von einer Optimierung profitieren würde.

Kennzahlen auf Indexebene

unusedStorageSize(Indexebene)

• Standort — Befehl „IndexStats“ für die Datenbank

• Beschreibung — Schätzt den ungenutzten Speicherplatz in einem Index auf der Grundlage von Stichprobenstatistiken. Es beinhaltet Speicherplatz aus veralteten Indexeinträgen und leeren Segmenten.

• Empfehlung — Verwenden Sie den reIndex Befehl, um Indizes ohne Ausfallzeiten neu zu erstellen und ungenutzten Speicherplatz zurückzugewinnen. Weitere Informationen finden Sie unter Indizes verwalten.

Beispiel für eine CollStats-Ausgabe

Das folgende Beispiel zeigt eine typische collStats Ausgabe mit Garbage-Collection- und Speichermetriken:

{
    "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 Garbage Collection nicht effizient funktioniert?

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

• Übermäßiger Sammlungsaufwand — Stetig steigende unusedStorageSize Kennzahlen bei umfangreichen Schreibvorgängen oder Massenlöschungen, insbesondere bei großen Indizes.

• Hoher Prozentsatz an toten Fragmenten — documentFragmentStats zeigt konstant hohe deadDocFragmentsPercent Werte (über 10-15%).

• Niedrigere Abfragelatenz — Erhöhte Abfragelatenz aufgrund der Häufung toter Dokumente.

• Verlängerte GC-Dauer — Garbage Collection-Operationen dauern länger als die historischen Durchschnittswerte. gcRuntimeStats

• Erhöhte GC-Verarbeitung — Hoch, LongestActiveGCRuntime was bedeutet, dass der Garbage Collector nicht mit den Systemanforderungen Schritt halten kann.

Beeinträchtigt die Garbage Collection die Leistung meiner Datenbank?

Unter normalen Bedingungen hat die Garbage Collection nur minimale Auswirkungen auf die Leistung. Wenn die Garbage Collection jedoch ins Hintertreffen gerät, kann Folgendes auftreten:

• Erhöhte Speicherkosten aufgrund angesammelter toter Dokumente.

• Langsamere Abfrageleistung aufgrund veralteter Indexeinträge.

• Temporärer schreibgeschützter Modus, wenn MVCC-IDs erschöpft sind.

• Höherer Ressourcenverbrauch bei intensiven Erfassungsläufen, insbesondere bei kleineren Instances.

• Geringere Effizienz bei Vorgängen im erweiterten Speichersegment für große Dokumente.

Kann ich die Müllabfuhr manuell auslösen?

Nein, die Müllabfuhr 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 Best Practice für den Betrieb einrichten?

Richten Sie die Überwachung sowohl auf Cluster- als auch auf Sammlungsebene ein, um eine optimale Leistung Ihres Amazon DocumentDB-Systems sicherzustellen.

Für die Überwachung auf Cluster-Ebene erstellen Sie zunächst einen CloudWatch Amazon-Alarm für die AvailableMVCCIds Metrik mit einem Schwellenwert von 1,3 Milliarden. Dies gibt Ihnen ausreichend Zeit, um Maßnahmen zu ergreifen, bevor die Metrik Null erreicht. An diesem Punkt würde Ihr Cluster in den schreibgeschützten Modus wechseln. Denken Sie daran, dass diese Metrik 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, wenn die Speicherbereinigung abgeschlossen ist.

Es ist auch wichtig, die LongestActiveGCRuntime Kennzahl über Amazon CloudWatch zu überwachen. Diese Metrik hilft Ihnen außerdem zu verstehengcRuntimeStats, wie effizient die Speicherbereinigung in Ihrem System funktioniert.

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

• MVCCIdScale— Achten Sie auf steigende Werte, die darauf hindeuten, dass MVCC-IDs älter werden und möglicherweise Aufmerksamkeit erfordern.

• gcRuntimeStats— Identifizieren Sie Garbage Collection-Prozesse, die ungewöhnlich lange dauern oder sich über mehrere Tage erstrecken.

• documentFragmentStats— deadDocFragmentsPercent Werte überwachen — konstant hohe Prozentsätze (über 10-15%) können darauf hindeuten, dass die Müllabfuhr ins Hintertreffen gerät.

• storageSizeStatsund unusedStorageSize — Verfolgen Sie die Speicherauslastungsmuster und identifizieren Sie Sammlungen mit erheblichem ungenutztem Speicherplatz in beiden Speichersegmenten.

Sammlungen mit häufigen Schreibvorgängen erfordern besondere Aufmerksamkeit, da sie dem Garbage Collector mehr Arbeit abverlangen. Überprüfe diese Metriken häufiger für Sammlungen mit hoher Schreibaktivität, um sicherzustellen, dass die Garbage Collection mit deiner Arbeitslast Schritt hält.

Beachten Sie, dass diese Überwachungsempfehlungen als Ausgangspunkt dienen. Wenn Sie sich mit dem Verhalten Ihres Systems vertraut machen, sollten Sie diese Schwellenwerte möglicherweise anpassen, um Ihren spezifischen Nutzungsmustern und Anforderungen besser gerecht zu werden.

Was muss ich tun, wenn meine verfügbaren MVCCIDs unter 1,3 Milliarden fallen?

Wenn Ihre AvailableMVCCIds Metrik unter 1,3 Milliarden fällt, ergreifen Sie sofort Maßnahmen, um zu verhindern, dass Ihr Cluster in den schreibgeschützten Modus wechselt. Skalieren Sie zunächst Ihre Instance-Größe, um dem Garbage Collector mehr Rechenressourcen zur Verfügung zu stellen. Auf diese Weise kann Ihre Anwendung ihren normalen Betrieb fortsetzen und gleichzeitig erhält der Garbage Collector die zusätzliche Leistung, die er benötigt, um den Anschluss aufzuholen.

Wenn eine Skalierung allein die Situation nicht verbessert, sollten Sie erwägen, Ihre Schreibvorgänge zu reduzieren. Verwenden Sie die MVCCIdScale Metrik, um zu ermitteln, welche spezifischen Sammlungen ältere MVCC-IDs enthalten, die Aufmerksamkeit erfordern. Überwachen Sie außerdem, documentFragmentStats um Sammlungen mit einem hohen Prozentsatz an toten Fragmenten zu identifizieren, die zur Ineffizienz der Speicherbereinigung beitragen könnten.

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. Überwachen Sie die AvailableMVCCIds Kennzahl während der Erholungsphase genau, um sicherzustellen, dass Ihre Aktionen die gewünschte Wirkung haben. Ihr Cluster gilt als intakt, sobald der AvailableMVCCIds Wert auf 1,5 Milliarden oder höher zurückkehrt.

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 die Kennzahl unter 1,3 Milliarden gefallen ist, desto wahrscheinlicher ist es, dass Sie jegliche Auswirkungen auf Ihre Schreibvorgänge vermeiden.