深入理解ElasticSearch（六）排序与相关性-技术圈

排序与相关性

默认情况下，返回的结果是按照相关性进行排序的——最相关的文档排在最前。在本章的后面部分，我们会解释相关性意味着什么以及它是如何计算的，不过让我们首先看看 sort 参数以及如何使用它。

1、排序

为了按照相关性来排序，需要将相关性表示为一个数值。在 Elasticsearch 中，相关性得分由一个浮点数进行表示，并在搜索结果中通过 _score 参数返回，默认排序是 _score 降序。

有时，相关性评分对你来说并没有意义。例如，下面的查询返回所有 user_id 字段包含 1 的结果：

GET /_search
{
"query" : {
"bool" : {
"filter" : {
"term" : {
"user_id" : 1
}
}
}
}
}

这里没有一个有意义的分数：因为我们使用的是 filter （过滤），这表明我们只希望获取匹配 user_id: 1 的文档，并没有试图确定这些文档的相关性。实际上文档将按照随机顺序返回，并且每个文档都会评为零分。

1.1、按照字段的值排序

在这个案例中，通过时间来对 tweets 进行排序是有意义的，最新的 tweets 排在最前。我们可以使用 sort 参数进行实现：

GET /_search
{
"query" : {
"bool" : {
"filter" : { "term" : { "user_id" : 1 }}
}
},
"sort": { "date": { "order": "desc" }}
}

你会注意到结果中的两个不同点：

"hits" : {
"total" :           6,
"max_score" :       null,
"hits" : [ {
"_index" :      "us",
"_type" :       "tweet",
"_id" :         "14",
"_score" :      null,
"_source" :     {
"date":    "2014-09-24",
...
},
"sort" :        [ 1411516800000 ]
},
...
}

_score 不被计算, 因为它并没有用于排序。

date 字段的值表示为自 epoch (January 1, 1970 00:00:00 UTC)以来的毫秒数，通过 sort 字段的值进行返回。

首先我们在每个结果中有一个新的名为 sort 的元素，它包含了我们用于排序的值。在这个案例中，我们按照 date 进行排序，在内部被索引为自 epoch 以来的毫秒数。long 类型数 1411516800000 等价于日期字符串 2014-09-24 00:00:00 UTC 。

其次 _score 和 max_score 字段都是 null 。计算 _score 的花销巨大，通常仅用于排序；我们并不根据相关性排序，所以记录 _score 是没有意义的。如果无论如何你都要计算 _score ，你可以将 track_scores 参数设置为 true 。

1.2、多级排序

假定我们想要结合使用 date 和 _score 进行查询，并且匹配的结果首先按照日期排序，然后按照相关性排序：

GET /_search
{
"query" : {
"bool" : {
"must":   { "match": { "tweet": "manage text search" }},
"filter" : { "term" : { "user_id" : 2 }}
}
},
"sort": [
{ "date":   { "order": "desc" }},
{ "_score": { "order": "desc" }}
]
}

排序条件的顺序是很重要的。结果首先按第一个条件排序，仅当结果集的第一个 sort 值完全相同时才会按照第二个条件进行排序，以此类推。

多级排序并不一定包含 _score 。你可以根据一些不同的字段进行排序，如地理距离或是脚本计算的特定值。

1.3、字段多值的排序

一种情形是字段有多个值的排序，需要记住这些值并没有固有的顺序；一个多值的字段仅仅是多个值的包装，这时应该选择哪个进行排序呢？

对于数字或日期，你可以将多值字段减为单值，这可以通过使用 min 、 max 、 avg 或是 sum 排序模式。例如你可以按照每个 date 字段中的最早日期进行排序，通过以下方法：

"sort": {
"dates": {
"order": "asc",
"mode":  "min"
}
}

2、字符串排序与多字段

被解析的字符串字段也是多值字段，但是很少会按照你想要的方式进行排序。如果你想分析一个字符串，如 fine old art ，这包含 3 项。我们很可能想要按第一项的字母排序，然后按第二项的字母排序，诸如此类，但是 Elasticsearch 在排序过程中没有这样的信息。

你可以使用 min 和 max 排序模式（默认是 min ），但是这会导致排序以 art 或是 old ，任何一个都不是所希望的。

为了以字符串字段进行排序，这个字段应仅包含一项：整个 not_analyzed 字符串。但是我们仍需要 analyzed 字段，这样才能以全文进行查询

一个简单的方法是用两种方式对同一个字符串进行索引，这将在文档中包括两个字段：analyzed 用于搜索， not_analyzed 用于排序

但是保存相同的字符串两次在 _source 字段是浪费空间的。我们真正想要做的是传递一个单字段但是却用两种方式索引它。所有的 _core_field 类型 (strings, numbers, Booleans, dates) 接收一个 fields 参数

该参数允许你转化一个简单的映射如：

"tweet": {
"type":     "string",
"analyzer": "english"
}

为一个多字段映射如：

"tweet": {
"type":     "string",
"analyzer": "english",
"fields": {
"raw": {
"type":  "string",
"index": "not_analyzed"
}
}
}

tweet 主字段与之前的一样: 是一个 analyzed 全文字段。

新的 tweet.raw 子字段是 not_analyzed.

现在，至少只要我们重新索引了我们的数据，使用 tweet 字段用于搜索，tweet.raw 字段用于排序：

GET /_search
{
"query": {
"match": {
"tweet": "elasticsearch"
}
},
"sort": "tweet.raw"
}

3、什么是相关性?

我们曾经讲过，默认情况下，返回结果是按相关性倒序排列的。但是什么是相关性？相关性如何计算？

每个文档都有相关性评分，用一个正浮点数字段 _score 来表示。_score 的评分越高，相关性越高。

查询语句会为每个文档生成一个 _score 字段。评分的计算方式取决于查询类型不同的查询语句用于不同的目的：fuzzy 查询会计算与关键词的拼写相似程度，terms 查询会计算找到的内容与关键词组成部分匹配的百分比，但是通常我们说的 relevance 是我们用来计算全文本字段的值相对于全文本检索词相似程度的算法。

Elasticsearch 的相似度算法被定义为检索词频率/反向文档频率， TF/IDF ，包括以下内容：

检索词频率
检索词在该字段出现的频率？出现频率越高，相关性也越高。字段中出现过 5 次要比只出现过 1 次的相关性高。
反向文档频率
每个检索词在索引中出现的频率？频率越高，相关性越低。检索词出现在多数文档中会比出现在少数文档中的权重更低。
字段长度准则
字段的长度是多少？长度越长，相关性越低。检索词出现在一个短的 title 要比同样的词出现在一个长的 content 字段权重更大。

单个查询可以联合使用 TF/IDF 和其他方式，比如短语查询中检索词的距离或模糊查询里的检索词相似度。

相关性并不只是全文本检索的专利。也适用于 yes|no 的子句，匹配的子句越多，相关性评分越高。

如果多条查询子句被合并为一条复合查询语句，比如 bool 查询，则每个查询子句计算得出的评分会被合并到总的相关性评分中。

3.1、理解评分标准

当调试一条复杂的查询语句时，想要理解 _score 究竟是如何计算是比较困难的。Elasticsearch 在每个查询语句中都有一个 explain 参数，将 explain 设为 true 就可以得到更详细的信息。

GET /_search?explain
{
"query"   : { "match" : { "tweet" : "honeymoon" }}
}

explain 参数可以让返回结果添加一个 _score 评分的得来依据。

首先，我们看一下普通查询返回的元数据：

{
"_index" :      "us",
"_type" :       "tweet",
"_id" :         "12",
"_score" :      0.076713204,
"_source" :     { ... trimmed ... },

这里加入了该文档来自于哪个节点哪个分片上的信息，这对我们是比较有帮助的，因为词频率和文档频率是在每个分片中计算出来的，而不是每个索引中：

"_shard" :      1,
"_node" :       "mzIVYCsqSWCG_M_ZffSs9Q",

然后它提供了 _explanation 。每个入口都包含一个 description 、 value 、 details 字段，它分别告诉你计算的类型、计算结果和任何我们需要的计算细节。

"_explanation": {
"description": "weight(tweet:honeymoon in 0)
[PerFieldSimilarity], result of:",
"value":       0.076713204,
"details": [
{
"description": "fieldWeight in 0, product of:",
"value":       0.076713204,
"details": [
{
"description": "tf(freq=1.0), with freq of:",
"value":       1,
"details": [
{
"description": "termFreq=1.0",
"value":       1
}
]
},
{
"description": "idf(docFreq=1, maxDocs=1)",
"value":       0.30685282
},
{
"description": "fieldNorm(doc=0)",
"value":        0.25,
}
]
}
]
}

第一部分是关于计算的总结。告诉了我们 honeymoon 在 tweet 字段中的检索词频率/反向文档频率或 TF/IDF，（这里的文档 0 是一个内部的 ID，跟我们没有关系，可以忽略。）

然后它提供了权重是如何计算的细节：

检索词频率:

检索词 honeymoon 在这个文档的 tweet 字段中的出现次数。

反向文档频率:

检索词 honeymoon 在索引上所有文档的 tweet 字段中出现的次数。

字段长度准则:

在这个文档中， tweet 字段内容的长度 – 内容越长，值越小。

复杂的查询语句解释也非常复杂，但是包含的内容与上面例子大致相同。通过这段信息我们可以了解搜索结果是如何产生的。

3.2、理解文档是如何被匹配到的

当 explain 选项加到某一文档上时， explain api 会帮助你理解为何这个文档会被匹配，更重要的是，一个文档为何没有被匹配。

请求路径为 /index/type/id/_explain ，如下所示：

GET /us/tweet/12/_explain
{
"query" : {
"bool" : {
"filter" : { "term" :  { "user_id" : 2           }},
"must" :  { "match" : { "tweet" :   "honeymoon" }}
}
}
}

不只是我们之前看到的充分解释，我们现在有了一个 description 元素，它将告诉我们：

"failure to match filter: cache(user_id:[2 TO 2])"

也就是说我们的 user_id 过滤子句使该文档不能匹配到。

4、Doc Values 介绍

本章的最后一个话题是关于 Elasticsearch 内部的一些运行情况。在这里我们先不介绍新的知识点，所以我们应该意识到，Doc Values 是我们需要反复提到的一个重要话题。

当你对一个字段进行排序时，Elasticsearch 需要访问每个匹配到的文档得到相关的值。倒排索引的检索性能是非常快的，但是在字段值排序时却不是理想的结构。

在搜索的时候，我们能通过搜索关键词快速得到结果集。
当排序的时候，我们需要倒排索引里面某个字段值的集合。换句话说，我们需要 倒置 倒排索引。

倒置 结构在其他系统中经常被称作 列存储 。实质上，它将所有单字段的值存储在单数据列中，这使得对其进行操作是十分高效的，例如排序。

在 Elasticsearch 中，doc values 就是一种列式存储结构，默认情况下每个字段的 doc values 都是激活的，doc values 是在索引时创建的，当字段索引时，Elasticsearch 为了能够快速检索，会把字段的值加入倒排索引中，同时它也会存储该字段的 doc values。

Elasticsearch 中的 doc vaules 常被应用到以下场景：

对一个字段进行排序
对一个字段进行聚合
某些过滤，比如地理位置过滤
某些与字段相关的脚本计算

因为文档值被序列化到磁盘，我们可以依靠操作系统的帮助来快速访问。当 working set 远小于节点的可用内存，系统会自动将所有的文档值保存在内存中，使得其读写十分高速；当其远大于可用内存，操作系统会自动把 doc values 加载到系统的页缓存中，从而避免了 jvm 堆内存溢出异常。