ES 7.7 官方文档
除了 Explain Api，大多数的搜索api都支持多索引(multi-index)。
主要内容:
- 路由 (Routing)
- 自适应副本选择策略 (Adaptive Replica Selection)
- 统计分组 (Stats Groups)
- 全局搜索超时时间 (Global Search Timeout)
- 搜索取消策略 (Search Cancellation)
- 搜索的并发和并行 (Search concurrency and parallelism)
路由 (Routing)
在执行搜索时，ES将根据自适应副本选择(adaptive replica selection, 下面会讲到 )公式选择数据的“最佳”副本。 也可以通过参数"路由(routing)"来控制将在哪个分片上搜索。 例如，在索引twitter中插入/更新文档时，路由的值可以是用户名：
# 先删除之前的测试的数据
DELETE /twitter
# 新增doc_id=1的文档, 指定路由的值:
POST /twitter/_doc/1?routing=kimchy
{
"user": "kimchy",
"post_date": "2009-11-15T14:12:12",
"message": "trying out Elasticsearch"
}
# 新增doc_id=2, 不指定路由
POST /twitter/_doc/2
{
"user": "kimchy",
"post_date": "2009-11-15T14:12:12",
"message": "trying out Elasticsearch2"
}
获取数据看一下:
GET /twitter/_doc/1
返回结果是:
{
"_index" : "twitter",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"_seq_no" : 0,
"_primary_term" : 1,
"_routing" : "kimchy", # 这里多了一个 _routing 的值
"found" : true,
"_source" : {
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
}
在这种情况下，如果我们只想在索引twitter上搜索一个特定的用户，我们可以指定路由，结果是只命中(检索)相关的分片：
POST /twitter/_search?routing=kimchy
{
"query": {
"term": {
"user": "kimchy"
}
}
}
官方文档的查询条件用了bool模式, 又用了query_string, 不适合入门阅读
路由参数(_routing)可以使用逗号分割的字符串列表，这将命中与路由值相匹配的多个分片。
注意: someone says 只要在索引时候加入路由字段，那么在以后的get，delete，update操作中都必须使用路由字段，否则会出现问题。
在执行上面的查询时, 已经指定了路由, 但是仍然匹配了之前插入的2个文档，但是第二个文档明明没有指定路由啊? 这可能与我的主分片数量是1有关。所有的数据都在一个分片上， 所以查询的时候该分片上的数据都会被检索到，默认的分片定位公式：
shard_num = hash(\_routing) % num_primary_shards
自适应副本选择 (Adaptive Replica Selection)
默认情况下，ES将使用所谓的自适应副本选择策略。 这允许协调节点(coordinating node)根据以下标准将请求发送至被视为“最佳”的副本：
-
协调节点和包含副本的节点在之前的请求中的响应时间 (Response time of past requests between the coordinating node and the node containing the copy of the data)
-
之前在包含数据的节点上执行搜索请求所花费的时间 (Time past search requests took to execute on the node containing the data)
-
包含数据的节点上的搜索线程池的队列大小 (The queue size of the search threadpool on the node containing the data)
简单点说就是, 它会以服务器的响应时间和请求队列作为参考指标，智能的选择副本进行查询，尽可能的缩短请求响应时间。
不过，可以通过动态修改集群的设置cluster.routing.use_adaptive_replica_selection 为false来关闭，默认值是true。
# 查询集群的所有设置
GET /_cluster/settings?include_defaults=true
# 查询routing的设置
GET /_cluster/settings?&filter_path=transient.cluster.routing.*
# 关闭自适应副本选择
PUT /_cluster/settings
{
"transient": {
"cluster.routing.use_adaptive_replica_selection": false
}
}
# 还原设置
PUT /_cluster/settings
{
"transient": {
"cluster.routing.use_adaptive_replica_selection": null
}
}
如果关闭了自适应副本选择， 将在数据的所有副本(主分片和副本分片)之间以轮询方式发送搜索请求到索引/索引分片。
统计分组 (Stats Groups)
搜索可以与统计分组关联，后者维护每个组的统计聚合。 稍后可以使用索引的stats API进行检索。 例如，下面是一个搜索请求，它将请求与两个不同的组关联起来：
POST /_search
{
"query": {
"match_all": {}
},
"stats": [ "group1", "group2" ]
}
全局搜索超时时间 (Global Search Timeout)
作为搜索请求的body的一部分，单个搜索可以设置一个超时时间。 由于搜索请求可以来自多个资源，ES为全局搜索的超时时间提供了一个动态的集群级别(cluster-level)的设置，该设置适用于所有没有在请求body中设置超时时间的搜索请求。 这些请求将在指定时间后使用下面的搜索取消(Search Cancellation)中描述的机制而被取消。因此，同样适用于超时响应的警告。
搜索取消 (Search Cancellation)
可以使用标准的任务取消(task cancellation)机制来取消搜索，也可以在客户端关闭用于执行请求的http连接时自动取消搜索。当请求超时或中止时，发送请求的http客户端必须关闭连接。
搜索的并发和并行 (Search concurrency and parallelism)
默认情况下，ES不会根据请求命中的碎片数量拒绝任何搜索请求。 虽然ES将优化协调节点(coordinating node)上的搜索命令的执行，但大量的分片可能会对CPU和内存产生重大影响。 以更少、更大的分片的方式组织数据通常是一个更好的主意。 如果您想配置软限制(soft limit)，可以修改集群设置action.search.shard_count以拒绝命中过多碎片的搜索请求。
last updated at 2021/11/9 23:06