Raccolta dei rifiuti in Amazon DocumentDB

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

Informazioni sulla Garbage Collection in Amazon DocumentDB

La 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 ad ogni aggiornamento. Ogni operazione di scrittura utilizza un ID MVCC univoco da un contatore finito. Questi ID identificano a quale transazione appartiene una versione del documento e se è stata salvata o annullata. Nel tempo, queste vecchie versioni e i relativi ID MVCC si accumulano e richiedono una pulizia per evitare un peggioramento delle prestazioni.

Funzioni della 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.

• Previene l'overflow degli ID MVCC: previene l'overflow degli ID MVCC gestendo il contatore finito degli ID MVCC. Senza questa gestione, il contatore alla fine raggiungerebbe il limite, costringendo il database a una modalità temporanea di sola lettura fino al riciclaggio degli ID.

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

Processo di raccolta dei rifiuti

Il processo GC opera per raccolta e può avere più processi in esecuzione contemporaneamente su raccolte diverse. Il processo è costituito da quattro fasi sequenziali:

1. Identificazione: il sistema identifica le versioni del documento e dell'indice non più referenziate da transazioni o interrogazioni attive.

2. Caricamento in 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 gli ID MVCC dalle versioni eliminate per nuove operazioni.

Quando Garbage Collection completa l'elaborazione delle vecchie versioni dei documenti, rimuove gli ID MVCC più vecchi dal sistema. Questa pulizia è fondamentale per prevenire l'overflow degli ID MVCC riciclando gli ID MVCC e rendendoli disponibili per nuove operazioni di scrittura nel cluster. Senza questo processo di riciclo, il sistema finirebbe per esaurire il numero limitato di ID MVCC e entrare in uno 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 archiviazione e archiviazione estesa

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

Segmento di storage di base

Il segmento di archiviazione di base contiene i dati e i metadati del documento principale. 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.

• Collection-level statistiche e configurazione.

Segmento di archiviazione esteso

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

• Gestione efficiente dei documenti di grandi dimensioni: i documenti più grandi della soglia di archiviazione di base vengono automaticamente spostati nel segmento di archiviazione esteso.

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

• Raccolta indipendente dei rifiuti: il segmento di archiviazione esteso ha 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 dover 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 strutture annidate estese.

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

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

Monitoraggio della raccolta dei rifiuti

Metriche a livello di cluster

AvailableMVCCIds

• Luogo: 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 gli ID non vengono recuperati e riciclati. Il contatore diminuisce a ogni operazione di scrittura e aumenta man mano che la Garbage Collection ricicla i vecchi ID MVCC.

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

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 nella raccolta dei rifiuti, ad esempio tempi di esecuzione prolungati durante le eliminazioni di massa.

Metriche relative al 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. Usa questa metrica insieme AvailableMVCCIds per identificare le raccolte contenenti gli ID MVCC più vecchi che stanno invecchiando il cluster.

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

gcRuntimeStats

• Posizione: comando CollStats del database

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

storageSizeStats

• Posizione: comando CollStats del database

• Descrizione: fornisce una suddivisione 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: aiuta a identificare le raccolte con una notevole quantità di documenti di grandi dimensioni e a comprendere i modelli di distribuzione dello storage.

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 in tutti i segmenti di storage unusedBytes unusedPercent

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

  • storageSegmentExtended— Spazio inutilizzato specificamente nel segmento di archiviazione esteso

documentFragmentStats

• Posizione: comando CollStats del database

• Descrizione: fornisce informazioni dettagliate sui frammenti di documenti e sui dati non più disponibili all'interno delle raccolte. I frammenti di documento rappresentano le unità di archiviazione interne utilizzate dal motore di database, mentre 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 validi

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

  • Per-segment suddivisione 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. Le 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 contenuto nelle voci dell'indice obsolete e nei segmenti vuoti.

• Raccomandazione: utilizzate il reIndex comando per ricostruire gli indici senza tempi di inattività e recuperare spazio inutilizzato. Per ulteriori informazioni, fare riferimento a Gestione degli indici.

Esempio di output CollStats

L'esempio seguente mostra un collStats output tipico con metriche di garbage collection e storage:

{
    "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 garbage collection 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 scritture pesanti o eliminazioni in blocco, specialmente con indici di grandi dimensioni.

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

• Latenza delle query ridotta: maggiore latenza delle query a causa dell'accumulo di documenti inattivi.

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

• Elaborazione GC elevata: LongestActiveGCRuntime valore elevato che indica che il garbage collector non è in grado di tenere il passo con le richieste di sistema.

La garbage collection influisce sulle prestazioni del mio database?

In condizioni normali, la garbage collection ha un impatto minimo sulle prestazioni. Tuttavia, quando la raccolta dei rifiuti non funziona, potresti riscontrare:

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

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

• Modalità temporanea di sola lettura se gli ID MVCC sono esauriti.

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

• Efficienza ridotta nelle operazioni estese dei segmenti di archiviazione per documenti di grandi dimensioni.

Posso attivare manualmente la raccolta dei rifiuti?

No, la garbage collection in Amazon DocumentDB non può essere attivata manualmente. Il sistema gestisce automaticamente la raccolta dei rifiuti come parte delle sue operazioni di manutenzione interne.

Quali allarmi devo impostare come best practice operativa?

Imposta 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. Questo ti dà il tempo sufficiente per agire prima che la metrica raggiunga lo zero, dopodiché il cluster entri 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 e poi recuperarla oltre 1,5 miliardi quando la Garbage Collection completa il suo lavoro.

È anche importante monitorare la metrica tramite Amazon. LongestActiveGCRuntime CloudWatch Questa metrica, insieme agcRuntimeStats, ti aiuta a capire l'efficienza della Garbage Collection nel tuo sistema.

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

• MVCCIdScale— Fai attenzione ai valori crescenti che suggeriscono che gli ID MVCC stanno invecchiando e potrebbero richiedere attenzione.

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

• documentFragmentStats— deadDocFragmentsPercent Valori di monitoraggio: 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 significativa quantità di spazio inutilizzato in entrambi i segmenti di archiviazione.

Le raccolte con frequenti operazioni di scrittura richiedono un'attenzione particolare, in quanto generano più lavoro per il garbage collector. Controlla queste metriche più frequentemente per le raccolte con un'intensa attività di scrittura per assicurarti che Garbage Collection sia 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 tuo sistema, potresti voler modificare queste soglie per adattarle meglio ai tuoi modelli e requisiti di utilizzo specifici.

Cosa devo fare se i miei MVCCID disponibili scendono al di sotto di 1,3 miliardi?

Se la AvailableMVCCIds metrica scende al di sotto di 1,3 miliardi, agisci immediatamente per evitare che il cluster entri in modalità di sola lettura. Innanzitutto, aumenta le dimensioni dell'istanza per fornire al Garbage Collector più risorse di elaborazione. Ciò consente all'applicazione di continuare le normali operazioni fornendo al garbage collector la potenza aggiuntiva di cui ha bisogno per recuperare il ritardo.

Se la scalabilità da sola non migliora la situazione, valuta la possibilità di ridurre le operazioni di scrittura. Utilizzate la MVCCIdScale metrica per identificare quali raccolte specifiche contengono ID MVCC precedenti che richiedono attenzione. Inoltre, esegui documentFragmentStats il monitoraggio 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 ridurne temporaneamente le operazioni di scrittura per consentire a Garbage Collection di recuperare il ritardo accumulato. Durante il periodo di recupero, monitora attentamente la AvailableMVCCIds metrica per assicurarti che le tue azioni abbiano l'effetto desiderato. Il cluster è considerato integro quando il AvailableMVCCIds valore torna a 1,5 miliardi o più.

Ricorda che questi passaggi sono misure preventive per aiutare il sistema a ripristinarsi 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 evitino impatti sulle operazioni di scrittura.