Redis bitmap数据格式优化 (RoaringBitmap)

1. Key-Value 存储

尝试插入1kw条数据, key为设备MD5值, value为1, 此时Redis中存在1kw条key-value键值对.

通过info指令查看内存占用:

1kw数据key-value占用内存

结论:

• 可以看到, 1kw条MD5数据占用Redis内存约为892MB;
• 这还只是一个客户上传的人群包, 如果上传的人群包较多, 则Redis需要大量的集群部署, 成本会及其大;
• 无论是采用List, Hash, Set等结构都会出现这种情况, 所以Redis的这些数据结构都不适用;

2. BitMap存储

原理

8bit = 1b = 0.001kb
bitmap即位图, 就是通过最小的单位bit来进行0或者1的设置，表示某个元素对应的值或者状态。
一个bit的值，或者是0，或者是1；也就是说一个bit能存储的最多信息是2。

举例:

场景: 有用户id分别为1, 2, 3, 4, 5, 6, 7, 8的用户, 其中用户2, 5在今日登录, 统计今
日登录用户

采用位图存储: 用户id为偏移量, 可以看做是在位图中的索引, value为true

用户登录情况

通过bitcount获取登录用户数为2:

登录用户数

测试1:

测试offset从1-1kw连续整数时候的内存占用:

 

Jedis jedis = null;
        try {
            jedis = getJedis();
            Pipeline pipeline = jedis.pipelined();
            for (int offset = 0; offset < 10000000; offset ++) {
                pipeline.setbit("test", offset, true);
            }
            pipeline.sync();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedis != null) jedis.close();
        }

可以发现内存占用仅为 1.19MB, 1个亿的数据也才12MB, 极大的减少了内存;

1kw连续的正整数内存占用

测试2:

由于我们的业务没有如此完美的情况出现, 采用设备MD5的hash做Offset, 不会出现连续正整数的情况;

各常用Hash函数性能对比: https://byvoid.com/zhs/blog/string-hash-compare/

所以我们接下来测试1kw条MD5数据的位图内存占用:

 

private void saveBitMap(List<String> values) {
        Jedis jedis = null;
        try {
            jedis = getJedis();
            Pipeline pipeline = jedis.pipelined();
            for (String arg : values) {
                int offset = arg.hashCode() & 0x7FFFFFFF;
                pipeline.setbit("audience_id", offset, true);
            }
            pipeline.sync();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedis != null) jedis.close();
        }
    }

注意:

1. JAVA String的哈希方法默认使用BKDRHash;
2. java字符串hash的返回值为有符号型int, 所以会出现负数, 这里用 & 0x7FFFFFFF 转为无符号型, 或者使用java自带的Integer.toUnsignedString;

查看Redis内存占用:

1kwMD5的hash内存占用

问题: 为什么同样1kw的bitmap, MD5数据的Hash占用会比测试一的多200倍?

1. Bitmap索引一般用来存储整数。整数的范围是0～2^32-1. 所以如果用最朴素的思想, 一个bit位代表一个整数是否存在, 可以计算出所占用的大小就是2^32/8/1024/1024 ＝ 512M. 而且再考虑到大多数情况下, bitmap中元素不会太多, 反而是非常的稀疏, 用512M的空间来存储一个稀疏的bitmap, 自然是不可接受的;
2. 就算测试2kw, 3kw条MD5数据, 也同样会占用这么大内存;

结论:

1. 256MB的数据虽然相比Key-Value存储缩减了约4倍, 不过仍然比理想情况下的bitmap占用多出了200倍; 人群包较多的情况下同样无法适用;
2. 需要缩短非连续情况下offset的区间(压缩算法)

3. RoaringBitmap

原理

将32位无符号整数按照高16位分桶，即最多可能有216=65536个桶，称为container。存储数据时，按照数据的高16位找到container（找不到就会新建一个），再将低16位放入container中。也就是说，一个RBM就是很多container的集合。

图中示出了三个container：

• 高16位为0000H的container，存储有前1000个62的倍数。
• 高16位为0001H的container，存储有[216, 216+100)区间内的100个数。
• 高16位为0002H的container，存储有[2×216, 3×216)区间内的所有偶数，共215个。

测试:

1kw条MD5数据的插入:

 

private void saveWithRoaringBitmap(List<String> values) throws IOException {
        int[] offsets = new int[values.size()];
        for (int i = 0; i < values.size(); i ++) {
            int offset = values.hashCode() & 0x7FFFFFFF;
            offsets[i] = offset;
        }

        MutableRoaringBitmap mrb = MutableRoaringBitmap.bitmapOf(offsets);
        ByteBuffer outbb = ByteBuffer.allocate(mrb.serializedSizeInBytes());
        mrb.serialize(new DataOutputStream(new OutputStream(){
            ByteBuffer mBB;
            OutputStream init(ByteBuffer mbb) {mBB=mbb; return this;}
            public void close() {}
            public void flush() {}
            public void write(int b) {
                mBB.put((byte) b);}
            public void write(byte[] b) {mBB.put(b);}
            public void write(byte[] b, int off, int l) {mBB.put(b,off,l);}
        }.init(outbb)));
        outbb.flip();

        // Base64编码后存入Redis
        String encodeString = Base64.getEncoder().encodeToString(outbb.array());
        getJedis().set("roaringMap", encodeString);
    }

RoaringBitMap内存占用

结论:

1. 采用压缩算法后的bitmap, 内存占用比Key-value缩减100倍, 比Redis自带的bitmap缩减10倍;
2. 由于RoaringBitmap中容器的不同, 包括offset的稀散性, 还是比理想的连续整型offset大了越20倍内存
3. 大家可以测试一下2kw, 3kw数据, 数据越多, offset离散区间越小, 所取得的压缩效果也会更好

注意:

1. 以上代码在服务器中不考虑内存的情况下, 如果连续for循环kw次对服务器内存占用还是挺大; 特别是在服务器连接数较高时候;
2. 亿级数据, RoaringBitmap存入Redis也有几十MB的内存占用, 每读取一次都会比较耗时; 所以建议在实际项目中对offset进行分片存储, 减少每次读取的耗时