Coleta de resíduos no Amazon DocumentDB - Amazon DocumentDB
Entendendo a coleta de lixo no Amazon DocumentDBProcesso de coleta de resíduosArquitetura de armazenamento e armazenamento estendidoMonitoramento da coleta de resíduosExemplo de saída CollStatsPerguntas frequentes

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Coleta de resíduos no Amazon DocumentDB

O Amazon DocumentDB implementa uma arquitetura de banco de dados de controle de simultaneidade de várias versões (MVCC) que cria novas versões de entradas de documentos e índices para cada operação de atualização. Essa arquitetura permite o isolamento de transações, impedindo que as alterações de uma transação apareçam em outra.

Entendendo a coleta de lixo no Amazon DocumentDB

A coleta de resíduos (GC) é um processo automatizado em segundo plano que mantém a performance e a disponibilidade ideais do sistema no Amazon DocumentDB. Como muitos bancos de dados modernos, a arquitetura MVCC do Amazon DocumentDB cria novas versões de documentos e índices a cada atualização. Cada operação de gravação consome um ID MVCC exclusivo de um contador finito. Eles IDs identificam a qual transação uma versão do documento pertence e se ela foi confirmada ou revertida. Com o tempo, essas versões antigas e seu MVCC IDs se acumulam, exigindo limpeza para evitar a degradação do desempenho.

Funções da coleta de resíduos

O coletor de resíduos tem três funções essenciais:

  • Recuperar espaço de armazenamento: ele remove versões obsoletas de documentos e índices que não sejam mais necessárias para consultas ativas, liberando espaço para futuras operações de gravação.

  • Evita o estouro do ID do MVCC — Evita o estouro do ID do MVCC gerenciando o contador finito do MVCC. IDs Sem esse gerenciamento, o contador acabaria atingindo seu limite, forçando o banco de dados a entrar em um modo temporário somente para leitura até IDs ser reciclado.

  • Manter a performance da consulta: ele mantém a performance ideal da consulta eliminando versões inativas de documentos que, de outra forma, se acumulariam e retardariam o processamento de consultas.

Processo de coleta de resíduos

O processo de GC opera por coleção e pode ter vários processos sendo executados simultaneamente em coleções diferentes. O processo consiste em quatro fases sequenciais:

  1. Identificação: o sistema identifica versões de documentos e índices que não são mais referenciadas por transações ou consultas ativas.

  2. Carregamento na memória: os documentos antigos e as entradas de índice são carregados na memória se ainda não estiverem presentes.

  3. Exclusão: as versões obsoletas são excluídas permanentemente para recuperar espaço de armazenamento.

  4. Reciclagem de ID MVCC — O sistema recicla o MVCC de versões IDs excluídas para novas operações.

Quando a coleta de lixo conclui o processamento das versões antigas do documento, ela remove o MVCC IDs mais antigo do sistema. Essa limpeza é crucial para evitar o estouro de IDs do MVCC ao reciclar o MVCC IDs, disponibilizando-o para novas operações de gravação em todo o cluster. Sem esse processo de reciclagem, o sistema acabaria por esgotar seu contador finito de IDs do MVCC e entrar em um estado somente de leitura.

Programação da coleta de resíduos

A coleta de resíduos é executada automaticamente em segundo plano, em intervalos periódicos. O tempo e a frequência se ajustam dinamicamente com base na carga do sistema, nos recursos disponíveis, no volume de gravação e nos níveis de consumo de IDs do MVCC. Durante a alta atividade de gravação, o processo de GC é executado com mais frequência para gerenciar o aumento do número de versões do documento.

Arquitetura de armazenamento e armazenamento estendido

O Amazon DocumentDB usa uma arquitetura de armazenamento sofisticada que separa o armazenamento de documentos em dois segmentos distintos:

Segmento de armazenamento básico

O segmento de armazenamento básico contém os dados e metadados do documento primário. Esse segmento armazena:

  • Conteúdo do documento que se encaixa no tamanho padrão da página (8 KB).

  • Documente os metadados e estruture as informações.

  • Índices primários e suas entradas.

  • Estatísticas e configuração em nível de coleção.

Segmento de armazenamento estendido

O segmento de armazenamento estendido utiliza um grande repositório especializado de objetos de documentos, projetado para lidar com documentos que excedem o tamanho padrão da página de armazenamento. Esse segmento fornece:

  • Manipulação eficiente de documentos grandes — Documentos maiores que o limite básico de armazenamento são movidos automaticamente para o segmento de armazenamento estendido.

  • Layout de armazenamento otimizado — O segmento usa um formato de armazenamento diferente, otimizado para objetos grandes, reduzindo a fragmentação e melhorando os padrões de acesso.

  • Coleta de lixo independente — O segmento de armazenamento estendido tem seu próprio processo de coleta de lixo que pode ser executado independentemente da limpeza do armazenamento básico.

  • Acesso transparente — os aplicativos acessam documentos grandes sem precisar saber qual segmento de armazenamento contém os dados.

O segmento de armazenamento estendido é particularmente benéfico para:

  • Coleções com documentos contendo grandes matrizes incorporadas.

  • Documentos com extensas estruturas aninhadas.

  • Coleções que armazenam dados binários ou grandes campos de texto.

  • Aplicativos com tamanhos de documentos mistos em que alguns documentos excedem significativamente o tamanho médio.

Monitoramento da coleta de resíduos

Métricas em nível de cluster

AvailableMVCCIds

  • Localização — Amazon CloudWatch

  • Descrição — Um contador que mostra o número de operações de gravação restantes disponíveis a partir de um limite máximo de 1,8 bilhão. Quando esse contador chega a zero, seu cluster entra no modo somente leitura até IDs ser recuperado e reciclado. O contador diminui a cada operação de gravação e aumenta à medida que a coleta de lixo recicla o MVCC antigo. IDs

  • Recomendação: define um alarme quando o valor cair abaixo de 1,3 bilhão. Esse aviso antecipado permite que você execute as etapas recomendadas discutidas posteriormente.

LongestActiveGCRuntime

  • Localização — Amazon CloudWatch

  • Descrição: duração em segundos do processo de coleta de resíduos ativo mais longo. Atualiza a cada minuto e rastreia somente as operações ativas, excluindo os processos concluídos dentro da janela de um minuto.

  • Recomendação — compare com dados gcRuntimeStats históricos para identificar comportamentos anormais de coleta de lixo, como tempos de execução estendidos durante exclusões em massa.

Métricas de nível de coleção

MVCCIDStats: MVCCIdScale

  • Localização: comando collStats do banco de dados

  • Descrição: mede a idade do ID do MVCC em uma escala de 0 a 1, em que 1 indica a idade máxima antes de um cluster entrar em um estado somente de leitura. Use essa métrica ao lado AvailableMVCCIds para identificar coleções contendo o MVCC mais antigo IDs que estão envelhecendo o cluster.

  • Recomendação: mantenha valores abaixo de 0,3 para cada coleção.

gcRuntimeStats

  • Localização: comando collStats do banco de dados

  • Descrição: fornece um histórico de dois meses das métricas de coleta de resíduos, incluindo o total de execuções, a duração média e a duração máxima. Inclui apenas operações de coleta de resíduos com duração superior a cinco minutos para garantir estatísticas significativas.

Importante

gcRuntimeStats,documentFragmentStats, e divisão das métricas de nível de coleção em storageSegmentBase e só storageSegmentExtended estão disponíveis para o Amazon DocumentDB 8.0.

storageSizeStats

  • Localização: comando collStats do banco de dados

  • Descrição — fornece uma análise detalhada da utilização do armazenamento em diferentes segmentos de armazenamento:

    • storageSegmentBase— Armazenamento usado pelo segmento de armazenamento básico para documentos padrão

    • storageSegmentExtended— Armazenamento usado pelo segmento de armazenamento estendido para documentos grandes

  • Uso — ajuda a identificar coleções com armazenamento significativo de documentos grandes e a entender os padrões de distribuição de armazenamento.

unusedStorageSize (nível de coleção)

  • Localização: comando collStats do banco de dados

  • Descrição: estima o espaço de armazenamento não utilizado em uma coleção com base nas estatísticas amostradas. Ela inclui o espaço de documentos excluídos e segmentos vazios. A métrica fornece totais combinados e detalhamentos por segmento:

    • Combinado unusedBytes e unusedPercent em todos os segmentos de armazenamento

    • storageSegmentBase— Espaço não utilizado, especificamente no segmento de armazenamento básico

    • storageSegmentExtended— Espaço não utilizado, especificamente no segmento de armazenamento estendido

documentFragmentStats

  • Localização: comando collStats do banco de dados

  • Descrição — Fornece informações detalhadas sobre fragmentos de documentos e dados mortos nas coleções. Fragmentos de documentos representam as unidades de armazenamento interno usadas pelo mecanismo de banco de dados, e fragmentos mortos indicam dados que não estão mais acessíveis, mas que ainda não foram recuperados. Essa métrica inclui:

    • totalDocFragmentsCount— Número total de fragmentos de documentos na coleção

    • deadDocFragmentsCount— Número de fragmentos contendo dados mortos (inacessíveis)

    • deadDocFragmentsPercent— Porcentagem de fragmentos que contêm dados mortos

    • deadDocFragmentBytes— Estimativa de bytes consumidos por fragmentos de documentos mortos

    • Detalhamento por segmento para e storageSegmentBase storageSegmentExtended

  • Uso — Monitore essa métrica para entender a eficácia da coleta de lixo e identificar as coleções que podem se beneficiar das operações de manutenção. Altas porcentagens de fragmentos mortos indicam que a coleta de lixo pode estar ficando para trás ou que a coleta se beneficiaria com a otimização.

Métricas de nível de índice

unusedStorageSize (nível de índice)

  • Localização: comando indexStats do banco de dados

  • Descrição: estima o espaço de armazenamento não utilizado em um índice com base nas estatísticas amostradas. Ela inclui o espaço de entradas de índice obsoletas e segmentos vazios.

  • Recomendação: use o comando reIndex para reconstruir índices sem tempo de inatividade e recuperar espaço não utilizado. Para obter mais detalhes, consulte Gerenciamento de índices.

Exemplo de saída CollStats

O exemplo a seguir mostra uma collStats saída típica com métricas de coleta e armazenamento de lixo:

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

Perguntas frequentes

Como faço para identificar se a coleta de resíduos não está funcionando de forma eficiente?

Monitore estes sinais de alerta que indicam coleta de resíduos ineficiente:

  • Excessivo inchaço da coleção — Aumento constante das unusedStorageSize métricas durante gravações pesadas ou exclusões em massa, especialmente com índices grandes.

  • Alta porcentagem de fragmentos mortos — documentFragmentStats mostrando deadDocFragmentsPercent valores consistentemente altos (acima de 10-15%).

  • Latência de consulta reduzida — Aumento da latência de consulta devido ao acúmulo de documentos mortos.

  • Duração estendida do GC — As operações de coleta de lixo demoram mais do que as médias históricas em. gcRuntimeStats

  • Processamento de GC elevado — Alto LongestActiveGCRuntime indicador de que o coletor de lixo não consegue atender às demandas do sistema.

A coleta de resíduos afeta a performance do meu banco de dados?

Em condições normais, a coleta de resíduos tem um impacto mínimo na performance. No entanto, quando a coleta de resíduos atrasa, pode ser que você experimente:

  • Aumento dos custos de armazenamento de documentos mortos acumulados.

  • Desempenho de consulta mais lento devido a entradas de índice obsoletas.

  • Modo somente leitura temporário se o MVCC estiver esgotado IDs .

  • Maior uso de recursos durante execuções intensivas de coleta, especialmente em instâncias menores.

  • Eficiência reduzida em operações de segmentos de armazenamento estendidos para documentos grandes.

Posso acionar manualmente a coleta de resíduos?

Não, a coleta de resíduos no Amazon DocumentDB não pode ser acionada manualmente. O sistema gerencia a coleta de resíduos automaticamente como parte de suas operações internas de manutenção.

Quais alarmes devo definir como prática recomendada operacional?

Recomendamos configurar o monitoramento nos níveis de cluster e coleção para garantir a performance ideal do seu sistema do Amazon DocumentDB.

Para monitoramento em nível de cluster, comece criando um CloudWatch alarme da Amazon para a AvailableMVCCIds métrica com um limite de 1,3 bilhão. Isso proporciona tempo suficiente para uma ação antes que a métrica chegue a zero, momento em que seu cluster entraria no modo somente de leitura. Lembre-se de que essa métrica pode flutuar com base em seus padrões de uso específicos. Alguns clientes a veem cair abaixo de 1,3 bilhão e depois se recuperar acima de 1,5 bilhão à medida que a coleta de lixo conclui seu trabalho.

Também é importante monitorar a LongestActiveGCRuntime métrica por meio da Amazon CloudWatch. Essa métrica, junto com gcRuntimeStats, ajuda você a entender a eficiência com que a coleta de resíduos está funcionando em todo o sistema.

Para monitoramento em nível de coleção, concentre-se nessas métricas principais:

  • MVCCIdScale— Observe os valores crescentes que sugerem que o MVCC IDs está envelhecendo e pode precisar de atenção.

  • gcRuntimeStats— identifique processos de coleta de lixo que demoram muito ou se estendem por vários dias.

  • documentFragmentStats— Monitore deadDocFragmentsPercent valores — porcentagens consistentemente altas (acima de 10-15%) podem indicar que a coleta de lixo está ficando para trás.

  • storageSizeStatse unusedStorageSize — Rastreie os padrões de utilização do armazenamento e identifique coleções com espaço não utilizado significativo em qualquer segmento de armazenamento.

Coleções com operações de gravação frequentes precisam de atenção extra, pois geram mais trabalho para o coletor de resíduos. Recomendamos verificar essas métricas com mais frequência para coleções com muita atividade de gravação, para garantir que a coleta de resíduos acompanhe a sua workload.

Observe que essas recomendações de monitoramento servem como ponto de partida. À medida que você se familiariza com o comportamento do seu sistema, talvez queira ajustar esses limites para melhor corresponder aos seus padrões e requisitos de uso específicos.

O que devo fazer se meu AvailableMVCCIds cair abaixo de 1,3 bilhão?

Caso sua métrica AvailableMVCCIds caia abaixo de 1,3 bilhão, recomendamos tomar medidas imediatas para evitar que seu cluster entre no modo somente de leitura. Recomendamos primeiramente aumentar o tamanho da sua instância para fornecer ao coletor de resíduos mais recursos computacionais. Essa é nossa principal recomendação, pois permite que seu aplicativo continue com as operações normais e, ao mesmo tempo, forneça ao coletor de lixo a energia adicional necessária para se recuperar.

Se o aumento da escala na vertical, por si só, não melhorar a situação, recomendamos considerar uma redução em suas operações de gravação. Use a MVCCIdScale métrica para identificar quais coleções específicas contêm MVCC mais antigos IDs que precisam de atenção. Além disso, monitore documentFragmentStats para identificar coleções com altas porcentagens de fragmentos mortos que possam estar contribuindo para a ineficiência da coleta de lixo.

Depois de identificar essas coleções, talvez seja necessário reduzir temporariamente as operações de gravação nelas para permitir que a coleta de resíduos se atualize. Durante o período de recuperação, recomendamos monitorar de perto a métrica AvailableMVCCIds para garantir que suas ações tenham o efeito desejado. Seu cluster será considerado íntegro quando o valor AvailableMVCCIds retornar para 1,5 bilhão ou mais.

Lembre-se de que essas etapas são medidas preventivas para ajudar seu sistema a se recuperar antes de atingir um estado crítico. Quanto mais cedo você agir tão logo veja a métrica cair abaixo de 1,3 bilhão, maior a probabilidade de evitar qualquer impacto em suas operações de gravação.