ElasticSearch-排序

时间  2019-11-09
标签 elasticsearch 排序 栏目 日志分析 繁體版
原文   原文链接

引用自ElaticSearch权威指南node

1、排序

相关性排序

默认状况下，结果集会按照相关性进行排序 -- 相关性越高，排名越靠前。 这一章咱们会讲述相关性是什么以及它是如何计算的。 在此以前，咱们先看一下sort参数的使用方法。算法

排序方式

为了使结果能够按照相关性进行排序，咱们须要一个相关性的值。在ElasticSearch的查询结果中， 相关性分值会用_score字段来给出一个浮点型的数值，因此默认状况下，结果集以_score进行倒序排列。api

有时，即使如此，你仍是没有一个有意义的相关性分值。好比，如下语句返回全部tweets中 user_id 是否 包含值 1：app

复制代码 
GET /_search
{
    "query" : {
        "filtered" : {
            "filter" : {
                "term" : {
                    "user_id" : 1
                }
            }
        }
    }
}
复制代码

过滤语句与 _score 没有关系，可是有隐含的查询条件 match_all 为全部的文档的 _score 设值为 1。 也就至关于全部的文档相关性是相同的。elasticsearch

字段值排序

下面例子中，对结果集按照时间排序，这也是最多见的情形，将最新的文档排列靠前。 咱们使用 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>
    },
    ...
}
复制代码

_score字段没有通过计算，由于它没有用做排序。date 字段被转为毫秒看成排序依据。spa

首先，在每一个结果中增长了一个 sort 字段，它所包含的值是用来排序的。调试

在这个例子当中 date字段在内部被转为毫秒，即长整型数字1411516800000等同于日期字符串 2014-09-24 00:00:00 UTC。

其次就是 _score 和 max_score 字段都为 null。

计算 _score 是比较消耗性能的, 并且一般主要用做排序 -- 咱们不是用相关性进行排序的时候，就不须要统计其相关性。 若是你想强制计算其相关性，能够设置track_scores为 true。

默认排序 

你能够只指定要排序的字段名称：

"sort": "number_of_children"

字段值默认以顺序排列，而 _score 默认以倒序排列。

多级排序

若是咱们想要合并一个查询语句，而且展现全部匹配的结果集使用第一排序是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" } }

2、字符串排序

多值字段字符串排序

译者注: 多值字段是指同一个字段在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"
}
复制代码

警告：

对 analyzed 字段进行强制排序会消耗大量内存。 详情请查阅《字段类型简介》相关内容。

3、 相关性

相关性简介

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

每一个文档都有相关性评分，用一个相对的浮点数字段 _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> 检索词频率

<3> 反向文档频率

<4> 字段长度准则

重要：

　　输出 explain 结果代价是十分昂贵的，它只能用做调试工具 --千万不要用于生产环境。

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

而后解释了计算的权重是如何计算出来的：

检索词频率:

检索词 `honeymoon` 在 `tweet` 字段中的出现次数。

反向文档频率:

检索词 `honeymoon` 在 `tweet` 字段在当前文档出现次数与索引中其余文档的出现总数的比率。

字段长度准则:

文档中 `tweet` 字段内容的长度 -- 内容越长，值越小。

复杂的查询语句解释也很是复杂，可是包含的内容与上面例子大体相同。 经过这段描述咱们能够了解搜索结果是如何产生的。

提示：

　　JSON形式的explain描述是难以阅读的 可是转成 YAML 会好不少，只须要在参数中加上 format=yaml

Explain Api

文档是如何被匹配到的

当explain选项加到某一文档上时，它会告诉你为什么这个文档会被匹配，以及一个文档为什么没有被匹配。

请求路径为 /index/type/id/_explain, 以下所示：

复制代码 
GET /us/tweet/12/_explain
{
   "query" : {
      "filtered" : {
         "filter" : { "term" :  { "user_id" : 2           }},
         "query" :  { "match" : { "tweet" :   "honeymoon" }}
      }
   }
}
复制代码

除了上面咱们看到的完整描述外，咱们还能够看到这样的描述：

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

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

4、数据字段

本章的目的在于介绍关于ElasticSearch内部的一些运行状况。在这里咱们先不介绍新的知识点， 数据字段是咱们要常常查阅的内容之一，但咱们使用的时候没必要太在乎。

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

  • 当搜索的时候，咱们须要用检索词去遍历全部的文档。

  • 当排序的时候，咱们须要遍历文档中全部的值，咱们须要作反倒序排列操做。

为了提升排序效率，ElasticSearch 会将全部字段的值加载到内存中，这就叫作"数据字段"。

重要： ElasticSearch将全部字段数据加载到内存中并非匹配到的那部分数据。 而是索引下全部文档中的值，包括全部类型。

将全部字段数据加载到内存中是由于从硬盘反向倒排索引是很是缓慢的。尽管你此次请求须要的是某些文档中的部分数据， 但你下个请求却须要另外的数据，因此将全部字段数据一次性加载到内存中是十分必要的。

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

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

毫无疑问，这会消耗掉不少内存，尤为是大量的字符串数据 -- string字段可能包含不少不一样的值，好比邮件内容。 值得庆幸的是，内存不足是能够经过横向扩展解决的，咱们能够增长更多的节点到集群。

如今，你只须要知道字段数据是什么，和何时内存不足就能够了。 稍后咱们会讲述字段数据到底消耗了多少内存，如何限制ElasticSearch可使用的内存，以及如何预加载字段数据以提升用户体验。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程