默认情况下，结果集会按照相关性进行排序——相关性越高，排名越靠前。在本文中会讲述相关是什么以及它是如何计算的。在此之前，我们先看一下sort参数的使用方法。
为了使结果可以按照相关性进行排序，我们需要一个相关性的值。在Elasticsearch的查询结果中，相关性分值会用_score字段来给出一个浮点型的数值，所以默认情况下，结果集以_score进行倒序排列。
有时，即便如此，你还是没有一个有意义的相关性分值。比如，以下语句返回所有tweets中user_id是否包含值1：
GET /_search
"query" : {
"filtered" : {
"filter" : {
"term" : {
"user_id" : 1
过滤语句与_score没有关系，但是有隐含的查询条件match_all为所有的文档的_score设值为1.也就相当于所有的文档相关性是相同的。
字段值排序
下面的例子中，对结果集按照时间排序，这也是最常见的情形，将最新的文档排列靠前。我们使用sort参数进行排序：
GET /_search
"query" : {
"filtered" : {
"filter" : { "term" : { "user_id" : 1 } }
"sort" : { "date" : { "order" : "desc" } }
你会发现这里有两个不同点：
<1> _score 字段没有经过计算，因为他没有用作排序。
<2> date 字段被转为毫秒当做排序依据。
首先，在每个结果中增加了一个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"
多值字段字符串排序
analyzed字符串字段同事也是多值字段，在这些字段上排序往往得不到你想要的值。比如你分析一个字符“fine old art”，他最终会得到三个值。例如我们想要按照第一个词首字母排序，如果第一个单词相同的话，再用第二个词的首字母排序，以此类推，可惜Elasticsearch在进行排序时是得不到这些信息的。
当然你可以使用min和max模式来排序（默认使用的是min模式），但它是依据art或者old排序，而不是我们所期望的那样。
为了使一个string字段可以进行排序，他必须只包含一个词：即完整的not_analyzed字符串。当然我们需要对字段进行全文本搜索的时候还必须使用analyzed。
在_source下相同的字符串上排序两次会造成不必要的资源浪费。而我们想要的是一个字段中同时包含这两种索引方式。现在我们介绍一个在所有核心字段类型上通用的参数fields，这样我们就可以改变他的mapping：
“tweet” : {
"type" : "string",
"analyzer" : "english"
改变后的多值字段mapping如下：
<1> tweet字段用于全文本的analyzed索引方式不变。
<2> 新增的tweet.raw子字段索引方式是not_analyzed。
现在，在给数据创建索引后，我们既可以使用tweet字段进行全文本搜索，也可以用tweet.raw字段进行排序：
GET /_search
"query" : {
"match" : {
"tweet" : "elasticsearch"
"sort" : "tweet.raw"
警告，对analyzed字段进行强制排序会消耗大量内存。
相关性简介
我们曾经讲过，默认情况下，返回结果是按相关性倒序排列的。但是什么是相关性？相关性如何计算？
每个文档都有相关性评分，用一个相对的浮点数字段_score来表示——_score的评分越高，相关性越高。
查询语句会为每个文档添加一个_score字段。评分的计算方式取决于不同的查询类型——不同的查询语句用于不同的目的：fuzzy查询会计算与关键词的拼写相似程度，terms查询会计算找到的内容与关键词组成部分匹配的百分比，但是一般意义上我们说的全文本搜索是指计算内容与关键词的类似程度。
Elasticsearch的相似度算法被定义为TF/IDF，即检索词频率/反向文档频率，包括以下内容：
检索词频率：
检索词在该字段出现的频率？出现频率越高，相关性也越高。字段中出现过5次要比只出现过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参数会为每个匹配到的文档产生一大堆额外内容，但是花时间去理解它是很有意义的。
首先，我们看一下普通查询返回的元数据：
这里加入了该文档来自于哪个节点哪个分片上的信息，这对我们是比较有帮助的，因为词频率和文档频率是在每个分片中计算出来的，而不是每个索引中：
然后返回值中_explanation会包含在每一个入口，告诉你采用了哪种计算方式，并让你知道计算的结果以及其他详情：
重要：输出explain结果代价是十分昂贵的，它只能用作调试工具——千万不要用于生产环境。
第一部分是关于计算的总结。告诉了我们“honeymoon”在tweet字段中的检索词频率/反向文档频率或TF/IDF，（这里的文档0是一个内部的ID，跟我们没有关系，可以忽略。）然后解释了计算的权重是如何计算出来的：
检索词频率：
检索词“honeymoon”在“tweet”字段中的出现次数。
反向文档频率：
检索词“honeymoon”在“tweet”字段在当前文档出现次数与索引中其他文档的出现总数的比率。
字段长度准则：
文档中“tweet”字段内容的长度——内容越长，这个文件中D字段的长度是多长，这个数字越小。
复杂的查询语句解释也非常复杂，但是包含的内容与上面例子大致相同。通过这段描述我们可以了解搜索结果是如何产生的。
提示：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" } }
除了上面我们看到的完整描述外，我们还可以看到这样的描述：
也就是说我们的user_id过滤子句使该文档不能匹配到。
本文的目的在于介绍关于Elasticsearch内部的一些运行情况。
当你对一个字段进行排序时，Elasticsearch需要进入每个匹配到的文档得到相关的值。倒排索引在用于搜索时是非常卓越的，但却不是理想的排序结构。
-
当搜索的时候，我们需要用检索词去遍历所有的文档。
-
当排序的时候，我们需要遍历文档中所有的值，我们需要做反倒序排列操作。
为了提高排序效率，Elasticsearch会将所有字段的值加载到内存中，这就叫做“数据字段”。
重要：Elasticsearch将所有字段数据加载到内存中并不是匹配的那部分数据。而是索引下所有文档中的值，包括所有类型。
将所有字段数据加载到内存中因为从硬盘反向倒排序索引是非常缓慢的。尽管你这次请求需要的是某些文档的部分数据，但你下个请求却需要另外的数据，所以讲所有字段数据一次性加载到内存中是十分必要的。
Elasticsearch中的字段数据常被应用到以下场景：
-
对一个字段进行排序
-
对一个字段进行聚合
-
某些过滤，比如地理位置过滤
-
某些与字段相关的脚本计算
毫无疑问，这会消耗掉很多内存，尤其是大量的字符串数据——String字段可能包含很多不同的值，比如邮件内容。值得庆幸的是，内存不足时可以通过横向扩展解决的，我们可以增加更多的节点到集群。
现在，你只需要知道字段数据是什么，和什么内存不足就可以了。
转载并且补充：https://mp.weixin.qq.com/s/0g86s-o7kgn8ZUxA3UBc0w 请看原文
读者提问：ES 的
权重
排序
有没有示列，参考参考？
刚好之前也稍微接触过，于是写了这篇文章，可以简单参考下。
在很多复杂的业务场景下，
排序
的规则会比较复杂，单一的降序，升序无法满足日常需求。不过 ES 中提供了给文档加
权重
的方式来
排序
，还是挺好用的。
首先初始化三条测试数据，方便查看效果：
POST score-test/_doc
"id": 1,
"title":
现在要根据关键字去检索数据，我们主要是根据name和address去检索数据，给name和address分配配置上相应的score，然后根据评分
排序
另外也会传一个城市名称，需要对上面检索出的数据，再加上城市名称的评分，最后再
排序
比如说有3条数据如下
* 希望那条记录排名靠前，需要将记录中包含的字段值设置其加权值，调高加权值，可以使得排名越靠前。反之，靠后。
SearchResponse response = client.prepareSearch("myblog")
.setTypes("article")
//只要t.
