3.filter原理（bitset机制与caching机制）

主要知识点：

• 一次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

   

 

   

   

   

转载于:https://www.cnblogs.com/liuqianli/p/8482391.html