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 fornisce l'isolamento della lettura consentendo alle interrogazioni di lettura di utilizzare documenti con versioni diverse senza blocchi.

Informazioni sulla Garbage Collection in Amazon DocumentDB

Garbage collection (GC) è un processo automatizzato in background che mantiene prestazioni e disponibilità di sistema ottimali in Amazon DocumentDB. A differenza dei database tradizionali che sovrascrivono i dati sul posto, l'architettura MVCC di Amazon DocumentDB crea nuove versioni di documenti e voci di indice ad ogni operazione di aggiornamento. Ogni operazione di scrittura che porta a una nuova versione del documento utilizza un ID MVCC univoco proveniente da un contatore finito, il che rende essenziale una pulizia efficiente. Nel tempo, queste vecchie versioni si accumulano e devono essere ripulite per evitare un peggioramento 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 suo 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 di documenti e 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 il file 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.

Monitoraggio della raccolta dei rifiuti

Metriche a livello di cluster

AvailableMVCCIds

• Posizione — Amazon CloudWatch

• Descrizione: un contatore che mostra il numero di operazioni di scrittura rimanenti disponibili prima di raggiungere lo zero. 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.

LongestRunningGCProcess

• Posizione — 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:

Metriche a livello di raccolta

MVCCIDStats: MvccIdAgeScale

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

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.

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

{
    "ns": "xid_consumption_test_db.xid_test_collection",
    "MVCCIdStats": {
        "MVCCIdScale": 0.03
    },
    "gcRuntimeStats": {
        "numRuns": 1,
        "historicalAvgRuntime": 3295,
        "historicalMaxRuntime": 3295,
        "lastRuntime": 3295,
        "lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
    },
    "collScans": 14,
    "count": 30000000,
    "size": 1320000000,
    "avgObjSize": 44,
    "storageSize": 6461497344,
    "capped": false,
    "nindexes": 2,
    "totalIndexSize": 9649553408,
    "indexSizes": {
        "_id_": 1910661120,
        "c_1": 7738892288
    },
    "unusedStorageSize": {
        "unusedBytes": 4201881600,
        "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

Argomenti

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

• La raccolta dei rifiuti influisce sulle prestazioni del mio database?

• Posso attivare manualmente la raccolta dei rifiuti?

• Quali allarmi devo impostare come best practice operativa?

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

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 operazioni di scrittura impegnative o eliminazioni di massa, specialmente con indici di grandi dimensioni

• 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 in GCRuntimeStats

• Elaborazione GC elevata: un LongestRunningGCProcess 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.

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 per la AvailableMVCCId 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 e poi recuperare oltre 1,5 miliardi man mano che la raccolta dei rifiuti completa il suo lavoro.

È anche importante monitorare la metrica. LongestRunningGCProcess CloudWatch Questa metrica, insieme aGCRuntimeStats, ti aiuta a capire l'efficienza della raccolta dei rifiuti nel tuo sistema.

Per il monitoraggio a livello di raccolta

Concentrati su due metriche chiave. Innanzitutto, ti consigliamo di controllare il MvccIdAgeScale valore di ogni collezione. L'aumento dei valori indica che gli MVCC IDs stanno invecchiando e potrebbero richiedere attenzione. In secondo luogo, monitorate GCRuntimeStats per identificare eventuali processi di raccolta dei rifiuti che richiedono insolitamente tempo o si protraggono per più giorni. 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 AvailableMVCCId scende al di sotto di 1,3 miliardi?

Se la AvailableMVCCId 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. 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 il solo ridimensionamento non migliora la situazione, consigliamo di prendere in considerazione una riduzione delle operazioni di scrittura. Utilizza la MvccIdAgeScale metrica per identificare quali raccolte specifiche contengono MVCC meno recenti IDs che richiedono attenzione. 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 AvailableMVCCId metrica per assicurarti che le tue azioni abbiano l'effetto desiderato. Il cluster viene considerato integro una volta che il AvailableMVCCId 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.