可动态扩展的分库分表策略浅谈

一般的系统总是由小到大发展的。一开始使用一个数据库，而后逐渐扩展。在分库过程中经常使用对特定的键值进行hash的办法进行分库分表。但是使用hash来进行分库分表，在具体的应用中可能不能满足需求。比如，在SAAS平台下，不同租户的数据量是千差万别的，根据二八现象，20%的租户可能占用了80%的存储资源。如果使用hash算法，很可能导致数据分布不均匀。

这里提出一个分库分表算法，解决SAAS平台下，数据存储的二八现象。

元数据准备
1. 业务数据按照租户ID进行分库。
2. 用一张表存储，租户ID->虚拟库ID的映射关系，（可在启动后，导入内存）。
3. 用另一张表存储，虚拟库ID->实际库连接信息（也可以在启动后，导入内存）。

业务数据存取
1. 需要存储数据前，先根据租户ID（数据中总是带有租户ID），切换数据源
2. 数据源查找的过程，基本上是对上述两张元数据表进行查找，先找到虚拟库ID，进而找到实际的库连接信息。
3. 需要提取数据时，也按照上述方法找到实际的库连接信息，进行数据源切换。

分析
1. 之所以使用两张表而不是一张表（直接租户ID->实际库连接信息），是为了便于管理。及减少内存消耗。
2. 可以在虚拟库ID上进行某种业务划分，如，分为散户，小客户，普通客户，大客户，超大客户。被划分在同一个虚拟库ID上的租户必将共享一个实际的物理库。所以在开始规划的时候，应当尽量均匀地将租户分配到不同的虚拟库ID上。
3. 在虚拟库ID上的数据是基本均匀的假设下，就可以将虚拟库ID映射到实际的物理库上。
4. 在物理库扩展的情况下，可以将部分虚拟库ID的数据，迁移到新的物理库上。

实际案例模拟
1. 租户A被分配了虚拟库#12；虚拟库#12实际处于物理库#1上。
2. 由于物理库#1已经负载过重，决定扩展一个物理库#5，并把虚拟库#12迁移到物理库#5.
3. 停机（不知道有没有更好的办法），将虚拟库#12的数据导出，导入到物理库#5中。注意，此时虚拟库#12的数据同时在#1和#5上。
4. 切换元数据表，进行验证。如果验证通过，则，择机回收物理库#1上的数据空间；如果验证失败，恢复元数据信息，找到失败原因，下次再做数据迁移。

利弊分析
1. 引入虚拟库的原因是：一次可以将有逻辑关联的一组租户一并迁移，减少维护成本。
2. 该算法仍旧不支持“不停机”数据迁移，可能都不支持“部分停机，大部分不停机”数据迁移。