概述

继续跟中华石杉老师学习ES，第二篇

课程地址： https://www.roncoo.com/view/55

白话Elasticsearch01- 使用term filter来搜索数据中演示了 term filter的用法，这里我们来剖析下执行原理

步骤

在倒排索引中查找搜索串，获取document list

为每个在倒排索引中搜索到的结果，构建一个bitset .

遍历每个过滤条件对应的bitset，优先从最稀疏的开始搜索，查找满足所有条件的document

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

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

如果document有新增或修改，那么cached bitset会被自动更新

以后只要是有相同的filter条件的，会直接来使用这个过滤条件对应的cached bitset

接下来逐条来说一下过程

Step1 在倒排索引中查找搜索串，获取document list

举个例子 ， 上节中用到的 postDate字段，假设有3条数据，在document1 、document2、document3中的分布情况

filter : 2017-02-02

比如：

GET /forum/article/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "term": {
          "postDate": "2017-02-02"
        }
      }
    }
  }
}

发现2017-02-02 对应的 document list 为 doc2 和 doc3 ，这样就完成了第一步，取到了document list

Step2 为每个在倒排索引中搜索到的结果，构建一个bitset .

这个地方很关键，非常重要。

上一步中，获取到了 document list , ES 会 根据这些document list 构建一个 bitset .

啥是bitset ? bitset是一个二进制的数组， 数组的每个元素要么是0要么是1 ， 0 表示不匹配，1 表示匹配。

刚才filter 2017-02-02 的 document list就可以表示为 [0,1,1]

表示

doc1 —>0 , 不匹配该filter

doc2—>1 ,匹配该filter

doc3----> ,匹配该filter

也就是说 这个filter，在整个document中（假设该document只有3条记录），对应的bitset就是 [0,1,1]

使用二进制数组来标识有什么好处呢？ ES本着使用尽可能简单的su数据结构来实现复杂的功能，节省空间，提高性能。

Step3 遍历每个过滤条件对应的bitset，优先从最稀疏的开始搜索，查找满足所有条件的document

在一个search请求中，可以有多个filter条件，每个filter条件都会对应一个bitset。

再获取到每个filter对应的bitset后 ,遍历每个filter条件对应的bitset，先从最稀疏的开始遍历。

啥叫稀疏？ 举个例子

[0, 0, 0, 1, 0, 0]

[0, 1, 0, 1, 0, 1]

上面两个filter对应的匹配结果状况，第一个比较稀疏（不匹配的较多，因为0表示不匹配，也就是0越多越稀疏）

先遍历比较稀疏的bitset，就可以先过滤掉尽可能多的数据

遍历所有的bitset，找到匹配所有filter条件的doc

举个例子请求：filter，postDate=2017-01-01，userID=1

postDate: [0, 0, 1, 1, 0, 0]

userID: [0, 1, 0, 1, 0, 1]

遍历完两个bitset之后，找到的匹配所有条件的doc，第4个doc均为1 ，均匹配这两个filter ，就是doc4

就可以将document作为结果返回给client了

Step4 caching bitset，跟踪query，在最近256个query中超过一定次数的过滤条件，缓存其bitset

比如postDate=2017-01-01这个条件的filter，对应的bitset[0, 0, 1, 1, 0, 0]，可以缓存在内存中，这样下次如果再有这个条件过来的时候，就不用重新扫描倒排索引，反复生成bitset，直接在内存中获取该filter对应的bitset即可，这样做可以大幅度提升性能。

在最近的256个filter中，有某个filter超过了一定的次数，次数不固定，就会自动缓存这个filter对应的bitset

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

不缓存小segment的理由：

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

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

filter比query的好处就在于会caching，但是之前不知道caching的是什么东西，实际上并不是一个filter返回的完整的doc list数据结果。而是filter bitset缓存起来。下次不用扫描倒排索引了。

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

query：是会计算doc对搜索条件的relevance score，还会根据这个score去排序

filter：只是简单过滤出想要的数据，不计算relevance score，也不排序

Step6 如果document有新增或修改，那么cached bitset会被自动更新

举个例子

我们的article document中有4条数据，postDate=2017-01-01这个filter对应的bitset为 [0, 0, 1, 0] ， 第三条数据符合这个条件

我们又新增了一条数据，article document加上id=5 ,postDate=2017-01-01，会自动更新到postDate=2017-01-01这个filter的bitset中，全自动，缓存会自动更新。postDate=2017-01-01的bitset就自动变为了[0, 0, 1, 0, 1]

如果我们修改了数值呢？ 假设修改document，id=1为postDate=2016-12-30，修改为postDate-2017-01-01，此时也会自动更新bitset，变为[1, 0, 1, 0, 1]

Step7 以后只要是有相同的filter条件的，会直接来使用这个过滤条件对应的cached bitset

以后只要是有相同的filter条件的，会直接来使用这个过滤条件对应的cached bitset