分库分表

时间:2021-01-23 MXC肖某某人气:0

一、分库分表是什么

　　以常用的表设计为例，当前数据为卖家数据库，包含有商品表、店铺表和地区表：

　当需要查询商品的店铺和地理信息时，连表查询SQL为：

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

　　关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。

解决方案1：

　　通过提升服务器硬件能力来提高数据处理能力，比如增加存储容量、CPU等，这种方案成本很高，并且如果瓶颈在MySQL本身那么提高硬件也是有很的。

解决方案2：

　　把数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的，如下图：将电商数据库拆分为若干独立的数据库，并且对于大表也拆分为若干小表，通过这种数据库

拆分的方法来解决数据库的性能问题。

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

二、分库分表的方式

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

1，垂直分表

a）定义

　　将一个表按照字段分成多表，每个表存储其中一部分字段。

b）好处

为了避免IO争抢并减少锁表的几率，查看商品列表信息与商品详情互不影响
充分发挥热门数据的操作效率，商品信息的操作高效率不会被商品描述的低效率所拖累。

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

c）垂直拆分的原则

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

2，垂直分库

a）定义

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

　　将卖家数据库(SELLER_DB)，拆分为商品数据库(PRODUCT_DB)和店铺数据库(STORE_DB)，并将这两个库分散到不同服务器。

b）好处

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

3，水平分库

a）定义

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

　随着业务量的增长，PRODUCT_DB(商品库)单库存储数据已经超出预估，尝试水平分库。如果店铺ID为双数，将此操作映射至RRODUCT_DB1(商品库1)；如果店铺ID为单数，将操作映射至RRODUCT_DB2(商品库2)。此操作要访问数据库名称的表达式为RRODUCT_DB[店铺ID%2 + 1] 。

b）好处

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

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

4，水平分表

a）定义

　　水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。

　与水平分库的思路类似，不过这次操作的目标是表，商品信息及商品描述被分成了两套表。如果商品ID为双数，将此操作映射至商品信息1表；如果商品ID为单数，将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息[商品ID%2 + 1] 。

b）好处

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

　　库内的水平分表，解决了单一表数据量过大的问题，分出来的小表只包含一部分数据，从而使得单个表的数据量变小，提高检索性能。

5，总结

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

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

三、分库分表的问题

1，事务一致性问题

　　由于分库分表把数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。

2，跨节点关联查询

　　在没有分库前，我们检索商品时可以通过以下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...

　　但垂直分库后[商品信息]和[店铺信息]不在一个数据库，甚至不在一台服务器，无法进行关联查询。

　　可将原关联查询分为两次查询，第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据，最后将获得到的数据进行拼装。

3，跨节点分页、排序函数

　　跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。

　　如，进行水平分库后的商品库，按ID倒序排序分页，取第一页：

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

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

4，主键避重

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

5，公共表

　　实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。例子中地理区域表也属于此类型。

　　可以将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行。

　　未完待续，采用Sharding-JDBC来解决这些问题。

加载全部内容