阿里巴巴数据库分库分表的实践

如果一个电商平台的业务发展健康的话，订单数据是比较容易出现因为单个数据库表中的数据太大而造成性能的瓶颈，所以需要对它进行数据库的拆分。此时从理论上对订单拆分是可以由两个维度进行的，一个维度是通过订单ID（一般为自增ID）取模的方式，即以订单ID为分库分表键；一个是通过买家用户ID的维度进行哈希取模，即以买家用户ID为分库分表键。

两种方案做一下对比：

如果是按照订单ID取模的方式，比如按64取模，则可以保证主订单数据以及相关的子订单、订单详情数据平均落入到后端的64个数据库中，原则上很好地满足了数据尽可能平均拆分的原则。

通过采用买家用户ID哈希取模的方式，比如也是按64取模，技术上则也能保证订单数据拆分到后端的64个数据库中，但这里就会出现一个业务场景中带来的一个问题，就是如果有些卖家是交易量非常大的（这样的群体不在少数），那这些卖家产生的订单数据量（特别是订单详情表的数据量）会比其他卖家要多出不少，也就是会出现数据不平均的现象，最终导致这些卖家的订单数据所在的数据库会相对其他数据库提早进入到数据归档（为了避免在线交易数据库的数据的增大带来数据库性能问题，淘宝将3个月内的订单数据保存进在线交易数据库中，超过3个月的订单会归档到后端专门的归档数据库）。

所以从对“数据尽可能平均拆分”这条原则来看，按照订单ID取模的方式看起来是更能保证订单数据进行平均拆分，但我们暂且不要这么快下结论，让我们继续从下面几条原则和最佳实践角度多思考不同的拆分维度带来的优缺点。

3、尽量减少事务边界

不管是TDDL平台还是DRDS，采用分库分表的方式将业务数据拆分后，如果每一条SQL语句中都能带有分库分表键，如图5-6所示是以自增的订单ID以8取模，将订单平均分布到8个数据库的订单表中，通过分布式服务层在对于SQL解析后都能精准地将这条SQL语句推送到该数据所在的数据库上执行，数据库将执行的结果再返回给分布式服务层，分布式服务层再将结果返回给应用，整个数据库访问的过程跟之前的单机数据库操作没有任何差别。这个是在数据进行了分库分表拆分后，SQL语句执行效率最高的方式。

图5-6DRDS对带分库分表键的SQL请求处理

但不是所有的业务场景在进行数据库访问时每次都能带分库分表键的。比如在买家中心的界面中，要显示买家test1过去三个月的订单列表信息，因为该买家test1的订单按订单ID取模的方式分布到了不同的数据库中，此时SQL语句中就没有了分库分表键值，则出现了如图5-7所示的情况，分布式数据层会将获取test1订单的SQL语句推送到后端所有数据库中执行，然后将后端数据库返回的结果在分布式数据层进行聚合后再返回给前端应用。

图5-7DRDS对不带分库分表键的SQL请求进行全表扫描处理

此时就出现了我们所说的全表扫描。此时我们来解释一下这里“事务边界”的定义，所谓的事务边界即是指单个SQL语句在后端数据库上同时执行的数量，上面示例中就是事务边界大的典型示例，即一条SQL语句同时被推送到后端所有数据库中运行。事务边界的数量越大，会给系统带来以下弊端：

系统的锁冲突概率越高。如果事务边界大的SQL请求比较多，在一次SQL请求处理过程中自然对于后端的数据库操作的数据库记录覆盖比较广，当有多个类似的SQL请求并行执行时，则出现数据锁造成的资源访问互斥的概率会大大增加。

系统越难以扩展。如果有大量的SQL请求都是这样全表扫描，或者从极端角度说明这个问题，如果每一次的SQL请求都需要全表扫描执行，你会发现整个平台的数据库连接数量是取决于后端单个数据库的连接能力，也就意味着整个数据库的能力是无法通过增加后端数据库实例来扩展的。所以如果有大量的全表扫描的SQL请求对于系统的扩展能力会带来不小的影响。

整体性能越低。对于性能，这里想强调的是对系统整体性能的影响，而不是单次SQL的性能。应用发送获取买家test1订单列表SQL的请求（如图5-8步骤①）时，分布式数据层会并行的将这条SQL语句推送（如图5-8步骤②）到后端8台数据库上运行，因为订单数据进行了平均的拆分，单个数据库订单表的数据量大小都使得数据库处于最佳性能表现的状态，所以意味着每一个数据库返回的计算结果都是在一个可期望的时间内（比如100毫秒），将结果返回到分布式数据层（如图5-8步骤③），分布式数据层将从各个数据库返回来的结果在内存中进行聚合或排序等操作（如图5-8步骤④），最后返回订单列表给应用（如图5-8步骤⑤）。

图5-8DRDS对需全表扫描操作的SQL请求处理流程

整个SQL执行的过程包含了5个步骤，仔细看看，你会发现一次带分库分表键执行的SQL过程也会经历这5个步骤，区别只是在②③步骤是并行的方式同时跟多个后端数据库进行交互，但在时间上带来的影响几乎是毫秒级的；而第④个步骤是可能造成差异的一个点，如果像示例中一个用户的订单信息可能最多几千条，对于几千条数据的内存聚合操作，处理时间也是毫秒级的，所以这样一次全表扫描的操作，用户的体验是完全无感知的，跟访问单机数据库的体验是没有差异的。但如果在第④个步骤中确实遇到对大数据量（比如几十万、几百万条数据）的聚合、排序、分组等计算时，则会占用较大的内存和CPU计算资源，如果这样类型的SQL请求比较频繁的话，就会给分布式数据层带来较大的资源占用，从而导致整体分布式服务的处理性能受到影响。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!