A query that uses a query parser in order to parse its content. Here is an example:
GET /_search
{
"query": {
"query_string" : {
"default_field" : "content",
"query" : "this AND that OR thus"
}
}
}The query_string query parses the input and splits text around operators.
Each textual part is analyzed independently of each other. For instance the following query:
GET /_search
{
"query": {
"query_string" : {
"default_field" : "content",
"query" : "(new york city) OR (big apple)" 
}
}
}
|
will be split into |
Whitespaces are not considered operators, this means that new york city
will be passed "as is" to the analyzer configured for the field. If the field is a keyword
field the analyzer will create a single term new york city and the query builder will
use this term in the query. If you want to query each term separately you need to add explicit
operators around the terms (e.g. new AND york AND city).
When multiple fields are provided it is also possible to modify how the different
field queries are combined inside each textual part using the type parameter.
The possible modes are described here and the default is best_fields.
The query_string top level parameters include:
| Parameter | Description |
|---|---|
| The actual query to be parsed. See Query string syntax. |
| The default field for query terms if no prefix field is
specified. Defaults to the WARNING: There is a limit on the number of fields that can be queried
at once. It is defined by the |
| The default operator used if no explicit operator
is specified. For example, with a default operator of |
| The analyzer name used to analyze the query string. |
| The name of the analyzer that is used to analyze
quoted phrases in the query string. For those parts, it overrides other
analyzers that are set using the |
| When set, |
| Set to |
| Controls the number of terms fuzzy queries will
expand to. Defaults to |
| Set the fuzziness for fuzzy queries. Defaults
to |
| Set the prefix length for fuzzy queries. Default
is |
| Set to |
| Sets the default slop for phrases. If zero, then exact
phrase matches are required. Default value is |
| Sets the boost value of the query. Defaults to |
| By default, wildcards terms in a query string are
not analyzed. By setting this value to |
| Limit on how many automaton states regexp queries are allowed to create. This protects against too-difficult (e.g. exponentially hard) regexps. Defaults to 10000. |
| A value controlling how many "should" clauses
in the resulting boolean query should match. It can be an absolute value
( |
| If set to |
| Time Zone to be applied to any range query related to dates. |
| A suffix to append to fields for quoted parts of the query string. This allows to use a field that has a different analysis chain for exact matching. Look here for a comprehensive example. |
| Whether phrase queries should be automatically generated for multi terms synonyms.
Defaults to |
When a multi term query is being generated, one can control how it gets rewritten using the rewrite parameter.
Default Field
When not explicitly specifying the field to search on in the query
string syntax, the index.query.default_field will be used to derive
which field to search on. If the index.query.default_field is not specified,
the query_string will automatically attempt to determine the existing fields in the index’s
mapping that are queryable, and perform the search on those fields.
This will not include nested documents, use a nested query to search those documents.
For mappings with a large number of fields, searching across all queryable fields in the mapping could be expensive.
Multi Field
The query_string query can also run against multiple fields. Fields can be
provided via the fields parameter (example below).
The idea of running the query_string query against multiple fields is to
expand each query term to an OR clause like this:
field1:query_term OR field2:query_term | ...
For example, the following query
GET /_search
{
"query": {
"query_string" : {
"fields" : ["content", "name"],
"query" : "this AND that"
}
}
}matches the same words as
GET /_search
{
"query": {
"query_string": {
"query": "(content:this OR name:this) AND (content:that OR name:that)"
}
}
}Since several queries are generated from the individual search terms,
combining them is automatically done using a dis_max query with a tie_breaker.
For example (the name is boosted by 5 using ^5 notation):
GET /_search
{
"query": {
"query_string" : {
"fields" : ["content", "name^5"],
"query" : "this AND that OR thus",
"tie_breaker" : 0
}
}
}Simple wildcard can also be used to search "within" specific inner
elements of the document. For example, if we have a city object with
several fields (or inner object with fields) in it, we can automatically
search on all "city" fields:
GET /_search
{
"query": {
"query_string" : {
"fields" : ["city.*"],
"query" : "this AND that OR thus"
}
}
}Another option is to provide the wildcard fields search in the query
string itself (properly escaping the * sign), for example:
city.\*:something:
GET /_search
{
"query": {
"query_string" : {
"query" : "city.\\*:(this AND that OR thus)"
}
}
}Since \ (backslash) is a special character in json strings, it needs to
be escaped, hence the two backslashes in the above query_string.
When running the query_string query against multiple fields, the
following additional parameters are allowed:
| Parameter | Description |
|---|---|
| How the fields should be combined to build the text query.
See types for a complete example.
Defaults to |
| The disjunction max tie breaker for multi fields.
Defaults to |
The fields parameter can also include pattern based field names, allowing to automatically expand to the relevant fields (dynamically introduced fields included). For example:
GET /_search
{
"query": {
"query_string" : {
"fields" : ["content", "name.*^5"],
"query" : "this AND that OR thus"
}
}
}Synonyms
The query_string query supports multi-terms synonym expansion with the synonym_graph token filter. When this filter is used, the parser creates a phrase query for each multi-terms synonyms.
For example, the following synonym: ny, new york would produce:
(ny OR ("new york"))
It is also possible to match multi terms synonyms with conjunctions instead:
GET /_search
{
"query": {
"query_string" : {
"default_field": "title",
"query" : "ny city",
"auto_generate_synonyms_phrase_query" : false
}
}
}The example above creates a boolean query:
(ny OR (new AND york)) city
that matches documents with the term ny or the conjunction new AND york.
By default the parameter auto_generate_synonyms_phrase_query is set to true.
Minimum should match
The query_string splits the query around each operator to create a boolean
query for the entire input. You can use minimum_should_match to control how
many "should" clauses in the resulting query should match.
GET /_search
{
"query": {
"query_string": {
"fields": [
"title"
],
"query": "this that thus",
"minimum_should_match": 2
}
}
}The example above creates a boolean query:
(title:this title:that title:thus)~2
that matches documents with at least two of the terms this, that or thus
in the single field title.
Multi Field
GET /_search
{
"query": {
"query_string": {
"fields": [
"title",
"content"
],
"query": "this that thus",
"minimum_should_match": 2
}
}
}The example above creates a boolean query:
((content:this content:that content:thus) | (title:this title:that title:thus))
that matches documents with the disjunction max over the fields title and
content. Here the minimum_should_match parameter can’t be applied.
GET /_search
{
"query": {
"query_string": {
"fields": [
"title",
"content"
],
"query": "this OR that OR thus",
"minimum_should_match": 2
}
}
}Adding explicit operators forces each term to be considered as a separate clause.
The example above creates a boolean query:
((content:this | title:this) (content:that | title:that) (content:thus | title:thus))~2
that matches documents with at least two of the three "should" clauses, each of them made of the disjunction max over the fields for each term.
Cross Field
GET /_search
{
"query": {
"query_string": {
"fields": [
"title",
"content"
],
"query": "this OR that OR thus",
"type": "cross_fields",
"minimum_should_match": 2
}
}
}The cross_fields value in the type field indicates that fields that have the
same analyzer should be grouped together when the input is analyzed.
The example above creates a boolean query:
(blended(terms:[field2:this, field1:this]) blended(terms:[field2:that, field1:that]) blended(terms:[field2:thus, field1:thus]))~2
that matches documents with at least two of the three per-term blended queries.
The query string “mini-language” is used by the
Query String Query and by the
q query string parameter in the search API.
The query string is parsed into a series of terms and operators. A
term can be a single word — quick or brown — or a phrase, surrounded by
double quotes — "quick brown" — which searches for all the words in the
phrase, in the same order.
Operators allow you to customize the search — the available options are explained below.
As mentioned in Query String Query, the default_field is searched for the
search terms, but it is possible to specify other fields in the query syntax:
where the
statusfield containsactivestatus:active
where the
titlefield containsquickorbrowntitle:(quick OR brown)
where the
authorfield contains the exact phrase"john smith"author:"John Smith"
where any of the fields
book.title,book.contentorbook.datecontainsquickorbrown(note how we need to escape the*with a backslash):book.\*:(quick OR brown)
where the field
titlehas any non-null value:_exists_:title
Wildcard searches can be run on individual terms, using ? to replace
a single character, and * to replace zero or more characters:
qu?ck bro*
Be aware that wildcard queries can use an enormous amount of memory and
perform very badly — just think how many terms need to be queried to
match the query string "a* b* c*".
Pure wildcards \* are rewritten to exists queries for efficiency.
As a consequence, the wildcard "field:*" would match documents with an empty value
like the following:
```
{
"field": ""
}
```
... and would not match if the field is missing or set with an explicit null
value like the following:
```
{
"field": null
}
```
Allowing a wildcard at the beginning of a word (eg "*ing") is particularly
heavy, because all terms in the index need to be examined, just in case
they match. Leading wildcards can be disabled by setting
allow_leading_wildcard to false.
Only parts of the analysis chain that operate at the character level are applied. So for instance, if the analyzer performs both lowercasing and stemming, only the lowercasing will be applied: it would be wrong to perform stemming on a word that is missing some of its letters.
By setting analyze_wildcard to true, queries that end with a * will be
analyzed and a boolean query will be built out of the different tokens, by
ensuring exact matches on the first N-1 tokens, and prefix match on the last
token.
Regular expression patterns can be embedded in the query string by
wrapping them in forward-slashes ("/"):
name:/joh?n(ath[oa]n)/
The supported regular expression syntax is explained in Regular expression syntax.
The allow_leading_wildcard parameter does not have any control over
regular expressions. A query string such as the following would force
Elasticsearch to visit every term in the index:
/.*n/
Use with caution!
We can search for terms that are similar to, but not exactly like our search terms, using the “fuzzy” operator:
quikc~ brwn~ foks~
This uses the Damerau-Levenshtein distance to find all terms with a maximum of two changes, where a change is the insertion, deletion or substitution of a single character, or transposition of two adjacent characters.
The default edit distance is 2, but an edit distance of 1 should be
sufficient to catch 80% of all human misspellings. It can be specified as:
quikc~1
While a phrase query (eg "john smith") expects all of the terms in exactly
the same order, a proximity query allows the specified words to be further
apart or in a different order. In the same way that fuzzy queries can
specify a maximum edit distance for characters in a word, a proximity search
allows us to specify a maximum edit distance of words in a phrase:
"fox quick"~5
The closer the text in a field is to the original order specified in the
query string, the more relevant that document is considered to be. When
compared to the above example query, the phrase "quick fox" would be
considered more relevant than "quick brown fox".
Ranges can be specified for date, numeric or string fields. Inclusive ranges
are specified with square brackets [min TO max] and exclusive ranges with
curly brackets {min TO max}.
All days in 2012:
date:[2012-01-01 TO 2012-12-31]
Numbers 1..5
count:[1 TO 5]
Tags between
alphaandomega, excludingalphaandomega:tag:{alpha TO omega}Numbers from 10 upwards
count:[10 TO *]
Dates before 2012
date:{* TO 2012-01-01}
Curly and square brackets can be combined:
Numbers from 1 up to but not including 5
count:[1 TO 5}
Ranges with one side unbounded can use the following syntax:
age:>10 age:>=10 age:<10 age:<=10
To combine an upper and lower bound with the simplified syntax, you
would need to join two clauses with an AND operator:
age:(>=10 AND <20) age:(+>=10 +<20)
The parsing of ranges in query strings can be complex and error prone. It is
much more reliable to use an explicit range query.
Use the boost operator ^ to make one term more relevant than another.
For instance, if we want to find all documents about foxes, but we are
especially interested in quick foxes:
quick^2 fox
The default boost value is 1, but can be any positive floating point number.
Boosts between 0 and 1 reduce relevance.
Boosts can also be applied to phrases or to groups:
"john smith"^2 (foo bar)^4
By default, all terms are optional, as long as one term matches. A search
for foo bar baz will find any document that contains one or more of
foo or bar or baz. We have already discussed the default_operator
above which allows you to force all terms to be required, but there are
also boolean operators which can be used in the query string itself
to provide more control.
The preferred operators are + (this term must be present) and -
(this term must not be present). All other terms are optional.
For example, this query:
quick brown +fox -news
states that:
-
foxmust be present -
newsmust not be present -
quickandbrownare optional — their presence increases the relevance
The familiar boolean operators AND, OR and NOT (also written &&, ||
and !) are also supported but beware that they do not honor the usual
precedence rules, so parentheses should be used whenever multiple operators are
used together. For instance the previous query could be rewritten as:
-
((quick AND fox) OR (brown AND fox) OR fox) AND NOT news - This form now replicates the logic from the original query correctly, but the relevance scoring bears little resemblance to the original.
In contrast, the same query rewritten using the match query
would look like this:
{
"bool": {
"must": { "match": "fox" },
"should": { "match": "quick brown" },
"must_not": { "match": "news" }
}
}Multiple terms or clauses can be grouped together with parentheses, to form sub-queries:
(quick OR brown) AND fox
Groups can be used to target a particular field, or to boost the result of a sub-query:
status:(active OR pending) title:(full text search)^2
If you need to use any of the characters which function as operators in your
query itself (and not as operators), then you should escape them with
a leading backslash. For instance, to search for (1+1)=2, you would
need to write your query as \(1\+1\)\=2.
The reserved characters are: + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /
Failing to escape these special characters correctly could lead to a syntax error which prevents your query from running.
< and > can’t be escaped at all. The only way to prevent them from
attempting to create a range query is to remove them from the query string
entirely.