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