《深入理解Elasticsearch(原书第2版)》一2.2 查询改写

本节书摘来自华章出版社《深入理解Elasticsearch(原书第2版)》一书中的第2章,第2.2节,作者[美]拉斐尔·酷奇(Rafal Ku) 马雷克·罗戈任斯基(Marek Rogoziski),更多章节内容可以访问云栖社区“华章计算机”公众号查看

2.2 查询改写

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


bbfc8731728d51dff7052f97b251d589cfa3e3ad


36993acfda9ade4abc867afddf62b27a4500227a

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


987abeec3f334a8b3bd469045c01f767881cee41

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


b5a2c2137a9745b0a4f4b10c3276542740fc37bd


87fd3040442e05a6740c723add7b98b18486ab03

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


32a2ec29bd51bfb27ca06191f6d88764c49f0bae

Elasticsearch将返回类似下面的结果:

96e79f02a2250a981f7dca572600b07c0da62510

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


ad575765d493e6b638ef11cf5c4a7e268763e2f7

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


f3ea2844f0fadaefd90b5894bac56e2a84963586

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


8d643aa4e0e5db0bb86478198395b3c5bad2c09f

执行结果如下:


002f7aa2fb9623cfea75b7767367efd91004db81

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


95f825cf5ec144ddd11970e9b4f16b9bfe888c0e


2358057eeb6bf6509ce33a51fa11caaaaf8e1e1d

Elasticsearch返回的结果如下:


24ece9479811df5c990ac7b3e6fdfbea43479617

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


8562372db76d2af88b37efe81df93926fb11b3d1

现在让我们来看看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,那么查询看起来与下面的代码类似:


a56cedc404b734c72a25f4ac74b91aea0c6c6b43

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


8be2d567924c72460e69750f993cdef838c006b7


60ad937d4836d53470d91fe105a32ca676dab590

这是因为top_terms_N需要保留得分最高的N个词项。
结束本节之前,读者应该会产生一个疑问,我们如何决定何时采用何种查询改写方法?该问题的答案更多地取决于您的应用场景。简单来说,如果您能接受较低的精度和相关性(但是追求更高的性能),那么可以采用top-N查询改写方法。如果您需要更高的查询精度和更好的相关性(同时可以接受较低的性能),那么应该采用布尔方法。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值