在ES中查询分为两类：1.基于文档ID查询，2.按照非文档ID查询。

1.基于文档ID查询

当执行如下查询时：

GET /megacorp/employee/1

ES在执行上述查询的具体过程如下：

1、客户端向 Node 1 发送获取请求，此时Node1为协调者节点。

2、协调者节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个节点上。 在这种情况下，它将请求转发到 Node 2 。

3、Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。

在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

2.基于其他条件查询

基于其他条件进行文档检索的过程分为：查询和获取。

查询

由于不确定被检索的文档在多个分片中的分布情况，所以会在所有分片上进行文档查询，所以当一个索引的主分片比较多的时候，检索性能反而不高。

具体检索的过程如下：

1.客户端发送检索请求，此时ES集群中的某个节点会接受到这个请求，接受请求的节点，被称为协调者节点，如图中Node1。

2.协调者节点将检索请求发送到所有主分片/从分片上，如图上Node2中的R0和Node3中的R1，各个主从分/从分片在所在节点本地执行检索请求。此时检索的结果仅仅是符合条件的文档ID和对应排序字段的值，默认情况下，这个排序字段为相关性评分_score。

3.各个分片所在的节点将检索的结果返回给协调节点。

获取

经过查询过程，协调者节点获得了目标文档的ID和文档中对应的排序字段值。基于这些结果数据，接下来会执行数据获取的操作：

1.协调者节点根据排序逻辑和分页逻辑，从结果集数据中筛选最终需要的文档ID。协调者节点根据结果文档ID，计算出文档所在的分片信息，然后向某个或某些个目标分片(如图中Node1的R0和Node2的R1)发送 multi-get request请求，获取文档的全部信息。

2.目标分片将文档数据返回给协调者节点。

3.协调者节点将获取到的结果文档数据，返回给客户端。

上述取回数据的过程和关系型数据库中的普通索引回表过程类似。

3.深度分页查询问题

在分布式系统中，对于分页查询的场景，我们需要了解一下深度分页的性能问题，这是在分布式系统中，比较常见的一个问题。在讨论深度分页问题前，我们先熟悉一下分布式系统中的分页问题。

分页查询通常会伴随着排序问题，如果不按照某个指标进行排序的话，那么分页就没有意义了，如果不进行排序，那么如何区分第一个和第二页的内容呢？

当向分布式系统提交一个分页查询时，该查询请求会被转发到分布式系统中的各个子节点上，在每个子节点中执行该查询，但是我们需要知道，每个子节点的查询结果只是在该节点上的一个局部结果，并不是全局结果，全局结果是所有子节点查询结果的一个综合结果。只有每个局部结果数据集比较"完整"才能保证全局结果的正确性。

这里的完整怎么理解呢？

假如我们把学生考试成绩存储在一个有3个节点的分布式系统中，此时我们需要获取成绩排名第5到第10的学生信息，那么此时的查询流程如下：

1.每个节点需要查询出当前节点，所拥有数据集中学生成绩排名前10的学生信息。

2.汇总30名学生信息，然后从30名学生中找出考试成绩排名在第5到第10名的6位学生。

这里我们会发现，我们的查询请求只需要6名学生信息，但是查询过程却需要对30名学生信息进行处理。具体可以参考下图：

通过上图我们可以发现，考试成绩排名在第5到第10的6名学生信息，在3个节点中的分布并不是在第5到第10的存储位置，有可能分布在第1到第10的任何位置，所以为了保证全局数据的准确性，每个子节点要获取考试成绩是前10名的 10个学生的信息才可以。

上面的查询需求翻译成查询语句就是：按照考试成绩排序后的学生信息集合中 ，查询从考试成绩第5名开始的后5位学生信息。或者是：在分页大小为5的查询中，获取第2页数据。此时各个子节点需要查询的数据量其实是：pagesize*pagenum。

在ES中的查询语句如下：

GET /_search
{
    "from": 5,
    "size": 5
}

此时我们在回到上面的问题，在分布式系统中执行深度分页查询时(页码比较大)，会导致子节点的系统资源被大量占用，查询性能迅速下降。

实际上， “深分页” 不太符合人的行为。当2到3页过去以后，人会停止翻页，或者改变搜索标准，试想一下你在搜索引擎搜索信息时，通常只会看前2页的搜索结果