少啰嗦,直接看东西。——罗永浩
1、query和filter的本质区别?
以下几张图能更好的概括:
query关注点:此文档与此查询子句的匹配程度如何?
filter关注点:此文档和查询子句匹配吗?
2、Query检索细化关注点
1)是否包含?
确定文档是否应该成为结果的一部分.
2)相关度得分多少?
除了确定文档是否匹配外,查询子句还计算了表示文档与其他文档相比匹配程度的_score。
3)得分越高,相关度越高。
更相关的文件,在搜索排名更高。
典型应用场景:
1)全文检索——这种相关性的概念非常适合全文搜索,因为很少有完全“正确”的答案。
举例如下:
文档中存在字段hotel_name:“上海浦东香格里拉酒店”
IK实际分词结果如下:
上海浦东,上海,浦东,香格里拉,格里,里拉,酒店。
也就是说,搜索以上关键词都能搜到:hotel_name:“上海浦东香格里拉酒店”的酒店。这些都是“相关”的。
但是搜索:“香格里” 是搜索不到结果的。
2)包含单词“run”, 但也匹配"runs", "running", "jog"或者"sprint"。(都是奔跑的意思)
3、filter过滤细化关注点
1)是否包含?
确定是否包含在检索结果中,回答只有“是”或“否”。
2)不涉及评分。
在搜索中没有额外的相关度排名。
3)针对结构化数据。
适用于完全精确匹配,范围检索。
参见官网举例:
以下场景适用于filter过滤检索:
举例1:时间戳timestamp 是否在2015至2016年范围内?
举例2:状态字段status 是否设置为“published”?
4)更快。
只确定是否包括结果中,不需要考虑得分。
为什么会更快?——经常使用的过滤器将被Elasticsearch自动缓存,以提高性能。
4、query和filter的性能不同
过滤查询(filter)是对集合包含/排除的简单检查,这使得它们计算速度非常快。 当至少有一个过滤查询是“稀疏”(仅有少量匹配的文档)时,可以利用各种优化,并且可以将缓存经常使用的filter过滤查询缓存在内存中以加快访问速度。
对比之下,query检索(评分查询)不仅要查找匹配的文档,还要计算每个文档的相关程度,这通常会使其比非评分文档更复杂。 另外,查询结果不可缓存。
由于倒排索引,只有几个文档匹配的简单评分查询(query检索)可能会比跨越数百万个文档的过滤器(filter过滤)表现得更好。 但是,一般来说,fiter过滤的性能将胜过评分查询(query检索)。
过滤(filter)的目标是减少必须由评分查询(query)检查的文档数量。
5、filter过滤怎么缓存呢?
Elasticsearch将创建一个文档匹配过滤器的位集bitset(如果文档匹配则为1,否则为0)。 随后用相同的过滤器执行查询将重用此信息。
每当添加或更新新文档时,位集bitset也会更新。
6、使用场景
-
全文检索以及任何使用相关性评分的场景使用query检索。
- 除此之外的其他使用filter过滤器过滤。
7、query和filter实战
ebay在Elasticsearch使用经验中总结到:
Use filter context instead of query context if possible.
即:如果可能,请使用filter过滤器上下文而不是query查询上下文。
查询query和过滤器filter已合并(在ES1.X版本是分开的,存在filtered检索类型)。
ES高版本(2.X/5.X/6.x以后),任何查询子句都可以在“查询上下文query”中用作查询,并在“过滤器上下文filter”中用作过滤器。
举例:
1GET /_search2{3 \"query\": {4 \"bool\": {5 \"must\": [6 { \"match\": { \"title\": \"Search\" }},7 { \"match\": { \"content\": \"Elasticsearch\" }}8 ],9 \"filter\": [10 { \"term\": { \"status\": \"published\" }},11 { \"range\": { \"publish_date\": { \"gte\": \"2015-01-01\" }}}12 ]13 }14 }15}
8、小结
官网&源码才是王道。
多看、多思、多总结。弄清原理,高效开发才有了保障!
参考:
1、官网:
http://t.cn/R14moYO
http://t.cn/R14kLl6
2、实战:
http://t.cn/R1bZwy8
http://t.cn/RQhzDiP
3、Google工程师视频
加入知识星球,更短时间更快习得更多干货!