Raccolta dei rifiuti in Amazon DocumentDB

Amazon DocumentDB implementa un'architettura di database MVCC (Multi-version Concurrency Control) che crea nuove versioni di voci di documenti e indici per ogni operazione di aggiornamento. Questa architettura consente l'isolamento delle transazioni, impedendo che le modifiche di una transazione appaiano in un'altra.

Comprendere la Garbage Collection in Amazon DocumentDB

Garbage collection (GC) è un processo automatizzato in background che mantiene prestazioni e disponibilità di sistema ottimali in Amazon DocumentDB. Come molti database moderni, l'architettura MVCC di Amazon DocumentDB crea nuove versioni di documenti e indici con ogni aggiornamento. Ogni operazione di scrittura utilizza un ID MVCC univoco da un contatore finito. Questi IDs identificano a quale transazione appartiene la versione di un documento e se è stato eseguito il commit o il rollback. Nel tempo, queste vecchie versioni e il relativo MVCC IDs si accumulano e richiedono una pulizia per prevenire il degrado delle prestazioni.

Funzioni di raccolta dei rifiuti

Garbage collector svolge tre funzioni essenziali:

• Recupera spazio di archiviazione: rimuove le versioni obsolete di documenti e indici che non sono più necessarie per le query attive, liberando spazio per future operazioni di scrittura.

• Impedisce l'overflow dell'ID MVCC: previene l'overflow dell'ID MVCC gestendo il contatore finito di MVCC. IDs Senza questa gestione, il contatore alla fine raggiungerebbe il limite, forzando il database a passare alla modalità temporanea di sola lettura fino al riciclo. IDs

• Mantiene le prestazioni delle query: mantiene le prestazioni ottimali delle query eliminando le versioni obsolete dei documenti che altrimenti si accumulerebbero e rallenterebbero l'elaborazione delle query.

Processo di raccolta dei rifiuti

Il processo GC funziona per raccolta e può avere più processi in esecuzione contemporaneamente su diverse raccolte. Il processo consiste in quattro fasi sequenziali:

1. Identificazione: il sistema identifica le versioni dei documenti e degli indici a cui non fanno più riferimento le transazioni o le query attive.

2. Caricamento della memoria: i vecchi documenti e le voci dell'indice vengono caricati in memoria se non sono già presenti.

3. Eliminazione: le versioni obsolete vengono eliminate definitivamente per recuperare spazio di archiviazione.

4. Riciclaggio degli ID MVCC: il sistema ricicla l'MVCC IDs delle versioni eliminate per nuove operazioni.

Quando Garbage Collection completa l'elaborazione delle vecchie versioni dei documenti, rimuove l'MVCC più vecchio dal sistema. IDs Questa pulizia è fondamentale per prevenire l'overflow degli ID MVCC riciclando MVCC e rendendoli disponibili per nuove IDs operazioni di scrittura nel cluster. Senza questo processo di riciclaggio, il sistema finirebbe per esaurire il contatore ID MVCC finito e passare allo stato di sola lettura.

Pianificazione della raccolta dei rifiuti

La raccolta dei rifiuti viene eseguita automaticamente in background a intervalli periodici. La tempistica e la frequenza si regolano dinamicamente in base al carico del sistema, alle risorse disponibili, al volume di scrittura e ai livelli di consumo dell'ID MVCC. Durante un'elevata attività di scrittura, il processo GC viene eseguito più frequentemente per gestire l'aumento del numero di versioni dei documenti.

Architettura di storage e storage esteso

Amazon DocumentDB utilizza una sofisticata architettura di storage che separa lo storage dei documenti in due segmenti distinti:

Segmento di archiviazione di base

Il segmento di archiviazione di base contiene i dati e i metadati principali del documento. Questo segmento memorizza:

• Contenuto del documento che rientra nelle dimensioni standard della pagina (8 KB).

• Metadati del documento e informazioni sulla struttura.

• Indici primari e relative voci.

• Statistiche e configurazione a livello di raccolta.

Segmento di archiviazione esteso

Il segmento di archiviazione estesa utilizza un archivio di oggetti documentale di grandi dimensioni specializzato progettato per gestire documenti che superano le dimensioni della pagina di archiviazione standard. Questo segmento offre:

• Gestione efficiente di documenti di grandi dimensioni: i documenti che superano la soglia di archiviazione di base vengono spostati automaticamente nel segmento di archiviazione estesa.

• Layout di archiviazione ottimizzato: il segmento utilizza un formato di archiviazione diverso ottimizzato per oggetti di grandi dimensioni, che riduce la frammentazione e migliora i modelli di accesso.

• Independent Garbage Collection: il segmento di archiviazione estesa dispone di un proprio processo di raccolta dei rifiuti che può essere eseguito indipendentemente dalla pulizia dello storage di base.

• Accesso trasparente: le applicazioni accedono senza problemi a documenti di grandi dimensioni senza bisogno di sapere quale segmento di archiviazione contiene i dati.

Il segmento di archiviazione esteso è particolarmente utile per:

• Raccolte con documenti contenenti matrici incorporate di grandi dimensioni.

• Documenti con ampie strutture annidate.

• Raccolte che memorizzano dati binari o campi di testo di grandi dimensioni.

• Applicazioni con documenti di dimensioni miste in cui alcuni documenti superano notevolmente le dimensioni medie.

Monitoraggio della raccolta dei rifiuti

Metriche a livello di cluster

AvailableMVCCIds

• Ubicazione — Amazon CloudWatch

• Descrizione: un contatore che mostra il numero di operazioni di scrittura rimanenti disponibili a partire da un limite massimo di 1,8 miliardi. Quando questo contatore raggiunge lo zero, il cluster entra in modalità di sola lettura fino a quando non IDs viene recuperato e riciclato. Il contatore diminuisce a ogni operazione di scrittura e aumenta man mano che la Garbage Collection ricicla il vecchio MVCC. IDs

• Raccomandazione: imposta un allarme quando il valore scende al di sotto di 1,3 miliardi. Questo avviso precoce consente di adottare le misure consigliate discusse più avanti.

LongestActiveGCRuntime

• Ubicazione — Amazon CloudWatch

• Descrizione: Durata in secondi del processo di raccolta dei rifiuti attivo più lungo. Si aggiorna ogni minuto e tiene traccia solo delle operazioni attive, esclusi i processi che vengono completati entro la finestra di un minuto.

• Raccomandazione: confrontalo con i dati gcRuntimeStats storici per identificare comportamenti anomali di raccolta dei rifiuti, ad esempio tempi di esecuzione prolungati durante le eliminazioni in blocco.

Metriche a livello di raccolta

MVCCIDStats: MVCCIdScale

• Posizione — comando CollStats del database

• Descrizione: misura l'età dell'ID MVCC su una scala da 0 a 1, dove 1 indica l'età massima prima che un cluster entri in uno stato di sola lettura. Utilizza questa metrica insieme AvailableMVCCIds per identificare le raccolte contenenti l'MVCC più vecchio IDs che stanno invecchiando il cluster.

• Raccomandazione: mantieni i valori inferiori a 0,3 per ogni raccolta.

gcRuntimeStats

• Posizione — comando CollStats del database

• Descrizione: fornisce una cronologia di due mesi delle metriche relative alla raccolta dei rifiuti, tra cui esecuzioni totali, durata media e durata massima. Include solo le operazioni di raccolta dei rifiuti che durano più di cinque minuti per garantire statistiche significative.

Importante

gcRuntimeStatse documentFragmentStats la suddivisione delle metriche a livello di raccolta in storageSegmentBase e storageSegmentExtended sono disponibili solo per Amazon DocumentDB 8.0.

storageSizeStats

• Posizione — comando CollStats del database

• Descrizione: fornisce un'analisi dettagliata dell'utilizzo dello storage tra diversi segmenti di storage:

  • storageSegmentBase— Archiviazione utilizzata dal segmento di archiviazione di base per i documenti standard

  • storageSegmentExtended— Archiviazione utilizzata dal segmento di archiviazione esteso per documenti di grandi dimensioni

• Utilizzo: consente di identificare le raccolte con uno spazio di archiviazione di documenti di grandi dimensioni e di comprendere i modelli di distribuzione dell'archiviazione.

unusedStorageSize(livello di raccolta)

• Posizione — comando CollStats del database

• Descrizione: stima lo spazio di archiviazione inutilizzato in una raccolta in base a statistiche campionate. Include lo spazio dei documenti eliminati e dei segmenti vuoti. La metrica fornisce sia i totali combinati che le suddivisioni per segmento:

  • Combinato e trasversale a tutti i segmenti di storage unusedBytes unusedPercent

  • storageSegmentBase— Spazio inutilizzato, in particolare nel segmento di archiviazione di base

  • storageSegmentExtended— Spazio inutilizzato, in particolare nel segmento di archiviazione esteso

documentFragmentStats

• Posizione — comando CollStats del database

• Descrizione: fornisce informazioni dettagliate sui frammenti di documenti e sui dati obsoleti all'interno delle raccolte. I frammenti di documento rappresentano le unità di archiviazione interne utilizzate dal motore di database e i frammenti morti indicano dati che non sono più accessibili ma non sono ancora stati recuperati. Questa metrica include:

  • totalDocFragmentsCount— Numero totale di frammenti di documento nella raccolta

  • deadDocFragmentsCount— Numero di frammenti contenenti dati morti (inaccessibili)

  • deadDocFragmentsPercent— Percentuale di frammenti che contengono dati non più validi

  • deadDocFragmentBytes— Stima dei byte consumati dai frammenti di documento non funzionanti

  • Suddivisione per segmento per e storageSegmentBase storageSegmentExtended

• Utilizzo: monitora questa metrica per comprendere l'efficacia della raccolta dei rifiuti e identificare le raccolte che potrebbero trarre vantaggio dalle operazioni di manutenzione. Alte percentuali di frammenti morti indicano che la raccolta dei rifiuti potrebbe essere in ritardo o che la raccolta trarrebbe vantaggio dall'ottimizzazione.

Metriche a livello di indice

unusedStorageSize(livello di indice)

• Posizione: comando Database IndexStats

• Descrizione: stima lo spazio di archiviazione inutilizzato in un indice in base a statistiche campionate. Include lo spazio occupato dalle voci di indice obsolete e dai segmenti vuoti.

• Raccomandazione: utilizzate il reIndex comando per ricostruire gli indici senza tempi di inattività e recuperare lo spazio inutilizzato. Per maggiori dettagli, consulta Gestione degli indici.

Esempio di output CollStats

L'esempio seguente mostra un collStats output tipico con metriche di raccolta e archiviazione dei rifiuti:

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

Domande frequenti

Come posso identificare se la raccolta dei rifiuti non funziona in modo efficiente?

Monitora questi segnali di avvertimento che indicano una raccolta dei rifiuti inefficiente:

• Eccessivo aumento della raccolta: unusedStorageSize metriche in costante aumento durante le operazioni di scrittura o le eliminazioni di massa, specialmente con indici di grandi dimensioni.

• Alta percentuale di frammenti morti: mostra valori costantemente elevati (superiori al 10-15%)documentFragmentStats. deadDocFragmentsPercent

• Latenza di interrogazione ridotta: maggiore latenza delle query dovuta all'accumulo di documenti non funzionanti.

• Durata GC estesa: le operazioni di raccolta dei rifiuti richiedono più tempo rispetto alle medie storiche. gcRuntimeStats

• Elaborazione GC elevata: un LongestActiveGCRuntime valore elevato indica che il Garbage Collector non è in grado di tenere il passo con le richieste del sistema.

La raccolta dei rifiuti influisce sulle prestazioni del mio database?

In condizioni normali, la raccolta dei rifiuti ha un impatto minimo sulle prestazioni. Tuttavia, quando la raccolta dei rifiuti è in ritardo, è possibile che si verifichino:

• Aumento dei costi di archiviazione dovuti all'accumulo di documenti obsoleti.

• Prestazioni di query più lente a causa di voci di indice obsolete.

• Modalità temporanea di sola lettura se MVCC è esaurito. IDs

• Maggiore utilizzo delle risorse durante le operazioni di raccolta intensive, specialmente su istanze più piccole.

• Efficienza ridotta nelle operazioni su segmenti di archiviazione estesi per documenti di grandi dimensioni.

Posso attivare manualmente la raccolta dei rifiuti?

No, la raccolta dei rifiuti in Amazon DocumentDB non può essere attivata manualmente. Il sistema gestisce automaticamente la raccolta dei rifiuti nell'ambito delle sue operazioni di manutenzione interne.

Quali allarmi devo impostare come best practice operativa?

Ti consigliamo di configurare il monitoraggio sia a livello di cluster che di raccolta per garantire prestazioni ottimali del tuo sistema Amazon DocumentDB.

Per il monitoraggio a livello di cluster, inizia creando un CloudWatch allarme Amazon per la AvailableMVCCIds metrica con una soglia di 1,3 miliardi. In questo modo avrai il tempo sufficiente per agire prima che la metrica raggiunga lo zero, dopodiché il cluster entrerà in modalità di sola lettura. Tieni presente che questa metrica può variare in base ai tuoi modelli di utilizzo specifici: alcuni clienti la vedono scendere al di sotto di 1,3 miliardi per poi risalire oltre 1,5 miliardi una volta completata la raccolta dei rifiuti.

È anche importante monitorare la LongestActiveGCRuntime metrica tramite Amazon CloudWatch. Questa metrica, insieme agcRuntimeStats, ti aiuta a capire l'efficienza della raccolta dei rifiuti in tutto il tuo sistema.

Per il monitoraggio a livello di raccolta, concentrati su queste metriche chiave:

• MVCCIdScale— Attenzione ai valori crescenti che indicano che gli MVCC IDs stanno invecchiando e potrebbero richiedere attenzione.

• gcRuntimeStats— Identifica i processi di raccolta dei rifiuti che richiedono tempi insolitamente lunghi o si estendono per più giorni.

• documentFragmentStats— Monitora deadDocFragmentsPercent i valori: percentuali costantemente elevate (superiori al 10-15%) possono indicare che la raccolta dei rifiuti è in ritardo.

• storageSizeStatse unusedStorageSize — Tieni traccia dei modelli di utilizzo dello storage e identifica le raccolte con una notevole quantità di spazio inutilizzato in entrambi i segmenti di archiviazione.

Le raccolte con operazioni di scrittura frequenti richiedono un'attenzione particolare, poiché generano più lavoro per il garbage collector. Ti consigliamo di controllare più frequentemente queste metriche per le raccolte con un'intensa attività di scrittura per garantire che Garbage Collection stia al passo con il tuo carico di lavoro.

Tieni presente che questi consigli di monitoraggio servono come punto di partenza. Man mano che acquisisci maggiore familiarità con il comportamento del sistema, potresti voler modificare queste soglie per adattarle meglio ai tuoi modelli e requisiti di utilizzo specifici.

Cosa devo fare se il mio valore AvailableMVCCIds scende al di sotto di 1,3 miliardi?

Se la AvailableMVCCIds metrica scende al di sotto di 1,3 miliardi, ti consigliamo di agire immediatamente per impedire al cluster di passare alla modalità di sola lettura. Ti consigliamo innanzitutto di aumentare le dimensioni dell'istanza per fornire al Garbage Collector più risorse di elaborazione. Questa è la nostra raccomandazione principale in quanto consente all'applicazione di continuare le normali operazioni fornendo al garbage collector la potenza aggiuntiva di cui ha bisogno per recuperare il ritardo.

Se il solo ridimensionamento non migliora la situazione, consigliamo di prendere in considerazione una riduzione delle operazioni di scrittura. Utilizza la MVCCIdScale metrica per identificare quali raccolte specifiche contengono MVCC meno recenti IDs che richiedono attenzione. Inoltre, monitora documentFragmentStats per identificare le raccolte con percentuali elevate di frammenti morti che potrebbero contribuire all'inefficienza della raccolta dei rifiuti.

Una volta identificate queste raccolte, potrebbe essere necessario ridurre temporaneamente le operazioni di scrittura su di esse per consentire alla garbage collection di recuperare il ritardo. Durante il periodo di recupero, ti consigliamo di monitorare attentamente la AvailableMVCCIds metrica per assicurarti che le tue azioni abbiano l'effetto desiderato. Il cluster viene considerato integro una volta che il AvailableMVCCIds valore torna a 1,5 miliardi o superiore.

Ricorda che questi passaggi sono misure preventive per aiutare il sistema a riprendersi prima che raggiunga uno stato critico. Quanto prima si interviene dopo aver visto la metrica scendere al di sotto di 1,3 miliardi, tanto più è probabile che si eviti qualsiasi impatto sulle operazioni di scrittura.