RoaringBitmap是一种在数据库和搜索引擎中广泛使用的压缩位图索引，尤其适用于实时OLAP分析引擎如Druid和Pinot。它通过将32位整数分为2^16个块，利用有序short数组或位数组存储元素，有效解决了稀疏位图的存储问题。当元素数量小于等于4096时，使用short数组；超过则切换为long数组。RoaringBitmap还支持快速的位运算，如AND、OR和XOR，其源码中的实现技巧值得深入研究。
更新一: RoaringBitmap源码分析一(AND操作)
Bitmap索引在数据库和搜索引擎里使用的很广泛。最近发现几个实时OLAP分析引擎，比如Druid和Pinot也都在用，所以深入研究了一下。这两个OLAP引擎都使用RoaringBitmap，这是一种压缩的、高效的bitmap索引。代码很精妙，看得很过瘾。
Bitmap索引一般用来存储整数。整数的范围是0～2^32-1。所以如果用最朴素的思想，一个bit位代表一个整数是否存在，可以计算出所占用的大小就是2^32/8/1024/1024 ＝ 512M。而且再考虑到大多数情况下，bitmap中元素不会太多，反而是非常的稀疏，用512M的空间来存储一个稀疏的bitmap，自然是不可接受的。
在RoaringBitmap中，32位整数被分成了2^16个块。任何一个32位整数的前16位决定放在哪个块里。后16位就是放在这个块里的内容。比如0xFFFF0000和0xFFFF0001，前16位都是FFFF，表明这两个数应该放在一个块里。后16位分别是0和1。在这个块中指保存0和1就可以了，不需要保存完整的整数。
在最开始的时候，一个块中包含一个长度为4的short数组，后16位所对应的值就存在这个short数组里。注意在插入的时候要保持顺序性，这里就需要用到二分查找来加快速度了。如果当块中的元素大于short数组的长度时，就需要重新分配更大的数组，把当前数组copy过去，并把新值插入对应的位置。扩展数组大小和STL中vector的方式类似，不过并不是完全的加倍，而且上限是4096，也就是说最多只保存4096个元素。那么问题来了，超过了4096怎么办呢？
一个块里最多可能需要存放2^16个元素，那么如果是用short来存放，最多需要65536个short，那么就是131072个byte。如果换一种方式，用位来存储元素，那么就需要65536个bit，相当于1024个long型数组，即2048个int，也就是4096个sho
最低0.47元/天 解锁文章
扫一扫
4721
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
