Elasticsearch中Query与Filter之间的区别

查询器与过滤器

尽管我们之前已经涉及了查询DSL，然而实际上存在两种DSL：查询DSL（query DSL）和过滤DSL（filter DSL）。而查询子句（query clause）和过滤器子句（filter clause）实际上也类似，只是它们的目的稍微不同。

过滤器（filter）用于向所有文档提问是非题，通常用于过滤文档的某个字段是否包含某个准确的值：

* 创建日期是否在2013-2014年间？

* status字段是否为published？

* lat_lon字段是否在某个坐标的10公里范围内？

查询器（query）很像过滤器，也是用于提问：这个文档有多匹配？

查询器的典型用法是用于查找文档：

* 与full text search的匹配度最高

* 包含run单词，如果包含这些单词：runs、running、jog、sprint，也被视为包含run单词

* 包含quick、brown、fox。这些词越接近，这份文档的相关性就越高

查询器会计算出每份文档对于某次查询有多相关（relevant），然后分配文档一个相关性分数：_score。而这个分数会被用来对匹配了的文档进行相关性排序。相关性概念十分适合全文搜索（full-text search），这个很难能给出完整、“正确”答案的领域。

性能上的不同

大多数过滤器子句的输出——一个通过筛选的文档列表——可以被快速的被计算出，同时可以被轻易的缓存在内存中，而且每份文档只用1比特。这些被缓存了的过滤器可以被后续的请求有效利用。

而查询器不只是要找出匹配的文档，同时还要计算出每份文档的相关性。所以通常查询器比过滤器更重，而且查询结果是不可缓存的。

感谢反向索引（inverted index）使用得一个只匹配少量文档的简单查询的性能可以媲美甚至超过一个缓存了跨了千万份文档的过滤器。然而，一个缓存了的过滤器的性能通常会胜过查询器，而且一直都将是这样。

使用过滤器的目的是精简查询器查询后结果的文档数。

它们的使用场景分别是？

作为一般规则，查询子句用于全文搜索或者任何影响相关性评分（relevance score）的条件，剩下的都可以使用过滤器子句。

关于inverted index目前我看到的书都翻译成倒排索引，但是我实在不喜欢这个翻译，更喜欢将它翻译成反向索引

反向索引的来源：http://www.zhihu.com/question/23202010