策略中心DRDS分库分表改造方案
一、问题描述二、DRDS数据库表的介绍
单库单表小表广播分库分表 三、改造过程
策略中心DRDS分库分表改造方案 一、问题描述在策略中心之前的数据存储过程中，在数据库方面一直使用的是单库单表模式，即生产库使用的是DRDS分布式数据库，但是建表语句并没有对所建表的存储、分片和路由进行合理设计，如图1。而前期表结构模型设计的不够科学合理，即便后期通过应用的SQL来优化，也成效甚微。特别是对DRDS分布式数据库而言，一旦数据表建立了，后期的分库分表的拆分方式是无法进行修改的，即便数据表删除重建，数据的恢复相对麻烦。因此在已经单库单表已经创建的基础上，评估选择策略中心后期业务开展过程中的几张核心业务表对其进行删表重建并恢复数据，由DRDS单库单表模式逐步过渡为DRDS分库分表模式。
二、DRDS数据库表的介绍 单库单表对于数据量不大的数据表，可以如同普通的单库RDS表一样，建立单库单表。但由于DRDS上单库单表只存在0库上，和其他不在0库的表可能存在跨库JOIN的风险。此外，过多的单库单表，容易造成DRDS后端分库资源损耗不平衡，0库的IO消耗过大的问题，因此应尽量予以避免。
小表广播对于数据量少，且数据变化不频繁，数据一致性要求不高的单库单表，为了解决上述的跨库问题，可以考虑使用小表广播。小表广播是指将表复制到每个分库上，在分库上通过同步机制实现数据一致，但存在秒级延迟。好处在于，可以将 JOIN 操作下推到底层的分库，来避免跨库 JOIN，提高执行效率。建表时使用BROADCAST关键字即可实现小表广播。如下表1。
CREATE TABLE users (
user_id int,
user_name varchar(50),
create_time date,
primary key(id)
) ENGINE=InnoDB BROADCAST;
但需要额外注意，小表广播的使用限定：
表数据量少，尽量不应超过10万；数据的更新不能太频繁；过大的表和更新过于频繁，都容易增加DRDS数据库底层IO压力和网络消耗。 分库分表
DRDS在后端将数据量较大的数据表水平拆分到后端的每个RDS数据库中，这些拆分到RDS中的数据库被称为分库，分库中的表称为分表。拆分后，每个分库负责每一份数据的读写操作，从而有效的分散了整体访问压力。而分库分表优化的目的在于，重点减轻分布式环境中的网络IO开销，尽量将SQL中的运算下推到底层各个分库执行，从而减少网络IO开销、提升SQL执行效率。
三、改造过程- 将对应的库表结构进行备份一份；然后对各表新建好对应的索引；在索引重建之前需要了解到几个问题。
由于策略中心数据库表是使用自增长的字段类型拿来做表的ID主键，这就会引申出一个问题，那就是DRDS将数据库表进行了分库分表，是否能够保证自增长字段的全局唯一的单调连续递增呢？
事实上，在DRDS中，当拆分表和广播表的字段指定了AUTO_INCREMENT后，DRDS就会创建隐式的Sequence来生成全局唯一和有序递增的数字序列。非拆分表的AUTO_INCREMENT的值是由底层RDS自己生成的。
那么分库分表是如何确定的？
一般情况下，单个物理分表的容量不超过 500 万行数据。我们通常可以预估未来的数据增长量，用估算出的总数据量除以总的物理分库数，再除以建议的最大数据量 500 万，即可得出每个物理分库上需要创建的物理分表数。策略中心的DRDS共有4个RDS实例，每个RDS实例上默认会创建8个物理分库，因此公式如下：
物理分库上的物理分表数 = 向上取整(估算的总数据量 / (RDS 实例数 * 8) / 5,000,000)
在策略中心开发成员对核心业务表的评估下，未来的总数据量不超过1亿，因此物理分库上的物理分表数可得1个。由公式可知目前策略中心的核心业务表的分库分表规则为只分库不分表。
如何选择核心业务表的拆分键？
拆分键即分库/分表字段，DRDS根据拆分键的值将数据表水平拆分到每个RDS实例上的物理分库中。
拆分键的选择遵循的原则有三个：
DRDS 目前支持数字型、字符型、日期型的字段做拆分键；尽可能找到数据表中的数据在业务逻辑上的主体，并确定大部分（或核心的）
数据库操作都是围绕这个主体的数据进行，然后可使用该主体对应的字段作为拆分键；根据数据分布和访问的均衡度来考虑拆分键，尽量将数据表中的数据相对均匀地分布在不同的物理分库/分表中。
因此在了解了自增长主键的自增长实现底层原理以及遵循拆分键选择原则的情况下，可以了解到在DRDS中自增长主键是可以作为分库分表的拆分键的，且可以使用哈希函数对自增长主键进行哈希计算达到随机落库的目的。故而在选取了核心业务表后均以自增长id哈希进行只分库不分表。
- 在选取了拆分键之后则是对现有的业务表进行删表重建。然后执行数据的同步，将原有库表的数据执行迁移。
至此策略中心的DRDS分库分表重建方案已完成。
