概要
本篇主要介绍一下分布式环境中搜索的两阶段执行过程。
两阶段搜索过程
回顾我们之前的CRUD操作,因为只对单个文档进行处理,文档的唯一性很容易确定,并且很容易知道是此文档在哪个node,哪个shard中。
但搜索比CRUD复杂,符合搜索条件的文档,可能散落在各个node、各个shard中,我们需要找到匹配的文档,并且把从各个node,各个shard返回的结果进行汇总、排序,组成一个最终的结果排序列表,才算完成一个搜索过程。我们将按两阶段的方式对这个过程进行讲解。
查询阶段
假定我们的ES集群有三个node,numberofprimary_shards为3,replica shard为1,我们执行一个这样的查询请求:
GET /music/children/_search
{
"from": 980,
"size": 20
}
查询阶段的过程示意图如下:
- Java客户端发起查询请求,接受请求的node-1成为Coordinate Node(协调者),该node会创建一个priority queue,长度为from size即1000。
- Coordinate Node将请求分发到所有的primary shard或replica shard中,每个shard在本地创建一个同样大小的priority queue,长度也为from size,用于存储该shard执行查询的结果。
- 每个shard将各自priority queue的元素返回给Coordinate Node,元素内只包含文档的ID和排序值(如_score),Coordinate Node将合并所有的元素到自己的priority queue中,并完成排序动作,最终根据from、size值对结果进行截取。
补充说明:
- 哪个node接收客户端的请求,该node就会成为Coordinate Node。
- Coordinate Node转发请求时,会根据负载均衡算法分配到同一分片的primary shard或replica shard上,为什么说replica值设置得大一些可以增加系统吞吐量的原理就在这里,Coordinate Node的查询请求负载均衡算法会轮询所有的可用shard,并发场景时就会有更多的硬件资源(CPU、内存,IO)会参与其中,系统整体的吞吐量就能提升。
- 此查询过程Coordinate Node得到是轻量级的元素信息&#