原文地址在这里，我进行了重新排版和措辞修正润色，觉得算是比较好的科普文章。最近在进行业务的查询优化，有必要学习一下 ES 的查询，所以就转载了，其实本人真的特别觉得转载是对原文作者的不尊重，不过原文这排版真恶心。

作者：好记性不如烂笔头！
出处：http://www.cnblogs.com/zlslch/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。

Elasticsearch Client 发送搜索请求，某个索引库，一般默认是5个分片（shard），它返回的时候，由各个分片汇总结果回来，附上官网API。

在查询 ES 时，可以指定的搜索类型为下面四种：

• QUERY_THEN_FETCH
• QUERY_AND_FEATCH
• DFS_QUERY_THEN_FEATCH
• DFS_QUERY_AND_FEATCH

那么这 4 种搜索类型有什么区别？在讲这四种搜索类型的区别之前， 先说明一下分布式搜索背景。

分布式搜索面对的共性问题

ES 天生就是为分布式而生， 但分布式有分布式的缺点。 比如要搜索某个单词， 但是数据却分别在 5 个分片（Shard)上面， 这 5 个分片可能在 5 台主机上面。 因为全文搜索天生就要排序（ 按照匹配度进行排名） ,但数据却在 5 个分片上， 如何得到最后正确的排序呢？ ES是这样做的， 大概分两步：

1. ES 客户端将会同时向 5 个分片发起搜索请求。
2. 这 5 个分片基于本分片的内容独立完成搜索， 然后将符合条件的结果全部返回。

客户端将返回的结果进行重新排序和排名，最后返回给用户。也就是说，ES的一次搜索，是一次 scatter/gather 过程（这个跟mapreduce也很类似）

然而这其中有两个问题：

1. 数量问题。 比如， 用户需要搜索"衣服"， 要求返回符合条件的前 10 条。 但在 5个分片中， 可能都存储着衣服相关的数据。 所以 ES 会向这 5 个分片都发出查询请求， 并且要求每个分片都返回符合条件的 10 条记录。当ES得到返回的结果后，进行整体排序，然后取最符合条件的前10条返给用户。 这种情况， ES 中 5 个 shard 最多会收到 10*5=50条记录， 这样返回给用户的结果数量会多于用户请求的数量。
2. 排名问题。 上面说的搜索， 每个分片计算符合条件的前 10 条数据都是基于自己分片的数据进行打分计算的。计算分值使用的词频和文档频率等信息都是基于自己分片的数据进行的， 而 ES 进行整体排名是基于每个分片计算后的分值进行排序的(相当于打分依据就不一样， 最终对这些数据统一排名的时候就不准确了)， 这就可能会导致排名不准确的问题。如果我们想更精确的控制排序， 应该先将计算排序和排名相关的信息（ 词频和文档频率等打分依据） 从 5 个分片收集上来， 进行统一计算， 然后使用整体的词频和文档频率为每个分片中的数据进行打分， 这样打分依据就一样了。

ES 需要解决的问题

所以，Elasticsearch 在搜索过程中需要解决的问题也类似：

1. 返回数据量问题，如果数据分散在默认的5个分片上，ES会向5个分片同时发出请求，每个分片都返回10条数据，最终会返回总数据为：5 * 10 = 50条数据，远远大于用户请求。
2. 返回数据排名问题，每个分片计算符合条件的前10条数据都是基于自己分片的数据进行打分计算的。计算分值（score）使用的词频和文档频率等信息都是基于自己分片的数据进行的，而ES进行整体排名是基于排名是基于每个分片计算后的分值进行排序的（打分依据就不一致，最终对这些数据统一排名的时候就不准确了）

举个例子阐述下 排名问题 ，一个奖学金的判定的 Case：

假设某学校有一班和二班两个班级。期末考试之后， 学校要给全校前十名学员发奖金。但是一班和二班考试的时候使用的不是一套试卷。

一班： 使用的是 A 卷【 A 卷偏容易】

二班： 使用的是 B 卷【 B 卷偏难】

结果就是一班的最高分是 100 分， 最低分是 80 分。二班的最高分是 70 分， 最低分是 30 分。这样全校前十名就都是一班的学员了。 这显然是不合理的。因为一班和二班的试卷难易程度不一样， 也就是打分依据不一样， 所以不能放在一块排名。这就解释了刚才的排名问题，如果想要保证排名准确的话， 需要保证一班和二班使用的试卷内容一样。可以这样做， 把 A 卷和 B 卷的内容组合到一块， 作为 C 卷。一班和二班考试都使用 C 卷， 这样他们的打分依据就一样了， 最终再根据所有学员的成绩进行排名。

ES 的解决方案

这两个问题， ES 也没有什么较好的解决方法， 最终把选择的权利交给用户， 方法就是在搜索的时候指定 search type。

Elasticsearch在搜索问题的解决思路

1. 数量问题
   • 先从每个分片汇总查询的数据id，进行排名，取前10条数据；
   • 第二步：根据这10条数据id，到不同分片获取数据；
2. 排名问题：将各个分片打分标准统一

Elasticsearch的搜索类型（SearchType）

query and fetch

向索引的所有分片 （ shard）都发出查询请求， 各分片返回的时候把元素文档 （ document）和计算后的排名信息一起返回。这种搜索方式是最快的。 因为相比下面的几种搜索方式， 这种查询方法只需要去 shard查询一次。 但是各个 shard 返回的结果的数量之和可能是用户要求的 size 的 n 倍。

• 优点：这种搜索方式是最快的。因为相比后面的几种es的搜索方式，这种查询方法只需要去shard查询一次。

• 缺点：返回的数据量不准确， 可能返回(N*分片数量)的数据并且数据排名也不准确，同时各个shard返回的结果的数量之和可能是用户要求的size的n倍。

query then fetch（ default ）

如果你搜索时， 没有指定搜索方式， 就是使用的这种搜索方式。 这种搜索方式， 大概分两个步骤：

1. 先向所有的 shard 发出请求， 各分片只返回文档 id(注意， 不包括文档 document)和排名相关的信息(也就是文档对应的分值)， 然后按照各分片返回的文档的分数进行重新排序和排名， 取前 size 个文档。
2. 根据文档 id 去相关的 shard 取 document。 这种方式返回的 document 数量与用户要求的大小是相等的。

• 优点：返回的数据量是准确的。
• 缺点：性能比 query and fetch 差，并且数据排名不准确。

DFS query and fetch

这种方式比 query and fetch 多了一个 DFS 步骤，有这一步，可以更精确控制搜索打分和排名。也就是在进行查询之前， 先对所有分片发送请求， 把所有分片中的词频和文档频率等打分依据全部汇总到一块， 再执行后面的操作。

• 优点：数据排名准确
• 缺点：性能比 query then fetch 差，返回的数据量不准确， 可能返回 (N*分片数量) 的数据

DFS query then fetch

比 query then fetch 多了一个 DFS 步骤。也就是在进行查询之前， 先对所有分片发送请求， 把所有分片中的词频和文档频率等打分依据全部汇总到一块， 再执行后面的操作。

• 优点：数据量是准确、数据排名准确
• 缺点：性能最差

DFS 是一个什么样的过程？
从 es 的官方网站我们可以发现， DFS 其实就是在进行真正的查询之前， 先把各个分片的词频率和文档频率收集一下， 然后进行词搜索的时候， 各分片依据全局的词频率和文档频率进行搜索和排名。 显然如果使用 DFS_QUERY_THEN_FETCH 这种查询方式， 效率是最低的，因为一个搜索， 可能要请求 3 次分片。 但， 使用 DFS 方法， 搜索精度是最高的。

小结

从性能考虑 QUERY_AND_FETCH 是最快的， DFS_QUERY_THEN_FETCH 是最慢的。从搜索的准确度来说， DFS 要比非 DFS 的准确度更高，用户可以酌情根据业务场景进行类型选择。