Lucene默认评分公式是如何工作的
查詢二次评分是如何工作的。
如何在单次请求中实现批量准实时读取操作
如何在单次请求中发送多个查询。
如何对包括嵌套文档和多值字段的数据排序
如何更新已索引的文档。
如何通过使用过滤器来优化查询
如何在ElasticSearch的切面计算机制中使用过滤器和作用域。

为了计算文档嘚分需要考虑以下这些因子:

• 文档权重(document boost):索引期赋予某个文档的权重值。
• 字段权重(field boost ):查询期赋予某个字段的权重值
• 协调因子(coord):基于文档中词项命中个数的协调因子，一个文档命中了查询中的词项越多得分越高。
• 逆文档频率(inverse document frequency ):一个基于词项的因子用来告诉评分公式该词项有多么罕见。逆文档频率越低词项越罕见。评分公式利用该因子为包含罕见词项的文档加权
• 长度范数(( length norm ):每个字段的基于词项个数的归一化因子(茬索引期计算出来并存储在索引中)。一个字段包含的词项数越多该因子的权重越低，这意味着Apache Lucene评分公式更“喜欢”包含更少词项的字段
• 词频(term frequency):一个基于词项的因子，用来表示一个词项在某个文档中出现了多少次词频越高，文档得分越高
• 查询范数(query norm ):一个基于查询的归一化洇子，它等于查询中词项的权重平方和查询范数使不同查询的得分能相互比较，尽管这种比较通常是困难且不可行的

  “1.1.2 Lucene的总体架构”┅节的索引示意图。

TF/IDF公式的理论形式如下:

现在让我们看看Lucene实际使用的评分公式:
从前面的公式我们可以导出一些基本规则:

• 越多罕见嘚词项被匹配上文档得分越高。
• 文档字段越短(包含更少的词项)文档得分越高。
• 权重越高(不论是索引期还是查询期赋予的权重值)文档嘚分越高。

0.90中出现的二次评分功能通过在返回文档集之上执行另外一个查询，重新计算前N个文档的文档得分

从Lucene的角度来看，所谓的查詢改写操作就是把费时的原始查询类型实例改写成一个性能更高的查询类型实例。

最后一条索引应该是原书将Jane写错为Jannet

也许鼡户想找出索引中所有name字段以字母 j 开头的文档

返回结果中有3个文档，这些文档的name字段以字母 j 开头我们并没有显式设置待查询索引的映射，因此ElasticSearch猜测name字段的映射并将其设置为字符串类型并进行文本分析。可使用下面的命令查看索引的映射:

我们看看之前存储到clients索引中嘚数据是如何组织的:
Term(词项)这一列非常重要如果去探究ElasticSearch和Lucene的内部实现，就会发现前缀查询已经改写为下面这种查询:

这意味着我们的前缀查詢已经改写为常数得分查询(constant score query )该查询由一个布尔查询构成，而这个布尔查询又由三个词项查询构成Lucene所做的事情就是:枚举索引中的词项，並利用这些词项的信息来构建新的查询当我们比较改写前后的两个查询的执行效果，会发现改写后的查询性能有所提升尤其是当索引Φ有大量不同词项时。

2.2.3 查询改写的属性

我们可以将rewrite参数存放在代表实际查询的JSON对象中例如，下面的代码:

现在我们来看看rewrite參数有哪些选项可以配置:

)这种处理方法比较耗CPU(因为要计算和保存每个词项的得分)，而且有些查询生成的词项太多从而超出了布尔查询的限制默认为1024个从句。改写后的查询会保存计算出来的得分默认的布尔查询限制可以通过设置elasticsearch.yml文件的index.query.bool.max_ clause_ count属性来修改。但需谨记改写后的咘尔查询的从句越多，查询性能越低
• constant_score_boolean:该选项与前面提到的scoring_boolean类似，但是CPU消耗较少这是因为该过程并不计算每个从句的得分，而是每个从呴得到一个与查询权重相同的常数得分默认情况下等于1，当然我们也可以通过设置查询权重来改变这个默认值与scoring_boolean类似，该选项也有布爾从句数的限制
• constant_score_filter:正如Lucene的Javadoc描述的那样，该选项按如下方式改写原始查询:通过顺序遍历每个词项来创建一个私有的过滤器标记跟每个词项楿关的所有文档。命中的文档被赋予一个跟查询权重相同的常量得分当命中词项数或文档数较大时，该方法比scoring_boolean和constant_ score_boolean执行速度更快
• top_terms_N:该选项將每个生成的词项转化为布尔查询中的一个或从句，并保存计算出来的查询得分与scoring_boolean不同之处在于，该方法只保留了最佳的前N个同项从洏避免超出布尔从句数的限制。
• top_terms_boost_N:该选项与top_ terms_ N类似不同之处在于该选项产生的从句类型为常量得分查询，得分为从句的权重

如何决定何时采用何种查询改写方法?
该问题的答案更多取决于具体的应用场景。简单来说如果你能接受低精度(往往伴随着高性能)，那么可以采用top N查询妀写方法如果你需要更高的查询精度(往往伴随着低性能)，那么应该使用布尔方法

ElasticSearch中的二次评分指的是重新计算查询返回攵档中指定个数文档的得分。这意味着ElasticSearch会截取查询返回文档的前N个并使用预定义的二次评分方法来重新计算它们的得分。

我们嘚范例数据保存在documents.json文件中(本书提供了这些代码)并可用以下命令添加到索引中:

2.3.4 二次评分查询的结构

我们在查询中指定呮返回文档的title和available字段。

这里只是使用了一个简单的查询返回所有的文档并且将每个文档的得分改写为该文档的year字段中的值(本范例只是用來演示二次评分，并没有实际意义)

仔细看看现在让我们看看原始文档以及各个文档的得分。ElasticSearch截取了前N个文档并对它们使用了第二个查詢。这么做的结果是文档的得分等于两个查询的得分之和。

读者应该知道执行脚本性能低下，因此我们在第二个查询上再使用它范唎中的第一个match_all查询可能会返回成千上万的文档，如果直接在这里使用基于脚本的评分那么性能会非常低下。由于二次评分使得我们可以茬原始查询返回文档的前N个文档上重新计算得分因而降低了对性能的影响。

2.3.5二次评分参数配置

在rescore对象中的查询对象中必须配置下面这些参数:

• window_size:窗口大小，该参数默认设置为from和size参数值之和它提供了之前提到的N个文档的相关信息。该参数值指定了每个分片仩参与二次评分的文档N个数
• query_weight:查询权重值，默认等于1原始查询的得分与二次评分的得分相加之前将乘以该值。
• rescore_query_weight:二次评分查询的权重值默认等于1，二次评分查询的得分在与原始查询得分相加之前将乘以该值。
avg和multiply当我们设置该参数值为total时，文档得分为原始查询得分与二佽评分得分之和当该参数值设置为max，文档得分为原始查询得分与二次评分得分中的最大值与max选项类似，当该参数值设置为min时文档得汾为两次查询得分中的最小值。以此类推参数值为avg时，文档得分为两次查询得分的平均值当参数值为multiply时，文档得分为两次杳询得分的塖积

二次评分功能并不能与排序一起使用，这是因为排序发生在二次评分之前

批量取(MultiGet)可以通过_mget端点(endpoint )操作，它允许使用一个请求獲取多个文档与实时获取功能类似，文档获取也是实时的ElasticSearch会返回那些被索引的文档，而不论这些文档可用于搜索还是暂时对查询不可見请查看下面的操作:

与批量取类似，批量查询允许用户将多个查询请求打包到一组不过它的分组略有不同，更像批量索引操莋ElasticSearch将输人解析成一行一行的文本，而文本行(每一对)包含了目标索引、其他参数以及查询串等信息请查看下面这个简单的范例:

URL中的索引洺及类型是可选的，并且会作为剩余输人行的默认参数剩余行可用于存储搜索类型信息(search_type)以及查询执行的路由或提示信息(preference)。因为这些参数並不是必需的在某些特殊情况下，行中可以包含空对象({})甚至行本身为空请求的偶数行负责携带真正的查询。

以上批量查询只发送了三個请求而已两行组成一个查询

返回的JSON结果包含了与批量搜索中的查询相对应的响应对象(response object)数组。如前所述批量查询允许我们将多个独立嘚查询打包到一个请求中，因此与之对应的，不同查询的返回文档可能具有不同的结构(本范例省略了)

该查询范例会返回所有在title字段上臸少命中一个词项的文档，并基于section字段数据排序
也可以通过添加查询的sort部分的missing属性为那些section字段有缺失值的文档益制排序行为。例如这樣设置之前查询范例的sort配置，将section字段值缺失的文档排在最后:

2.5.1 基于多值字段的排序

某些文档的release_dates字段里存储了多个电影上映日期(同一部电影在不同国家的上映日期不同)如果我们使用了ElasticSearch 0.90，我们可以如此构造查询请求:

例子中ElasticSearch将基于每个文档的release dates字段的最小值进荇排序。mode参数可以设置为以下这些值:

• min:升序排序的默认值ElasticSearch将依照该字段的最小值进行排序。
• max:降序排序的默认值ElasticSearch将依照该字段的最大值进荇排序。
请注意后面两个选项只对数值类型字段有效。

注意“_geo_distance”并非一个具体的字段，loc才是具体的字段

2.5.3 基于嵌套对象的排序

基于嵌套文档的字段排序，对以下两种情形都适用:使用了显式嵌套映射(在映射中配置type="nested")的文档以及使用了對象类型的文档但是，两者之间的一些细微区别仍需要注意

假设我们索引了如下数据:

正如你所见，文档中有嵌套对象并且某些字段Φ有多个值(如存在多张选票)。
当使用对象类型(object type)时可以简化查询，这是因为整个对象结构被当成一个Lucene文档进行存储的而在使用嵌套类型嘚时候，ElasticSearch需要更多精确的字段信息这是因为这些文档确实是独立的Lucene文档。但有些时候使用nested_path属性会更加便捷。

查询返回结果按嵌套对象嘚users字段最小值降序排序

如果我们将嵌套文档中的子文档视为一种数据类型，则可以将查询简化为如下形式:

• 按照严格的嵌套类型查询

在索引一个新文档的时候Lucene会对每个字段进行分析并产生词条流，词条流中的词条可能会经过滤器的额外处理而没有过滤掉的词条会写人倒排索引中。索引过程中一些不需要的信息可能会被抛弃，这些信息包括:某些特殊词条的位置(当词项向量没有存储时)特定词汇(停用词或哃义词)，词条的变形(如词干还原)因此，我们无法更新索引中的文档并且在每次修改文档时不得不向索引发送文档所有字段的数据。

但ElasticSearch鈳以通过使用_source伪字段存储和检索文档的原始数据来解决这个问题当用户需要更改文档时，ElasticSearch会获取_source字段中的值做相应的修改，然后向索引提交一个新文档当然，为了使这个特性生效_source字段必须是可用的。更新命令一个很大的局限性就是它只能更新单个的文档目前还不支持通过查询实现批量更新。

作为示例,本节的其余部分都将使用下面命令所索引的文档:

2.6.2 使用脚本按条件哽新

有些时候在修改文档的时候添加一些额外的逻辑是很有好处的，基于这点考虑ElasticSearch允许用户结合脚本使用更新API。例如我们发送下面這样的请求:
script字段定义了要对文档进行的操作，这可以是任何脚本在范例中我们指派了ctx变量来引用源文档，但一般来说脚本中会定义多個变量。通过使用ctx._source我们可以修改当前字段或创建新字段(如果引用不存在的字段，ElasticSearch会自动创建这个字段)这正是范例中ctx._source.year =new_date语句产生的动作。此外也可以使用remove()方法来移除某些字段，例如:

2.6.3 使用更新API创建或删除文档

更新API不仅仅可以用来修改字段也可以用來操作整个文档。upsert属性允许用户在当URL中地址不存在时创建一个新的文档请查看下面这个命令:

该命令修改了某个已有文档的year字段(该文档位於索引library中，book类型文档ID为1)。如果该文档不存在将会创建一个新文档，并且该文档会创建一个新字段title ,如请求命令中upset部分定义的那样此外，前面的命令也可以使用脚本重写为以下形式:

最后一个有趣的特性是有条件地移除整个文档具体可以通过设置ctx.op的值为delete来实现：

下面一种查询方法，该查询组合了查询类型与过滤器:

我们已经使用了filtered查询来同时包含查询和过滤器元素第一次执行该查询以后， 过濾器就会被ElasticSearch缓存起来如果后续的其他查询也要使用该过滤器，则它将会 被重复利用从而避免ElasticSearch重复加载相关数据。

过滤器缓存(filter cache )用来存儲过滤器的结果。而且被缓存的过滤器 并不需要消耗过多的内存(因为它们只存储了哪些文档能与过滤器相匹配的相关信息)，而且可供后續所有与之相关的查询重复使用从而极大地提高了查询性能。

并不是所有过滤都默认被缓存
缓存很有用但事实上ElasticSearch并不是默认缓存所有過滤器。这是因为在ElasticSearch中某些过滤器使用了字段数据缓存这是一种特殊的缓存，它可以在基于字段数据 的排序时使用也能在计算切面结果时使用。以下过滤器默认不缓存:

上面提到的过滤器中最后三个本身并不使用字段缓存，但由于它们操作其他过滤器 因而它们不缓存。

如果有需要ElasticSearch允许用户通过设置_cache和_cache_ key属性来开启或关闭 过滤器的缓存机制。回到先前的例子进行相关配置从而缓存词项过滤器结果，缓存的key 为year_1981_cache:

• 通过名称清空特定过滤器缓存：

2.7.2 词项查找过滤器

缓存和各种标准查询并不是ElasticSearch的全部家当随着ElasticSearch 0.90的发布， 又一个精巧嘚过滤器可供我们使用了它用于给一个具体的查询传递从ElasticSearch取回的多个词项(与SQL的IN操作符类似)。

现在考虑一下如何获取某个特定用户购买嘚所有书籍，例如ID为 1 的用户。

• 笨拙的方法分两步骤进行
  查找用户1所有信息，并取books字段表示该用户所有书籍的IDs

然后根据上述IDs查找所有books：

因为ElasticSearch优先在本地执行词项查询以避免不必要的网络开销和延迟，因而上述查询时若client索引与book索引在同一分片能提高查询的性能。

词项查詢过滤器缓存设置
前面提到过为了提供词项查找功能，ElasticSearch引进了一种新的缓存类型它使用 了一种快速的LRU(最近最少使用算法)缓存来处理词項缓存。

为了配置这种缓存用户可以在elasticsearch.yml文件中配置下面这些属性:

• indices.cache.filter.terms.size:默认设置ElasticSearch词项查找缓存的最大内存使用 量为10mb。对于大多数案例来说这個默认值够用了，但如果要加载更多的数据至缓存中那么可以调大该参数值。

2.8.2 切面计算和过滤

尽管查询被限制为只返回category字段值為book的文档但是对切而计算来说,切面作用于books索引的所有文档(因为使用了match_all查询)。系统只在查询结果之上计算切面结果如果你在filter对象内部且茬query对象外部包含了过滤器，那么这些过滤器将不会对参与切面计算的文档产生影响

查询执行以后，将得到下面的返回结果:

2.8.3 过滤器作为查询的一部分

切面仅依赖于查询所以让查询中包含过滤

切面计算作用于查询返回结果上，且跟事前预期的结果一樣这正是因 为过滤器成为了查询的一部分!在我们的案例中, 切面计算结果包含两个范围，每个范围 只有一个文档

切面有自己嘚过滤机制，并与查询同时生效

考虑一下上述查询不变，但如果只想为title字段包含词项2的书籍计算分组我们应该怎么做。
在切面类型的楿同层级上使用facet_filter过滤器能通过使用过滤器减少计算切面时 的文档数，就像在查询时使用过滤器那样

切面是全局的，不依赖於查询

如果我们想查询所有category为book的文档但同时又要显示索引中所有文档的基于范围的切面计算结果，应该如何处理呢?幸运的是此处并不需要强制运行第二个查询， 这是因为可以使用全局切面作用域(global faceting scope)来达成目的并具体通过将切面类型的global属性配置为true来实现。