咆哮位图使用比普通位集更多的存储空间

Question

我有一个用于跟踪项目是否存在的位集示例

b = 01100110000

它表示第 2 项和第 3 项存在，第 1 项和第 4 项不存在。

在搜索可以优化此位集数组的库时。 我遇到了听起来非常令人兴奋的咆哮位图。

我用它做了一个快速测试，

    public static void main(String[] args) throws IOException {
        RoaringBitmap roaringBitMap = new RoaringBitmap();
        BitSet bitSet = new BitSet(5000);
        double prob = 0.001;
        Random random = new Random();
        for (int i = 0; i < 5000; i++) {
            if (random.nextDouble() < prob) {
                bitSet.set(i);
                roaringBitMap.add(i);
            }
        }
        System.out.println(bitSet.cardinality());
        System.out.println("bitset bytes: "+ bitSet.size());
        System.out.println("RoaringBitmap bytes: " + roaringBitMap.getSizeInBytes() * 8);
    }

基本上我们正在设置一些值并检查数据结构的整体大小。

当我们使用多个概率值运行它时。 我有

概率字节	位集字节	RoaringBitmap 字节
0.001	5056	288
0.01	5056	944
0.1	5056	7872
0.999	5056	65616

如果您看到我们插入的数字越来越多，RoaringBitmap 的内存占用就会增加。

1. 这是预期的吗？
2. 在最坏的情况下，它不应该只是退回到基于位集的实现吗？
3. 0.999 不能被视为 0.001 的倒数，我们可以将它存储在 288 个字节中吗？
4. 当我们进行服务间调用和使用杰克逊库（但不是基于字节的序列化库）时，将这些位集表示为字符串的最佳方式是什么

Answer 1

当条目数量很少时似乎就是这种情况，但是随着条目数量的增加，差异变得不那么明显。 尽管lib作者没有确认（我在这里询问并在此处跟进）

概率	条目数	位集位	RoaringBitmap 位	节省 %
0.001	50000	50048	928	98
0.01	50000	50048	7744	84
0.1	50000	50048	65616	-31
0.999	50000	50048	65616 <- 注意它不会增加	-31
0.001	500000	500032	8704	98
0.01	500000	500032	80720	83
0.1	500000	500032	524480	-4
0.999	500000	500032	524480 <- 注意它不会增加	-4
0.001	50000000	50000000	835232	98
0.01	50000000	50000000	8036368	83
0.1	50000000	50000000	50016240	-0.03
0.999	50000000	50000000	50016240 <- 注意它不会增加	-0.03

看着这一点，似乎随着条目数量的增加，他们可能只在幕后使用位图。 要点是不要盲目地使用库，测试你的用例。