云数据库 GAUSSDB NOSQL-基本设计规范:设计规范

时间：2023-11-10 12:13:27

云数据库 GAUSSDB NOSQL 数据库规范

规则1：禁止在数据库中存储图片、文件等大数据。图片或文件等大数据建议存储到对象存储服务中。

规则2：单行key和value数据大小最大不能超过64KB，平均大小不超过10KB。

规则3：任何表的设计都要考虑到数据的删除策略，表中的数据不能无限的增长而不删除。

规则4：设计分区键以均匀分发工作负载，避免出现数据倾斜问题。

表的主键的分区键部分确定存储表数据的逻辑分区，如果分区键分布不均衡，会导致节点与节点之间数据和负载不均衡，从而出现数据倾斜的问题。

如表1为一些常见分区键分布均匀性的效果对比。

表1 常见分区键分布均匀效果
分区键值	分区键分布均匀性
用户 ID，应用程序中有许多用户。	好
状态代码，只有几个可用的状态代码。	差
项目创建日期，四舍五入至最近的时间段 (例如，天、小时或分钟)。	差
设备 ID，每个设备以相对类似的间隔访问数据。	好
设备 ID，被跟踪的设备有很多，但到现在为止，其中某个设备比其他所有设备更加常用。	差

如下为常见均匀分布分区键的设计方案

规则5：合理设计分区key，均匀访问数据，避免出现大key或者热key问题。

大key问题：大key的产生，最主要的原因是主键设计不合理，使得单个分区的记录数或数据量过大。一旦某一个分区出现极大时，对该分区的访问，会造成分区所在服务器的负载变高，甚至造成节点内存溢出（即OOM）等。
热key问题：在日常生活中，经常会发生各种热门事件，应用中对该热点新闻进行上万次的点击浏览和评论时，会形成一个较大的请求量，这种情况下会造成短时间内对同一个key频繁操作，会导致key所在节点的CPU和负载升高，从而影响落在该节点的其他请求，导致业务成功率下降。诸如此类的还有热门商品促销，网红直播等场景，这些典型的读多写少的场景也会产生热点问题。

如何处理大key和热key问题请参见如何检测和解决大key与热key问题。

另外，对 GaussDB (for Cassandra)数据库的读能力有更高要求的，读多写少的场景，可以考虑把热点数据缓存到GaussDB(for Redis)。

规则6：单个分区键的行数不能超过10万，单个分区磁盘空间不超过100MB。

规则7：所有写入GaussDB(for Cassandra)的数据，提供数据副本强一致性，但是不支持事务。

表2 GaussDB(for Cassandra)一致性说明
一致性类型	是否支持一致性	说明
并发写一致性	支持	GaussDB(for Cassandra)不支持事务，数据写入强一致。
表之间一致性	支持	GaussDB(for Cassandra)不支持事务，数据写入强一致。
数据迁移一致性	最终一致性	采用DRS迁移提供数据抽样对比验证能力。业务自己完成迁移时，需要业务自行完成迁移前后数据校验。