terms-query.asciidoc 2.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113
  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. [float]
  48. ===== Terms lookup twitter example
  49. At first we index the information for user with id 2, specifically, its
  50. followers, then index a tweet from user with id 1. Finally we search on
  51. all the tweets that match the followers of user 2.
  52. [source,js]
  53. --------------------------------------------------
  54. PUT /users/user/2
  55. {
  56. "followers" : ["1", "3"]
  57. }
  58. PUT /tweets/tweet/1
  59. {
  60. "user" : "1"
  61. }
  62. GET /tweets/_search
  63. {
  64. "query" : {
  65. "terms" : {
  66. "user" : {
  67. "index" : "users",
  68. "type" : "user",
  69. "id" : "2",
  70. "path" : "followers"
  71. }
  72. }
  73. }
  74. }
  75. --------------------------------------------------
  76. // CONSOLE
  77. The structure of the external terms document can also include an array of
  78. inner objects, for example:
  79. [source,js]
  80. --------------------------------------------------
  81. PUT /users/user/2
  82. {
  83. "followers" : [
  84. {
  85. "id" : "1"
  86. },
  87. {
  88. "id" : "2"
  89. }
  90. ]
  91. }
  92. --------------------------------------------------
  93. // CONSOLE
  94. In which case, the lookup path will be `followers.id`.