Estou ficando preso ao arquivar uma enorme quantidade de dados no MongoDB 3.6
Quero excluir 506 milhões de registros em uma coleção. Eu tentei remover usando bulk.remove(), mas isso também é lento. 50 registros estão sendo removidos por segundo.
Mas em algum lugar eu leio, índice TTL e faço intervalo de varredura a cada 1 hora. Então ele vai remover de forma mais rápida.
Mas se eu criar esse índice em primeiro plano, ele bloqueará a coleção. Então estou pensando em fazer com o método de criação de índice de rolamento.
Se fizer assim, digamos, em um conjunto de réplicas de 3 nós, desanexe o node3 e, em seguida, crie o índice. Uma vez criado, ele começará a remover automaticamente os dados. Então, uma vez que eu adiciono o nó de volta ao conjunto de réplicas, talvez o primário faça a exclusão depois de criar o índice, dessa vez ele tentará replicar, na pior das hipóteses, os dados já foram removidos desse nó, então ele vai quebrar a replicação?
Sim, essa é uma abordagem com suporte para criar índices em conjuntos de réplicas . No entanto, se o seu objetivo é remover com eficiência uma grande quantidade de documentos existentes, há algumas ressalvas a serem observadas, conforme indicado abaixo.
Um índice TTL não acelerará a remoção de documentos se você já tiver um índice que suporte a localização de documentos expirados: o thread TTL ainda precisa encontrar e remover documentos correspondentes, portanto, fará um trabalho semelhante a uma remoção em massa.
Eu investigaria por que suas operações atuais de remoção em massa são lentas. Por exemplo, certifique-se de ter um índice ideal para localizar documentos para remover e monitorar os recursos do sistema (memória, E/S, rede, ...) para garantir que não haja gargalos óbvios.
Se você tiver um grande número de documentos prontos para serem removidos quando o índice TTL for criado, isso poderá ter um impacto significativo no desempenho. As consultas de remoção em massa com um índice de suporte permitiriam mais controle sobre o impacto, pois você pode adicionar critérios de consulta para restringir o intervalo de documentos correspondentes a cada exclusão em massa.
Esse tempo está incorreto: a tarefa de exclusão de TTL é executada a cada 60 segundos. Com base em um campo de data indexado, o monitor TTL pode expirar documentos após um determinado número de segundos ou expirar documentos em um horário específico .
Supondo que seus documentos tenham um intervalo de datas de expiração, assim que a remoção inicial de documentos expirados for concluída, um índice TTL poderá excluir documentos em lotes menores, o que terá menos impacto do que uma exclusão em massa pouco frequente.
Antes do MongoDB 4.2, um índice de primeiro plano construído em uma coleção preenchida bloquearia todas as outras operações no banco de dados que contém essa coleção. Para uma coleção preenchida em um ambiente de produção, você definitivamente desejará usar uma compilação de índice contínuo ou uma compilação de índice em segundo plano. A compilação de índice contínuo garante que apenas um dos membros do conjunto de réplicas esteja criando um índice e permite que uma compilação de índice em primeiro plano seja concluída mais rapidamente, no entanto, essa abordagem inclui algum risco de esse membro se tornar obsoleto durante a execução no modo autônomo.
O MongoDB 4.2+ usa um processo de compilação de índice otimizado que limita o escopo do bloqueio à coleção afetada e mantém apenas um bloqueio exclusivo no início e no final da compilação do índice. Você ainda pode usar a abordagem de criação de índice contínuo, mas não há mais uma distinção de criação de índice em primeiro plano versus em segundo plano.
O thread de índice TTL em membros do conjunto de réplicas somente exclui documentos quando um membro está no estado primário . As exclusões de documentos são replicadas por meio do oplog para que os secundários sempre tenham um ponto de tempo consistente com o primário atual.
Se você reiniciar um membro do conjunto de réplicas no modo autônomo, o monitor de coleta de TTL não será iniciado (novamente, para manter o estado secundário consistente).