京东面试题：ElasticSearch 深度分页解决方案

前言

Elasticsearch 是一个实时的分布式搜索与分析引擎，在使用过程中，有一些典型的使用场景，比如分页、遍历等。

在使用关系型数据库中，我们被告知要注意甚至被明确禁止使用深度分页，同理，在 Elasticsearch 中，也应该尽量避免使用深度分页。

这篇文章主要介绍 Elasticsearch 中分页相关内容！

From/Size 参数

在 ES 中，分页查询默认返回最顶端的 10 条匹配 hits。

如果需要分页，需要使用 from 和 size 参数。

• from 参数定义了需要跳过的 hits 数，默认为 0；

• size 参数定义了需要返回的 hits 数目的最大值。

一个基本的 ES 查询语句是这样的：

POST /my_index/my_type/_search{
      "query": { "match_all": {}},    "from": 100,    "size":  10}

复制代码

上面的查询表示从搜索结果中取第 100 条开始的 10 条数据。

「那么，这个查询语句在 ES 集群内部是怎么执行的呢？」

在 ES 中，搜索一般包括两个阶段，query 和 fetch 阶段，可以简单的理解，query 阶段确定要取哪些 doc，fetch 阶段取出具体的 doc。

❝

Query 阶段

如上图所示，描述了一次搜索请求的 query 阶段：·

1. Client 发送一次搜索请求，node1 接收到请求，然后，node1 创建一个大小为from + size的优先级队列用来存结果，我们管 node1 叫 coordinating node。

2. coordinating node 将请求广播到涉及到的 shards，每个 shard 在内部执行搜索请求，然后，将结果存到内部的大小同样为from + size 的优先级队列里，可以把优先级队列理解为一个包含top N结果的列表。

3. 每个 shard 把暂存在自身优先级队列里的数据返回给 coordinating node，coordinating node 拿到各个 shards 返回的结果后对结果进行一次合并，产生一个全局的优先级队列，存到自身的优先级队列里。

在上面的例子中，coordinating node 拿到(from + size) * 6条数据，然后合并并排序后选择前面的from + size条数据存到优先级队列，以便 fetch 阶段使用。

另外，各个分片返回给 coordinating node 的数据用于选出前from + size条数据，所以，只需要返回唯一标记 doc 的_id以及用于排序的_score即可，这样也可以保证返回的数据量足够小。

coordinating node 计算好自己的优先级队列后，query 阶段结束，进入 fetch 阶段。

❝

Fetch 阶段

query 阶段知道了要取哪些数据，但是并没有取具体的数据，这就是 fetch 阶段要做的。

上图展示了 fetch 过程：

1. coordinating node 发送 GET 请求到相关 shards。

2. shard 根据 doc 的_id取到数据详情，然后返回给 coordinating node。

3. coordinating node 返回数据给 Client。

coordinating node 的优先级队列里有from + size 个_doc _id，但是，在 fetch 阶段，并不需要取回所有数据，在上面的例子中，前 100 条数据是不需要取的，只需要取优先级队列里的第 101 到 110 条数据即可。

需要取的数据可能在不同分片，也可能在同一分片，coordinating node 使用 「multi-get」 来避免多次去同一分片取数据，从而提高性能。

「这种方式请求深度分页是有问题的：」

我们可以假设在一个有 5 个主分片的索引中搜索。当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给 协调节点 ，协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页—结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前 10010 个结果以外。然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。

「对结果排序的成本随分页的深度成指数上升。」

「注意 1：」

size 的大小不能超过index.max_result_window这个参数的设置，默认为 10000。

如果搜索 size 大