标签：酒店 浦东 集合 bitset 设置 参考 排名 block ast
少啰嗦，直接看东西。——罗永浩以下几张图能更好的概括：
query关注点：此文档与此查询子句的匹配程度如何？
filter关注点：此文档和查询子句匹配吗？
1）是否包含？
确定文档是否应该成为结果的一部分.
2）相关度得分多少？
除了确定文档是否匹配外，查询子句还计算了表示文档与其他文档相比匹配程度的_score。
3）得分越高，相关度越高。
更相关的文件，在搜索排名更高。
典型应用场景：
1）全文检索——这种相关性的概念非常适合全文搜索，因为很少有完全“正确”的答案。
举例如下：
文档中存在字段hotel_name：“上海浦东香格里拉酒店”
IK实际分词结果如下：
上海浦东,上海,浦东,香格里拉,格里,里拉,酒店。
也就是说，搜索以上关键词都能搜到：hotel_name：“上海浦东香格里拉酒店”的酒店。这些都是“相关”的。
但是搜索：“香格里” 是搜索不到结果的。
2）包含单词“run”， 但也匹配"runs", "running", "jog"或者"sprint"。（都是奔跑的意思）
1）是否包含？
确定是否包含在检索结果中，回答只有“是”或“否”。
2）不涉及评分。
在搜索中没有额外的相关度排名。
3）针对结构化数据。
适用于完全精确匹配，范围检索。
参见官网举例：
以下场景适用于filter过滤检索：
举例1：时间戳timestamp 是否在2015至2016年范围内？
举例2：状态字段status 是否设置为“published”？
4）更快。
只确定是否包括结果中，不需要考虑得分。
为什么会更快？——经常使用的过滤器将被Elasticsearch自动缓存，以提高性能。
过滤查询（filter）是对集合包含/排除的简单检查，这使得它们计算速度非常快。 当至少有一个过滤查询是“稀疏”（仅有少量匹配的文档）时，可以利用各种优化，并且可以将缓存经常使用的filter过滤查询缓存在内存中以加快访问速度。
对比之下，query检索(评分查询)不仅要查找匹配的文档，还要计算每个文档的相关程度，这通常会使其比非评分文档更复杂。 另外，查询结果不可缓存。
由于倒排索引，只有几个文档匹配的简单评分查询（query检索）可能会比跨越数百万个文档的过滤器（filter过滤）表现得更好。 但是，一般来说，fiter过滤的性能将胜过评分查询（query检索）。
过滤（filter）的目标是减少必须由评分查询（query）检查的文档数量。
Elasticsearch将创建一个文档匹配过滤器的位集bitset（如果文档匹配则为1，否则为0）。 随后用相同的过滤器执行查询将重用此信息。
每当添加或更新新文档时，位集bitset也会更新。
全文检索以及任何使用相关性评分的场景使用query检索。
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 /_search
2{
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}官网&源码才是王道。
多看、多思、多总结。弄清原理，高效开发才有了保障！
参考：
1、官网：
2、实战：
3、Google工程师视频
加入知识星球，更短时间更快习得更多干货！
吃透 | Elasticsearch filter和query的不同
标签：酒店 浦东 集合 bitset 设置 参考 排名 block ast
原文地址：https://blog.51cto.com/15050720/2562046
