Redis中的Bitmap偏移量过大
大佬们请教个问题,现在有个场景需要统计每个设备的日活信息,设备的编号采用的是雪花ID的方式,目前想采用Redis的Bitmap的方式进行数据存储,但是有个问题是,假如1号那天有个设备上线了计算出偏移量为1将bitmap的指定的位设置了1,然后又有一个设备的id计算出的偏移量超过了Bitmap的最大限制,导致redis直接开辟了512M的内存,如何防止偏移量过大呢?还有假如一个设备计算出的偏移量是1,另外一个设备计算出的偏移量为100000,实际1号那天只有2个设备上线,那么2-99999就属于无效的空间导致内存的浪费,这种有什么方式可以解决?我知道的有谷歌的EWAHCompressedBitmap可以进行压缩,但是这个只能用在单实例上。
全部评论
我的思路是这样的,首先每天一个bitmap肯定是确定的,如果用bitmap的话,然后我理解雪花id每个id是不会一样的吧,那总可以映射到bitmap 0- x这个范围上吧.. 然后一个bit对应一个设备. 这是用bitmap的思路. 这个真的要看业务,如果只有两个设备,为什么不直接用string 存呢,id可以是 设备id + 日期, 1,0标识就好了,这两个思路.
简单一点吧. 你用 bitpost 计算出已经上线设备的目前最大的偏移量. 正在上线的设备的偏移量 +1
前面已经有大佬提出用分组,其实分组是个很好的方案。如果你觉得这个还不能满足你的要求。那么
bitmap最大长度是2^32-1,占用512M,其实这个已经非常大了。这是三个1024积的4倍,一定大于40亿,你哪儿来的那么多设备?假如说你有超过这个上限值的设备数,可以对你说的设备雪花id做除运算(除2^32,只需要做位移动,自己理解)得出设备所在空间,做模运算得出设备所在空间偏移量。因为一个bitmap已经无法满足你的业务需求了,此时你需要用多个bitmap存设备状态值,每一个bitmap就是一个空间。
咆哮位图,roaringmap可以看看
还有一种方案是,一定要统计所有设备的日活吗,设备能不能分组,然后统计每一个设备组的活跃信息,这样也能压缩空间了。
个人感觉用redis bitmap的话就得考虑到数据范围?如果只统计数量用hyperloglog?
给一下我的思路:假设用一个序号标识设备id在原来bitMap中的顺序,现在将这个id的前x位当做bitMAp的标识,后y位作为他在第i个map中的位置,然后采用懒加载策略,只有当这个设备用到时才创建这个设备所在的bitMap,这样应对极端情况
mark等后续
相关推荐
06-06 17:27
天津工业大学 golang 点赞 评论 收藏
分享