RoaringBitmap简析

RoaringBitmap是一种在数据库和搜索引擎中广泛使用的压缩位图索引,尤其适用于实时OLAP分析引擎如Druid和Pinot。它通过将32位整数分为2^16个块,利用有序short数组或位数组存储元素,有效解决了稀疏位图的存储问题。当元素数量小于等于4096时,使用short数组;超过则切换为long数组。RoaringBitmap还支持快速的位运算,如AND、OR和XOR,其源码中的实现技巧值得深入研究。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

更新一: 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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值