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的形式口头，
并在如下官网链接做了详尽解释。
简而言之，filter context 关键用于查问的过滤条件，并且不用算分，与 bool 的 filter 条件没有严厉关联，除了 bool 的 filter 外，bool 中的 must_not， constant_score 查问中的 filter，聚合中的 filter 也都属于。
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_countsegment segmentsize size由于小 segment 的查问自身曾经足够快，不须要缓存来减速。
其治理战略类是 lucene 的 UsageTrackingQueryCachingPolicy，合乎 LRU 的规定，也就是说 Query Cache 中的查问结果长期间不被访问会被优先淘汰。
这里判别能否被缓存的方法是shouldCache(Query query)，有兴味的同窗可以去钻研下
判别能否可以缓存的关键规定如下：
5、经常使用和观测 Query Cache
最后，咱们来看下怎样去经常使用和观测 Query Cache。
自动状况下节点的 Query cache最多缓存 10000个子查问的结果，或许最多经常使用堆内存的10%，都可以经过性能来调整:
indicesqueriescachecountindicesqueriescachesize对 Query Cache 也可以启动人工清算：POST /<index>/_cache/clear?query=true
而 Nodes stats API 和 Index stats API 都提供了 Query Cache 的监控
经常使用小倡议：
6、小结
本文持久总结了 Filter context 如何构成 Query Cache 并启动保养观测的全体流程。
重点：Filter context 自身可以省去复杂的算分环节，再加上 Query Cache 的减速长处，倡议大家在编写只要要婚配过滤查问语句中优先选用。
也就是：实践业务开发能经常使用 filter 过滤的，记得必定加上！
