O MongoDB 8.0 traz melhorias significativas de desempenho e novos recursos para gerenciamento de memória, replicação, sharding, agregação e segurança. Este tópico resume as principais alterações para ajudar na avaliação da atualização e no entendimento dos impactos nas aplicações.
Para consultar o changelog completo upstream, visualize as notas de lançamento do MongoDB 8.0.
TCMalloc avançado
O MongoDB 8.0 substitui o alocador de memória anterior por uma versão avançada do TCMalloc, que reduz a fragmentação de memória e mantém o desempenho sob cargas intensas. Duas mudanças principais impulsionam essa melhoria:
Cache por CPU: O TCMalloc avançado usa um cache por núcleo de CPU em vez de por thread. Isso diminui a fragmentação de memória e permite que o banco de dados processe cargas de trabalho simultâneas mais elevadas.
Liberação de memória em segundo plano: Uma thread em segundo plano tenta devolver a memória não utilizada ao sistema operacional a cada segundo.
O parâmetro tcmallocReleaseRate controla a taxa de liberação em bytes/s. Antes do MongoDB 8.0, esse parâmetro aceitava um intervalo impreciso de 1–10. No ApsaraDB for MongoDB, o valor padrão é 10485760 (10 MB). Mesmo quando definido como 0, o alocador ainda libera parte da memória. Ajuste esse valor conforme os requisitos da sua carga de trabalho.
Desempenho de replicação
Mudança no comportamento do write concern "majority"
A partir do MongoDB 8.0, quando o writeConcern está definido como majority, o MongoDB confirma a gravação assim que a entrada do oplog é escrita na maioria dos membros do replica set, sem aguardar a aplicação da alteração nesses membros. Isso aumenta o throughput de gravação no modo majority.
Impacto potencial: Se a aplicação ler de um nó secundário imediatamente após receber uma confirmação de gravação majority, a consulta poderá retornar resultados que não incluem as alterações dessa gravação.
Gravação e aplicação paralelas do oplog
Os nós secundários agora gravam e aplicam lotes do oplog em paralelo:
Uma thread Writer lê novas entradas do oplog do nó primário e as grava no oplog local.
Uma thread Applier aplica essas alterações de forma assíncrona ao banco de dados local.
Essa mudança melhora o throughput de replicação nos nós secundários. As métricas relacionadas do serverStatus agora são reportadas como metrics.repl.buffer.write e metrics.repl.buffer.apply.
Desempenho de resharding
O comando reshardCollection está significativamente mais rápido no MongoDB 8.0. A nova opção forceRedistribution permite fazer o resharding de uma coleção usando sua shard key existente e redistribuir os dados para novos shards. Esse processo termina mais rapidamente do que a migração de um chunk para um intervalo específico. Combine forceRedistribution com a opção zones para migrar dados para uma zona específica.
db.adminCommand({
reshardCollection: "db.coll",
key: { shard_key: "hashed" },
forceRedistribution: true
})Criar índices durante o resharding pode causar falhas silenciosas na construção, sem mensagens de erro explícitas. Conclua todas as construções de índices antes de iniciar o resharding ou evite criar índices enquanto ele estiver em andamento.
Durante a fase incremental de recuperação do oplog, o shard de source bloqueia gravações na coleção apenas quando o tempo restante estimado é inferior a dois segundos e, em seguida, aguarda o shard de destino concluir a recuperação. Se seu caso de uso tolerar uma janela de bloqueio maior — por exemplo, durante uma janela de manutenção — execute o comando commitReshardCollection para bloquear as gravações imediatamente e acelerar a conclusão do resharding.
Para obter mais informações, consulte Processo de resharding e Fazer shard de uma coleção.
Sharding
Além das melhorias de resharding mencionadas acima, o MongoDB 8.0 inclui as seguintes alterações de sharding:
Padrão de hashed sharding: O hashed sharding cria 1 chunk por shard por padrão (antes eram 2 chunks no MongoDB 8.0).
dbHashem shards: O comandodbHashagora pode ser executado em shards individuais.Shard keys parciais em consultas: Os comandos
findAndModifyedeleteOneaceitam shard keys parciais como predicados de consulta.updateOnecom upsert: Ao usarupdateOnecomupsert: trueem uma coleção com sharding, todos os campos da shard key podem ser omitidos do predicado da consulta.unshardCollection: Remove o sharding de uma coleção existente e move todos os documentos para um shard específico ou para o shard com menos dados.moveCollection: Move uma coleção sem sharding para um shard específico, independentemente do shard primário. Coleções de séries temporais e coleções com Queryable Encryption não podem ser movidas. As operações de gravação ficam bloqueadas por aproximadamente 2 segundos durante a movimentação.
Os seguintes comandos e funções auxiliares do mongosh estão disponíveis agora:
|
Comando |
Auxiliar do mongosh |
Descrição |
|
|
|
Move uma coleção sem sharding para um shard específico. |
|
|
|
Remove o sharding de uma coleção e move todos os dados para um shard específico. |
|
|
|
Cancela uma operação |
|
|
|
Cancela uma operação |
|
Nenhum |
|
Cria shards para uma coleção e redistribui os dados imediatamente com uma shard key existente. Equivalente a executar |
Logging
O campo workingMillis foi adicionado aos logs de consultas lentas. Ele mostra o tempo efetivo gasto pelo MongoDB processando a operação, útil para identificar gargalos reais de desempenho.
Diferente do durationMillis — que reflete a latência total da operação, incluindo espera por locks ou limitação de tráfego — o workingMillis exclui esses tempos de espera externos. Use o workingMillis para medir o tempo real de processamento, independentemente de contenção de fila ou locks.
Agregação
Conversão de BinData
O operador $convert agora suporta as seguintes conversões:
String para BinData
BinData para string
A expressão $toUUID oferece um atalho para converter valores de string em UUID.
$queryStats
O estágio de agregação $queryStats retorna estatísticas para consultas registradas. No MongoDB 8.0, ele também rastreia e reporta métricas em change streams de maneira mais eficiente.
Segurança do banco de dados
Queryable Encryption: consultas de intervalo
O Queryable Encryption agora suporta consultas de intervalo em campos criptografados usando $lt, $lte, $gt e $gte.
Fila de entrada
O MongoDB 8.0 introduz uma fila de entrada (ingressAdmissionControllerTicketPoolSize) para requisições de rede recebidas. As operações vindas da rede entram nessa fila antes de serem admitidas no banco de dados.
Por padrão, a fila é ilimitada. Defina um tamanho máximo para limitar o número de requisições enfileiradas e evitar filas sem limites durante picos de tráfego.
Outras otimizações
Formas de consulta e configurações de consulta
O MongoDB 8.0 introduz um novo conceito de Query Shape. A forma de consulta anterior agora chama-se plan cache query shape. Use configurações de consulta (não filtros de índice) para influenciar a seleção do plano de consulta. O comando planCacheSetFilter para definir filtros de índice não é mais suportado no MongoDB 8.0.
Três comandos gerenciam as configurações de consulta:
setQuerySettings: Especifique dicas de índice ou defina uma políticarejectpara uma Query Shape específica a fim de impedir sua execução.removeQuerySettings: Exclua as configurações de consulta para uma Query Shape.$querySettings: Visualize as configurações de consulta atuais.
Tempo de otimização do plano de consulta
A saída do explain() agora inclui queryPlanner.optimizationTimeMillis, que reporta o tempo gasto na otimização do plano de consulta em milissegundos.
Timeout padrão para operações de leitura
O novo parâmetro defaultMaxTimeMS define um limite de tempo padrão (em milissegundos) para operações de leitura. Ele se aplica a find, aggregate (excluindo os estágios $merge e $out), count, distinct e dbHash. Se o cliente especificar maxTimeMS em uma operação individual, esse valor terá precedência.
Comando bulkWrite
O novo comando bulkWrite executa múltiplas operações de inserção, atualização e exclusão em várias coleções dentro de uma única requisição.
Alterações adicionais
Ordenação no
updateOne: O comandoupdateOneagora suporta a opçãosort.Índices TTL em coleções capped: Agora é possível criar índices TTL em coleções capped.
Batching de oplog para inserção em massa: Inserções em massa não transacionais agora são gravadas como uma única entrada de oplog em vez de entradas separadas. Todos os documentos inseridos compartilham o mesmo
clusterTimenos eventos de change stream. Isso melhora o desempenho de inserção em massa e reduz o atraso de replicação causado pela reprodução de múltiplos oplogs nos nós secundários.Operações DDL simultâneas: Diferentes coleções no mesmo banco de dados agora podem passar por operações DDL simultaneamente.
Alterações de membresia de shard durante DDL: A adição ou remoção de shards de um cluster com sharding é bloqueada enquanto operações DDL (como
reshardCollection) estiverem em andamento. Conclua as operações DDL antes de modificar a membresia dos shards.
Melhorias na criação de índices
O MongoDB 8.0 aprimora o relatório de erros e a resiliência na criação de índices:
|
Aspecto |
MongoDB 8.0 |
Antes do MongoDB 8.0 |
|
Relatório de erros |
Erros detectados durante a fase de varredura da coleção (exceto erros de chave duplicada) são retornados imediatamente e a criação do índice é interrompida. |
Erros detectados durante a varredura da coleção eram retornados apenas na fase de commit, ao final da criação do índice, aumentando o tempo para diagnóstico. |
|
Resiliência do nó secundário |
Em caso de erro na criação do índice, os nós secundários podem solicitar que o primário pare a criação e não travam. (Se um secundário já tiver votado para fazer o commit, ele não pode parar e irá travar — consistente com o comportamento do MongoDB 7.0.) |
Erros na criação de índices podiam causar travamentos nos nós secundários. |
|
Gerenciamento de espaço em disco |
Se o espaço disponível em disco cair abaixo de |
A criação de índices também era interrompida em caso de espaço em disco insuficiente. |