“`html
Erros comuns em Elasticsearch que você deve evitar
Quando o Elasticsearch funciona, ele parece “mágico”. Mas a diferença entre um cluster estável e um pesadelo quase sempre
está nos detalhes: mapeamento, consultas, índices, refresh, shards e segurança. Abaixo estão os erros mais frequentes
(e como corrigir).
1) Ignorar mapeamento: confiar no “vai dar certo”
Mapeamento & tipos
O primeiro erro é deixar o Elasticsearch adivinhar tipos e estruturas. Isso costuma levar a problemas difíceis de reverter:
campos que viram texto quando você queria keyword, números tratados como
string, datas sem formato consistente, e campos que exigem reindexação para mudar.
Regra prática: defina explicitamente o mapeamento para campos usados em filtro/agrupamento e para campos com semântica
(datas, IDs, valores numéricos).
- Keywords para agregações: campos usados em terms (ou filtros exatos) devem ser
keyword. - Texto com intenção: campos de busca full-text geralmente são
textcom estratégia de análise. - Datas: padronize o formato no ingestão e no mapeamento (evite “meio confuso” entre strings e epoch).
- Arrays e objetos: entenda como o Elasticsearch “flata” campos e evite estruturas inconsistentes.
Se você perceber que precisa trocar tipo/estrutura depois, planeje reindexação desde o início. Trocar mapeamento “no susto”
tende a gerar interrupções, custos e bugs silenciosos.
2) Consultas caras: errar no tipo de query e no contexto
Query DSL
Outro erro frequente é montar consultas que fazem trabalho demais: usar query “genérica” onde uma mais específica
seria suficiente, misturar filtros com pontuação quando você só quer filtrar, e desperdiçar caching.
-
Confundir filter com must: quando você só quer restringir resultados, use
bool.filter(contexto sem score).
Isso reduz custo e melhora cache. -
Usar match quando deveria ser termo exato: para IDs e valores “imutáveis”, use
term/termssobrekeyword. - Range sem estratégia: ranges frequentes precisam de atenção: valores mal modelados (ex.: datas como texto) custam caro.
- Wildcard “dinâmico” demais: padrões amplos em campos não otimizados podem varrer grande parte do índice.
-
Achar “tudo” com shoulds demais: consultas complexas com muitos
shouldpodem inflar o custo
e gerar resultados difíceis de explicar.
Checklist rápido: filtre primeiro, pagine com cuidado, evite queries com baixa seletividade em campos errados
e valide a performance com dados reais.
3) Gerenciar shards no “achismo”
Shards & escala
Shards determinam paralelismo, memória e overhead. O erro comum é criar índice com número de shards baseado em expectativa
(ou no padrão “5 porque sim”). Resultado: muitos shards pequenos (overhead alto) ou poucos shards gigantes (hotspot e lentidão).
- Shards demais: aumenta custo de cluster (metadados, buscas, manutenção). Isso derruba performance mesmo quando “parece pouco”.
- Shards de menos: concentra workload e cria gargalos (principalmente em índices com crescimento e queries pesadas).
- Replica sem estratégia: replica melhora leitura, mas também aumenta custo de escrita e consumo de disco.
- Ignorar lifecycle: índices temporários sem estratégia de rollover/retention viram um cemitério de shards antigos.
Dica operacional: ajuste estratégia de shards por volume e taxa de crescimento. Reavalie conforme o padrão real
de queries e ingestão evolui.
4) Esquecer refresh, escrita e retenção
Ingestão & consistência
Muita gente otimiza “a busca” e ignora “a escrita”. No Elasticsearch, refresh afeta latência e custo. Além disso,
configurações de retenção e ingestão mal pensadas geram crescimento descontrolado e picos de I/O.
- Refresh agressivo demais: se você não precisa de visibilidade imediata, refresh frequente aumenta custo.
- Bulk pequeno: bulk com requisições pequenas reduz throughput. Prefira lotes consistentes e dimensionados.
- Não planejar índices por ciclo: índices “eternos” tendem a ficar mais lentos com o tempo (segmentos crescem, merges aumentam).
- Ignorar merge policy e segment churn: ingestão pesada + updates frequentes pode aumentar custo de manutenção do índice.
- Retenção sem regra: sem uma estratégia (ex.: retenção por tempo), você paga por histórico que não precisa mais.
Objetivo: alinhar consistência esperada (tempo até aparecer na busca) com o custo operacional de refresh/merge.
Exemplo: query com filtros em contextos corretos
Performance na prática
Quando você separa filter (sem score) de must (com score), você reduz trabalho e deixa a intenção explícita.
Ajuste conforme seus campos (keyword vs text).
{
"query": {
"bool": {
"filter": [
{ "term": { "status.keyword": "active" } },
{ "range": { "createdAt": { "gte": "now-30d/d", "lt": "now/d" } } }
],
"must": [
{ "match": { "title": { "query": "elasticsearch", "operator": "and" } } }
]
}
},
"sort": [
{ "createdAt": { "order": "desc" } }
],
"size": 25
}
Se você sempre filtra por status e por datas, mover isso para filter costuma ser uma das
mudanças com melhor relação custo/benefício.
Quer continuar evoluindo seu Elasticsearch?
Eu recomendo ler outros posts do yurideveloper.com.br para consolidar boas práticas em mapeamento, modelagem,
desempenho e operação de cluster.
“`
Sou Apaixonado pela programação e estou trilhando o caminho de ter cada diz mais conhecimento e trazer toda minha experiência vinda do Design para a programação resultando em layouts incríveis e idéias inovadoras! Conecte-se Comigo!