标签：word Redis redis bitmap myBit 32 10000 Bitmap 大事

在日常的开发中, redis的BitMap做过滤非常的方便, 但是存在一些坑, 所以记录下来, 给大家学习下:

1. Redis 的 bitmap 的key的长度会影响它的性能, 最大是2的32次方, 要是10位数就是10亿了, 必然比从0开始慢. 例如

bitmap set myBit 1 1, 必然会比bitmap set myBit 1000000 1  要快. 单个查询没啥影响, 但是查询的数量一旦大了性能差异就非常大了.

2. bitmap 在 redis 中按 string 来存储，因此上限是 512MB（2^32 bits）.

setbit  myBit  0 1

Setbit  myBit 999999999 1

因此当我的第二个 setbit 值为 2^32-1=4294967295 时，由于 redis 没有采用压缩实现，就会直接申请到 512MB 内存空间来存储 2^32-1 bit 位置的值 1，中间的 bit 也会全填上 0.

而 guava 中 EWAHCompressedBitmap 是一种压缩的 bitmap 实现，将 64 bit 作为一个 word（一个 long 的长度），4个 word 作为一组，并在每一组的第一个 word 引入了 Running Length Word （携带跨度信息 word，类似路标）概念，其他三个 word 为 Literal Word（直接存储信息的 word）。在压缩 bitmap 实现下，本文的两个 setbit 操作就不会使 EWAHCompressedBitmap 内存占用暴涨，而是只会使用 2组 word，即 64 bytes.

不过即使通过压缩节省了空间，google 官方仍建议使用者从小到大来插入数据......

所以为了测试，给 redis bitmap 试了两个骚操作，结果证明 redis bitmap 没有用压缩结构实现.

这个问题解决方案：

https://blog.csdn.net/weixin_40721856/article/details/103112042

1、首先按天维护一个String值，就是将每天的最大id保存一下。我们叙述方便，将其记为 maxId。

2、每一天维护bitmap的时候，位置数值-昨天的maxid。

例如：昨天最大的id是10000，今天的id肯定是从10000以后开始的。

以我们要存储10005这个数值来计算，我们先拿到昨天的maxId(10000)，然后用10005-10000 =5 来表示这个id，只需要将今天的bitmap的第五位设置成1就可以解决这个问题了。
 

3.使用命令  info memory ,查询redis的内存占用.

开始准备截图的, 后面又忘记截图了, 等以后再把截图补上.

宣布一件大事.

今天领了结婚照, 国家分配的对象已经到了, 已经建立了长期稳定的合作伙伴关系. 哈哈哈哈

标签：word,Redis,redis,bitmap,myBit,32,10000,Bitmap,大事
来源： https://blog.csdn.net/u010398771/article/details/118220460

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。