Diagnosticando e Corrigindo Consultas Lentas no Elasticsearch

Pesquisas lentas no Elasticsearch geralmente vêm de consultas amplas, agregações caras, escolhas de mapeamento, layout de shards ou pressão de recursos no cluster. Se sua API de pesquisa começar a expirar ou a latência aumentar após o crescimento de um índice, você precisa identificar se a consulta, o índice ou o cluster está fazendo muito trabalho.

Use logs lentos e a API Profile para encontrar a parte cara e, em seguida, ajuste a consulta, o mapeamento, a estratégia de shard ou o hardware com base no que as evidências mostrarem.

Principais Causas de Pesquisas Lentas no Elasticsearch

Vários fatores podem contribuir para consultas de pesquisa lentas. Identificar a causa específica em seu ambiente é crucial para uma solução de problemas eficaz.

1. Consultas Ineficientes

O design da consulta é frequentemente a influência mais direta no desempenho da pesquisa. Consultas complexas ou mal estruturadas podem forçar o Elasticsearch a fazer muito trabalho, levando ao aumento da latência.

• Consultas Amplas: Consultas que varrem um grande número de documentos ou campos sem filtragem suficiente.
  • Exemplo: Uma consulta match_all em um índice massivo.
• Paginação Profunda: Solicitar uma página muito grande usando from e size. Para paginação profunda voltada ao usuário, prefira search_after com uma ordenação estável e pesquisa point-in-time. Use scroll principalmente para processamento em lote ou cargas de trabalho de reindexação.
• Agregações Complexas: Agregações excessivamente complicadas ou intensivas em recursos, especialmente quando combinadas com consultas amplas.
• Consultas Wildcard: Wildcards iniciais (ex.: *term) são particularmente ineficientes, pois não podem usar pesquisas no índice invertido de forma eficaz. Wildcards finais geralmente são melhores, mas ainda podem ser lentos em grandes conjuntos de dados.
• Consultas com Expressões Regulares: Elas podem ser computacionalmente caras e devem ser usadas com moderação.

2. Problemas de Mapeamento

Como seus dados são indexados (definido por seus mapeamentos) impacta profundamente a velocidade da pesquisa. Escolhas incorretas de mapeamento podem levar a indexação ineficiente e pesquisas mais lentas.

• Mapeamentos Dinâmicos: Embora convenientes, os mapeamentos dinâmicos podem, às vezes, levar a tipos de campo inesperados ou à criação de campos analyzed desnecessários, aumentando o tamanho do índice e a sobrecarga da pesquisa.
• Campos text vs. keyword: Usar campos text para correspondência exata ou ordenação/agregações quando um campo keyword seria mais apropriado. Campos text são analisados para pesquisa de texto completo, enquanto campos keyword são indexados como estão, tornando-os ideais para correspondências exatas, ordenação e agregações.
  • Exemplo: Se você precisa filtrar por um ID de produto (PROD-123), ele deve ser mapeado como keyword, não text.

  PUT my-index
  {
    "mappings": {
      "properties": {
        "product_id": {
          "type": "keyword"
        }
      }
    }
  }
  

• Suposições antigas sobre o campo _all: Versões antigas do Elasticsearch tinham um campo _all que indexava conteúdo de outros campos. Versões modernas o removeram, então use campos explícitos ou copy_to quando precisar de texto de pesquisa combinado.
• Estruturas de Dados Aninhadas: Usar tipos de dados nested pode ser poderoso para manter relacionamentos, mas também pode ser mais intensivo em recursos para consultas em comparação com tipos flattened ou object se não for consultado com cuidado.

3. Hardware e Configuração do Cluster

A infraestrutura subjacente e como o Elasticsearch é configurado desempenham um papel crítico no desempenho.

• Recursos de Hardware Insuficientes:
  • CPU: Alto uso de CPU pode indicar consultas ineficientes ou cargas pesadas de indexação/pesquisa.
  • RAM: RAM insuficiente leva ao aumento de E/S de disco, pois o sistema operacional faz swap de memória. O Elasticsearch também depende muito do heap da JVM e do cache do sistema de arquivos do SO.
  • E/S de Disco: Discos lentos (especialmente HDDs) são um grande gargalo. O uso de SSDs é altamente recomendado para clusters de produção do Elasticsearch.
• Tamanho e Número de Shards:
  • Muitos Shards Pequenos: Cada shard tem sobrecarga. Um número muito grande de shards pequenos pode sobrecarregar o cluster.
  • Poucos Shards Grandes: Shards grandes podem levar a longos tempos de recuperação e distribuição desigual da carga.
  • Diretriz geral: Shards na casa das dezenas de gigabytes são comuns para muitas cargas de trabalho de logging e pesquisa, mas o tamanho certo depende do volume de dados, padrões de consulta, metas de recuperação e recursos do nó.
• Réplicas: Embora as réplicas melhorem a disponibilidade e a taxa de transferência de leitura, elas também aumentam a sobrecarga de indexação e o uso de espaço em disco. Muitas réplicas podem sobrecarregar os recursos.
• Tamanho do Heap da JVM: Um heap da JVM configurado incorretamente pode levar a pausas de garbage collection. Um ponto de partida comum é não mais da metade da RAM do sistema, deixando memória suficiente para o cache do sistema de arquivos do SO. Siga as orientações de heap da sua versão do Elasticsearch.
• Latência de Rede: Em ambientes distribuídos, a latência de rede entre nós pode afetar a comunicação entre nós e a coordenação da pesquisa.

4. Problemas de Desempenho de Indexação que Afetam a Pesquisa

Embora este artigo se concentre na pesquisa, problemas durante a indexação podem impactar indiretamente a velocidade da pesquisa.

• Alta Carga de Indexação: Se o cluster está lutando para acompanhar as solicitações de indexação, isso pode impactar o desempenho da pesquisa. Isso geralmente é devido a hardware insuficiente ou estratégias de indexação mal otimizadas.
• Grande Número de Segmentos: Indexação frequente sem mesclagem regular de segmentos pode levar a um alto número de pequenos segmentos. Embora o Elasticsearch mescle segmentos automaticamente, esse processo é intensivo em recursos e pode desacelerar temporariamente as pesquisas.

Diagnosticando Consultas Lentas

Antes de implementar correções, você precisa identificar quais consultas são lentas e por quê.

1. Logs Lentos do Elasticsearch

Configure o Elasticsearch para registrar consultas lentas. Esta é a maneira mais direta de identificar solicitações de pesquisa problemáticas.

• Configuração: Defina limites de log lento por índice. Use os sufixos de nível de log que o Elasticsearch espera, como warn, info, debug ou trace.

  PUT _settings
  {
    "index": {
      "search": {
        "slowlog": {
          "threshold": {
            "query": {
              "warn": "1s"
            },
            "fetch": {
              "warn": "1s"
            }
          }
        }
      }
    }
  }
  

  • query: Registra consultas que demoram mais que o limite especificado para executar a fase de consulta.
  • fetch: Registra consultas que demoram mais que o limite especificado para executar a fase de busca (recuperação dos documentos reais).
• Localização do log: Os logs lentos são gravados através do log do Elasticsearch e geralmente aparecem em arquivos de log lento de pesquisa separados, dependendo do seu pacote, plataforma de implantação e configuração de log.

2. Ferramentas de Monitoramento do Elasticsearch

Utilize ferramentas de monitoramento para obter insights sobre a saúde e o desempenho do cluster.

• Monitoramento do Elastic Stack: Fornece dashboards para CPU, memória, E/S de disco, uso de heap da JVM, latência de consulta, taxas de indexação e muito mais quando configurado.
• APM (Monitoramento de Desempenho de Aplicações): Pode ajudar a rastrear solicitações da sua aplicação para o Elasticsearch, identificando gargalos no nível da aplicação ou do Elasticsearch.
• Ferramentas de Terceiros: Muitas ferramentas externas oferecem recursos avançados de monitoramento e análise.

3. API Analyze

A API _analyze pode ajudar a entender como seus campos de texto são tokenizados e processados, o que é crucial para depurar problemas de pesquisa de texto completo.

• Exemplo: Veja como uma string de consulta é processada.

  GET my-index/_analyze
  {
    "field": "my_text_field",
    "text": "Quick brown fox"
  }
  

4. API Profile

Para ajuste de desempenho de consulta muito específico, a API Profile pode fornecer informações detalhadas de tempo para cada componente de uma solicitação de pesquisa.

• Exemplo:

  GET my-index/_search
  {
    "profile": true,
    "query": {
      "match": {
        "my_field": "search term"
      }
    }
  }
  

Corrigindo Consultas Lentas: Soluções e Otimizações

Depois de identificar a causa raiz, você pode implementar soluções direcionadas.

1. Otimizando Consultas

• Contexto de Filtro: Use a cláusula filter para condições que não precisam de pontuação. O Elasticsearch pode executá-las como filtros sim/não e pode armazenar em cache filtros usados com frequência.

  GET my-index/_search
  {
    "query": {
      "bool": {
        "must": [
          { "match": { "title": "elasticsearch" } }
        ],
        "filter": [
          { "term": { "status": "published" } },
          { "range": { "publish_date": { "gte": "now-1M/M" } } }
        ]
      }
    }
  }
  

• Evite Wildcards Iniciais: Reescreva consultas para evitar wildcards iniciais (*term) se possível. Considere usar tokenizers ngram ou métodos de pesquisa alternativos.
• Limite Varreduras de Campos: Especifique apenas os campos que você precisa em sua consulta e na filtragem _source de sua resposta.
• Use search_after para Paginação Profunda: Para paginação interativa além de páginas rasas, use search_after com uma ordenação determinística. Para grandes exportações, use scroll ou point-in-time mais search_after, dependendo da sua versão do Elasticsearch e da carga de trabalho.
• Simplifique Agregações: Revise e otimize agregações complexas. Considere usar agregações composite para paginação profunda de agregações.
• keyword para Correspondências Exatas/Ordenação: Certifique-se de que os campos usados para correspondência exata, ordenação ou agregações sejam mapeados como keyword.

2. Melhorando Mapeamentos

• Mapeamentos Explícitos: Defina mapeamentos explícitos para seus índices em vez de depender apenas de mapeamentos dinâmicos. Isso garante que os campos sejam indexados com os tipos corretos.
• Cuidado com _source e doc_values: Desabilitar _source pode quebrar atualizações, reindexação, realce e fluxos de trabalho de depuração. Desabilitar doc_values em campos usados para ordenação ou agregações prejudicará essas cargas de trabalho. Trate-os como otimizações de armazenamento, não correções de pesquisa padrão.
• index_options: Para campos text, ajuste index_options para armazenar apenas as informações necessárias (ex.: posições para consultas de frase).

3. Ajuste de Hardware e Cluster

• Atualize o Hardware: Invista em CPUs mais rápidas, mais RAM e especialmente SSDs.
• Otimize a Estratégia de Sharding: Revise o número e o tamanho dos seus shards. Considere reindexar dados em um novo índice com uma estratégia de sharding otimizada, se necessário. Use ferramentas como o Index Lifecycle Management (ILM) para gerenciar índices baseados em tempo e seu sharding.
• Ajuste o Heap da JVM: Certifique-se de que o heap da JVM esteja dimensionado corretamente (ex.: 50% da RAM, máximo 30-32GB) e monitore a garbage collection.
• Papéis dos Nós: Distribua papéis (master, data, ingest, coordinating) entre diferentes nós para evitar contenção de recursos.
• Aumente Réplicas (para cargas de trabalho pesadas de leitura): Se seu gargalo for a taxa de transferência de leitura e não a indexação, considere adicionar mais réplicas, mas monitore o impacto na indexação.

4. Otimização de Índice

• Force Merge: Execute _forcemerge apenas em índices somente leitura, onde menos segmentos ajudarão na pesquisa e no armazenamento. É intensivo em recursos e pode criar segmentos muito grandes que são caros para reescrever se o índice continuar recebendo gravações.

  POST my-index/_forcemerge?max_num_segments=1
  

• Index Lifecycle Management (ILM): Use ILM para gerenciar automaticamente índices, incluindo fases de otimização como force merge em índices mais antigos e inativos.

Melhores Práticas para Manter o Desempenho

• Monitore Regularmente: O monitoramento contínuo é fundamental para detectar regressões de desempenho precocemente.
• Teste Mudanças: Antes de implantar mudanças significativas em produção, teste-as em um ambiente de staging.
• Entenda Seus Dados e Consultas: As melhores otimizações são específicas do contexto. Saiba quais dados você tem e como os consulta.
• Mantenha o Elasticsearch Atualizado: Versões mais recentes geralmente incluem melhorias de desempenho e correções de bugs.
• Dimensione Corretamente Seu Cluster: Evite provisionamento excessivo ou insuficiente de recursos. Avalie regularmente as necessidades do seu cluster.

Conclusão

Corrija pesquisas lentas no Elasticsearch medindo primeiro. Logs lentos informam quais solicitações são prejudiciais, a API Profile mostra onde o tempo é gasto e as métricas do cluster mostram se a consulta está competindo com pressão de heap, E/S de disco, indexação ou sobrecarga de shard. Faça uma alteração, execute a mesma consulta novamente e mantenha o resultado apenas se a latência e o uso de recursos melhorarem.