分库分表－基本概念

1 概述

1.1 为什么分库分表

以MySQL为例，单库数据量在5000万以内性能比较好，超过阈值后性能会随 着数据量的增大而明显降低。单表的数据量超过1000w，性能也会下降严重。这就会导致查询一次所花 的时间变长，并发操作达到一定量时可能会卡死，甚至把系统给拖垮，因此需要解决这 个性能瓶颈问题。

我们是否可以通过提升服务器硬件能力来提高数据处理能力？能，但是这种方案很贵，并且提高硬件是 有上限的。那我们能不能把数据分散在不同的数据库中，使得单一数据库和表的数据量变小，从而达到 提升数据库操作性能的目的？ 可以，这就是数据库分库分表。

分库分表就是把较大的数据库和数据表按照某种策略进行拆分。目的在于：降低每个库、每张表的数据 量，减小数据库的负担，提高数据库的效率，缩短查询时间。另外，因为分库分表这种改造是可控的， 底层还是基于RDBMS，因此整个数据库的运维体系以及相关基础设施都是可重用的。

1.2 分库分表的方式

1.2.1 垂直分表

用户在电商平台流览商品时，首先看到的是商品的基本信息，如果对该商品感兴趣时才会继续查看该商 品的详细描述。因此，商品基本信息的访问频次要高于商品详细描述信息，商品基本信息的访问效率要 高于商品详细描述信息(大字段)。 由于这两种数据的特性不一样，因此考虑将商品信息表拆分如下：

 

 

 这种拆分就叫垂直分表。垂直分表定义：将一个表的字段分散到多个表中，每个表存储其中一部分字 段。垂直分表带来的提升是：

1. 减少IO争抢，减少锁表的几率，查看商品详情的与商品概述互不影响。

2. 充分发挥高频数据的操作效率，对商品概述数据操作的高效率不会被操作商品详情数据的低效率所 拖累。

一般来说，某业务实体中的各个数据项的访问频次是不一样的，部分数据项可能是占用存储空间比较大 的BLOB或是TEXT，例如上例中的商品描述字段。所以，当数据量很大时，可以将表按字段拆分，将热 门字段、冷门字段分开放置在不同表中。垂直切分带来的性能提升，主要集中在热门数据的操作效率 上，而且磁盘争用情况减少。通常我们按以下原则进行垂直拆分:

• 把不常用的字段单独放在一张表
• 把text，blob等大字段拆分出来单独放在一张表
• 经常组合查询的字段单独放在一张表中

1.2.2 垂直分库

通过垂直分表，数据库性能得到了一定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了， 因为数据还是始终存放在一台服务器。库内垂直分表只解决了单一表数据量过大的问题，但没有将表分 布到不同机器的库上，因此对于减轻数据库的压力来说，作用有限，大家还是竞争同一个物理机的 CPU、内存、网络IO、磁盘。 以电商平台为例，可以把原有的SELLER_DB(卖家库)，拆分为PRODUCT_DB(商品库)和STORE_DB(店铺 库)，并把这两个库分散到不同服务器上，如下图所示：

 

 

由于商品信息与商品描述业务耦合度较高，因此一起被存放在PRODUCT_DB(商品库)；而店铺信息相对 独立，因此单独被存放在STORE_DB(店铺库)，这就叫垂直分库。

 

垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，从 而达到多个服务器共同分摊压力的效果。垂直分库带来的提升是：

 

• 解决业务层面的耦合，业务清晰
• 能对不同业务的数据进行分级管理、维护、监控、扩展等
• 高并发场景下，垂直分库在一定程度上可以提升IO、数据库连接数、单机硬件资源的性能

 

1.2.3 水平分库

 

经过垂直分表和垂直分库后，数据库性能问题就完全解决了？假设某电商平台发展迅猛， PRODUCT_DB(商品库)单库存储数据已经超出预估。假设目前该平台有8w店铺，每个店铺平均有150个 不同规格的商品，再算上增长，那商品数量就会达到1500w+级别，并且PRODUCT_DB(商品库)属于访 问非常频繁的资源，性能瓶颈再次出现。 能再次垂直分库吗？从业务角度分析，目前已经无法再次垂直拆分。于是我们又想了一个办法，判断商 品ID是奇数还是偶数，然后把商品信息分别存放到两个数据库中。也就是说，要操作某条数据，先分析 这条数据的商品ID，如果商品ID为奇数，将此操作映射至RRODUCT_DB1(商品库1)；如果商品ID为偶 数，将操作映射至RRODUCT_DB2(商品库2)，这就叫水平分库。

 

 

水平分库是把同一个表的数据按一定规则拆分到不同的数据库中，每个库可以放在不同的服务器上。它 带来的提升是：

• 解决了单库大数据，高并发的性能瓶颈。
• 按照合理拆分规则拆分，join操作基本避免跨库。
• 提高了系统的稳定性及可用性。

当一个应用难以再细粒度的垂直切分，或切分后数据量行数仍然巨大，存在单库读写、存储性能瓶颈， 这时候就需要进行水平分库了，经过水平切分的优化，往往能解决单库存储量及性能瓶颈。但由于同一 个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大增加了系统复杂度。

 

 1.2.4 水平分表

数据库能水平拆分，那数据表是不是也可以呢？我们尝试把某PRODUCT_DB(商品库)内的表，进行了一 次水平拆分：

 

 

 与水平分库的思路类似，不过这次拆分的目标是表，商品信息及商品描述被分成了两套表。如果商品ID 为奇数，将此操作映射至商品信息1表；如果商品ID为偶数，将操作映射至商品信息2表，这就叫水平分 表。水平分表是在同一个数据库内，把同一个表的数据按一定规则拆分到多个表中。它带来的提升是：

• 优化单一表数据量过大而产生的性能问题
• 避免IO争抢并减少锁表的几率

库内的水平分表，解决了单一表数据量过大的问题，分出来的小表中只包含一部分数据，从而使得单个 表的数据量变小，提高检索性能。但由于同一个表的数据被拆分为多张表，也需要额外进行数据操作的 路由工作，因此增加了系统复杂度。

1.2.5 小结

 

 

• 垂直分表：可以把一个宽表的字段按访问频次、业务耦合松紧、是否是大字段的原则拆分为多个 表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面 将得不偿失。
• 垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务 器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的 业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。
• 水平分库：可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这 些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨 库带来的所有复杂问题，还要解决数据路由的问题。
• 水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表 的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。

一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问 压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再 考虑水平分库分表方案。

1.3 分库分表带来的问题

分库分表有效的缓解了大数据、高并发带来的性能和压力，也能突破网络IO、硬件资源、连接数的瓶 颈，但同时也带来了一些问题。

1.3.1 事务一致性问题

由于分库分表把数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题，我们需要额外编 程解决该问题。

1.3.2 跨节点join

在没有进行分库分表前，我们检索商品时可以通过以下SQL对店铺信息进行关联查询：

SELECT p.*,s.[店铺名称],s.[信誉]
FROM [商品信息] p
LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺]
WHERE...ORDER BY...LIMIT...

但经过分库分表后，[商品信息]和[店铺信息]不在一个数据库或一个表中，甚至不在一台服务器上，无 法通过sql语句进行关联查询，我们需要额外编程解决该问题。

1.3.3 跨节点分页、排序和聚合函数

跨节点多库进行查询时，limit分页、order by排序以及聚合函数等问题，就变得比较复杂了。需要先在 不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。例如， 进行水平分库后的商品库，按ID倒序排序分页，取第一页：

 

 

 以上流程是取第一页的数据，性能影响不大，但由于商品信息的分布在各数据库的数据可能是随机的， 如果是取第N页，需要将所有节点前N页数据都取出来合并，再进行整体的排序，操作效率可想而知， 所以请求页数越大，系统的性能也会越差。

在使用Max、Min、Sum、Count之类的函数进行计算的时候，与排序分页同理，也需要先在每个分片 上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回。

1.3.4 主键避重

在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某 个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。

 

由于分库分表之后，数据被分散在不同的服务器、数据库和表中。因此，对数据的操作也就无法通过常 规方式完成，并且它还带来了一系列的问题。我们在开发过程中需要通过一些中间件解决这些问题，市 面上有很多中间件可供我们选择，其中Sharding-JDBC较为流行。