terms-query.asciidoc 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
  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. "constant_score" : {
  11. "filter" : {
  12. "terms" : { "user" : ["kimchy", "elasticsearch"]}
  13. }
  14. }
  15. }
  16. }
  17. --------------------------------------------------
  18. // CONSOLE
  19. The `terms` query is also aliased with `in` as the filter name for
  20. simpler usage deprecated[5.0.0,use `terms` instead].
  21. [float]
  22. [[query-dsl-terms-lookup]]
  23. ===== Terms lookup mechanism
  24. When it's needed to specify a `terms` filter with a lot of terms it can
  25. be beneficial to fetch those term values from a document in an index. A
  26. concrete example would be to filter tweets tweeted by your followers.
  27. Potentially the amount of user ids specified in the terms filter can be
  28. a lot. In this scenario it makes sense to use the terms filter's terms
  29. lookup mechanism.
  30. The terms lookup mechanism supports the following options:
  31. [horizontal]
  32. `index`::
  33. The index to fetch the term values from. Defaults to the
  34. current index.
  35. `type`::
  36. The type to fetch the term values from.
  37. `id`::
  38. The id of the document to fetch the term values from.
  39. `path`::
  40. The field specified as path to fetch the actual values for the
  41. `terms` filter.
  42. `routing`::
  43. A custom routing value to be used when retrieving the
  44. external terms doc.
  45. The values for the `terms` filter will be fetched from a field in a
  46. document with the specified id in the specified type and index.
  47. Internally a get request is executed to fetch the values from the
  48. specified path. At the moment for this feature to work the `_source`
  49. needs to be stored.
  50. Also, consider using an index with a single shard and fully replicated
  51. across all nodes if the "reference" terms data is not large. The lookup
  52. terms filter will prefer to execute the get request on a local node if
  53. possible, reducing the need for networking.
  54. [float]
  55. ===== Terms lookup twitter example
  56. At first we index the information for user with id 2, specifically, its
  57. followers, than 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/user/2
  62. {
  63. "followers" : ["1", "3"]
  64. }
  65. PUT /tweets/tweet/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 array of
  85. inner objects, for example:
  86. [source,js]
  87. --------------------------------------------------
  88. curl -XPUT localhost:9200/users/user/2 -d '{
  89. "followers" : [
  90. {
  91. "id" : "1"
  92. },
  93. {
  94. "id" : "2"
  95. }
  96. ]
  97. }'
  98. --------------------------------------------------
  99. In which case, the lookup path will be `followers.id`.