Search API

大部分查询的 API 都是多索引方式的，除了 explain api；

路由

当执行一个查询，它将会广播到所有的索引分片中（副本之间为轮询方式）。可以通过使用routing 参数控制查询哪个分片。如：当索引 tweets，routing 的值可以为用户的名称：

  1. curl -X POST "localhost:9200/twitter/_doc?routing=kimchy&pretty" -H 'Content-Type: application/json' -d'
  2. {
  3.     "user" : "kimchy",
  4.     "postDate" : "2009-11-15T14:12:12",
  5.     "message" : "trying out Elasticsearch"
  6. }
  7. '

这种情形下，如果想要查询特定用户的 tweets，可以指定 routing 参数，就只会有相关分片的查询结果。

  1. curl -X POST "localhost:9200/twitter/_search?routing=kimchy&pretty" -H 'Content-Type: application/json' -d'
  2. {
  3.     "query": {
  4.         "bool" : {
  5.             "must" : {
  6.                 "query_string" : {
  7.                     "query" : "some query string here"
  8.                 }
  9.             },
  10.             "filter" : {
  11.                 "term" : { "user" : "kimchy" }
  12.             }
  13.         }
  14.     }
  15. }
  16. '

路由参数可以是用逗号分隔的多个值，这将会返回路由值匹配的多个分片中的值；

自适应副本选择

除了对副本进行轮询方式，还可以选择对副本进行自适应选择。这将会使协调节点基于以下的标准把请求发送到最佳的副本：

  • 基于过去的请求中协调节点与数据副本节点的响应时间；
  • 请求在数据节点上搜索所花费的时间；
  • 数据节点上搜索线程池队列的大小；

这个可以通过更改动态集群设置，将cluster.routing.use_adaptive_replica_selection 从 false to true;

  1. curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
  2. {
  3.     "transient": {
  4.         "cluster.routing.use_adaptive_replica_selection": true
  5.     }
  6. }
  7. '

统计组（不太明白）

一个查询可以与统计组信息相关，从而维护每个组的统计信息汇总。以后可以通过indices stats API专门获取。如下是将一个请求关联到两个不同组的查询体示例：

  1. POST /_search
  2. {
  3.     "query" : {
  4.         "match_all" : {}
  5.     },
  6.     "stats" : ["group1", "group2"]
  7. }

全局查询超时

个别请求可以在请求正文中包含超时设置，由于搜索请求可能来自许多源，es 有一个动态的集群级别的全局查询超时时间，可以应用在没有在请求体中设置过超时的请求。默认并没有全局超时。设置的键是 search.default_search_timeout，可以通过使用集群更新的端点来设置。设置该值为 -1 会重置全局超时时间为无。

查询取消

查询可以使用标准的任务取消机制来取消。默认情况下，正在运行中的查询仅仅会检查是否在段边界上被取消，因此，取消行为可能会因为大的段延迟。
The search cancellation responsiveness can be improved by setting the dynamic cluster-level setting search.low_level_cancellation to true. However, it comes with an additional overhead of more frequent cancellation checks that can be noticeable on large fast running search queries. Changing this setting only affects the searches that start after the change is made.

搜索并发核并行

By default Elasticsearch doesn’t reject any search requests based on the number of shards the request hits. While Elasticsearch will optimize the search execution on the coordinating node a large number of shards can have a significant impact CPU and memory wise. It is usually a better idea to organize data in such a way that there are fewer larger shards. In case you would like to configure a soft limit, you can update the action.search.shard_count.limit cluster setting in order to reject search requests that hit too many shards.

The request parameter max_concurrent_shard_requests can be used to control the maximum number of concurrent shard requests the search API will execute for the request. This parameter should be used to protect a single request from overloading a cluster (e.g., a default request will hit all indices in a cluster which could cause shard request rejections if the number of shards per node is high). This default is based on the number of data nodes in the cluster but at most 256

慢查询日志配置

  1. PUT /my_index/_settings
  2. {
  3.     "index.search.slowlog.threshold.query.warn" : "10s", 
  4.     "index.search.slowlog.threshold.fetch.debug": "500ms", 
  5.     "index.indexing.slowlog.threshold.index.info": "5s" 
  6. }