Redis 大数据量(百亿级)Key存储需求及解决方案
点击下方公众号「关注」和「星标」
回复“1024”获取独家整理的学习资料!
最近我在思考实时数仓问题的时候,想到了巨量的redis的存储的问题,然后翻阅到这篇文章,与各位分享。
需求背景
该应用场景为DMP缓存存储需求,DMP需要管理非常多的第三方id数据,其中包括各媒体cookie与自身cookie(以下统称supperid)的mapping关系,还包括了supperid的人口标签、移动端id(主要是idfa和imei)的人口标签,以及一些黑名单id、ip等数据。
在hdfs的帮助下离线存储千亿记录并不困难,然而DMP还需要提供毫秒级的实时查询。由于cookie这种id本身具有不稳定性,所以很多的真实用户的浏览行为会导致大量的新cookie生成,只有及时同步mapping的数据才能命中DMP的人口标签,无法通过预热来获取较高的命中,这就跟缓存存储带来了极大的挑战。
经过实际测试,对于上述数据,常规存储超过五十亿的kv记录就需要1T多的内存,如果需要做高可用多副本那带来的消耗是巨大的,另外kv的长短不齐也会带来很多内存碎片,这就需要超大规模的存储方案来解决上述问题。
存储何种数据
人⼝标签主要是cookie、imei、idfa以及其对应的gender(性别)、age(年龄段)、geo(地域)等;mapping关系主要是媒体cookie对supperid的映射。以下是数据存储⽰示例:
PC端的ID:媒体编号-媒体cookie=>supperid
supperid => { age=>年龄段编码,gender=>性别编码,geo=>地理位置编码 }
Device端的ID:
imei or idfa => { age=>年龄段编码,gender=>性别编码,geo=>地理位置编码 }
显然PC数据需要存储两种key=>value还有key=>hashmap,⽽而Device数据需要存储⼀一种key=>hashmap即可。
数据特点
短key短value:
其中superid为21位数字:比如1605242015141689522
imei为小写md5:比如2d131005dc0f37d362a5d97094103633
idfa为大写带”-”md5:比如:51DFFC83-9541-4411-FA4F-356927E39D04
媒体自身的cookie长短不一;
需要为全量数据提供服务,supperid是百亿级、媒体映射是千亿级、移动id是几十亿级;
每天有十亿级别的mapping关系产生;
对于较大时间窗口内可以预判热数据(有一些存留的稳定cookie);
对于当前mapping数据无法预判热数据,有很多是新生成的cookie;
存在的技术挑战
1)长短不一容易造成内存碎片;
2)由于指针大量存在,内存膨胀率比较高,一般在7倍,纯内存存储通病;
3)虽然可以通过cookie的行为预判其热度,但每天新生成的id依然很多(百分比比较敏感,暂不透露);
4)由于服务要求在公网环境(国内公网延迟60ms以下)下100ms以内,所以原则上当天新更新的mapping和人口标签需要全部in memory,而不会让请求落到后端的冷数据;
5)业务方面,所有数据原则上至少保留35天甚至更久;
6)内存至今也比较昂贵,百亿级Key乃至千亿级存储方案势在必行!
解决方案
5.1 淘汰策略
存储吃紧的一个重要原因在于每天会有很多新数据入库,所以及时清理数据尤为重要。主要方法就是发现和保留热数据淘汰冷数据。网民的量级远远达不到几十亿的规模,id有一定的生命周期,会不断的变化。所以很大程度上我们存储的id实际上是无效的。而查询其实前端的逻辑就是广告曝光,跟人的行为有关,所以一个id在某个时间窗口的(可能是一个campaign,半个月、几个月)访问行为上会有一定的重复性。数据初始化之前,我们先利用hbase将日志的id聚合去重,划定TTL的范围,一般是35天,这样可以砍掉近35天未出现的id。另外在Redis中设置过期时间是35天,当有访问并命中时,对key进行续命,延长过期时间,未在35天出现的自然淘汰。这样可以针对稳定cookie或id有效,实际证明,续命的方法对idfa和imei比较实用,长期积累可达到非常理想的命中。
5.2 减少膨胀
Hash表空间大小和Key的个数决定了冲突率(或者用负载因子衡量),再合理的范围内,key越多自然hash表空间越大,消耗的内存自然也会很大。再加上大量指针本身是长整型,所以内存存储的膨胀十分可观。先来谈谈如何把key的个数减少。
大家先来了解一种存储结构。我们期望将key1=>value1存储在redis中,那么可以按照如下过程去存储。先用固定长度的随机散列md5(key)值作为redis的key,我们称之为BucketId,而将key1=>value1存储在hashmap结构中,这样在查询的时候就可以让client按照上面的过程计算出散列,从而查询到value1。
过程变化简单描述为:get(key1) -> hget(md5(key1), key1) 从而得到value1。如果我们通过预先计算,让很多key可以在BucketId空间里碰撞,那么可以认为一个BucketId下面挂了多个key。比如平均每个BucketId下面挂10个key,那么理论上我们将会减少超过90%的redis key的个数。
具体实现起来有一些麻烦,而且用这个方法之前你要想好容量规模。我们通常使用的md5是32位的hexString(16进制字符),它的空间是128bit,这个量级太大了,我们需要存储的是百亿级,大约是33bit(2的33次方),所以我们需要有一种机制计算出合适位数的散列,而且为了节约内存,我们需要利用全部字符类型(ASCII码在0~127之间)来填充,而不用HexString,这样Key的长度可以缩短到一半。
下面是具体的实现方式
public static byte [] getBucketId(byte [] key, Integer bit) {MessageDigest mdInst = MessageDigest.getInstance("MD5");mdInst.update(key);byte [] md = mdInst.digest();byte [] r = new byte[(bit-1)/7 + 1];// 因为一个字节中只有7位能够表示成单字符,ascii码是7位int a = (int) Math.pow(2, bit%7)-2;md[r.length-1] = (byte) (md[r.length-1] & a);System.arraycopy(md, 0, r, 0, r.length);for(int i=0;i<r.length;i++) {if(r[i]<0) r[i] &= 127;}return r;
}
参数bit决定了最终BucketId空间的大小,空间大小集合是2的整数幂次的离散值。这里解释一下为何一个字节中只有7位可用,是因为redis存储key时需要是ASCII(0~127),而不是byte array。如果规划百亿级存储,计划每个桶分担10个kv,那么我们只需2^30=1073741824的桶个数即可,也就是最终key的个数。
5.3 减少碎片
碎片主要原因在于内存无法对齐、过期删除后,内存无法重新分配。通过上文描述的方式,我们可以将人口标签和mapping数据按照上面的方式去存储,这样的好处就是redis key是等长的。
另外对于hashmap中的key我们也做了相关优化,截取cookie或者deviceid的后六位作为key,这样也可以保证内存对齐,理论上会有冲突的可能性,但在同一个桶内后缀相同的概率极低(试想id几乎是随机的字符串,随意10个由较长字符组成的id后缀相同的概率*桶样本数=发生冲突的期望值<<0.05,也就是说出现一个冲突样本则是极小概率事件,而且这个概率可以通过调整后缀保留长度控制期望值)。而value只存储age、gender、geo的编码,用三个字节去存储。
另外提一下,减少碎片还有个很low但是有效的方法,将slave重启,然后强制的failover切换主从,这样相当于给master整理的内存的碎片。
推荐Google-tcmalloc, facebook-jemalloc内存分配,可以在value不大时减少内存碎片和内存消耗。有人测过大value情况下反而libc更节约。
作者:小热爱
来源:juejin.cn/post/6956147115286822948
推荐阅读 点击标题可跳转
这篇 ElasticSearch 详细使用教程,内部分享时被老大表扬了
放弃 Maven 之后,我用它!!!速度贼快
最牛逼的故障诊断工具!秒级定位线上问题
我卖掉北京 500 万的房子,在老家生活的这两年…
最牛逼的性能监控系统!集强大功能于一身
挺带劲!通过 Nginx 来实现封杀恶意访问
Zabbix 通过 API 监控 Kubernetes
面试官:为什么 delete 表数据,磁盘空间却还是被占用
如何快速定位当前数据库消耗 CPU 最高的 sql 语句?
Redis 大数据量(百亿级)Key存储需求及解决方案相关推荐
- 【Redis】大数据量(百亿级)Key存储需求及解决方案
原文链接:http://www.cnblogs.com/colorfulkoala/p/5783556.html 问题导读: 1. 需求背景是什么? 2. 存储何种数据? 3. 数据特点是什么? 4. ...
- key redis 遍历_快乐运维Redis大数据量查询与清理
一. keys命令(生产环境禁止使用) 简单粗暴,由于Redis单线程这一特性,keys命令是以阻塞的方式执行的,keys是以遍历的方式实现的复杂度是 O(n),Redis库中的key越多,查找实现代 ...
- 极光笔记|百亿级KV存储在极光的运维实践之路
前言 极光从某种意义上讲,是一家数据公司.在整个公司的技术运营体系中,需要存储大量的KV数据.根据数据量.KV结构特点.数据更新频率.数据冷热.读写请求量和比例等因素,在极光逐步形成了CouchBas ...
- 大数据之_亿级分布式日志管理ELK_工作笔记001_ELK认识介绍
技术交流QQ群[JAVA,.NET,BigData,AI]:170933152 这个需要搭建集群,用自己的电脑的话,需要至少模拟3台Centos虚拟机,很费内存 ELK介绍 需求背景: 业务发展越来越 ...
- 数据库查询经常卡死?面对亿级大数据量,我是这么展示分析的
建议你们看到文末,不会亏待你们 日常一提数据分析和可视化,就想到这个工具操作要多简单易用,图表要多美多炫,然而总是忽略背后的数据支撑. excel 几十万行数据就卡死崩,谈何数据透视表.可视化? 近千 ...
- 上亿级的大数据量,如何高性能实现展示分析?
上亿级的大数据量,如何高性能实现展示分析? 日常一提数据分析和可视化,就想到这个工具操作要多简单易用,图表要多美多炫,然而总是忽略背后的数据支撑. excel 几十万行数据就卡死崩,谈何数据透视表.可 ...
- 大数据量分页存储过程效率测试附代码
在项目中,我们经常遇到或用到分页,那么在大数据量(百万级以上)下,哪种分页算法效率最优呢?我们不妨用事实说话. 测试环境 硬件:CPU 酷睿双核T5750 内存:2G 软件:Windows serv ...
- (转)大数据量分页存储过程效率测试附代码
大数据量分页存储过程效率测试附代码 在项目中,我们经常遇到或用到分页,那么在大数据量(百万级以上)下,哪种分页算法效率最优呢?我们不妨用事实说话. 测试环境 硬件:CPU 酷睿双核T5750 内存: ...
- Mysql数据库平滑扩容解决高并发和大数据量问题
目录 1 停机方案 2 停写方案 3 平滑扩容之双写方案(中小型数据) 4 平滑扩容之2N方案大数据量问题解决 4.1 扩容问题 4.2 解决方案 4.3 双主架构思想 4.4 环境部署 4.4.1 ...
最新文章
- IOS UITabBarViewController 修改背景颜色
- 基于视觉惯性里程计的无监督深度补全方法
- 如何优雅的使用 phpStorm 开发工具
- JavaScript多线程之HTML5 Web Worker
- YUM更换源(1)--yum找不到安装包 2013-01-18 20:08 8687人阅读 评论(1) 收藏 举报 分类: linux(70) 公司提供的CentOS VM中,/etc/yum.r
- python脚本批量登录crt_Python实现批量新建SecureCRT Session
- SQL Server索引超出了数组界限解决方法
- sev2008服务器系统,在windows 2008 64位系统安装sql server 2000
- matlab绘制均匀b样条曲线,MATLAB绘制B样条曲线
- IE8 兼容性问题总结
- Docker 之 高级篇(应用复杂安装、DockerFile、Docker网络、Docker-compose、可视化工具)
- 传奇手游战神引擎多机多区配置方法
- 爬虫实战——中国天气网数据
- 宇宙少女-小贾的一时兴起
- 四旋翼无人机学习第4节--STM32、MPU9250等器件的绘制
- 深度学习系列-前言:深度学习的好教程
- Vue禁用ESLint
- 微信小程序 - 页面插入广告(激励式广告)超详细教程
- 多用户商城系统解决方案
- Ubuntu 搭建FTP文件服务器
热门文章
- 做一个简单的“远程”开关 ESP8266 + APP
- C++ Traits编程技法--从迭代器的设计看参数推导与类型推导
- 编辑器漏洞 EWebedtitor FCKeditor spaw editor
- 普通话测试软件测试成绩很差,普通话测试成绩的差异性分析
- Cadence allegro 17.4 PCB DRC检查
- 今年诺贝尔奖得主居然把这事研究清楚了:学历和收入到底有多大关系?
- 传奇服务器需要满足什么条件
- GSL----积分部分(翻译+精简)
- Shell批量重命名文件,使得在在移动设备中排序正确
- 手把手教你用数据分析帮女神学姐选婚房