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 lixo no Amazon DocumentDB
O Amazon DocumentDB implementa uma arquitetura de banco de dados de controle de concorrência 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 fornece isolamento de leitura, permitindo que as consultas de leitura usem documentos versionados sem bloqueios.
Tópicos
Entendendo a coleta de lixo no Amazon DocumentDB
A coleta de lixo (GC) é um processo automatizado em segundo plano que mantém o desempenho e a disponibilidade ideais do sistema no Amazon DocumentDB. Diferentemente dos bancos de dados tradicionais que sobrescrevem dados no local, a arquitetura MVCC do Amazon DocumentDB cria novas versões de documentos e entradas de índice a cada operação de atualização. Cada operação de gravação que resulta em uma nova versão do documento consome uma ID MVCC exclusiva de um contador finito, tornando essencial uma limpeza eficiente. Com o tempo, essas versões antigas se acumulam e precisam ser limpas para evitar a degradação do desempenho.
Funções da coleta de lixo
O coletor de lixo tem três funções essenciais:
Recupera espaço de armazenamento — Ele remove versões obsoletas de documentos e índices que não são 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.
Mantém o desempenho da consulta — Ele mantém o desempenho 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 lixo
O processo 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:
Identificação — O sistema identifica versões de documentos e índices que não são mais referenciadas por transações ou consultas ativas.
Carregamento de memória — Documentos antigos e entradas de índice são carregados na memória se ainda não estiverem presentes.
Exclusão — As versões obsoletas são excluídas permanentemente para recuperar espaço de armazenamento.
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 de ID MVCC finito e entrar em um estado somente para leitura.
Programação da coleta de lixo
A coleta de lixo é 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 do ID 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.
Monitoramento da coleta de lixo
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 antes de chegar a zero. 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 — Defina um alarme quando o valor cair abaixo de 1,3 bilhão. Esse aviso antecipado permite que você execute as etapas recomendadas discutidas posteriormente.
LongestRunningGCProcess
Localização — Amazon CloudWatch
Descrição — Duração em segundos do processo de coleta de lixo ativo mais longo. Atualiza a cada minuto e rastreia somente as operações ativas, excluindo os processos que são concluídos dentro da janela de um minuto.
Recomendação —
Métricas de nível de coleção
MVCCIDStats: MvccIdAgeScale
Localização — comando Database CollStats
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 para leitura. Use essa métrica ao lado
AvailableMVCCIdspara 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 Database CollStats
Descrição — Fornece um histórico de dois meses das métricas de coleta de lixo, incluindo o total de execuções, a duração média e a duração máxima. Inclui apenas operações de coleta de lixo com duração superior a cinco minutos para garantir estatísticas significativas.
UnusedStorageSize(nível de coleção)
Localização — comando Database CollStats
Descrição — Estima o espaço de armazenamento não utilizado em uma coleção com base nas estatísticas amostradas. Inclui espaço de documentos excluídos e segmentos vazios.
Métricas de nível de índice
UnusedStorageSize(nível do índice)
Localização — comando Database IndexStats
Descrição — Estima o espaço de armazenamento não utilizado em um índice com base nas estatísticas amostradas. Ele inclui espaço de entradas de índice obsoletas e segmentos vazios.
Recomendação — Use o
reIndexcomando para reconstruir índices sem tempo de inatividade e recuperar espaço não utilizado. Consulte Gerenciando índices para obter mais detalhes.
Exemplo collStats de saída
{
"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)
}Perguntas frequentes
Tópicos
Como faço para identificar se a coleta de lixo não está funcionando de forma eficiente?
Monitore esses sinais de alerta que indicam coleta de lixo ineficiente:
Inchaço excessivo da coleção — Aumento constante das
UnusedStorageSizemétricas durante gravações pesadas ou exclusões em massa, especialmente com índices grandesLatê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
GCRuntimeStatsProcessamento elevado de GC — Alto
LongestRunningGCProcessindicador de que o coletor de lixo não consegue atender às demandas do sistema
A coleta de lixo afeta o desempenho do meu banco de dados?
Em condições normais, a coleta de lixo tem um impacto mínimo no desempenho. No entanto, quando a coleta de lixo fica para trás, você pode experimentar:
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.
Posso acionar manualmente a coleta de lixo?
Não, a coleta de lixo no Amazon DocumentDB não pode ser acionada manualmente. O sistema gerencia a coleta de lixo automaticamente como parte de suas operações internas de manutenção.
Quais alarmes devo definir como uma melhor prática operacional?
Recomendamos configurar o monitoramento nos níveis de cluster e coleção para garantir o desempenho ideal do seu sistema Amazon DocumentDB.
Para monitoramento em nível de cluster
Comece criando um CloudWatch alarme para a AvailableMVCCId métrica com um limite de 1,3 bilhão. Isso lhe dá tempo suficiente para agir antes que a métrica chegue a zero, momento em que seu cluster entraria no modo somente leitura. Lembre-se de que essa métrica pode variar com base em seus padrões de uso específicos. Alguns clientes o 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 LongestRunningGCProcess métrica por completo CloudWatch. Além disso, essa métrica ajuda você a entender a eficiência com GCRuntimeStats que a coleta de lixo está funcionando em todo o sistema.
Para monitoramento em nível de coleção
Concentre-se em duas métricas principais. Primeiro, recomendamos observar o MvccIdAgeScale valor de cada coleção. Valores crescentes sugerem que o MVCC IDs está envelhecendo e pode precisar de atenção. Em segundo lugar, monitore GCRuntimeStats para identificar quaisquer processos de coleta de lixo que estejam demorando muito ou se estendendo por vários dias. Coleções com operações de gravação frequentes precisam de atenção extra, pois geram mais trabalho para o coletor de lixo. Recomendamos verificar essas métricas com mais frequência para coleções com muita atividade de gravação para garantir que a coleta de lixo acompanhe sua carga de trabalho.
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 AvailableMVCCId cair abaixo de 1,3 bilhão?
Se sua AvailableMVCCId métrica cair abaixo de 1,3 bilhão, recomendamos tomar medidas imediatas para evitar que seu cluster entre no modo somente leitura. Recomendamos primeiro aumentar o tamanho da instância para fornecer ao coletor de lixo mais recursos computacionais. Isso 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 a ampliação por si só não melhorar a situação, recomendamos considerar uma redução em suas operações de gravação. Use a MvccIdAgeScale métrica para identificar quais coleções específicas contêm MVCC mais antigos IDs que precisam de atenção. 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 lixo se atualize. Durante o período de recuperação, recomendamos monitorar de perto a AvailableMVCCId métrica para garantir que suas ações tenham o efeito desejado. Seu cluster é considerado íntegro quando o AvailableMVCCId valor retorna 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 que ele atinja um estado crítico. Quanto mais cedo você agir depois de ver a métrica cair abaixo de 1,3 bilhão, maior a probabilidade de evitar qualquer impacto em suas operações de gravação.
