searchType使用

之前用java写了一个查询，发现一模一样的查询语句，java查询出来的数据跟kibana查询出来的数据会有细微的区别，百思不得其解，一直在寻求问题的根本原因，后来各种搜索之后，发现了是由于查询方式的不一致。在我所开发的项目中指定的方式为DFS query then fetch
一般来讲，在未指定的情况下，默认是query then fetch。
1、query then fetch（默认的搜索方式）
如果你搜索时，没有指定搜索方式，就是使用的这种搜索方式。这种搜索方式，大概分两个步骤，第一步，先向所有的shard发出请求，各分片只返回排序和排名相关的信息（注意，不包括文档document)，然后按照各分片返回的分数进行重新排序和排名，取前size个文档。然后进行第二步，去相关的shard取document。这种方式返回的document与用户要求的size是相等的。
2、DFS query then fetch
比第2种方式多了一个初始化散发(initial scatter)步骤。
从es的官方网站我们可以指定，初始化散发其实就是在进行真正的查询之前，先把各个分片的词频率和文档频率收集一下，然后进行词搜索的时候，各分片依据全局的词频率和文档频率进行搜索和排名。显然如果使用DFS_QUERY_THEN_FETCH这种查询方式，效率是最低的，因为一个搜索，可能要请求3次分片。但，使用DFS方法，搜索精度应该是最高的。
至于DFS是什么缩写，没有找到相关资料，这个D可能是Distributed，F可能是frequency的缩写，至于S可能是Scatter的缩写，整个单词可能是分布式词频率和文档频率散发的缩写。
总结一下，从性能考虑QUERY_AND_FETCH是最快的，DFS_QUERY_THEN_FETCH是最慢的。从搜索的准确度来说，DFS要比非DFS的准确度更高。
下面就来验证一下
POST index/type/_search?search_type=dfs_query_then_fetch
{
“size”: 1,
“query”: {
“multi_match”: {
“query”: “海风藤”,
“fields”: [
“name_map^0.85”],
“type”: “most_fields”,
“tie_breaker”: 0.3
}
}
}
得出的结果为：

POST index/type/_search?search_type=query_then_fetch
{
“size”: 1,
“query”: {
“multi_match”: {
“query”: “海风藤”,
“fields”: [
“name_map^0.85”],
“type”: “most_fields”,
“tie_breaker”: 0.3
}
}
}
得出结果为：