分库分表

分库分表

• [1 分库分表介绍](#1 分库分表介绍)
• • 1.1、分库分表概述
  • 1.2、分库分表场景示例
  • 1.3、大数据存储下数据库性能分析
  • 1.4、小结
• [2 分库分表方式](#2 分库分表方式)
• • 2.1、垂直分表
  • 2.2、垂直分库
  • 2.3、水平分表
  • 2.4、水平分库
  • 2.5、分库分表带来的问题
  • 2.6、分库分表小结

1 分库分表介绍

1.1、分库分表概述

分库分表本质上就是为了解决由于库表数据量过大而导致数据库性能降低的问题;

核心操作：

• 将原来独立的数据库拆分成若干数据库组成;
• 将原来的大表(存储近千万数据的表)拆分成若干个小表；

目的：使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的；

1.2、分库分表场景示例

场景说明

老王是一家初创电商平台的开发人员,负责卖家模块的功能开发，其中涉及了店铺、商品的相关业务，设计如下数据库：

实际业务中经常需要查询商品、商铺、地理位置等信息，效果如下：

通过以下SQL能够获取到商品相关的店铺信息、地理区域信息：

SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]
FROM [商品信息表] p 
LEFT JOIN [地理区域表] r ON p.[产地] = r.[地理区域编码]
LEFT JOIN [店铺信息表] s ON p.id = s.[所属店铺]
WHERE p.id = ?

随着公司业务快速发展，数据库中的店铺、商品等数据量会猛增，大数据量且并发高的访问会导致数据库性能急剧下降；

数据库访问变慢原因分析

原因如下：

• 在系统应用中关系型数据库本身比较容易成为系统瓶颈（I/O）,比如：单机存储容量、数据库连接数、处理能力等都有上限；
• 当单表的数据量达到 800W或100G以后(大表)，即使做了优化索引等操作，查询性能仍会下降严重，更不要说复杂的多表关联查询了；
• 对于商家模块来说，当数据量过大是，会存在大表关联查询，导致查询性能急剧下降！[尽量避免大表的关联查询-查询优化-反三大范式]

1.3、大数据存储下数据库性能分析

优化数据库要从硬件和软件层面优化：

• 硬件层面

  • 提升服务器硬件能力来提高数据处理能力，比如增加存储容量 、CPU等；
  • 提升硬件配置相对成本较高，且如果瓶颈在MySQL本身那么提高硬件带来的性能提升也是有限的；

• 软件层面

  • 把大量数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题；

  • 把大表拆分成若干小表，解决单张大表查询性能问题；

  • 对于关系型数据库来说，磁盘I/O会成为其瓶颈，通过缓存热点数据，在一定程度来可提升系统性能；

如下图将电商数据库拆分为若干独立的数据库，并且对于大表也拆分为若干小表，通过这种数据库拆分的方法来解决数据库的性能问题：

1.4、小结

• 分库分表是为了解决由于数据量过大而导致数据库性能降低的问题；
• 分库分表是将原来独立的数据库拆分成若干数据库，将独立的大表拆分成若干小表过程；
• 分库分表最终使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的；

2 分库分表方式

分库分表包括分库和分表 两个部分，在生产中通常包括：垂直分库、水平分库、垂直分表、水平分表四种方式；

2.1、垂直分表

垂直分表定义

• 垂直分表就是在同一数据库内将一张表按照指定字段分成若干表，每张表仅存储其中一部分字段；
• 垂直分表拆解了原有的表结构，拆分的表之间一般是一对一的关系；

垂直分表场景示例

场景说明

下边通过一个商品查询的案例讲解垂直分表，通常在商品列表中是不显示商品详情信息的，如下图：

说明：

• 用户浏览商品列表时只对感兴趣商品查看商品详情：商品描述信息被访问的频次较低，且该字段占用存储空间较大；
• 商品表字段出现部分字段访问频次不一致的情况：商品名称、商品图片、商品价格等其他字段数据访问频次较高

由于这两组数据的特性不一样，因此我们可以考虑将商品信息表拆分如下，将访问频次低的商品描述信息单独存放在一张表中，访问频次较高的商品基本信息单独放在一张表中：

商品列表可采用以下sql：

SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]
FROM [商品信息] p 
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码]
LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺]
WHERE...ORDER BY...LIMIT...

需要获取商品描述时，再通过以下sql获取：

SELECT *
FROM [商品描述] 
WHERE [商品ID] = ?

垂直分表优势

• 充分提高了热点数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累（冷热数据分离）；
• 避免了IO过度争抢并减少锁表的几率，查看商品详情的用户与商品信息浏览互不影响；

垂直分表原则

• 把不常用的字段单独放在一张表;（因为数据库加载数据时，会将表整整行的信息加载）
• 把text（大文本存储），blob（图片、视频类存储）等大字段拆分出来放在附表中（阿里开发手册严禁使用text等大字段）;
• 经常组合查询的列放在一张表中，避免多表联查，性能最高;

2.2、垂直分库

垂直分表存在的问题

• 经过垂直分表后表的查询性能确实得到了一定程度的提升，但数据始终限制在同一台机器内，因此因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘；
• 单台服务器的性能瓶颈（比如：CPU、内存、网络IO、磁盘等）通过垂直分表始终得不到突破；

垂直分库定义

垂直分库是指按照业务将表进行归类，然后把不同类的表分布到不同的数据库上面，而每个库又可以放在不同的服务器上，它的核心理念是-专库专用；

示例场景

经过思考，我们可以将原有的卖家库，拆分为分为商品库和店铺库，并把这两个库分散到不同服务器上，如下图：

注意事项：

由于商品信息与商品描述业务耦合度较高，因此一起被存放在商品库（避免跨库联查）；

店铺信息相对独立，因此可单独被存放在店铺库下；

对于地理区域表，因为商品信息和店铺信息都需要，且地理区域是不经常变动的常量表但是会存在与其他表联查的情况，所以可以将它作为公共表分别等量部署到不同的数据库节点下；

以上操作就可以称为垂直分库。

垂直分库优势

垂直分库带来的提升是：

• 通过不同表的业务聚合（聚合为库），使得数据库维护更加清晰；

• 能对不同业务的数据进行分级管理、维护、监控、扩展等；

• 高并发场景下，垂直分库在一定程度上提高了磁盘IO和数据库连接数，并改善了单机硬件资源的瓶颈问题；

但是，垂直分库依然没有解决库中单表数据量过大的问题！

2.3、水平分表

水平分表定义

• 水平分表就是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中，表的结构没有变化；
• 水平分表解决单表数据量大的问题；

水平分表示例

为解决单表数据量大的问题，我们可把商品库内的表进行水平拆分，得到若干相同表结构的小表；

需要注意的是各个小表存储的数据不同，且数据依旧保存在同一个数据库内；

如下图：

分表算法说明：

如果商品ID为双数，将此操作映射至商品信息1表；如果商品ID为单数，将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息[商品ID%2 + 1];

这种操作就叫做：水平分表。

水平分表优势

水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中，它带来的提升是：

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

整体看，水平分表仅仅解决了单表数据量过大的问题，但是没有解决单库数据量过大的问题；

2.4、水平分库

水平分库定义

• 水平分库可以看做是水平分表的进一步拆分，是把同一个表的数据按一定规则拆到不同的数据库中，每个库又可以部署到不同的服务器上；
• 水平分库解决了单库数据量大的问题，突破了服务器物理存储的瓶颈；

水平分库示例场景

经过垂直分库和水平分表后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，商品库单库存储数据已经超出预估。

假如当前有8w店铺，每个店铺平均150个不同规格的商品，那商品数量得往1200w+上预估，并且商品库属于访问非常频繁的资源，单台服务器已经无法支撑。

此时该如何优化？

目前情况是那怕再次垂直分库也无法解决数据瓶颈问题 。我们可以尝试水平分库，将商品ID为单数的和商品ID为双数的商品信息分别放在两个不同库中；

说明：

如果商品ID为双数，将此操作映射至【商品库-1】；

如果店铺ID为单数，将操作映射至【商品库-2】；

此操作要访问数据库名称的表达式为：商品库_(商品ID%2 + 1)；

这种操作就叫水平分库。

总之，水平分库后，各个库保存的表结构是一致的，但是表中内容不一样；

水平分库优势

水平分库带来的提升是：

• 解决了单库大数据，高并发的性能瓶颈问题；
• 提高了系统的稳定性及可用性；

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

2.5、分库分表带来的问题

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

• 分布式事务一致性问题
• 跨节点关联查询
• 跨节点分页、排序函数
• 主键避重
• 公共表(小数据量的表且经常使用，可能存在联查的情况）

显然如果我们自己去解决上述问题，开发工作量较大，所以我们就有必要学习一种支持分库分表特性的技术：sharding-jdbc、mycat等；

2.6、分库分表小结

分库分表方式：垂直分表、垂直分库、水平分库和水平分表

垂直分表 ：可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失【同一库中将单张表按照字段拆分成若干表，拆分后表的记录行数不变】。

垂直分库 ：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。 【根据业务将表分组形成不同的库，这些库又可以部署到不同的数据库中-专库专用】

水平分表 ：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。【同一数据库中将大表拆分成若干小表，每张表的结构一致，但保存的数据不同】

水平分库 ：可以把表的数据(按数据行)分 到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。

最佳实践：

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

总之，基于开发和维护成本比考虑，非必须，不要对数据库做分库分表处理！