Recolección de basura en Amazon DocumentDB

Amazon DocumentDB implementa una arquitectura de base de datos de control de concurrencia multiversión (MVCC) que crea nuevas versiones de entradas de documentos e índices para cada operación de actualización. Esta arquitectura proporciona aislamiento de lectura al permitir que las consultas de lectura utilicen documentos versionados sin bloquearlos.

Descripción de la recolección de basura en Amazon DocumentDB

La recolección de elementos no utilizados (GC) es un proceso en segundo plano automatizado que mantiene un rendimiento y una disponibilidad óptimos del sistema en Amazon DocumentDB. A diferencia de las bases de datos tradicionales que sobrescriben los datos in situ, la arquitectura MVCC de Amazon DocumentDB crea nuevas versiones de documentos y entradas de índice con cada operación de actualización. Cada operación de escritura que da como resultado una nueva versión del documento consume un identificador MVCC único de un contador finito, por lo que es fundamental realizar una limpieza eficaz. Con el tiempo, estas versiones antiguas se acumulan y deben limpiarse para evitar una degradación del rendimiento.

Funciones de recolección de basura

El recolector de basura cumple tres funciones esenciales:

• Recupera espacio de almacenamiento: elimina las versiones obsoletas de documentos e índices que las consultas activas ya no necesitan, lo que libera espacio para futuras operaciones de escritura.

• Evita el desbordamiento de identificadores de MVCC: evita el desbordamiento de identificadores de MVCC mediante la administración del contador finito de MVCC. IDs Sin esta administración, el contador eventualmente alcanzaría su límite, lo que obligaría a la base de datos a pasar a un modo temporal de solo lectura hasta que se recicle. IDs

• Mantiene el rendimiento de las consultas: mantiene un rendimiento óptimo de las consultas al eliminar las versiones inactivas de los documentos que, de otro modo, se acumularían y ralentiza el procesamiento de las consultas.

Proceso de recolección de basura

El proceso de GC funciona por colección y puede tener varios procesos ejecutándose simultáneamente en diferentes colecciones. El proceso consta de cuatro fases secuenciales:

1. Identificación: el sistema identifica las versiones de documentos e índices a las que ya no hacen referencia las transacciones o consultas activas.

2. Carga de memoria: los documentos antiguos y las entradas del índice se cargan en la memoria si aún no están presentes.

3. Eliminación: las versiones obsoletas se eliminan permanentemente para recuperar espacio de almacenamiento.

4. Reciclaje de identificadores de MVCC: el sistema recicla los MVCC de las versiones IDs eliminadas para realizar nuevas operaciones.

Cuando la recolección de basura termina de procesar las versiones antiguas de los documentos, elimina el MVCC IDs más antiguo del sistema. Esta limpieza es fundamental para evitar que los identificadores de los MVCC se desborden IDs, ya que reciclan los MVCC y los ponen a disposición para nuevas operaciones de escritura en todo el clúster. Sin este proceso de reciclaje, el sistema acabaría agotando su contador finito de identificadores de MVCC y pasaría a un estado de solo lectura.

Programación de recolección de basura

La recolección de basura se ejecuta automáticamente en segundo plano a intervalos periódicos. La temporización y la frecuencia se ajustan dinámicamente en función de la carga del sistema, los recursos disponibles, el volumen de escritura y los niveles de consumo de la ID del MVCC. Cuando hay mucha actividad de escritura, el proceso de GC se ejecuta con más frecuencia para gestionar el aumento del número de versiones de los documentos.

Supervisión de la recolección de basura

Métricas a nivel de clúster

AvailableMVCCIds

• Ubicación — Amazon CloudWatch

• Descripción: contador que muestra el número de operaciones de escritura restantes disponibles antes de llegar a cero. Cuando este contador llega a cero, el clúster pasa al modo de solo lectura hasta que IDs se recupere y se recicle. El contador disminuye con cada operación de escritura y aumenta a medida que la recolección de basura recicla el MVCC antiguo. IDs

• Recomendación: active una alarma cuando el valor caiga por debajo de los 1.300 millones. Esta alerta temprana le permite tomar las medidas recomendadas que se describen más adelante.

LongestRunningGCProcess

• Ubicación — Amazon CloudWatch

• Descripción: Duración en segundos del proceso de recolección de basura activo más prolongado. Se actualiza cada minuto y realiza un seguimiento únicamente de las operaciones activas, excluyendo los procesos que se completan en el intervalo de un minuto.

• Recomendación:

Métricas a nivel de recopilación

MVCCIDStats: MvccIdAgeScale

• Ubicación: comando CollStats de base de datos

• Descripción: mide la antigüedad del identificador MVCC en una escala de 0 a 1, donde 1 indica la antigüedad máxima antes de que un clúster entre en estado de solo lectura. Utilice esta métrica junto con ella AvailableMVCCIds para identificar las colecciones que contienen el MVCC más antiguo y IDs que están anticuadas en el clúster.

• Recomendación: mantenga los valores por debajo de 0.3 para cada colección.

GCRuntimeStats

• Ubicación: comando CollStats de base de datos

• Descripción: proporciona un historial de dos meses con las métricas de recolección de basura, que incluye el total de ejecuciones, la duración media y la duración máxima. Solo incluye las operaciones de recolección de basura que duren más de cinco minutos para garantizar estadísticas significativas.

UnusedStorageSize(nivel de recolección)

• Ubicación: comando CollStats de base de datos

• Descripción: estima el espacio de almacenamiento no utilizado en una colección en función de las estadísticas muestreadas. Incluye el espacio de los documentos eliminados y los segmentos vacíos.

Métricas a nivel de índice

UnusedStorageSize(nivel de índice)

• Ubicación: comando Database IndexStats

• Descripción: estima el espacio de almacenamiento no utilizado en un índice en función de las estadísticas muestreadas. Incluye el espacio de las entradas de índice obsoletas y de los segmentos vacíos.

• Recomendación: utilice el reIndex comando para reconstruir los índices sin tiempo de inactividad y recuperar el espacio no utilizado. Consulte Gestión de índices para obtener más información.

Ejemplo collStats de salida

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

Preguntas frecuentes

Temas

• ¿Cómo identifico si la recolección de basura no funciona de manera eficiente?

• ¿La recolección de basura afecta al rendimiento de mi base de datos?

• ¿Puedo activar manualmente la recolección de basura?

• ¿Qué alarmas debo configurar como mejor práctica operativa?

• ¿Qué debo hacer si el mío AvailableMVCCId cae por debajo de los 1300 millones?

¿Cómo identifico si la recolección de basura no funciona de manera eficiente?

Supervise estas señales de advertencia que indican una recolección de basura ineficiente:

• Recolección excesiva: las UnusedStorageSize métricas aumentan de forma constante durante las escrituras intensivas o las eliminaciones masivas, especialmente cuando se trata de índices de gran tamaño

• Latencia de consulta reducida: aumento de la latencia de consulta debido a la acumulación de documentos inactivos

• Duración extendida del GC: las operaciones de recolección de basura tardan más que los promedios históricos en GCRuntimeStats

• Procesamiento de GC elevado: un nivel alto LongestRunningGCProcess indica que el recolector de basura no puede satisfacer las demandas del sistema

¿La recolección de basura afecta al rendimiento de mi base de datos?

En condiciones normales, la recolección de basura tiene un impacto mínimo en el rendimiento. Sin embargo, si la recolección de basura se retrasa, puede experimentar lo siguiente:

• aumento de los costes de almacenamiento debido a la acumulación de documentos muertos.

• un rendimiento de consultas más lento debido a las entradas de índice obsoletas.

• modo temporal de solo lectura si los MVCC IDs están agotados.

• mayor uso de recursos durante las ejecuciones intensivas de recopilación, especialmente en instancias más pequeñas.

¿Puedo activar manualmente la recolección de basura?

No, la recolección de elementos no utilizados en Amazon DocumentDB no se puede activar manualmente. El sistema administra la recolección de basura automáticamente como parte de sus operaciones de mantenimiento interno.

¿Qué alarmas debo configurar como mejor práctica operativa?

Recomendamos configurar la supervisión tanto a nivel de clúster como de recopilación para garantizar un rendimiento óptimo del sistema Amazon DocumentDB.

Para el monitoreo a nivel de clúster

Comience por crear una CloudWatch alarma para la AvailableMVCCId métrica con un umbral de 1 300 millones. Esto le da tiempo suficiente para tomar medidas antes de que la métrica llegue a cero, momento en el que el clúster pasará al modo de solo lectura. Ten en cuenta que esta métrica puede fluctuar en función de tus patrones de uso específicos. Algunos clientes ven cómo cae por debajo de los 1300 millones y, después, se recupera por encima de los 1500 millones a medida que la recolección de basura termina su trabajo.

También es importante realizar un seguimiento exhaustivo de la LongestRunningGCProcess métrica CloudWatch. Esta métrica, además, le ayuda a comprender la eficiencia con GCRuntimeStats la que se realiza la recolección de basura en todo el sistema.

Para el monitoreo a nivel de recolección

Céntrese en dos métricas clave. En primer lugar, te recomendamos observar el MvccIdAgeScale valor de cada colección. El aumento de los valores sugiere que los MVCC IDs están envejeciendo y es posible que necesiten atención. En segundo lugar, GCRuntimeStats supervise para identificar cualquier proceso de recolección de basura que esté demorando inusualmente o que se extienda a lo largo de varios días. Las colecciones con operaciones de escritura frecuentes requieren una atención especial, ya que generan más trabajo para el recolector de basura. Te recomendamos que compruebes estas métricas con más frecuencia en las recopilaciones con mucha actividad de escritura para garantizar que la recolección de elementos no utilizados esté a la altura de tu carga de trabajo.

Tenga en cuenta que estas recomendaciones de monitoreo sirven como punto de partida. A medida que se familiarice con el comportamiento de su sistema, tal vez desee ajustar estos umbrales para que se adapten mejor a sus patrones y requisitos de uso específicos.

¿Qué debo hacer si el mío AvailableMVCCId cae por debajo de los 1300 millones?

Si su AvailableMVCCId métrica cae por debajo de los 1 300 millones, le recomendamos que tome medidas inmediatas para evitar que su clúster entre en modo de solo lectura. Te recomendamos que primero amplíes el tamaño de la instancia para proporcionar al recolector de basura más recursos informáticos. Esto permite que su aplicación continúe con sus operaciones normales y, al mismo tiempo, le da al recolector de basura la potencia adicional que necesita para ponerse al día.

Si la ampliación por sí sola no mejora la situación, te recomendamos que consideres reducir las operaciones de escritura. Usa la MvccIdAgeScale métrica para identificar qué colecciones específicas contienen MVCC más antiguas y IDs que requieren atención. Una vez que hayas identificado estas colecciones, es posible que tengas que reducir temporalmente las operaciones de escritura en ellas para permitir que la recolección de basura se ponga al día. Durante el período de recuperación, te recomendamos que supervises de cerca la AvailableMVCCId métrica para asegurarte de que tus acciones tengan el efecto deseado. Se considera que el clúster está en buen estado una vez que el AvailableMVCCId valor vuelva a ser de 1500 millones o más.

Recuerde que estos pasos son medidas preventivas para ayudar a su sistema a recuperarse antes de que alcance un estado crítico. Cuanto antes tome medidas tras ver caer la métrica por debajo de los 1300 millones, más probabilidades tendrá de evitar que sus operaciones de escritura se vean afectadas.