大规模数据处理：分库分表与数据迁移最佳实践

什么是分库分表

分库分表是一种数据库架构优化策略，它将数据分散存储在多个数据库或表中，以此来提高系统的可扩展性和性能。

虽然分库分表能够提升系统的整体性能，但是也不要一上来就分库分表，如果系统在单表的情况下，能够正常运行，就使用单表即可；

当业务出现性能瓶颈时，我们可以考虑先使用分区的方式去优化，如果分区之后仍然不能满足性能要求，再考虑分库分表；

在单库单表下，如果表的数据量累积到一定的数量时（5000W 行或 100G 以上），数据库的性能会出现明显下降，即使我们使用索引优化或读写库分离，性能依然存在瓶颈。此时，如果每日数据增长量非常大，就应该考虑分表，避免单表数据量过大，造成数据库操作性能下降。

面对海量数据，在单库单表下，数据库连接数、磁盘 I/O 、网络吞吐、并发能力等都是有限的。所以，在一些大数据量且高并发的业务场景中，我们就需要考虑分库分表来提升数据库的并发处理能力，从而提升应用的整体性能。

如何分库分表

通常，分库分表分为垂直切分和水平切分两种。

垂直分库

垂直分库通常是根据业务模块将数据库中的表进行分类，每个业务模块的表存储在独立的数据库中。这种方式可以减少数据库的宽度，提高查询效率，并且有利于数据库的维护和扩展。

水平分库

水平分库是将同一个库的数据按照某种规则拆分到多个数据库中，每个数据库存储数据的一部分。这种方式可以有效地分散单个数据库的负载，提高系统的并发处理能力。

垂直分表

垂直分表是将一个表的列拆分到多个表中，通常将不常用的列或大字段拆分出来。这种方式可以减少表的宽度，提高查询性能。

水平分表

水平分表是将一个大表的数据按照某种规则（如哈希分片、范围分片）拆分到多个表中。这种方式可以有效地分散单个表的数据量，提高查询效率。

举例说明一下，如何确定分表数量
提成系统有个课消明细表，用来记录学生上课课时消耗详情，每月大概有 400 万条数据，一年就是 4800 万，假如我们保留 10 年，是48000 万。
假如计划单表存储 200 万数据，则分表数量等于 240。
因为我们要用学生维度去查询数据，所以shard 键选择用学生 ID。

分库分表后的问题

分布式事务问题

比如在电商业务中，当我们提交订单时，除了会创建订单，还会扣除相应的库存。而订单表和库存表由于垂直分库位于不同的库中，此时我们需要分布式事务来保证事务的完整性。

跨节点JOIN查询问题

用户在查询订单时，往往通过表连接获取到商品信息，而商品信息表可能存在其他的库中，这就涉及到了跨库的 JOIN 查询。

通常可以采用冗余表和冗余字段来优化跨库 JOIN 查询。

• 对于一些基础表，如商品信息表，可以在每一个订单分库中复制一张基础表，避免跨库 JOIN 查询；
• 对于一两个字段的查询，可以将少量字段冗余在表中，从而避免 JOIN 查询，也就避免了跨库 JOIN 查询。

跨节点分页查询问题

以订单表为例，通常都是使用 UserId 字段做 Hash 取模，对订单表进行水平分表；若考虑高并发时的订单处理能力，还可以考虑基于UserId 字段 Hash 取模实现分库分表。

当用户在订单列表中查询所有订单时，可以通过用户 ID 的 Hash 值来快速查询到订单信息，而运营人员在后台对订单表进行查询时，则是通过订单付款时间来进行查询的，这些数据都分布在不同的库表中，此时就存在一个跨节点分页查询的问题了。

此时可以采用两套数据来解决跨节点分页查询问题。

1. 基于分库分表的用户单条或多条查询数据；
2. 基于 Elasticsearch 存储的订单数据，主要用于运营人员根据其它字段进行分页查询；

为了不影响提交订单的业务性能，一般使用异步消息来实现 Elasticsearch订单数据的新增和修改。

全局主键ID问题

在分库分表后，需要单独设计全局主键，避免不同的库和表中的主键重复问题。

有以下几种策略

UUID

UUID 是实现全局 ID 是最方便快捷的方式，即随机生成一个 32 位 16 进制数字，可以保证唯一性，水平扩展能力以及性能都比较高。但 UUID 最大的缺陷就是，它是一个比较长的字符串，连续性差，如果作为主键使用，性能相对来说会比较差，不建议使用。

redis分布式锁

基于 Redis 分布式锁实现一个递增的主键 ID，这种方式可以保证主键是一个整数且有一定的连续性，但分布式锁存在一定的性能消耗。

雪花算法

基于 Twitter 开源的分布式 ID 生产算法——snowflake 解决全局主键 ID 问题，snowflake 是通过分别截取时间、机器标识、顺序计数的位数组成一个 long 类型的主键 ID。这种算法可以满足每秒上万个全局 ID 生成，不仅性能好，而且低延时。

扩容问题

随着用户的订单量增加，以 UserId Hash 取模的分表中的数据量也在增加，此时需要考虑动态增加表，就涉及到了数据迁移问题。

在最开始设计表数据量时，尽量使用 2 的倍数来设置表数量。在扩容时，也同样按照 2 的倍数来扩容，这种方式可以减少数据的迁移量。

有 4 张表，分别为 t0,t1,t2,t3，UserID的哈希值4、8、12、16，则这几个的UserID % 4 = 0，都会存到 t0 表中
假如现在扩容到 8 张表，则 UserID为 4 和 12 的，被迁移到 t5，其他两个不动；
假如现在扩容到 6 张表，则 UserID为 4 和 8 和 16 的，都需要迁移，只有UserID为12 的不需要迁移。

双写数据迁移方案介绍

数据迁移前，上游业务应用是通过旧的服务访问旧的数据的。

步骤1：服务升级双写

首先，需要对旧服务升级，对旧库的增删改，在新库上也同样执行。

步骤2：数据迁移

开发一个数据迁移工具，负责将旧库中的数据迁移到新库中

到目前为止，还是旧库在提供服务，所以丝毫不影响我们的业务。

步骤3：数据校验

在数据迁移完成之后，需要使用数据校验的小工具，将旧库和新库中的数据进行比对，完全一致则符合预期，如果出现不一致的情况，则以旧库中的数据为准。

步骤4：流量切换

数据完全一致之后，将流量切到新库，完成平滑数据迁移。

订单分库分表流程图

假如现在有一个订单表，没有做分库分表，现在呢，我们要把订单进行分库分表，怎么在不停机的前提下，平滑迁移数据到新表呢？

按照上面的双写迁移方案，流程图如下：

当数据比对完全一致后，修改服务配置，只写入分库分表中间件就可以了。