terms-query.asciidoc 3.0 KB

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