1、filter和query区别
query查询会根据相关度排序
filter只是做数据过滤，不会计算相关度
2、filter执行流程
1.查找匹配文档
TermQuery先在倒排索引中匹配到符合指定查询值的文档列表，这个case中是查询值是productID=XHDK-A-1293-#fJ3的文档也就是_id=1的文档。
2.创建一个bitset
Filter根据第1步的查询结果创建一个bitset(一个只包含0和1的数组) ，用来表示文档是否被包含在这个TermQuery中，在我们的例子中这个bitset是[1,0,0,0] 它表示第1个文档匹配，第2、3.、4不匹配。
bitset：是java.util包下的一个类，他实际上是一个long数组
3.迭代生成的bitset
在多个TermQuery同时存在一个FilterContext 中执行过滤查询时，会生成多个bitset（一个Query clause对应一个BitSet），ES会迭代这些位图并从中找到符合条件的文档。当然ES会很智能的选择位图的执行顺序，通常情况下ES会选择稀疏的位图优先执行，这样的做的目的是过滤掉大部分不符合条件的文档。
4.叠加Bitset的执行次数
ES能缓存非评分查询并快速访问，但是它会很蠢的缓存一些不常使用的东东，在倒排索引中非评分查询已经相当快了，所以我们需要缓存那些“我们知道会在接下来的时间被多次访问的查询” 以免造成资源浪费。
为了这样做，ES跟踪记录了以每个索引为基础的历史访问记录，如果一个查询在最近的256个查询中被执行了若干次，那么它将会被缓存到内存中(一个非评分查询被缓存实际上是该查询的位图被缓存)，当位图被缓存时还有两个条件是要满足的：该查询对应的segments所持有的文档数必须大于1W 且必须大于总索引大小的3%，ES这样做是因为对于那些小的索引段会很快的被合并掉,对它们的缓存其实是一种浪费
主要原因：
1）小段本身扫描很快。
2）小段有大几率会发生合并，合并后。
bitset缓存起来的不是完整结果，只是不用再次扫描倒排索引而已。
3）filter操作基本要在query之前，因为可以过滤更多的数据。
4）如果doc有更新或新增操作，cache的bitset会自动更新。
5）以后只要有相同的filter条件，可以直接使用cache的bitset。
