使用要求
拆分键的类型必须是 DATE / DATETIME / TIMESTAMP 其中之一。
DRDS 实例的版本必须是 5.1.28-1320920 及其以上的版本。DRDS 版本说明请参考文档版本说明。
优化点
相对于 YYYYDD,YYYYDD_OPT 随着时间线递增能够保持数据在各个 RDS 实例之间的均衡分布,效果与 YYYYMM_OPT 类似。
YYYYDD_OPT 的各个 RDS 实例之间的数据均衡性,有助于充分利用各个 RDS 实例的性能。
YYYYDD 与 YYYYDD_OPT 该如何选择:
如果业务数据的时间按顺序逐渐增大的,并且各个时间点的数据量相差不大,那么适合用 YYYYDD_OPT 实现 RDS 实例之间的数据均衡;
如果业务数据的时间会比较跳跃,数据的时间点出现比较随机,那么适合用 YYYYDD。
路由方式
根据分库键的时间值的年份与一年的天数进行计算哈希值,然后再将哈希值按分库数去取余,完成路由计算。
分库分表键的哈希计算过程会根据 DRDS 之下的 RDS 实例的数目适当考虑 RDS 数据的均衡性。
使用场景
业务需要按年日进行分库分表。
希望 DRDS 的各个 RDS 实例的数据量保持相对均衡。
拆分键的时间呈顺序递增(即不是随机的)并且每天的数据量相对平均的前提下(例如,每天的流水日志,它随着日的期不断增大,数据不会集中在同一个 RDS 上)。
注意事项
YYYYDD_OPT 不支持对于每一个年天都独立对应一张分表,YYYYDD_OPT 的分库分表必须固定分表数目。
当日期经过一个轮回(如 2013-03-01 是 2012-03-01 的一个轮回)后,同一个日期有可能被路由到同一个分库分表,视实际的分表数目而定。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
从您的描述中,我们可以了解到您在讨论的是阿里云分布式关系型数据库服务(DRDS)中的分库分表策略,特别是关于使用YYYYDD
与YYYYDD_OPT
作为拆分键的场景、优化点、路由方式以及注意事项。下面我将基于这些信息帮助您更好地理解如何选择和应用这两种模式:
YYYYDD: 这种模式直接根据年份和日期进行哈希计算并路由到相应的RDS实例和分表。适用于业务数据时间跳跃较大,即数据的时间点分布较为随机的情况。这种方式不考虑数据量均衡性,可能导致某些RDS实例负载较高。
YYYYDD_OPT: 相较于YYYYDD,此选项通过优化的哈希算法,在保持按年日分库分表的同时,能更均衡地分布数据到各个RDS实例上。它更适合那些数据随着时间线递增且每天数据量相对平均的场景,比如每日流水日志。这种模式有助于充分利用每个RDS实例的性能,避免数据倾斜问题。
均衡性需求高:如果您的业务需要确保数据在不同RDS实例间均衡分布,且数据生成随时间有序增长,应选择YYYYDD_OPT
。这有助于长期维持系统的稳定性和效率。
数据随机性大:若业务数据产生的时间点非常随机,没有明显的顺序或周期性,那么采用YYYYDD
可能更为合适,尽管它可能不会达到最优的数据均衡状态。
路由计算:无论是哪种模式,DRDS都会基于分库键(这里是时间值)执行哈希计算,并根据当前RDS实例的数量来决定数据的最终存储位置,以实现数据的分散存储。
固定分表数目:使用YYYYDD_OPT
时,需要注意该方案不支持为每一天动态创建新表,而是要求预先设定固定的分表数目,这可能影响到特定日期轮回后数据的分布情况。
轮回效应:由于是基于年日进行哈希计算,当日期经过一个完整的周期(如一年)后,理论上相同日期的数据可能会被路由到相同的分库分表,但实际效果会受到分表数量的影响,这也是设计分表策略时需要考虑的因素之一。
综上所述,选择合适的分库分表策略需依据具体业务场景和数据特性,平衡数据分布的均衡性、系统扩展性和维护成本等因素。如果您对DRDS的配置或最佳实践有更多疑问,可以参考阿里云官方文档或咨询技术支持获取帮助。