terms-query.asciidoc 3.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121
  1. [[query-dsl-terms-query]]
  2. === Terms Query
  3. Filters documents that have fields that match any of the provided terms
  4. (*not analyzed*). For example:
  5. [source,js]
  6. --------------------------------------------------
  7. GET /_search
  8. {
  9. "query": {
  10. "terms" : { "user" : ["kimchy", "elasticsearch"]}
  11. }
  12. }
  13. --------------------------------------------------
  14. // CONSOLE
  15. [float]
  16. [[query-dsl-terms-lookup]]
  17. ===== Terms lookup mechanism
  18. When it's needed to specify a `terms` filter with a lot of terms it can
  19. be beneficial to fetch those term values from a document in an index. A
  20. concrete example would be to filter tweets tweeted by your followers.
  21. Potentially the amount of user ids specified in the terms filter can be
  22. a lot. In this scenario it makes sense to use the terms filter's terms
  23. lookup mechanism.
  24. The terms lookup mechanism supports the following options:
  25. [horizontal]
  26. `index`::
  27. The index to fetch the term values from.
  28. `type`::
  29. The type to fetch the term values from.
  30. `id`::
  31. The id of the document to fetch the term values from.
  32. `path`::
  33. The field specified as path to fetch the actual values for the
  34. `terms` filter.
  35. `routing`::
  36. A custom routing value to be used when retrieving the
  37. external terms doc.
  38. The values for the `terms` filter will be fetched from a field in a
  39. document with the specified id in the specified type and index.
  40. Internally a get request is executed to fetch the values from the
  41. specified path. At the moment for this feature to work the `_source`
  42. needs to be stored.
  43. Also, consider using an index with a single shard and fully replicated
  44. across all nodes if the "reference" terms data is not large. The lookup
  45. terms filter will prefer to execute the get request on a local node if
  46. possible, reducing the need for networking.
  47. [WARNING]
  48. Executing a Terms Query request with a lot of terms can be quite slow,
  49. as each additional term demands extra processing and memory.
  50. To safeguard against this, the maximum number of terms that can be used
  51. in a Terms Query both directly or through lookup has been limited to `65536`.
  52. This default maximum can be changed for a particular index with the index setting
  53. `index.max_terms_count`.
  54. [float]
  55. ===== Terms lookup twitter example
  56. At first we index the information for user with id 2, specifically, its
  57. followers, then index a tweet from user with id 1. Finally we search on
  58. all the tweets that match the followers of user 2.
  59. [source,js]
  60. --------------------------------------------------
  61. PUT /users/_doc/2
  62. {
  63. "followers" : ["1", "3"]
  64. }
  65. PUT /tweets/_doc/1
  66. {
  67. "user" : "1"
  68. }
  69. GET /tweets/_search
  70. {
  71. "query" : {
  72. "terms" : {
  73. "user" : {
  74. "index" : "users",
  75. "type" : "user",
  76. "id" : "2",
  77. "path" : "followers"
  78. }
  79. }
  80. }
  81. }
  82. --------------------------------------------------
  83. // CONSOLE
  84. The structure of the external terms document can also include an array of
  85. inner objects, for example:
  86. [source,js]
  87. --------------------------------------------------
  88. PUT /users/_doc/2
  89. {
  90. "followers" : [
  91. {
  92. "id" : "1"
  93. },
  94. {
  95. "id" : "2"
  96. }
  97. ]
  98. }
  99. --------------------------------------------------
  100. // CONSOLE
  101. In which case, the lookup path will be `followers.id`.