基本设计规范

设计规范

规则1：禁止在数据库中存储图片、文件等大数据。

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

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

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

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

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

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

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

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

• 单个分区键的行数不能超过10万。
• 单个分区键下记录大小不能超过100MB。

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

规则8：大规模存储要重点考虑数据库拆分。

GeminiDB Cassandra整个集群的节点数控制在100以内，超过100节点要考虑拆分，一般有垂直拆分和水平拆分两种方法。

• 垂直拆分：是指按功能模块拆分，比如分为订单库、商品库、用户库等，这种方式多个数据库之间的表结构不同。
• 水平拆分：将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的表结构完全相同。

规则9：设计上避免大面积删除导致的墓碑问题。

• 尽量使用TTL代替Delete操作。
• 不要出现大面积删除数据，尽量通过主键前缀删除。
• 单个分区键内一次范围删除所包含行数不超过1000。
• 范围查询避免查询已删除数据。
• 不推荐在单个分区内频繁做范围删除。

设计建议

建议1：合理控制数据库规模和数量。

• 建议单表数据量不超过1000亿。
• 建议单库不超过100个表。
• 建议单表字段数上限控制在20~50个。

建议2：提前进行资源估算，估算出对GeminiDB Cassandra服务器要求。

• 根据业务估算需要使用N节点集群，建议在评估的基础上冗余N/2个节点，保证容忍故障节点个数N/2，以支撑故障场景下性能保持一致。
• 正常业务压力下每个节点CPU使用率限制使用在50%，防止业务出现高峰波动。

建议3：大规模GeminiDB Cassandra存储要考虑基于业务场景做数据库性能测试。

对于请求量、数据量比较大的业务场景，需要提前做性能摸底，原因是业务读写比例和随机访问模式以及不同的规格实例，性能差异较大。

建议4：数据库集群拆分粒度要合适。

• 分布式场景，考虑节约资源费用和维护成本，一个服务内部各个微服务可以共用一个GeminiDB Cassandra集群。
• 服务内部，根据数据重要程度、表数量和单表记录数，可进一步拆分成不同集群。

建议5：避免单条数据部分字段频繁更新。

建议6：List、Map、Set等嵌套类型，当元素超过一定数量，会影响读取性能，建议当元素过多时，采用转换成JSON字符串的形式进行存储。