1
0

search.asciidoc 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189
  1. [[search]]
  2. == Search APIs
  3. Most search APIs support <<search-multi-index,multi-target syntax>>, with the
  4. exception of the <<search-explain>> endpoints.
  5. [discrete]
  6. [[search-routing]]
  7. === Routing
  8. When executing a search, Elasticsearch will pick the "best" copy of the data
  9. based on the <<search-adaptive-replica,adaptive replica selection>> formula.
  10. Which shards will be searched on can also be controlled by providing the
  11. `routing` parameter.
  12. For example, the following indexing request routes documents to shard `1`:
  13. [source,console]
  14. --------------------------------------------------
  15. POST /my-index-000001/_doc?routing=1
  16. {
  17. "@timestamp": "2099-11-15T13:12:00",
  18. "message": "GET /search HTTP/1.1 200 1070000",
  19. "user": {
  20. "id": "kimchy"
  21. }
  22. }
  23. --------------------------------------------------
  24. Later, you can use the `routing` parameter in a search request to search only
  25. the specified shard. The following search requests hits only shard `1`.
  26. [source,console]
  27. --------------------------------------------------
  28. POST /my-index-000001/_search?routing=1
  29. {
  30. "query": {
  31. "bool": {
  32. "must": {
  33. "query_string": {
  34. "query": "some query string here"
  35. }
  36. },
  37. "filter": {
  38. "term": { "user.id": "kimchy" }
  39. }
  40. }
  41. }
  42. }
  43. --------------------------------------------------
  44. // TEST[continued]
  45. The routing parameter can be multi valued represented as a comma
  46. separated string. This will result in hitting the relevant shards where
  47. the routing values match to.
  48. [discrete]
  49. [[search-adaptive-replica]]
  50. === Adaptive Replica Selection
  51. By default, Elasticsearch will use what is called adaptive replica selection.
  52. This allows the coordinating node to send the request to the copy deemed "best"
  53. based on a number of criteria:
  54. - Response time of past requests between the coordinating node and the node
  55. containing the copy of the data
  56. - Time past search requests took to execute on the node containing the data
  57. - The queue size of the search threadpool on the node containing the data
  58. This can be turned off by changing the dynamic cluster setting
  59. `cluster.routing.use_adaptive_replica_selection` from `true` to `false`:
  60. [source,console]
  61. --------------------------------------------------
  62. PUT /_cluster/settings
  63. {
  64. "transient": {
  65. "cluster.routing.use_adaptive_replica_selection": false
  66. }
  67. }
  68. --------------------------------------------------
  69. If adaptive replica selection is turned off, searches are sent to the
  70. index/indices shards in a round robin fashion between all copies of the data
  71. (primaries and replicas).
  72. [discrete]
  73. [[stats-groups]]
  74. === Stats Groups
  75. A search can be associated with stats groups, which maintains a
  76. statistics aggregation per group. It can later be retrieved using the
  77. <<indices-stats,indices stats>> API
  78. specifically. For example, here is a search body request that associate
  79. the request with two different groups:
  80. [source,console]
  81. --------------------------------------------------
  82. POST /_search
  83. {
  84. "query" : {
  85. "match_all" : {}
  86. },
  87. "stats" : ["group1", "group2"]
  88. }
  89. --------------------------------------------------
  90. // TEST[setup:my_index]
  91. [discrete]
  92. [[global-search-timeout]]
  93. === Global Search Timeout
  94. Individual searches can have a timeout as part of the
  95. <<search-request-body>>. Since search requests can originate from many
  96. sources, Elasticsearch has a dynamic cluster-level setting for a global
  97. search timeout that applies to all search requests that do not set a
  98. timeout in the request body. These requests will be cancelled after
  99. the specified time using the mechanism described in the following section on
  100. <<global-search-cancellation>>. Therefore the same caveats about timeout
  101. responsiveness apply.
  102. The setting key is `search.default_search_timeout` and can be set using the
  103. <<cluster-update-settings>> endpoints. The default value is no global timeout.
  104. Setting this value to `-1` resets the global search timeout to no timeout.
  105. [discrete]
  106. [[global-search-cancellation]]
  107. === Search Cancellation
  108. Searches can be cancelled using standard <<task-cancellation,task cancellation>>
  109. mechanism and are also automatically cancelled when the http connection used to
  110. perform the request is closed by the client. It is fundamental that the http
  111. client sending requests closes connections whenever requests time out or are
  112. aborted.
  113. [discrete]
  114. [[search-concurrency-and-parallelism]]
  115. === Search concurrency and parallelism
  116. By default Elasticsearch doesn't reject any search requests based on the number
  117. of shards the request hits. While Elasticsearch will optimize the search
  118. execution on the coordinating node a large number of shards can have a
  119. significant impact CPU and memory wise. It is usually a better idea to organize
  120. data in such a way that there are fewer larger shards. In case you would like to
  121. configure a soft limit, you can update the `action.search.shard_count.limit`
  122. cluster setting in order to reject search requests that hit too many shards.
  123. The request parameter `max_concurrent_shard_requests` can be used to control the
  124. maximum number of concurrent shard requests the search API will execute per node
  125. for the request. This parameter should be used to protect a single request from
  126. overloading a cluster (e.g., a default request will hit all indices in a cluster
  127. which could cause shard request rejections if the number of shards per node is
  128. high). This default value is `5`.
  129. include::search/search.asciidoc[]
  130. include::search/request-body.asciidoc[]
  131. include::search/async-search.asciidoc[]
  132. include::search/scroll-api.asciidoc[]
  133. include::search/clear-scroll-api.asciidoc[]
  134. include::search/search-template.asciidoc[]
  135. include::search/search-shards.asciidoc[]
  136. include::search/suggesters.asciidoc[]
  137. include::search/multi-search.asciidoc[]
  138. include::eql/eql-search-api.asciidoc[]
  139. include::eql/get-async-eql-search-api.asciidoc[]
  140. include::eql/delete-async-eql-search-api.asciidoc[]
  141. include::search/count.asciidoc[]
  142. include::search/validate.asciidoc[]
  143. include::search/explain.asciidoc[]
  144. include::search/profile.asciidoc[]
  145. include::search/field-caps.asciidoc[]
  146. include::search/rank-eval.asciidoc[]