query關注點：此文檔與此查詢子句的比對程度如何？
filter關注點：此文檔和查詢子句比對嗎？
2、Query檢索細化關注點
1）是否包含？
确定文檔是否應該成為結果的一部分.
2）相關度得分多少？
除了确定文檔是否比對外，查詢子句還計算了表示文檔與其他文檔相比比對程度的_score。
3）得分越高，相關度越高。
更相關的檔案，在搜尋排名更高。
典型應用場景：
1）全文檢索——這種相關性的概念非常适合全文搜尋，因為很少有完全“正确”的答案。
舉例如下：
文檔中存在字段hotel_name：“上海浦東香格裡拉酒店”
IK實際分詞結果如下：
上海浦東,上海,浦東,香格裡拉,格裡,裡拉,酒店。
也就是說，搜尋以上關鍵詞都能搜到：hotel_name：“上海浦東香格裡拉酒店”的酒店。這些都是“相關”的。
但是搜尋：“香格裡” 是搜尋不到結果的。
2）包含單詞“run”， 但也比對"runs", “running”, “jog"或者"sprint”。（都是奔跑的意思）
3、filter過濾細化關注點
确定是否包含在檢索結果中，回答隻有“是”或“否”。
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”中用作過濾器。
舉例：
GET /_search
{
"query": {
"bool": {
"must": [
{ "match": { "title": "Search" }},
{ "match": { "content": "Elasticsearch" }}
],
"filter": [
{ "term": { "status": "published" }},
{ "range": { "publish_date": { "gte": "2015-01-01" }}}
]
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
8、小結
官網&源碼才是王道。
多看、多思、多總結。弄清原理，高效開發才有了保障！
參考：
1、官網：
http://t.cn/R14moYO http://t.cn/R14kLl62、實戰：
http://t.cn/R1bZwy8 http://t.cn/RQhzDiP3、Google工程師視訊