Druid原理介绍(2)

       上一篇谈到了位图索引的问题，其中提到了一点： 如果某一列的取值的维度比较大，则不太适合建立位图索引。因为位图索引会非常大, 则不太适合建立位图索了。

      但是对于OLAP框架而言，这个问题时不可避免的，举例而言，我们需要保存和统计公司的所有网站的访问记录，那么IP的范围就会比较大。此时如果直接对IP建立位图索引的话就会导致该索引非常大，不太现实，那么怎么办呢？这就需要对位图索引进行压缩了。我们知道，常见的压缩算法对数据进行压缩之后，确实可以减少空间占用，但是当需要使用数据的时候，就需要对数据进行解压缩，效率不高。对于位图索引而言，其目的本来就是为了减少数据查询的处理时间，如果再查询的时候，需要对索引进行解压缩，然后再使用的话就不一定能够提高效率了。所以一般情况下位图索引的压缩算法，会使得索引在使用的时候， 可以不解压缩就可以直接使用。其原理如下图所示：

    

    图中的第一行是位图索引的原始数据，压缩算法将位图索引的原始数据按31位分成若干个字（一个字是32个bit，这里按31个bit分有其目的）， 最后的一个字有可能不足31位，则补充0。 分过之后，再分析每一个字, 这是有两种情况：

 (1) 该字中的31位不是全为0也不是全为1；

(2) 该字中的31位全为0；

(3) 该字中的31位全为1；

对于这三种情况，压缩算法分别有不同的处理方式： 

对于情况(1) , 则在其前面补1位1即可，这样就构成了一个32位的字;

对于情况(2), 则在其前面首先补1位0, 这个0代表该字全为0或者全为1。紧接着，再在这个0后面补一位0，这第二个0代表的是该字全为0， 然后向后遍历，看有多少个字(31位)的0， 像图中的情况，有3个字的0连在一起，所以后面的30位只需要写一个整形的值3即可， 它代表的是有31*3这么多个连续的0。

对于情况(3), 跟情况(2)类似，唯一的差别就是第二位是1.

该算法在进行与或非运算的时候，就可以不用解压缩整个位图索引，只需要一个字一个字的进行先分析再运算即可。并且，当某个属性的取值范围很大的时候，则原始的位图索引中必然有很大连续的0的情况，则其位图索引的压缩比例就会比较高。

目前很多的位图索引的压缩算法都是在这个算法的基础之上改进而来的。原理大同小异。

而Druid就是对我们插入其中的数据按一定的时间范围生成段，每个段其实就是该时间范围内的数据的位图索引，当进行查询自定义的查询的时候(例如我需要查询ip=ip1&url=url1的所有记录的总的访问次数)，druid会首先根据过滤条件，取得所有的满足条件的数据，再进行统计。这样由于其处理过滤条件会比较快速，从而也提高了查询效率。

下一讲我们开始谈Druid的架构。