华为云首页用户手册

云数据库 GEMINIDB-如何检测和解决大key与热key问题:大key问题

时间：2024-10-28 17:36:33

云数据库 GEMINIDB

大key问题

可能原因：
大key的产生，最主要的原因是主键设计不合理，使得单个分区的记录数或数据量过大。一旦某一个分区出现极大时，对该分区的访问，会造成分区所在服务器的负载变高，甚至造成节点内存溢出（OOM）等。
处理思路：
针对大key问题，一般采取如下两种处理思路。
- 增加缓存，优化表结构。
- 基于现有分区键，增加分区键散列。对数据进行打散，避免单个分区的记录过大。
检测方法：
通过长时间的业务观察，我们规定以下阈值，超过任何一个条件的阈值即为大key。
1. 单个分区键的行数不能超过10万。
2. 单个分区的大小不超过100MB。
GeminiDB Cassandra支持了大key的检测与告警。在 CES 界面，可以配置实例的大key告警，具体方法请参见设置告警规则。

当发生大key事件时，系统会第一时间发送预警通知，您可以前往CES界面查看监控事件数据，及时处理，避免业务波动。

图1 大key告警查看事件

告警字段说明如下：
```
[
  {
    "partition_size": "1008293497",             //超大分区键的总大小
    "timestamp": "2021-09-08 07:08:18,240",      //大key产生时间
    "partition_num": "676826",         //超大分区键的总行数
    "keyspace_name": "ssss",      //keyspace名称
    "node_id": "ae342330ded14605b6304e80e6a6efeeno06",      //节点id
    "table_name": "zzzz",        //表名称
    "table_id": "024a1070-0064-11eb-bdf3-d3fe5956183b",      //表id
    "partition_key": "{vin=TESTW3YWZD2021003}"      //分区键
  }
]
```
常见案例及解决方案：
案例1：某集群的数据量过大，导致集群存在大分区键(排查数量大概为2000+)，最大的分区键达到38GB。当业务频繁访问这部分大的分区键时，会导致节点持续高负载，影响业务请求成功率。

该案例中表结构设计如下：

表设计分析：

上述movie表保存了短视频的相关信息，分区键为movieid，并且保存了用户信息(uid)。如果movieid是一个热门短视频，有几千万甚至上亿用户点赞此短视频，则该热门短视频所在的分区非常大(当前发现有38GB)。

解决方法：

针对上述案例中问题，可以通过如下方法解决。
1. 优化表结构。
  创建新表保存热门短视频信息，只保留短视频公共信息，不包含用户信息，确保该表不会产生大的分区键。热门短视频信息写入该表中。
2. 增加缓存
   业务应用先从缓存中读取热门文件信息，没有查询到，则从数据库中查询，减少数据库查询次数。
  
  整体优化逻辑如下：
  1. 先查缓存，当缓存存在，直接返回结果。
  2. 当缓存不存在，查询热门视频缓存（缓存不存在，则查询hot表），当视频为为热门视频时，查询hotmovieaccess表。
  3. 当hotmovieaccess表存在结果时，直接返回。当hotmovieaccess表不存在记录时，查询movie表。
  4. 并缓存查询结果。
案例2：movie_meta以月度建表，每个表只存当月的数据，初始的这种设计是可以减轻或规避分区键过大问题的。由于业务频繁写入，热门视频存储的记录非常多，还是形成了大的数据分区。

解决方法：

新分区键增加一个随机数（0~999）：将原来一个分区存储的信息随机离散存储到1000个分区中。采用新的分区键之后，没有形成新超过100MB的分区键，旧的超过100MB的分区键数据，随着时间过期即可。