作者：刘晓国

Elasticsearch提供了一个最重要的功能就是相关性。它可以帮我们按照我们搜索的条件进行相关性计算。每个文档有一个叫做 _score 的分数。在默认没有 sort 的情况下，返回的文档时按照分数的大小从大到小进行排列的。这个分数的计算是按照如下的三个条件来进行计算的:

1) Term Frequency (TF)：给定术语在某个文档中的使用频率。在一个字段中该术语出现的越多，这个术语越重要。

TF 的计算永远是100%的精确，这是因为它是一个文档级的计算。

2）Inverse Document Frequency (IDF)： 给定术语在所有文档中的唯一性。一个字段在越多的文档中出现，那么这个术语就越不重要，比如 “the”，"to" 等这些词经常出现在一些文档，那么这些词的重要性就不强。

IDF 的计算不一定是100%的精确。在默认的 query-then-fetch 计算中，它是在本地针对每个 shard 来计算的。在绝大多数的情况下，这个绝不是一个问题：

1）使用本地 IDF 很少出现问题，尤其是对于大型数据集

2）如果您的文档在各个分片之间分布良好，则本地分片之间的 IDF 将基本相同

3）Field length：较短的字段比较长的字段更相关

相关性算法使用的是 TF-IDF。那么在计算相关性时，是否需要知道整个索引的 TF-IDF 还是每个分片（shard）的 TF-IDT?

默认搜索类型：“query-then-fetch”

默认情况下，Elasticsearch 将使用一种称为“先查询后取”的搜索类型。其工作方式如下：

1.将查询发送到每个分片

2.查找所有匹配的文档并使用本地 Term/Frequency 计算分数

3.建立结果优先级队列（排序，from/to 分页等）

4.将有关结果的元数据返回到请求节点。注意，实际文件还没有发送，只是分数

5.来自所有分片的分数在请求节点上合并并排序，根据查询条件选择文档

6.最后，从文档所在的各个分片中检索实际文档。

7.结果返回给客户

该系统通常运行良好。在大多数情况下，您的索引具有足够的文档，可以使 term/document 文档频率统计数据变得平滑。因此，尽管每个碎片可能不完全了解整个群集的频率，但结果“足够好”，因为各地的频率都非常相似。

默认搜索类型有时会失败。

DFS Query Then Fetch

如果遇到这种评分差异有问题的情况，则ES提供一种称为 “DFS Query Then Fetch” 的搜索类型。除了执行预查询以计算全局文档频率外，该过程几乎与 “Query-then-Fetch” 相同。

为了使得 IDF 100%精确，在分片可以计算每个匹配的 _score 之前，必须全局计算其值。那么问题来了：为什么我们不为每一个搜索都计算全局的 IDF 呢？答案是这样的计算会增加很多的开销。

1.预查询每个分片，询问术语和文档频率

2.将查询发送到每个分片

3.查找所有匹配的文档并使用从预查询中计算出的全局 term/document 频率来计算分数。

4.建立结果优先级队列（排序，从/到分页等）

5.将有关结果的元数据返回到请求节点。注意，实际文件还没有发送，只是分数

6.来自所有分片的分数在请求节点上合并并排序，根据查询条件选择文档

7.最后，从文档所在的各个分片中检索实际文档。

8.结果返回给客户

如果我们将此新的搜索类型应用于之前的查询，则会获得有意义的评分结果（例如，它们完全相同）：

$ curl -XGET 'localhost:9200/startswith/test/_search?pretty=true&search_type=dfs_query_then_fetch' -d '{
        "query": {
        "match_phrase_prefix": {
           "title": {
             "query": "d",
             "max_expansions": 5
           }
         }
       }
     }' | grep title
      "_score" : 1.9162908, "_source" : {"title":"dzone"}
      "_score" : 1.9162908, "_source" : {"title":"data"}
      "_score" : 1.9162908, "_source" : {"title":"drunk"}
      "_score" : 1.9162908, "_source" : {"title":"drive"}

在上面我们在查询请求中使用 search_type为 dfs_query_then_fetch ：

预查询首先从每个分片中检索本地 IDF，以计算全局 IDF

但是，你几乎不需要在生产中使用它

结论：

当然，更好的准确性并非免费提供。 预查询会导致分片之间的额外往返，这可能会导致性能下降，具体取决于索引的大小，分片的数量，查询率等。在大多数情况下，完全没有必要……拥有“足够的”数据 为您解决问题。

但是有时你会遇到奇怪的评分情况，在这种情况下，了解如何使用 DFS 查询和获取来调整搜索执行计划很有用。

参考：

【1】https://www.elastic.co/blog/understanding-query-then-fetch-vs-dfs-query-then-fetch