最近碰到手机设备匹配的业务, 用户在我司后台可以上传人群包, 里面存放的是设备的MD5标识符; 一个人群包大概有千万级的MD5数据, 与广告请求所携带设备标识进行匹配.
1. Key-Value 存储
尝试插入1kw条数据, key为设备MD5值, value为1, 此时Redis中存在1kw条key-value键值对.
通过info指令查看内存占用:
结论:
- 可以看到, 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, 极大的减少了内存;
测试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();
}
}
注意:
- JAVA String的哈希方法默认使用BKDRHash;
- java字符串hash的返回值为有符号型int, 所以会出现负数, 这里用
& 0x7FFFFFFF转为无符号型, 或者使用java自带的Integer.toUnsignedString;
查看Redis内存占用:
问题: 为什么同样1kw的bitmap, MD5数据的Hash占用会比测试一的多200倍?
- Bitmap索引一般用来存储整数。整数的范围是0～2^32-1. 所以如果用最朴素的思想, 一个bit位代表一个整数是否存在, 可以计算出所占用的大小就是2^32/8/1024/1024 ＝ 512M. 而且再考虑到大多数情况下, bitmap中元素不会太多, 反而是非常的稀疏, 用512M的空间来存储一个稀疏的bitmap, 自然是不可接受的;
- 就算测试2kw, 3kw条MD5数据, 也同样会占用这么大内存;
结论:
- 256MB的数据虽然相比Key-Value存储缩减了约4倍, 不过仍然比理想情况下的bitmap占用多出了200倍; 人群包较多的情况下同样无法适用;
- 需要缩短非连续情况下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);
}
结论:
- 采用压缩算法后的bitmap, 内存占用比Key-value缩减100倍, 比Redis自带的bitmap缩减10倍;
- 由于RoaringBitmap中容器的不同, 包括offset的稀散性, 还是比理想的连续整型offset大了越20倍内存
- 大家可以测试一下2kw, 3kw数据, 数据越多, offset离散区间越小, 所取得的压缩效果也会更好
注意:
- 以上代码在服务器中不考虑内存的情况下, 如果连续for循环kw次对服务器内存占用还是挺大; 特别是在服务器连接数较高时候;
- 亿级数据, RoaringBitmap存入Redis也有几十MB的内存占用, 每读取一次都会比较耗时; 所以建议在实际项目中对offset进行分片存储, 减少每次读取的耗时
