查询阶段标识哪些文档满足搜索请求，但是我们仍然需要取回这些文档，这是取回阶段的任务，正如 Figure 15, “分布式搜索的取回阶段”所展示的。

Figure 15. 分布式搜索的取回阶段

image.png

分布式阶段由以下步骤构成：

  1. 协调节点辨别出那些文档需要被取回并向相关的分片提交多个GET 请求。
  2. 每个分片加载并 丰富 文档，如果有需要的话，接着返回文档给协调节点。
  3. 一旦所有的文档都被取回了，协调节点返回结果给客户端。

协调节点首先决定那些文档 确实 需要被取回。例如，如果我们的查询指定了{“from”:90,”size”:10},最初的90个结果会被丢弃，只有从91个开始的10个结果需要被取回。这些文档课鞥呢来自和最初搜索请求有关的一个、多个甚至全部分片。

协调节点给持有相关文档的每个分片创建一个 multi-get request ，并发送请求给同样处理查询阶段的分片副本。

分片加载文档体—_source 字段——如果有需要，用元数据和 search snippet highlighting丰富结果文档。一旦协调节点接收到所有的结果文档，他就组装这些结果为单个响应返回给客户端。

深分页（Deep Pagination）

先查后取的过程支持用from 和 size 参数分页，但是这是有限制的。要记住需要传递信息给协调节点的每个分片必须先创建一个 from + size 长度的队列，协调节点需要根据number_of_shards * （from + size）排序文档，来找到被包含在size 里的文档。

取决于你的文档的大小，分片的数量取决于你的文档的大小，分片的数量和你使用的硬件，给10000到50000 的结果文档深分页（1000到5000页）是完全可行的。但是使用足够大的from值，排序过程可能会变得非常沉重，使用大量的CPU、内存和宽带。因为这个原因，我们强烈建议你不要使用深分页。

实际上，深分页很少复合人的行为。当2到3页过去以后，人会停止翻页，并且改变搜索标准。会不知疲倦的一页一页的获取网页直到你的服务崩溃的罪魁祸首一般是机器人或者 web spider、

如果你确实需要从你的集群取回大量的文档，你可以通过用scroll 查询禁用排序使这个取回行为更有效率，我们会在 later in this chapter 进行讨论。