Geek Answers Handbook

How to find elasticsearch search result in query_string?

Is there a way to find out through the elasticsearch API how the query string query is actually parsed? You can do this manually by looking at the lucene query syntax , but it would be very nice if you could look at some representation of the actual results the analyzer has.

+8
elasticsearch lucene
source share
1 answer

Since javanna is mentioned in the comments, _ validate api. Here's what works on my local elastic (version 1.6):

curl -XGET 'http://localhost:9201/pl/_validate/query?explain&pretty' -d' { "query": { "query_string": { "query": "a OR (b AND c) OR (d AND NOT(e or f))", "default_field": "t" } } } '

pl is the name of the index in my cluster. Another index may have different analyzers, so the query is checked in the index area.

The result of the above curl is as follows:

 { "valid" : true, "_shards" : { "total" : 1, "successful" : 1, "failed" : 0 }, "explanations" : [ { "index" : "pl", "valid" : true, "explanation" : "filtered(t:a (+t:b +t:c) (+t:d -(t:et:or t:f)))->cache(org.elasticsearch.index.search.nested.NonNestedDocsFilter@ce2d82f1)" } ] }

I made one OR lower case, and as you can see in the explanation, it is interpreted as a token, not as an operator.

Regarding the interpretation of the explanation. The format is similar to the +- operators of the query string :

  • (i) characters start and end bool query
  • + prefix means a sentence that will be in must
  • - the prefix means the sentence, which will be in must_not
  • No prefix means it will be in should (with default_operator equal to OR )

Thus, the above will be equivalent to the following:

 { "bool" : { "should" : [ { "term" : { "t" : "a" } }, { "bool": { "must": [ { "term" : { "t" : "b" } }, { "term" : { "t" : "c" } } ] } }, { "bool": { "must": { "term" : { "t" : "d" } }, "must_not": { "bool": { "should": [ { "term" : { "t" : "e" } }, { "term" : { "t" : "or" } }, { "term" : { "t" : "f" } } ] } } } } ] } }

I used the _validate api pretty heavily to debug complex filtered requests with many conditions. This is especially useful if you want to check how the token parser is entered as a URL or if any filter is cached.

There's also an awesome rewrite parameter that I still didn't know about, which further explains the explanation of the actual Lucene request that will be executed.

+5
source share

More articles:


All Articles