分库分表 - 数据库分片（sharding）研究（一）

什么要分片

分片是一项可跨许多独立数据库、分发大量相同结构数据的技术。 需要分片的原因有很多：

• 数据总量过大，超出单一数据库的约束范围
• 整个工作负载的事务吞吐量超出单一数据库的容量
• 租户可能需要与其他租户物理隔离，因此每个租户都需要单独的数据库
• 由于符合性、性能或地理政治的原因，不同的数据库部分可能需要驻留在不同的地域中。

概念

• 垂直分区 - 跨数据库查询：数据在数据层中的多个数据库之间垂直分区。 通常，不同的表集驻留在不同的数据库上。 这意味着不同数据库上的架构是不同的。 例如，清单的所有表都位于一个数据库上，而与会计相关的所有表都位于第二个数据库上。 采用此拓扑的常见使用案例需要使用一个查询跨多个数据库中的表进行查询或编译报表。

• 水平分区 - 分片：将数据进行水平分区以将行分布到扩大的数据层上。 使用此方法时，所有参与数据库中的架构是相同的。 此方法也称为“分片”。

水分区和垂直分区的对比 （以下摘自网图）

 

分片（水平分区）的方式

• 基于分区键 Hash 方式的分区 （Key Based Sharding）

 

• 基于分区键范围的分区（Range Based Sharding）

 

• 基于分区键目录的分区（Directory Based Sharding）

分片（水平分区） 设计参考

下图摘取自 Microsoft 的产品文档，显示了一种体系结构，它包含与数据库集合有关的弹性数据库功能。

在此图中，数据库颜色表示架构。 颜色相同的数据库具有相同的架构。

1. 一组使用分片体系结构的 SQL 数据库托管在 Azure 上。
2. 弹性数据库客户端库 用于管理分片集。
3. 一个数据库子集已放入 弹性池。
4. 弹性数据库针对所有数据库运行计划的或即席的 T-SQL 脚本。
5. 拆分/合并工具 用于将数据从一个分片移到另一个分片。
6. 使用 弹性数据库查询 可以编写跨分片集中所有数据库运行的查询。
7. 弹性事务允许跨多个数据库运行事务。

 思考

关于数据库的分片架构有很多，上面的 Microsoft Azure SQL 只是其中的一种设计。不过从这个设计中，我们可以看到数据库分片需要考虑以下方面：

1. 由多个DB构成的 Data Tier ，用于数据的存储和处理
2. Client 端的 library，需要考虑如何进行客户端的改造，尽可能减少对客户端的影响
3. 跨 Sharded 的查询，Microsoft 称之为 Elastic Database Query DB。虽然我们需要对分区的键进行优化设计，但也不可避免的会产生跨 Sharded的查询
4. Sharded 的管理，如拆分、合并、数据迁移等。可以由专门的工具，也可以只考虑方案。
5. Database Jobs 的执行
6. 事务

考虑到一些实际情况，延申的问题还有：

1. 数据的备份、恢复管理
2. 数据库连接配置管理，凭据管理
3. 数据库部署，创建、更新表
4. 原有存储过程、作业中的可能存在的跨 sharded 的 join
5. 之前可能存在其它库的 linkdb
6. 之前数据库中的的 ETL，订阅发布等
7.  数据库的搭建、高可用等问题。Azure 有自己的 Elastic database pool 来处理，如果是本地就需要考虑自动化或者手工搭建的问题了。       

 参考文献

• Understanding Database Sharding
• Scaling out with Azure SQL Database