roaring bitmap 与 bitmap 比较. 编译运行
https://zhuanlan.zhihu.com/p/351365841
是个一系列的文章
https://blog.csdn.net/yizishou/article/details/78342499
最后我们来将roaringbitmap相比于普通的bitmap的优势总结为以下几点：
内存上：
- bitmap比较适用于数据分布比较稠密的存储场景中，对于原始的Bitmap来说，若要存储uint32类型数据，这就需要2 ^ 32长度的bit数组 通过计算可以发现(2 ^ 32 / 8 bytes = 512MB), 一个普通的Bitmap需要耗费512MB的存储空间。 如果我们只存储几个数据的话依然需要占用521M空间，这就有些浪费空间了，因此我们可以采用对位图进行压缩的RoaringBitMap,以此减少内存和提高效率。 2 ^ 32 约等于42亿 我们的 倒排链表肯定不需要这么大啊！ key --- postlists. postlists肯定不会有这么大 总共广告数量就是亿就算足够了. 传统 bitmap 肯定浪费大量的空间了. 如果bitmap这样设计会浪费我们大量的内存空间 一个定向列表就消耗了 512m 50个定向条件就是50*512m ==25GB 100个倒排表 那就是50GB 原来我们系统估计就是100个倒排表。就是100个 <key , postlists[ ...40亿...]>. 这样的情况.
- 性能上：roaringbitmap除了比bitmap占用内存少之外，其并集和交集操作的速度也要比bitmap的快。原因归结为以下几点：
- 计算上的优化. 因为在同一个同的计算的位数只有16位了。所以当进行交集或并集运算的时候，roaringbitmap只需要去计算存在的一些块而不需要像bitmap那样对整个大的块进行计算。如果块内非常稀疏，那么只需要对这些小整数列表进行集合的 AND、OR 运算，这样的话计算量还能继续减轻。
2. 程序逻辑上的优化
（1）roaringbitmap维护了排好序的一级索引，以及有序的arraycontainer当进行交集操作的时候，只需要根据一级索引中对应的值来获取需要合并的容器，而不需要合并的容器则不需要对其进行操作直接过滤掉。
（2）当进行合并的arraycontainer中数据个数相差过大的时候采用基于二分查找的方法对arraycontainer求交集,避免不必要的线性合并花费的时间开销。
（3）roaingbitmap在做并集的时候同样根据一级索引只对相同的索引的容器进行合并操作，而索引不同的直接添加到新的roaringbitmap上即可，不需要遍历容器。
（4）.roaringbitmap在合并容器的时候会先预测结果，生成对应的容器，避免不必要的容器转换操作。
