二 bitset与caching机制

1. 对于document中的每一个filed，均建立一个bitset，其中存放的值为0（在文档中不存在）和1（在文档中存在）。

例如，有6个文档，id和date是其中的两个filed，对于这两个filed分别建立bitset：

id：[0, 1, 0, 1, 0, 1] --- id为1的值在第2、4、6个文档中存在。

date：[0, 0, 1, 1, 0, 0] ---日期为2019-07-22的值在第3、4个文档中存在。

那么，搜索id为1且日期为2019-07-22的值时，就可以根据上面的两个bitset进行过滤。首先会比较两个bitset的稀疏情况，有限过滤较为稀疏的矩阵，这样可以较多的过滤掉无用的值。上面两个bitset，date的bitset较为稀疏，会首先过滤。

 

2. caching bitset：跟踪query，在最近256个query中超过一定次数的过滤条件，缓存其bitset。对于小segment（<1000，或<3%），不缓存bitset。

filter针对小segment获取到的结果，可以不缓存，segment记录数<1000，或者segment大小<index总大小的3%

小segment不缓存的原因：

（1）segment数据量很小，此时哪怕是扫描也很快；

（2）segment会在后台自动合并，小segment很快就会跟其他小segment合并成大segment，此时就缓存也没有什么意义，segment很快就消失了.

• filter比query的好处就在于会caching，缓存的并不是一个filter返回的完整的doc list数据结果，而是将filter bitset缓存起来。下次不用扫描倒排索引了。

• filter大部分情况下来说，在query之前执行，先尽量过滤掉尽可能多的数据。

  query：是会计算doc对搜索条件的relevance score，还会根据这个score去排序。
  filter：只是简单过滤出想要的数据，不计算relevance score，也不排序。

• 如果document有新增或修改，那么cached bitset会被自动更新。
• 以后只要是有相同的filter条件的，会直接来使用这个过滤条件对应的cached bitset。