主要知识点：
- 一次filter执行顺序
- filter和query的特点
一、一次filter执行顺序
1、在倒排索引中查找搜索串，获取document list
以一下date数据来举例
word doc1 doc2 doc3
2017-01-01 * *
2017-02-02 * *
2017-03-03 * * *
filter：2017-02-02
到倒排索引中去查找，发现2017-02-02对应的document list是doc2,doc3
2、为每个在倒排索引中搜索到的结果，构建一个bitset，
这一步非常重要。使用找到的doc list，构建一个bitset，bitset就是一个二进制的数组，数组每个元素都是0或1，用来标识一个doc对一个filter条件是否匹配，如果匹配就是1，不匹配就是0
上例匹配的bitset是[0,1,1],doc1不匹配这个filter条件,doc2和do3匹配这个filter条件。
用bitset的目的是尽可能用最简单的数据结构去实现复杂的功能，可以节省内存空间，提升性能。
3、遍历每个过滤条件对应的bitset
在一个search请求中，可以发出多个filter条件，每个filter条件都会对应一个bitset。所以在遍历每个filter条件对应的bitset时，先从最稀疏的开始依次遍历，这样就可以先过滤掉尽可能多的数据。[0, 0, 0, 1, 0, 0]和[0, 1, 0, 1, 0, 1]比较，前者就比较稀疏，因为1较后者少。示例：
请求：filter，postDate=2017-01-01，userID=1
postDate: [0, 0, 1, 1, 0, 0]
userID: [0, 1, 0, 1, 0, 1]
遍历完两个bitset之后，找到的匹配所有条件的doc，本例结果就是doc4，这样就可以将doc4作为结果返回给client了
4、建立caching bitset
es会跟踪query，在最近256个query中es会对超过一定次数（该次数不固定）的过滤条件，自动缓存这个filter对应的bitset。对于小segment（数据小于1000条，或该segment的大小小于所在index的大小的3%）不缓存bitset。这样就可以把bitset缓存在内存中，这样下次如果再有同样的条件过来的时候，就不用再一次重新扫描倒排索引，反复生成bitset，可以大幅度提升性能
小segment对应的bitset不缓存的原因：segment数据量很小，扫描很快；segment会在后台自动合并，小segment很快就会跟其他小segment合并成大segment，此时就缓存也没有什么意义，因为segment很快就消失了，而原缓存的bitset还是对应原segment的顺序。
filter比query的好处就在于filter会自动caching，实际bitset上并不是一个filter返回的完整的doc list数据结果。而是把filter bitset缓存起来。下次不用扫描倒排索引了。
二、filter和query的特点
1、filter和query执行顺序
filter大部分情况下在query之前执行，这样做的目的是先过滤掉尽可能多的数据。
query：是会计算doc对搜索条件的relevance score，还会根据这个score去排序
filter：只是简单过滤出想要的数据，不计算relevance score，也不排序
2、cached bitset会被自动更新
如果document有新增或修改，或者segment有变化，那么cached bitset会被自动更新
3、对两次相同的filter条件
以后只要是有相同的filter条件的，会直接来使用这个过滤条件对应的cached bitset