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.
**Topics**
+ [Entendendo a coleta de lixo no Amazon DocumentDB](#understanding-garbage-collection)
+ [Processo de coleta de resíduos](#garbage-collection-process)
+ [Arquitetura de armazenamento e armazenamento estendido](#storage-architecture)
+ [Monitoramento da coleta de resíduos](#monitoring-garbage-collection)
+ [Exemplo de saída CollStats](#example-collstats-output)
+ [Perguntas frequentes](#garbage-collection-faq)
## 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.
1. **Carregamento na memória**: os documentos antigos e as entradas de índice são carregados na memória se ainda não estiverem presentes.
1. **Exclusão**: as versões obsoletas são excluídas permanentemente para recuperar espaço de armazenamento.
1. **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.
+ `storageSizeStats`e `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.