下面详细讲一下为什么filter的性能很高，filter的底层原理究竟是什么？
通过一个搜索的场景来深入剖析一下，当一个filter搜索请求打到Elasticsearch的时候，ES会进行下面的操作：
（1）在倒排索引中查找搜索串，获取document list
以date来举例：
word doc1 doc2 doc3
2019-01-01 * *
2019-02-02 * *
2019-03-03 * * *filter: 2019-02-02
到倒排索引中一找，发现2019-02-02对应的document list是doc2,doc3
（2）为每个在倒排索引中搜索到的结果，构建一个bitset
这一步是非常重要的，使用找到的doc list，构建一个bitset，就是一个二进制的数组，数组的每个元素都是0或1，用来标识一个doc对一个filter条件是否匹配，如果匹配的话值就是1，不匹配值就是0。
所以上面的filter的bitset的结果就是：
[0,1,1]doc1：不匹配这个filter的
doc2和doc3：匹配这个filter的
注意：这样做的好处就是尽可能用简单的数据结构去实现复杂的功能，可以节省内存空间，提升性能。
（3）遍历每个过滤条件对应的bitset，优先从最稀疏的开始搜索，查找满足所有条件的document
由于一次性可以在一个search请求中发出多个filter条件，那么就会产生多个bitset，遍历每个filter条件对应的bitset优先从最稀疏的开始遍历
[0,0,0,0,0,0,0,1] 比较稀疏的bitset
[1,0,1,1,0,1,0,1]这里主要是因为先遍历比较稀疏的bitset，就可以先过滤掉尽可能多的数据
（4）caching bitset
caching bitset会跟踪query，在最近256个query中超过一定次数的过滤条件，缓存其bitset。对于小segment（<1000 或<3%），不缓存bitset。这样下次如果在有这个条件过来的时候，就不用重新扫描倒排索引，反复生成bitset，可以大幅度提升性能。
说明：
1、在最近的256个filter中，有某个filter超过了一定次数，这个次数不固定，那么elasticsearch就会缓存这个filter对应的bitset
2、filter针对小的segment获取到的结果，是可以不缓存的，segment记录数小于1000，或者segment大小小于index总大小的3%。因为此时segment数据量很小，哪怕是扫描也是很快的；segment会在后台自动合并，小segment很快会跟其它小segment合并成大segment，此时缓存就没有什么意思了，segment很快会消失。
filter比query好的原因除了不计算相关度分数以外还有这个caching bitset。所以filter性能会很高。
（5）filter大部分的情况下，是在query之前执行的，可以尽可能过滤掉多的数据
query: 会计算每个doc的相关度分数，还会根据这个相关度分数去做排序
filter: 只是简单过滤出想要的数据，不计算相关度分数，也不排序
（6）如果document有新增和修改，那么caching bitset会被自动更新
这个过程是ES内部做的，比如之前的bitset是[0,0,0,1]。那么现在插入一条数据或是更新了一条数据doc5，而且doc5也在缓存的bitset[0,0,0,1]的filter查询条件中，那么ES会自动更新这个bitset，变为[0,0,0,1,1]
（7）以后只要有相同的filter条件的查询请求打过来，就会直接使用这个过滤条件对应的bitset
这样查询性能就会很高，一些热的filter查询，就会被cache住。