关于Filter
从solr到es，一路下来对搜索引擎的长期使用，工作内容也包含大量的搜索优化的问题，无论是搜索质量还是速度都是需要关心的问题。有一个结论我一直记得，就是能使用filter的情况尽量使用filter，filter速度快，而且自带缓存。但是之前是知其然不知其所以然，今天想到这个，所以专门研究了一下到底filter的原理。
Filter查询为什么快
关于bitset
首先介绍bitset是什么
可以简单的理解为bit数组，即数组中只包含0或1
关于Filter
以以下的数据举例子
| word | doc1 | doc2 | doc3 |
|---|---|---|---|
| how | no | yes | yes |
| are | yes | yes | no |
| you | no | yes | yes |
yes和no表示索引是否包含word的词
现在我们给出filter的条件word:are，根据表中所得为yes,yes,no，将yes做1，no做0，于是我们获得了这个filter条件在这个索引中的bitset[1, 1, 0]
然后我们再加一个条件word:you，获得新的bitset[0,1,1]
条件和起来的意思是word:are && word:you，所以我们就做位运算就可以了，可得到新集合[0, 1, 0]，到这里完成了一次过滤查询。
关于缓存
filter的特点就在于缓存速度快，那它是怎么缓存的呢？和我过去接触到的kv缓存的方式不一样，es会缓存一些bitset，当下次还有filter查询的时候直接访问的bitset，这样有以下好处
- bitset的内存占用非常小
- 位运算速度飞快
- 不需要再次访问倒排索引表
以上表举例的话，当我们的查询再次设计刚才的filter时，直接访问[0, 1, 0]即可。
以下引用官方文档中关于缓存规则的描述
为了解决问题，Elasticsearch 会基于使用频次自动缓存查询。如果一个非评分查询在最近的 256 次查询中被使用过（次数取决于查询类型），那么这个查询就会作为缓存的候选。但是，并不是所有的片段都能保证缓存 bitset 。只有那些文档数量超过 10,000 （或超过总文档数量的 3% )才会缓存 bitset 。因为小的片段可以很快的进行搜索和合并，这里缓存的意义不大。
一旦缓存了，非评分计算的 bitset 会一直驻留在缓存中直到它被剔除。剔除规则是基于 LRU 的：一旦缓存满了，最近最少使用的过滤器会被剔除。
