Elasticsearch Filter 緩存加速檢索的細節，你知道嗎？
1、前言
ES 進行信息檢索的時候，boolean 查詢組合條件有 must/must_not/should/filter四個操作。
其中 must 和 filter 的用途都是用于過濾必要符合的條件，但是 filter 在查詢過程中不算分并且可以進行緩存，這樣邏輯簡單又可以加速的查詢方式經常得到官方的提倡。
可是，只有 filter 的條件可以被緩存么？這里的緩存是屬于哪一部分？
緩存有什么樣的進入和淘汰機制？怎么去監控緩存的使用情況？
這些問題也會伴隨著對 Elasticsearch 的深入使用自然而然的產生。
本文中，我們結合官方的一些資料進行探索。
2、什么是 Filter Context？
仔細去看官方的文檔可以發現，在 filter 的使用介紹里是這么寫的。
Filter clauses are executed in filter context, meaning that scoring is ignored and clauses are considered for caching.
這里不僅措辭嚴謹的說 filter 條件以 filter context 的方式執行，
并在如下官方鏈接做了詳盡解釋。
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html#filter-context
簡而言之，filter context 主要用于查詢的過濾條件，并且不用算分，與 bool 的 filter 條件沒有嚴格關聯，除了 bool 的 filter 外，bool 中的 must_not， constant_score 查詢中的 filter，聚合中的 filter 也都屬于。
filter context
3、如何進入 Query Cache
現在我們來看看查詢是怎么進入 Query Cache的：
3.1. 找到匹配文檔
在倒排索引中找到 filter 條件符合的詞項，并在所有的文檔中檢索這個詞項。
3.2. 建立一個位圖 bitset
建立一個只包含1和0的位圖 bitset，這個 bitset 用于描述所有文檔的匹配情況，匹配的文檔被設置為1。ES 實際執行時，使用的是 RoaringBitMap。
3.3. 迭代 bitset
一旦為某個查詢生成了 bitset, Elasticsearch 就會遍歷 bitset 以查找滿足所有過濾條件的匹配文檔集。
執行順序通常是首先迭代最稀疏的bitset(因為它排除了最多數量的文檔)。
3.4. 增加使用計數
把查詢條件和其結果的 bitset 組合作為 key-value 進行緩存，這里利用對查詢條件的使用記錄來判斷是否進緩存。
簡單來說，如果一個查詢在最近的256個查詢中被多次使用，它將被緩存在內存中。更為詳細的保留機制見下一節。
圖片
4、Query Cache 的緩存機制
總體來說，Query Cache 是 Lucene 層面實現的，ES 層面會進行一些策略控制和信息統計。
Query Cache 僅應用于相對較大的 segment。
對于文檔數少于 1 萬或 segment 大小（size，單位：MB、GB等)小于整體索引大小 3% 的 segment(如下公式），Query Cache 將不啟用。
docs_count(segment) < 10000 || segment.size < 3%*index.size因為小 segment 的查詢本身已經足夠快，不需要緩存來加速。
其管理策略類是 lucene 的 UsageTrackingQueryCachingPolicy，符合 LRU 的規則，也就是說 Query Cache 中的查詢結果長時間不被訪問會被優先淘汰。
這里判斷是否被緩存的方法是shouldCache(Query query)，有興趣的同學可以去研究下
判斷是否可以緩存的主要規則如下：
- 判斷是否為 filter 查詢assert query instanceof BoostQuery == false;
- 命中永不緩存 shouldNeverCache 條件的淘汰，其中包括：TermQuery、MatchAllDocsQuery、MatchNoDocsQuery、以及子查詢為空的BooleanQuery、DisjunctionMaxQuery
- 某些大于特定閾值的查詢可以被緩存：3.1 大于2次：MultiTermQuery、MultiTermQueryConstantScoreWrapper、TermInSetQuery、PointQuery（在 isCostly方法中定義）3.2 大于5次：除了上面列出條件的所有 filter 查詢
5、使用和觀測 Query Cache
最后，我們來看下怎么去使用和觀測 Query Cache。
默認情況下節點的 Query cache最多緩存 10000個子查詢的結果，或者最多使用堆內存的10%，都可以通過配置來調整:
indices.queries.cache.count #默認 10000
indices.queries.cache.size #默認 10%對 Query Cache 也可以進行人工清理：POST /<index>/_cache/clear?query=true
而 Nodes stats API 和 Index stats API 都提供了 Query Cache 的監控
"query_cache": {
"memory_size_in_bytes": 1110305640,//使用的size
"total_count": 45109997,//歷史查詢總條數 total=hit+miss
"hit_count": 1192144,//命中的
"miss_count": 43917853,//未命中的
"cache_size": 1309,//當前緩存的條數
"cache_count": 51509,//歷史緩存總條數
"evictions": 50200//被驅逐的條數
}使用小建議：
- 當 evictions 大量發生時，緩存被大量置換，對高敏感的業務可能會有一定的查詢抖動。
- 在監控項上添加一個 hit/total 的百分比監控，更加直觀。
6、小結
本文短暫總結了 Filter context 如何形成 Query Cache 并進行維護觀測的整體流程。
重點：Filter context 本身可以省去復雜的算分過程，再加上 Query Cache 的加速優勢，建議大家在編寫只需要匹配過濾查詢語句中優先選擇。
也就是：實際業務開發能使用 filter 過濾的，記得一定加上！
作者介紹
金多安，Elastic 認證專家，Elastic資深運維工程師，死磕Elasticsearch知識星球嘉賓，星球Top活躍技術專家，搜索客社區日報責任編輯。
