《深入理解Elasticsearch（原书第2版）》一第2章 查询DSL进阶

2019独角兽企业重金招聘Python工程师标准>>>

第2章

查询DSL进阶
在上一章，我们了解了什么是Apache Lucene，它的整体架构，以及文本分析过程是如何完成的。之后，我们还介绍了Lucene的查询语言及其用法。除此之外，我们也讨论了Elasticsearch，讨论了它的架构，以及一些核心概念。在本章，我们将深入研究Elasticsearch的查询DSL（Domain Specific Language）。在了解那些高级查询之前，我们将先了解Lucene评分公式的工作原理。到本章结束，将涵盖以下内容：

• Lucene默认评分公式是如何工作的
• 什么是查询重写
• 什么是查询模板以及如何使用查询模板
• 如何优化复杂的Boolean查询
• 复杂Boolean查询的性能奥秘
• 如何为特定场景选择合适的查询类型

2.1　Apache Lucene默认评分公式解释

评分是Apache Lucene查询处理过程的一个重要环节。评分是指针对给定查询计算某个文档的score属性的过程。什么是文档得分？它是一个刻画文档与查询匹配程度的参数。在本节，我们将了解Apache Lucene的默认评分机制：TF/IDF（词频/逆文档频率）算法以及它是如何影响文档查询结果的。了解评分公式的工作原理对构造复杂查询以及分析查询中因子的重要性都是很有价值的。同时，掌握Lucene评分机制的基础知识有助于我们更好地优化查询来获取符合我们使用场景的结果。

2.1.1　何时文档被匹配上

一个文档被Lucene返回，意味着该文档与用户提交的查询是匹配的。在这种情况下，每个被返回文档会有一个得分。在某些场景下，所有文档的得分都一样（比如使用constant_score查询），不过一般情况下，各个文档的得分是不一样的。得分越高，文档更相关，至少从Apache Lucene及其评分公式的角度来看是这样的。得分还取决于匹配的文档、查询和索引内容，因此，很显然同一个文档对不同查询的得分是不同的。读者需要注意，同一文档在不同查询中的得分不具备可比较性，不同查询返回文档中的最高得分也不具备可比较性。这是因为文档得分依赖多个因子，除了权重和查询本身的结构，还依赖被匹配的词项数目、词项所在字段，以及用于查询规范化的匹配类型，如此等等。在一些比较极端的情况下，同一个文档在相似查询中的得分非常悬殊，仅仅是因为使用了自定义得分查询或者命中词项数的急剧变化。
现在，让我们再回到评分过程。为了计算文档得分，我们需要考虑以下这些因子。

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

2.1.2　TF/IDF评分公式

从Lucene 4.0版本起，Lucene引入了多种不同的打分公式，这一点或许你已经有所了解了。不过，我们还是希望在此探索一下默认的TF/IDF打分公式的一些细节。请记住，为了调节查询相关性，你并不需要深入理解这个公式的来龙去脉，但是了解它的工作原理却非常重要，因为这有助于简化相关度调优过程。
1. Lucene的理论评分公式
TF/IDF公式的理论形式如下：

上面的公式融合了布尔检索模型和向量空间检索模型。我们不打算在此讨论理论评分公式，而是直接跳到实践中使用的评分公式，看看Lucene内部是如何实现和使用评分公式的。
　关于布尔检索模型和向量空间检索模型的知识远远超出了本书的讨论范围，想了解更多相关知识，请参考http://en.wikipedia.org/wiki/Standard_Boolean_model 和http://en.wikipedia.org/ wiki/Vector_Space_Model。
2. Lucene的实际评分公式
现在让我们看看Lucene实际使用的评分公式：

也许你已经看到了，评分公式是一个关于查询q和文档d的函数，正如我们之前提到的一样。有两个因子并不直接依赖查询词项，它们是coord和queryNorm，这两个因子与查询词项的一个求和公式相乘。
求和公式中每个加数由以下因子连乘所得：词频，逆文档频率，词项权重，范数。范数就是之前我们提到过的长度范数。
这个公式听起来很复杂。请别担心，你并不用记住所有的细节，你只需要意识到哪些因素是与评分有关的即可。从前面的公式我们可以导出一些基本的规则：

• 越罕见的词项被匹配上，文档得分越高。Lucene认为包含独特单词的文档比包含常见单词的文档更重要。
• 文档字段越短（包含更少的词项），文档得分越高。通常，Lucene更加重视较短的文档，因为这些短文档更有可能和我们查询的主题高度吻合。
• 权重越高（不论是索引期或是查询期赋予的权重值），文档得分越高。因为更高的权重意味着特定数据（文档、词项、短语等）具有更高的重要性。 正如你所见，Lucene将最高得分赋予同时满足以下条件的文档：包含多个罕见查询词项，词项所在字段较短（该字段索引了较少的词项）。该公式更“喜欢”包含罕见词项的文档。 　如果你想了解更多关于Apache Lucene TF/IDF评分公式的信息，请参考Apache lucene 中TFIDFSimilarity类的文档：http://lucene.apache.org/core/4_9_0/core/org/ apache/lucene/search/similarities/TFIDFSimilarity.html.

2.1.3　Elasticsearch如何看评分

总而言之，Elasticsearch使用了Lucene的评分功能，幸运的是Elasticsearch允许我们挑选可用的similarity类实现，或者自定义similarity类，来替换默认的评分算法。不过请记住，Elasticsearch不仅仅是Lucene的简单封装，因为它虽然使用了Lucene的评分功能，但不仅限于Lucene的评分功能。
用户可以使用各种不同的查询类型，以精确控制文档评分的计算。例如使用function_score查询时,可以通过使用脚本(scripting)来改变文档得分，也可以使用Elasticsearch 0.90中出现的二次评分功能，通过在返回文档集之上执行另外一个查询，重新计算top-N文档的得分。
　想了解更多Apache Lucene查询类型，请参考http://lucene.apache.org/core/4_9_0/queries/org/apache/lucene/queries/package-summary.html上的相关文档。

2.1.4　一个例子

现在，我们已经了解评分的工作原理。接下来我们看一个在现实生活中应用评分的简单例子。首先我们需要创建一个名为scoring的新索引。使用如下命令创建这个索引：

简单起见，我们使用了只有一个物理分片和0个副本的索引（我们不需要在这个例子中关心分布式文档频率）。我们需要索引一个简单的文档，代码如下：

接着我们执行一个简单的匹配（match）查询，查询的词项是“document”。

Elasticsearch返回的结果如下：

显然，刚才索引的这个文档被匹配上了，并且被赋予了得分。我们可以通过下面这条命令来查看得分的计算过程：

Elasticsearch返回的结果如下：

可以看出，Elasticsearch给出了针对给定文档和查询的详细的得分计算过程。同时可以看出，得分等于词项频率（本例中是1）和逆文档频率（0.30685282）以及字段范数（0.625）的乘积。
现在，我们再把另一个文档加入索引。

此时，如果执行最开始的查询，我们将看到如下响应：

现在，可以对比一下TF/IDF评分公式在现实场景中的工作了。在把第2个文档索引到相同分片后（请记住我们创建的索引只有一个分片且没有副本），得分发生了变化，尽管此时的查询和刚才的一样。这是因为一些影响得分的因子已经改变了。比如，逆文档频率变了，因此得分也会跟着改变。我们还需要注意对比一下两个文档的得分。我们查询了一个单词“document”，查询匹配上了两个文档的相同字段的相同词项。第2个文档的得分为什么较低，是因为和第1个文档相比，它的name字段多了一个词项。根据先前的知识储备，我们知道，文档越短，Lucene给出的得分越高。
希望这个简短的介绍会让你对评分工作机制认识得更清楚，在你需要优化查询时理解目标查询的工作过程。

http://blog.csdn.net/molong1208/article/details/50623948

2.2　查询改写

之前我们探讨了评分机制，这些知识非常珍贵，特别是当你尝试改进查询相关性时。我们还认为，在对查询进行调试时，也很有必要搞清楚查询是如何执行的。因此我们决定在本节介绍一下查询改写是如何工作的，为什么需要查询改写，以及我们应该如何控制它。
如果你之前使用过诸如前缀查询或通配符查询之类的查询类型，那么你会了解这些都是基于多词项的查询，它们都涉及查询改写。Elasticsearch使用查询改写是出于对性能的考虑。从Lucene的角度来看，所谓的查询改写操作，就是把费时的原始查询类型实例改写成一组性能更高的查询类型实例，从而加快查询执行速度。查询改写过程对客户端不可见，不过最好能够知道我们可以修改查询改写过程。举个例子，让我们看看Elasticsearch是如何处理前缀查询的。

2.2.1　前缀查询示例

演示查询改写过程的最好方式莫过于通过范例深入了解该过程的内部实现机制，尤其是要去了解原始查询中的词项是如何被改写成目标查询中那些词项的。假设我们索引了下面这些文档中的数据：

现在我们想找出索引中所有name字段以字母j开头的文档。简单起见，我们在clients索引中执行以下查询：

这里使用了一个简单的前缀查询，想检索出所有name字段以字母j开头的文档。我们同时也设置了查询改写属性以确定执行查询改写的具体方法，不过现在我们跳过该参数，具体的参数值将在本章的后续部分讨论。
执行前面的查询以后，我们将得到下面的结果：

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

2.2.2　回到Apache Lucene

现在我们回到Lucene。如果你还记得Lucene倒排索引是如何构建的，你会指出倒排索引中包含了词项、词频以及文档指针（如果忘了，请重新阅读1.1节）。现在我们看看之前存储到clients索引中的数据大概是如何组织的。

Term这一列非常重要。如果我们去探究Elasticsearch和Lucene的内部实现，将会发现前缀查询被改写为下面这种查询：

我们可以用Elasticsearch API来检查重写片段。首先，使用Explain API执行如下命令：

执行结果如下：

可以看到，Elasticsearch对name字段使用了一个词项是joe的constant_score查询。当然，这一步发生在Lucene中，Elasticsearch实际上只是从缓存中获取这些词项。这一点可以用Validate查询API来验证。

Elasticsearch返回的结果如下：

2.2.3　查询改写的属性

当然，多词项查询的rewrite属性也可以支持除了“constant_score_boolean”之外的其他取值。我们可以通过这个属性来控制查询在Lucene内部的改写方式。我们可以将rewrite参数存放在代表实际查询的JSON对象中，例如，像下面的代码这样：

现在让我们来看看rewrite参数有哪些选项可以配置。
scoring_boolean：该选项将每个生成的词项转化为布尔查询中的一个或从句（Boolean should clause）。这种改写方法需要针对每个文档都计算得分。因此，这种方法比较耗费CPU（因为要计算和保存每个词项的得分），而且有些查询生成了太多的词项，以至于超出了布尔查询默认的1024个从句的限制。默认的布尔查询限制可以通过设置Elasticsearch.yml文件的index.query.bool.max_clause_count属性来修改。用户需谨记，改写后的布尔查询的从句数越多，查询性能越低。
constant_score_boolean：该选项与前面提到过的scoring_boolean类似，但是CPU耗费更少，这是因为并不计算每个从句的得分，而是每个从句得到一个与查询权重相同的一个常数得分，默认情况下等于1，我们也可以通过设置查询权重来改变这个默认值。与scoring_boolean类似，该选项也有布尔从句数的限制。
constant_score_filter：正如Lucene的Javadocs描述的那样，该选项按如下方式改写原始查询—通过顺序遍历每个词项来创建一个私有的过滤器，标记所有包含这个词项的文档。命中的文档被赋予一个与查询权重相同的常量得分。当命中词项数或文档数较大时，该方法比scoring_boolean 和constant_score_boolean执行速度更快。
top_terms_N：该选项将每个生成的词项转化为布尔查询中的一个或从句，并保存计算出来的查询得分。与scoring_boolean不同之处在于，该方法只保留最佳的N个词项，以避免触及布尔从句数的限制，并提升查询整体性能。
top_terms_boost_N：该选项与top_terms_N类似，不同之处在于它的文档得分不是通过计算得出的，而是被设置为跟查询权重（boost）一致，默认值为1。
　当rewrite属性设置为constant_score_auto或者没有设置时，Elasticsearch会根据查询的类型及其构造方式来决定是使用constant_score_filter还是constant_score_boolean。
现在，让我们再看一个例子。如果我们想在范例查询中使用top_terms_N选项，并且N的值设置为2，那么查询看起来与下面的代码类似：

从Elasticsearch返回的结果中可以看出，和我们之前使用的查询不同，这里的文档得分都不等于1.0。

这是因为top_terms_N需要保留得分最高的N个词项。
结束本节之前，读者应该会产生一个疑问，我们如何决定何时采用何种查询改写方法？该问题的答案更多地取决于您的应用场景。简单来说，如果您能接受较低的精度和相关性（但是追求更高的性能），那么可以采用top-N查询改写方法。如果您需要更高的查询精度和更好的相关性（同时可以接受较低的性能），那么应该采用布尔方法。

 

 

 

 

 

转载于:https://my.oschina.net/LucasZhu/blog/1559501