Roaringbitmap+Mysql构建标签--实际使用问题
项目github链接：baiye21/RoaringbitmapDemo · GitHub
前文：
RoaringBitMap处理海量数据内存diff_roaringbitmap实践-CSDN博客
基于配置实现RoaringBitMap的交、差、并集处理-CSDN博客
1、id映射：
因为Roaringbitmap，可以存储的是数字类型，所以如果需要标记的数据唯一键是字符型，就需要单独定义一张id映射表了，这可能会对后续关联业务造成一定的影响。
2、数据明细回表：
因为Roaringbitmap一位只能是1或者0，也就意味着只能存储单个信息，举个例子，如果对用户参与活动打标，那么你可能有一个用户参与某个活动的位图，这个位图只能查询某些用户是否参与某个活动，而不能关联活动参与时间查询，那么也就意味着，明细数据显示和排序可能实现起来比较麻烦，需要先通过位图缩小查询范围，再拿用户id去查询明细数据，带出活动参与时间，就有点类似myszql的回表，索引键没有的数据，需要回表进行查询。不过一般来说，使用位图去检索，是不会要求排序的，如果确实有对应需求，那么可以尝试建立更细维度的标签，还是使用用户参与活动的场景举例，如果关联参与时间，那么可以新增最近3天，5天，7天参与某某活动的标签，去检索。
3、Mysql存储空间碎片：
Mysql的text类型字段，如果数据频繁更新，会导致空间碎片增多，影响存储空间使用，这部分空间需要手动处理回收才能释放。我实际使用的场景，线上的标签表，实际存储空间还不到1G，但是由于频繁更新，1年左右产生了16G的空间碎片，对比实际存储空间，碎片空间确实比较大。
4、标签数据缓存：
虽然使用压缩位图Roaringbitmap序列化后进行存储，但是数据量上来，序列化后的字符串还是比较大，如果存储在数据库，又频繁查询的话，对数据库性能还有网络带宽还是有一定影响，所以建议对这类标签数据做本地缓存，诸如使用Caffeine、EhCache的等等，加快查询效率，同时减少数据库和传输压力。