1001Ferramentas
🔎Geradores

Gerador de Elasticsearch Query DSL

Constrói uma query Elasticsearch DSL (match, term, range, bool) em JSON, pronta para colar no _search.


  

Query DSL do Elasticsearch explicada

O Elasticsearch é um motor de busca distribuído construído sobre o Apache Lucene, criado por Shay Banon em 2010. Toda interação acontece via API REST JSON, e a Query DSL (Domain Specific Language) é o formato declarativo usado para descrever buscas, agregações e pontuação. O corpo de uma query é um documento JSON enviado para POST /index/_search com dois conceitos principais no topo: query (o que casar, com score) e filter (o que casar, sem score, cacheável).

Tipos de query que você usa de fato

  • match — full-text em campos analisados; aplica o mesmo analyzer da indexação.
  • term / terms — busca exata, sem análise; use em keyword, numéricos, datas e booleanos.
  • range — faixa numérica ou de data com gte, gt, lte, lt e format/time_zone opcionais.
  • bool — combinador com must, should, must_not e filter; o cavalo de batalha de qualquer busca real.
  • match_phrase / multi_match — busca por frase e busca em múltiplos campos com boost (title^3).
  • prefix, wildcard, regexp, fuzzy (Levenshtein) — casamento parcial e aproximado.
  • query_string / simple_query_string — mini-sintaxe completa do Lucene para usuários avançados.
  • exists, nested, has_child, geo_bounding_box — filtros estruturais e geográficos.

Filter vs Query e a história do scoring

Tudo dentro de filter ou must_not é uma pergunta sim/não e fica cacheado no bitset cache — é o que você quer para booleanos, datas e termos exatos. Tudo dentro de must ou should contribui para o score de relevância. O scoring padrão é o BM25 (desde o Elasticsearch 7), uma evolução do TF-IDF que lida melhor com saturação de termos e comprimento de documentos. Para boosting e re-ranking, use function_score com field_value_factor, script_score ou random_score.

Aggregations: GROUP BY do SQL com esteroides

As agregações se dividem em três famílias. Bucket agrupa documentos (terms, date_histogram, range, histogram, geohash_grid, filters, composite para drill-down paginado). Metric calcula valores (avg, sum, min, max, percentiles, cardinality, value_count, stats). Pipeline opera sobre o resultado de outras agregações (avg_bucket, derivative, moving_avg, cumulative_sum). Combinadas, são a base da maioria dos dashboards do Kibana.

Mapping, analyzers e a armadilha text vs keyword

O mapping é o schema do índice. A pegadinha clássica é a diferença entre text e keyword: text é analisado (lowercase, tokenização, eventual stemming), habilita full-text, mas não permite ordenação ou agregação sem fielddata: true; keyword guarda o valor literal e é a escolha certa para IDs, tags, enums e qualquer coisa que vá entrar em uma agregação terms. Um analyzer custom é uma cadeia de char_filtertokenizertoken_filter (lowercase, stop, stemmer, synonym, edge_ngram para autocomplete). O ILM (Index Lifecycle Management) rotaciona índices pelas fases hot, warm, cold, frozen e delete, e o cluster escala ajustando o número de shards primários e réplicas.

Como se compara às alternativas

O OpenSearch é o fork patrocinado pela AWS, nascido em 2021 quando a Elastic mudou para a licença SSPL; segue compatível em nível de API. O MongoDB Atlas Search embute o Lucene em clusters MongoDB, mas com superfície menor. O Algolia é uma alternativa totalmente gerenciada com latência em milissegundos e modelo de preços diferente. Meilisearch e Typesense são projetos mais novos que priorizam simplicidade, tolerância a typo instantânea e clusters pequenos.

Perguntas frequentes

É melhor que LIKE '%termo%' em SQL? Para full-text, está em outro nível: tokenização, stemming, ranking BM25, fuzziness, sinônimos e busca por frase ficam fora do alcance do LIKE.

O Elasticsearch suporta updates? Sim, mas parcialmente. Os segmentos do Lucene são imutáveis, então um update é implementado como delete + reindex do documento inteiro. Updates parciais frequentes fragmentam segmentos e forçam merges — faça bulk update com cuidado.

Por que paginação profunda (from + size além de 10 000) fica lenta? Cada shard precisa ranquear e devolver from + size documentos e o coordenador mescla — operação O(n). Para navegação profunda use search_after com um campo de desempate, ou as APIs scroll/point-in-time para exports com snapshot.

Dá para escrever SQL contra o Elasticsearch? Sim — o plugin oficial Elasticsearch SQL aceita um subconjunto de SQL e traduz para DSL por baixo. Excelente para analytics ad-hoc; em código de produção, prefira a DSL JSON.

Ferramentas Relacionadas