GaussDB (for Cassandra) 数据库治理:大 key 与热 key 问题的检测与解决
摘要:GaussDB(for Cassandra) 提供了大 key 和热 key 的实时检测,以帮助业务进行合理的 schema 设计,规避业务稳定性风险。
本文分享自华为云社区《GaussDB (forCassandra) 数据库治理-- 大key与热key问题的检测与解决》,作者:Cassandra 官方 。
Cassandra 数据库是一个高度可扩展的高性能分布式数据库,面向大数据场景,可用于管理大量的结构化数据。在业务使用的过程中,随着业务量和数据流量的持续增长,往往一些业务的设计弊端逐渐暴露出来,降低了集群的稳定性和可用性。比如主键设计不合理,单个分区的记录数或数据量过大,出现超大分区键,引起了节点负载不均,集群稳定性会下降,这一类问题称为大 key 问题。当某一热点 key 的请求在某一主机上的访问超过 server 极限时,会导致热点 Key 问题的产生。往往大 key 是造成热 key 问题的间接原因。
GaussDB(for Cassandra) 是一款基于华为自研的计算存储分离架构的分布式数据库,兼容 Cassandra 生态的云原生 NoSQL 数据库,支持类 SQL 语法 CQL。在华为云高性能、高可用、高可靠、高安全、可弹性伸缩的基础上,提供了一键部署、快速备份恢复、计算存储独立扩容、监控告警等服务能力。针对以上问题,GaussDB(for Cassandra) 提供了大 key 和热 key 的实时检测,以帮助业务进行合理的 schema 设计,规避业务稳定性风险。
大 key 的分析与解决
大 key 的产生,最主要的原因是主键设计不合理,使得单个分区的记录数或数据量过大。一旦某一个分区出现极大时,对该分区的访问,会造成分区所在 server 的负载变高,甚至造成节点 OOM 等。
针对大 key 问题,一般采取两种修复手段,一种是增加缓存,优化表结构。一种是基于现有分区键,增加分区键散列。对数据进行打散,避免单个分区的记录过大。GaussDB(for Cassandra) 有如下整改事例,业务整改后负载平稳运行。
案例 1:
XX 集群的数据量过大,导致集群存在大分区键(排查数量大概为 2000+),最大的分区键达到 38G。当业务频繁访问这部分大的分区键时,会导致节点持续高负载,影响业务请求成功率。
表结构如下
表设计分析 movie 表保存了短视频的相关信息,分区键为 movieid,并且保存了用户信息(uid),如果 movieid 是一个热门短视频,有几千万甚至上亿用户点赞此短视频,则该热门短视频所在的分区非常大(当前发现有 38G)。
解决方法:
1. 优化表结构创建新表保存热门短视频信息,只保留短视频公共信息,不包含用户信息,确保该表不会产生大的分区键。热门短视频信息写入该表中。
2. 增加缓存增加缓存,业务应用先从缓存中读取热门文件信息,没有查询到,则从数据库中查询,减少数据库查询次数。
整个优化逻辑如下:
1. 先查缓存,当缓存存在,直接返回结果。
2. 当缓存不存在,查询热门视频缓存(缓存不存在,则查询 hot 表),当视频为为热门视频时,查询 hotmovieaccess 表。
3. 当 hotmovieaccess 表存在结果时,直接返回,当 hotmovieaccess 表不存在记录时,查询 movie 表。
4. 并缓存查询结果。
案例 2:
movie_meta 以月度建表,每个表只存当月的数据,初始的这种设计是可以减轻或规避分区键过大问题的。由于业务频繁写入,热门视频存储的记录非常多,还是形成了大的数据分区。
解决办法:新分区键增加一个随机数(0~999):将原来一个分区存储的信息随机离散存储到 1000 个分区中。采用新的分区键之后,没有形成新超过 100M 的分区键,旧的超过 100M 的分区键数据,随着时间老化过期即可。
大 key 的定义与检测手段
通过长时间的业务观察,我们规定以下阈值,超过任何一个条件的阈值即为大 key:
1. 单个分区键的行数不能超过 10 万
2. 单个分区的大小不超过 100MB
GaussDB(forCassandra) 支持了大 key 的检测与告警。在 CES 界面,可以配置实例的大 key 告警。当发生大 key 事件时,会第一时间通知。及时整改,可避免业务波动。
大 key 告警字段解释
热 key 的危害与解决
在日常生活中,经常会发生各种热门事件,应用中对该热点新闻进行上万次的点击浏览和评论时,会形成一个较大的请求量,这种情况下会造成短时间内对同一个 key 频繁操作,会导致 key 所在节点的 CPU 和 load 飙高,从而影响落在该节点的其他请求。导致业务成功率下降。诸如此类的还有热门商品促销,网红直播等场景,这些典型的读多写少的场景也会产生热点问题。
热 key 会造成以下危害:
1. 流量集中,达到物理网卡上限。
2. 请求过多,缓存分片服务被打垮。
3. DB 击穿,引起业务雪崩。
GaussDB(forCassandra) 针对热 key 问题,常见的修复手段如下:
1. 设计上需要考虑热 key 的问题,避免在数据库上产生热 key
2. 业务侧通过增加缓存来减少热 key 出现的情况下对数据库造成的冲击。考虑多级缓存解决热 key 问题(如 Redis + 本地二级缓存)
3. 屏蔽热点 key, 比如在业务侧进行定制, 支持热 key 黑白名单能力,可以将热 key 临时屏蔽。
热 key 的检测
我们定义访问频率 大于 100000 次/min 的 key 为热 key。热 key 事件分为两种类型,一种时 WRITES 事件,代表写热点,一种是 READS 事件,表示读热点。
GaussDB(for Cassandra) 也提供了热 key 的监测与告警。在 CES 界面,可以配置实例的热 key 告警。如下
热 key 告警字段解释:
GaussDB(for Cassandra) 提供了大 key 和热 key 的实时监控。确保第一时间感知业务风险。提供的大 key 和热 key 解决方案,在面对大数据量洪峰场景,增强了集群的稳定性与可用性。为客户业务持续稳定运行保驾护航。
综上,在线业务在使用 Cassandra 时,必须执行相关的开发规则和使用规范,在开发设计阶段就降低使用风险。一般按照 制定规范 --> 接入评审 --> 定期巡检 --> 优化规则 的治理流程进行。合理的设计一般会降低大部份风险发生的概率,对于应用来说,任何表的设计都要考虑是否会造成热 key,大 key 的产生,是否会造成负载倾斜的问题;另外建立数据老化机制,表中的数据不能无限制的增长而不删除或者老化;针对读多写少的场景,要增加缓存机制,来应对读热点问题,并提升查询性能;对于每个 PK 以及每行 Row 的大小,要控制大小,否则将影响性能和稳定性。超出后要及时优化。
版权声明: 本文为 InfoQ 作者【华为云开发者社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/7bb59c129d9da2b8b9b1238c1】。文章转载请联系作者。
评论