term-query.asciidoc 4.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166
  1. [[query-dsl-term-query]]
  2. === Term Query
  3. The `term` query finds documents that contain the *exact* term specified
  4. in the inverted index. For instance:
  5. [source,js]
  6. --------------------------------------------------
  7. {
  8. "term" : { "user" : "Kimchy" } <1>
  9. }
  10. --------------------------------------------------
  11. <1> Finds documents which contain the exact term `Kimchy` in the inverted index
  12. of the `user` field.
  13. A `boost` parameter can be specified to give this `term` query a higher
  14. relevance score than another query, for instance:
  15. [source,js]
  16. --------------------------------------------------
  17. GET /_search
  18. {
  19. "query": {
  20. "bool": {
  21. "should": [
  22. {
  23. "term": {
  24. "status": {
  25. "value": "urgent",
  26. "boost": 2.0 <1>
  27. }
  28. }
  29. },
  30. {
  31. "term": {
  32. "status": "normal" <2>
  33. }
  34. }
  35. ]
  36. }
  37. }
  38. }
  39. --------------------------------------------------
  40. <1> The `urgent` query clause has a boost of `2.0`, meaning it is twice as important
  41. as the query clause for `normal`.
  42. <2> The `normal` clause has the default neutral boost of `1.0`.
  43. .Why doesn't the `term` query match my document?
  44. **************************************************
  45. String fields can be `analyzed` (treated as full text, like the body of an
  46. email), or `not_analyzed` (treated as exact values, like an email address or a
  47. zip code). Exact values (like numbers, dates, and `not_analyzed` strings) have
  48. the exact value specified in the field added to the inverted index in order
  49. to make them searchable.
  50. By default, however, `string` fields are `analyzed`. This means that their
  51. values are first passed through an <<analysis,analyzer>> to produce a list of
  52. terms, which are then added to the inverted index.
  53. There are many ways to analyze text: the default
  54. <<analysis-standard-analyzer,`standard` analyzer>> drops most punctuation,
  55. breaks up text into individual words, and lower cases them. For instance,
  56. the `standard` analyzer would turn the string ``Quick Brown Fox!'' into the
  57. terms [`quick`, `brown`, `fox`].
  58. This analysis process makes it possible to search for individual words
  59. within a big block of full text.
  60. The `term` query looks for the *exact* term in the field's inverted index --
  61. it doesn't know anything about the field's analyzer. This makes it useful for
  62. looking up values in `not_analyzed` string fields, or in numeric or date
  63. fields. When querying full text fields, use the
  64. <<query-dsl-match-query,`match` query>> instead, which understands how the field
  65. has been analyzed.
  66. To demonstrate, try out the example below. First, create an index, specifying the field mappings, and index a document:
  67. [source,js]
  68. --------------------------------------------------
  69. PUT my_index
  70. {
  71. "mappings": {
  72. "my_type": {
  73. "properties": {
  74. "full_text": {
  75. "type": "string" <1>
  76. },
  77. "exact_value": {
  78. "type": "string",
  79. "index": "not_analyzed" <2>
  80. }
  81. }
  82. }
  83. }
  84. }
  85. PUT my_index/my_type/1
  86. {
  87. "full_text": "Quick Foxes!", <3>
  88. "exact_value": "Quick Foxes!" <4>
  89. }
  90. --------------------------------------------------
  91. // AUTOSENSE
  92. <1> The `full_text` field is `analyzed` by default.
  93. <2> The `exact_value` field is set to be `not_analyzed`.
  94. <3> The `full_text` inverted index will contain the terms: [`quick`, `foxes`].
  95. <4> The `exact_value` inverted index will contain the exact term: [`Quick Foxes!`].
  96. Now, compare the results for the `term` query and the `match` query:
  97. [source,js]
  98. --------------------------------------------------
  99. GET my_index/my_type/_search
  100. {
  101. "query": {
  102. "term": {
  103. "exact_value": "Quick Foxes!" <1>
  104. }
  105. }
  106. }
  107. GET my_index/my_type/_search
  108. {
  109. "query": {
  110. "term": {
  111. "full_text": "Quick Foxes!" <2>
  112. }
  113. }
  114. }
  115. GET my_index/my_type/_search
  116. {
  117. "query": {
  118. "term": {
  119. "exact_value": "foxes" <3>
  120. }
  121. }
  122. }
  123. GET my_index/my_type/_search
  124. {
  125. "query": {
  126. "match": {
  127. "full_text": "Quick Foxes!" <4>
  128. }
  129. }
  130. }
  131. --------------------------------------------------
  132. // AUTOSENSE
  133. <1> This query matches because the `exact_value` field contains the exact
  134. term `Quick Foxes!`.
  135. <2> This query does not match, because the `full_text` field only contains
  136. the terms `quick` and `foxes`. It does not contain the exact term
  137. `Quick Foxes!`.
  138. <3> A `term` query for the term `foxes` matches the `full_text` field.
  139. <4> This `match` query on the `full_text` field first analyzes the query string,
  140. then looks for documents containing `quick` or `foxes` or both.
  141. **************************************************