query-string-query.asciidoc 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320
  1. [[query-dsl-query-string-query]]
  2. === Query String Query
  3. A query that uses a query parser in order to parse its content. Here is
  4. an example:
  5. [source,js]
  6. --------------------------------------------------
  7. GET /_search
  8. {
  9. "query": {
  10. "query_string" : {
  11. "default_field" : "content",
  12. "query" : "this AND that OR thus"
  13. }
  14. }
  15. }
  16. --------------------------------------------------
  17. // CONSOLE
  18. The `query_string` query parses the input and splits text around operators.
  19. Each textual part is analyzed independently of each other. For instance the following query:
  20. [source,js]
  21. --------------------------------------------------
  22. GET /_search
  23. {
  24. "query": {
  25. "query_string" : {
  26. "default_field" : "content",
  27. "query" : "(new york city) OR (big apple)"
  28. }
  29. }
  30. }
  31. --------------------------------------------------
  32. // CONSOLE
  33. ... will be split into `new york city` and `big apple` and each part is then
  34. analyzed independently by the analyzer configured for the field.
  35. WARNING: Whitespaces are not considered operators, this means that `new york city`
  36. will be passed "as is" to the analyzer configured for the field. If the field is a `keyword`
  37. field the analyzer will create a single term `new york city` and the query builder will
  38. use this term in the query. If you want to query each term separately you need to add explicit
  39. operators around the terms (e.g. `new AND york AND city`).
  40. When multiple fields are provided it is also possible to modify how the different
  41. field queries are combined inside each textual part using the `type` parameter.
  42. The possible modes are described <<multi-match-types, here>> and the default is `best_fields`.
  43. The `query_string` top level parameters include:
  44. [cols="<,<",options="header",]
  45. |=======================================================================
  46. |Parameter |Description
  47. |`query` |The actual query to be parsed. See <<query-string-syntax>>.
  48. |`default_field` |The default field for query terms if no prefix field is
  49. specified. Defaults to the `index.query.default_field` index settings, which in
  50. turn defaults to `*`. `*` extracts all fields in the mapping that are eligible
  51. to term queries and filters the metadata fields. All extracted fields are then
  52. combined to build a query when no prefix field is provided. There is a limit of
  53. no more than 1024 fields being queried at once.
  54. |`default_operator` |The default operator used if no explicit operator
  55. is specified. For example, with a default operator of `OR`, the query
  56. `capital of Hungary` is translated to `capital OR of OR Hungary`, and
  57. with default operator of `AND`, the same query is translated to
  58. `capital AND of AND Hungary`. The default value is `OR`.
  59. |`analyzer` |The analyzer name used to analyze the query string.
  60. |`quote_analyzer` |The name of the analyzer that is used to analyze
  61. quoted phrases in the query string. For those parts, it overrides other
  62. analyzers that are set using the `analyzer` parameter or the
  63. <<search-quote-analyzer,`search_quote_analyzer`>> setting.
  64. |`allow_leading_wildcard` |When set, `*` or `?` are allowed as the first
  65. character. Defaults to `true`.
  66. |`enable_position_increments` |Set to `true` to enable position
  67. increments in result queries. Defaults to `true`.
  68. |`fuzzy_max_expansions` |Controls the number of terms fuzzy queries will
  69. expand to. Defaults to `50`
  70. |`fuzziness` |Set the fuzziness for fuzzy queries. Defaults
  71. to `AUTO`. See <<fuzziness>> for allowed settings.
  72. |`fuzzy_prefix_length` |Set the prefix length for fuzzy queries. Default
  73. is `0`.
  74. |`fuzzy_transpositions` |Set to `false` to disable fuzzy transpositions (`ab` -> `ba`).
  75. Default is `true`.
  76. |`phrase_slop` |Sets the default slop for phrases. If zero, then exact
  77. phrase matches are required. Default value is `0`.
  78. |`boost` |Sets the boost value of the query. Defaults to `1.0`.
  79. |`analyze_wildcard` |By default, wildcards terms in a query string are
  80. not analyzed. By setting this value to `true`, a best effort will be
  81. made to analyze those as well.
  82. |`max_determinized_states` |Limit on how many automaton states regexp
  83. queries are allowed to create. This protects against too-difficult
  84. (e.g. exponentially hard) regexps. Defaults to 10000.
  85. |`minimum_should_match` |A value controlling how many "should" clauses
  86. in the resulting boolean query should match. It can be an absolute value
  87. (`2`), a percentage (`30%`) or a
  88. <<query-dsl-minimum-should-match,combination of
  89. both>>.
  90. |`lenient` |If set to `true` will cause format based failures (like
  91. providing text to a numeric field) to be ignored.
  92. |`time_zone` | Time Zone to be applied to any range query related to dates. See also
  93. http://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeZone.html[JODA timezone].
  94. |`quote_field_suffix` | A suffix to append to fields for quoted parts of
  95. the query string. This allows to use a field that has a different analysis chain
  96. for exact matching. Look <<mixing-exact-search-with-stemming,here>> for a
  97. comprehensive example.
  98. |`auto_generate_synonyms_phrase_query` |Whether phrase queries should be automatically generated for multi terms synonyms.
  99. Defaults to `true`.
  100. |=======================================================================
  101. When a multi term query is being generated, one can control how it gets
  102. rewritten using the
  103. <<query-dsl-multi-term-rewrite,rewrite>>
  104. parameter.
  105. [float]
  106. ==== Default Field
  107. When not explicitly specifying the field to search on in the query
  108. string syntax, the `index.query.default_field` will be used to derive
  109. which field to search on. If the `index.query.default_field` is not specified,
  110. the `query_string` will automatically attempt to determine the existing fields in the index's
  111. mapping that are queryable, and perform the search on those fields. Note that this will not
  112. include nested documents, use a nested query to search those documents.
  113. [float]
  114. ==== Multi Field
  115. The `query_string` query can also run against multiple fields. Fields can be
  116. provided via the `"fields"` parameter (example below).
  117. The idea of running the `query_string` query against multiple fields is to
  118. expand each query term to an OR clause like this:
  119. field1:query_term OR field2:query_term | ...
  120. For example, the following query
  121. [source,js]
  122. --------------------------------------------------
  123. GET /_search
  124. {
  125. "query": {
  126. "query_string" : {
  127. "fields" : ["content", "name"],
  128. "query" : "this AND that"
  129. }
  130. }
  131. }
  132. --------------------------------------------------
  133. // CONSOLE
  134. matches the same words as
  135. [source,js]
  136. --------------------------------------------------
  137. GET /_search
  138. {
  139. "query": {
  140. "query_string": {
  141. "query": "(content:this OR name:this) AND (content:that OR name:that)"
  142. }
  143. }
  144. }
  145. --------------------------------------------------
  146. // CONSOLE
  147. Since several queries are generated from the individual search terms,
  148. combining them is automatically done using a `dis_max` query with a tie_breaker.
  149. For example (the `name` is boosted by 5 using `^5` notation):
  150. [source,js]
  151. --------------------------------------------------
  152. GET /_search
  153. {
  154. "query": {
  155. "query_string" : {
  156. "fields" : ["content", "name^5"],
  157. "query" : "this AND that OR thus",
  158. "tie_breaker" : 0
  159. }
  160. }
  161. }
  162. --------------------------------------------------
  163. // CONSOLE
  164. Simple wildcard can also be used to search "within" specific inner
  165. elements of the document. For example, if we have a `city` object with
  166. several fields (or inner object with fields) in it, we can automatically
  167. search on all "city" fields:
  168. [source,js]
  169. --------------------------------------------------
  170. GET /_search
  171. {
  172. "query": {
  173. "query_string" : {
  174. "fields" : ["city.*"],
  175. "query" : "this AND that OR thus"
  176. }
  177. }
  178. }
  179. --------------------------------------------------
  180. // CONSOLE
  181. Another option is to provide the wildcard fields search in the query
  182. string itself (properly escaping the `*` sign), for example:
  183. `city.\*:something`:
  184. [source,js]
  185. --------------------------------------------------
  186. GET /_search
  187. {
  188. "query": {
  189. "query_string" : {
  190. "query" : "city.\\*:(this AND that OR thus)"
  191. }
  192. }
  193. }
  194. --------------------------------------------------
  195. // CONSOLE
  196. NOTE: Since `\` (backslash) is a special character in json strings, it needs to
  197. be escaped, hence the two backslashes in the above `query_string`.
  198. When running the `query_string` query against multiple fields, the
  199. following additional parameters are allowed:
  200. [cols="<,<",options="header",]
  201. |=======================================================================
  202. |Parameter |Description
  203. |`type` |How the fields should be combined to build the text query.
  204. See <<multi-match-types, types>> for a complete example.
  205. Defaults to `best_fields`
  206. |=======================================================================
  207. [cols="<,<",options="header",]
  208. |=======================================================================
  209. |Parameter |Description
  210. |`tie_breaker` |The disjunction max tie breaker for multi fields.
  211. Defaults to `0`
  212. |=======================================================================
  213. The fields parameter can also include pattern based field names,
  214. allowing to automatically expand to the relevant fields (dynamically
  215. introduced fields included). For example:
  216. [source,js]
  217. --------------------------------------------------
  218. GET /_search
  219. {
  220. "query": {
  221. "query_string" : {
  222. "fields" : ["content", "name.*^5"],
  223. "query" : "this AND that OR thus"
  224. }
  225. }
  226. }
  227. --------------------------------------------------
  228. // CONSOLE
  229. [float]
  230. ==== Synonyms
  231. The `query_string` query supports multi-terms synonym expansion with the <<analysis-synonym-graph-tokenfilter,
  232. synonym_graph>> token filter. When this filter is used, the parser creates a phrase query for each multi-terms synonyms.
  233. For example, the following synonym: `"ny, new york" would produce:`
  234. `(ny OR ("new york"))`
  235. It is also possible to match multi terms synonyms with conjunctions instead:
  236. [source,js]
  237. --------------------------------------------------
  238. GET /_search
  239. {
  240. "query": {
  241. "query_string" : {
  242. "default_field": "title",
  243. "query" : "ny city",
  244. "auto_generate_synonyms_phrase_query" : false
  245. }
  246. }
  247. }
  248. --------------------------------------------------
  249. // CONSOLE
  250. The example above creates a boolean query:
  251. `(ny OR (new AND york)) city`
  252. that matches documents with the term `ny` or the conjunction `new AND york`.
  253. By default the parameter `auto_generate_synonyms_phrase_query` is set to `true`.
  254. include::query-string-syntax.asciidoc[]