ES七| elasticsearch中的排序过程

免责声明：本专栏的内容都是在读了《Elasticsearch权威指南（ 中文版）》书籍后整理的读后感及部分内容笔记，具体内容请查阅原著内容。

引言

默认情况下， 结果集会按照相关性进行排序 -- 相关性越高， 排名越靠前。在ElasticSearch的查询结果中， 相关性分值会用 _score 字段来给出一个浮点型的数值， 所以默认情况下， 结果集以 _score 进行倒序排列。过滤语句与 _score 没有关系， 但是有隐含的查询条件 match_all 为所有的文档的 _score设值为 1 。 也就相当于所有的文档相关性是相同的。

字段值排序

下面例子中， 对结果集按照时间排序， 这也是最常见的情形， 将最新的文档排列靠前。 我们使用 sort 参数进行排序：

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

返回结果如下所示：

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

两个需要注意的地方：

<1> _score 字段没有经过计算， 因为它没有用作排序。

<2> date 字段被转为毫秒当作排序依据。

首先， 在每个结果中增加了一个 sort 字段， 它所包含的值是用来排序的。 在这个例子当中date 字段在内部被转为毫秒， 即长整型数字 1411516800000 等同于日期字符串 2014-09-2400:00:00 UTC 。

其次就是 _score 和 max_score 字段都为 null 。 计算 _score 是比较消耗性能的, 而且通常主要用作排序 -- 我们不是用相关性进行排序的时候， 就不需要统计其相关性。 如果你想强制计算其相关性， 可以设置 track_scores 为 true 。

此外，作为缩写， 你可以只指定要排序的字段名称，字段值默认以顺序排列， 而 _score 默认以倒序排列：

"sort": "number_of_children"

如果我们想要合并一个查询语句， 并且展示所有匹配的结果集使用第一排序是 date ， 第二排序是 _score ：

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

排序是很重要的。 结果集会先用第一排序字段来排序， 当用用作第一字段排序的值相同的时候， 然后再用第二字段对第一排序值相同的文档进行排序， 以此类推。多级排序不需要包含 _score -- 你可以使用几个不同的字段， 如位置距离或者自定义数值。

字符查询也支持自定义排序， 在查询字符串使用 sort 参数就可以：

GET /_search?sort=date:desc&sort=_score&q=search

在为一个字段的多个值进行排序的时候， 其实这些值本来是没有固定的排序的-- 一个拥有多值的字段就是一个集合。对于数字和日期， 你可以从多个值中取出一个来进行排序， 你可以使用 min , max , avg 或sum 这些模式。 比说你可以在 dates 字段中用最早的日期来进行排序：

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

多值字段字符串排序

多值字段 是指同一个字段在ES索引中可以有多个含义， 即可使用多个分析器(analyser)进行分词与排序， 也可以不添加分析器， 保留原值。

被分析器(analyser)处理过的字符称为 analyzed field，即已被分词并排序的字段，所有写入ES中的字段默认圴会被analyzed, analyzed 字符串字段同时也是多值字段， 在这些字段上排序往往得不到你想要的值。 比如你分析一个字符 "fine old art" ,它最终会得到三个值。 例如我们想要按照第一个词首字母排序， 如果第一个单词相同的话， 再用第二个词的首字母排序， 以此类推， 可惜 ElasticSearch 在进行排序时 是得不到这些信息的。

当然你可以使用 min 和 max 模式来排（ 默认使用的是 min 模式） 但它是依据 art 或者old 排序， 而不是我们所期望的那样。为了使一个string字段可以进行排序， 它必须只包含一个词： 即完整的 not_analyzed 字符串(未经分析器分词并排序的原字符串)。 当然我们需要对字段进行全文本搜索的时候还必须使用被 analyzed 标记的字段。

在 _source 下相同的字符串上排序两次会造成不必要的资源浪费。 而我们想要的是同一个字段中同时包含这两种索引方式， 我们只需要改变索引(index)的mapping即可。 方法是在所有核心字段类型上， 使用通用参数 fields 对mapping进行修改。 比如， 我们原有mapping如下：

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

改变后的多值字段mapping如下：

"tweet": { <1>
    "type": "string",
    "analyzer": "english",
    "fields": {
        "raw": { <2>
            "type": "string",
            "index": "not_analyzed"
        }
    }
}

<1> tweet 字段用于全文本的 analyzed 索引方式不变。

<2> 新增的 tweet.raw 子字段索引方式是 not_analyzed 。

现在， 在给数据重建索引后， 我们既可以使用 tweet 字段进行全文本搜索， 也可以用 tweet.raw 字段进行排序：

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

相关性

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

查询语句会为每个文档添加一个 _score 字段。 评分的计算方式取决于不同的查询类型 -- 不同的查询语句用于不同的目的： fuzzy 查询会计算与关键词的拼写相似程度， terms 查询会计算 找到的内容与关键词组成部分匹配的百分比， 但是一般意义上我们说的全文本搜索是指计算内容与关键词的类似程度。

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

检索词频率::

检索词在该字段出现的频率？ 出现频率越高， 相关性也越高。 字段中出现过5次要比只出现过1次的相关性高。

反向文档频率::

每个检索词在索引中出现的频率？ 频率越高， 相关性越低。 检索词出现在多数文档中会比出现在少数文档中的权重更低， 即检验一个检索词在文档中的普遍重要性。

字段长度准则::

字段的长度是多少？ 长度越长， 相关性越低。 检索词出现在一个短的 title 要比同样的词出现在一个长的 content 字段。单个查询可以使用TF/IDF评分标准或其他方式， 比如短语查询中检索词的距离或模糊查询里的检索词相似度。相关性并不只是全文本检索的专利。 也适用于 yes|no 的子句， 匹配的子句越多， 相关性评分越高。如果多条查询子句被合并为一条复合查询语句， 比如 bool 查询， 则每个查询子句计算得出的评分会被合并到总的相关性评分中。

当调试一条复杂的查询语句时， 想要理解相关性评分 _score 是比较困难的。 ElasticSearch在 每个查询语句中都有一个explain参数， 将 explain 设为 true 就可以得到更详细的信息。

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

<1> explain 参数可以让返回结果添加一个 _score 评分的得来依据。增加一个 explain 参数会为每个匹配到的文档产生一大堆额外内容， 但是花时间去理解它是很有意义的。

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

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

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

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

然后返回值中的 _explanation 会包含在每一个入口， 告诉你采用了哪种计算方式， 并让你知道计算的结果以及其他详情：

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

<1> honeymoon 相关性评分计算的总结；

<2> 检索词频率：检索词 `honeymoon` 在 `tweet` 字段中的出现次数。

<3> 反向文档频率：检索词 `honeymoon` 在 `tweet` 字段在当前文档出现次数与索引中其他文档的出现总数的比率。

<4> 字段长度准则：文档中 `tweet` 字段内容的长度 -- 内容越长， 值越小。

JSON形式的explain描述是难以阅读的 但是转成 YAML 会好很多， 只需要在参数中加上 format=yaml。

数据字段

当你对一个字段进行排序时， ElasticSearch 需要进入每个匹配到的文档得到相关的值。 倒排索引在用于搜索时是非常卓越的， 但却不是理想的排序结构。

• 当搜索的时候， 我们需要用检索词去遍历所有的文档。
• 当排序的时候， 我们需要遍历文档中所有的值， 我们需要做反倒序排列操作。

为了提高排序效率， ElasticSearch 会将所有字段的值加载到内存中， 这就叫做"数据字段"。

ElasticSearch将所有字段数据加载到内存中并不是匹配到的那部分数据。 而是索引下所有文档中的值， 包括所有类型。将所有字段数据加载到内存中是因为从硬盘反向倒排索引是非常缓慢的。 尽管你这次请求需要的是某些文档中的部分数据， 但你下个请求却需要另外的数据， 所以将所有字段数据一次性加载到内存中是十分必要的。

ElasticSearch中的字段数据常被应用到以下场景：

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

毫无疑问， 这会消耗掉很多内存， 尤其是大量的字符串数据 -- string字段可能包含很多不同的值， 比如邮件内容。 值得庆幸的是， 内存不足是可以通过横向扩展解决的， 我们可以增加更多的节点到集群。