Diagnosticando e Resolvendo Consultas Lentas no MongoDB: Um Guia Prático

Consultas lentas no MongoDB geralmente aparecem após o crescimento dos dados, mudança no padrão de acesso ou quando um índice não corresponde mais à forma como a aplicação lê os dados. Você pode notar endpoints de API expirando, dashboards carregando lentamente ou aumento de CPU e I/O de disco, mesmo que o tráfego pareça normal.

Use o profiler para encontrar a operação lenta, explain() para ver como o MongoDB a executa e índices direcionados para reduzir o trabalho que o MongoDB precisa realizar.

Entendendo Por Que as Consultas se Tornam Lentas

Antes de alterar índices, verifique as causas comuns:

1. Índices ausentes ou ineficazes: Sem um índice útil, o MongoDB pode realizar uma varredura de coleção e examinar todos os documentos.
2. Complexidade da Consulta: Operações que exigem estágios de agregação, ordenações grandes ou consultas entre coleções podem ser inerentemente lentas se não forem otimizadas.
3. Volume de Dados: Mesmo consultas indexadas podem ficar lentas se o conjunto de dados for massivo e a consulta ainda precisar processar milhões de documentos antes de filtrar.
4. Restrições de Hardware: RAM insuficiente (levando a troca extensiva de disco) ou I/O de disco lento podem degradar o desempenho em todas as operações.

Passo 1: Identificando Consultas Lentas Usando Profiling

O primeiro passo para a resolução é a identificação. O Database Profiler do MongoDB registra os tempos de execução das operações do banco de dados, permitindo identificar exatamente quais consultas estão causando problemas.

Habilitando e Configurando o Profiler

O profiler opera em diferentes níveis. O nível 0 desativa o profiling. O nível 1 registra operações mais lentas que o limite configurado. O nível 2 registra todas as operações.

Para analisar consultas lentas, geralmente defina o nível 1 com um limite, como 50 milissegundos:

// Mude para o banco de dados que deseja analisar
use myDatabase

// Capture operações que levam mais de 50 milissegundos
db.setProfilingLevel(1, { slowms: 50 })

Revisando os Resultados do Profiler

As operações lentas registradas são armazenadas na coleção system.profile. Você pode consultar esta coleção para ver consultas lentas recentes:

// Encontre operações que levam mais de 50ms
db.system.profile.find({ ns: "myDatabase.myCollection", millis: { $gt: 50 } }).sort({ ts: -1 }).limit(10).pretty()

Mantenha o nível 2 apenas para investigações curtas. Ele registra todas as operações e pode adicionar sobrecarga em um banco de dados de produção movimentado.

Passo 2: Analisando a Execução da Consulta com explain()

Depois de identificar uma consulta lenta, use explain() para ver como o MongoDB a processa.

Usando explain('executionStats')

O nível de detalhamento executionStats fornece a saída mais abrangente, incluindo tempos reais de execução e utilização de recursos.

Considere esta consulta lenta direcionada à coleção users:

db.users.find({ status: "active", city: "New York" }).sort({ registrationDate: -1 }).explain('executionStats')

Interpretando a Saída

Os campos-chave a serem inspecionados na saída do explain() são:

Campo	Descrição	Indicador de Lentidão
winningPlan stages	O plano de execução escolhido pelo otimizador.	Procure por COLLSCAN, SORT bloqueante ou um índice inesperado.
executionStats.nReturned	O número de documentos retornados pela operação.	Número alto quando se espera poucos resultados geralmente indica filtragem pobre no início.
executionStats.totalKeysExamined	Quantas chaves de índice foram verificadas.	Deve geralmente estar próximo de nReturned se um índice for usado de forma eficaz.
executionStats.totalDocsExamined	Quantos documentos foram realmente recuperados do disco/memória.	Número alto sugere que o índice não foi seletivo o suficiente.
executionStats.executionTimeMillis	O tempo total gasto na execução.	Compare isso com a latência do mundo real.

A Bandeira Vermelha: COLLSCAN

Se o plano vencedor contiver COLLSCAN, o MongoDB varreu a coleção. Isso geralmente significa que a consulta precisa de um índice melhor, o predicado não é seletivo ou a forma da consulta impede o uso do índice.

Passo 3: Implementando Estratégias de Índice

Resolver COLLSCAN geralmente envolve criar ou ajustar índices para corresponder ao padrão da consulta.

Criando Índices Compostos

Para consultas envolvendo múltiplos campos, como correspondências de igualdade, filtros de intervalo ou ordenação, um índice composto é frequentemente necessário. A diretriz comum ESR ordena os campos do índice composto primeiro pelos predicados de igualdade, depois pelos campos de ordenação e, em seguida, pelos predicados de intervalo. É uma diretriz, não um substituto para testes com sua consulta e dados reais.

Exemplo de Cenário: Consulta: db.orders.find({ status: "PENDING", customerId: 123 }).sort({ orderDate: -1 })

Com base no ESR, o índice deve seguir esta estrutura:

1. Predicados de igualdade (status, customerId)
2. Predicados de ordenação (orderDate)

Criação do Índice:

db.orders.createIndex( { status: 1, customerId: 1, orderDate: -1 } )

Este índice permite que o MongoDB filtre rapidamente por status e ID do cliente e, em seguida, recupere eficientemente os resultados já ordenados por orderDate.

Lidando com Operações de Ordenação

Se explain() mostrar um estágio SORT bloqueante após muitos documentos serem examinados, o MongoDB não conseguiu usar um índice para retornar o resultado em ordem ordenada.

Ordenações grandes podem consumir memória e podem transbordar para o disco, dependendo da versão do servidor e das opções de comando. A melhor correção geralmente é um índice que suporte tanto o filtro quanto a ordenação.

Certifique-se de que os campos usados na cláusula .sort() estejam presentes como os elementos finais no índice composto apropriado.

Passo 4: Técnicas Avançadas de Otimização

Se apenas a indexação não resolver a lentidão, considere estas etapas avançadas:

Otimização de Projeção

Use projeção, o segundo argumento em .find(), para retornar apenas os campos que sua aplicação precisa. Isso reduz a transferência de rede e pode permitir uma consulta coberta quando os campos projetados estão no índice.

// Retorna apenas os campos _id, name e email
db.users.find({ city: "Boston" }, { name: 1, email: 1, _id: 1 })

Índices Covering

Um índice covering é o objetivo final de desempenho. Isso ocorre quando todos os campos exigidos pela consulta (no filtro, projeção e ordenação) estão presentes no próprio índice. Quando isso acontece, o MongoDB nunca precisa buscar o documento real (COLLSCAN é evitado e totalDocsExamined será 0 ou muito baixo).

Na saída do explain(), um índice covering resulta no estágio mostrando IXSCAN e totalDocsExamined sendo 0.

Revisão de Hardware e Configuração

Se totalKeysExamined e totalDocsExamined parecerem razoáveis, mas a latência permanecer alta, olhe além da forma da consulta. Verifique se o conjunto de trabalho cabe na memória, se a latência do disco é alta e se o servidor está sob pressão de escrita, contenção de bloqueio ou saturação de CPU.

Conclusão

Diagnosticar consultas lentas no MongoDB é um ciclo: analise a carga de trabalho, explique a consulta lenta, adicione ou ajuste o índice e meça novamente. Uma boa correção reduz os documentos examinados, remove varreduras de coleção evitáveis ou ordenações bloqueantes e melhora o caminho real de requisição que seus usuários sentem.

Lista de Verificação Acionável:

1. Habilite o profiler temporariamente para capturar consultas lentas (slowms).
2. Execute a consulta problemática usando explain('executionStats').
3. Verifique se há COLLSCAN ou totalDocsExamined alto.
4. Crie ou modifique índices compostos com base na regra ESR para cobrir filtros e ordenações.
5. Verifique a melhoria executando novamente o comando explain().