此文章,是我针对分库分表的概念的理解,为什么要分库分表,分完之后有什么效果。分库分表会有什么问题。做出了一些解释和说明。所以,市面上会有各种 分库分表中间件 的产出。(参考了视频的教程)
解决痛点:数据量过大。对关系型数据库性能,造成影响。访问性能变慢。
例子:例如一个数据库有3张表,一个是商品信息表,一个是店铺表,一个是区域表。
问题:目前要根据商品ID 展示出 商品的描述,店铺的名称,和店铺所在的城市名字。那么就是3张表关联查询。如果3张表数据量越来越大,单表数据量超过1000W。再像之前这么查,是不可能了。增加索引也是一样的。还是慢。
想到的解决方案:
-
方案一:增加单机的硬件性能,但是mysql数据库对硬件的支持是有上限的。还是解决不了根本问题。
-
方案二:将原有数据库,根据业务拆分成多个数据库;大表拆分成多个小表。使得将大数据量,平摊到各个单一的数据库,减少了数据量。通过这种方式,来解决数据库性能问题。
分库分表包括分库和分表两个部分,在生产中通常包括:垂直分库、水平分库、垂直分表、水平分表四种方式。
-
垂直分表:根据业务,将一个表的字段,分成多个表,每个表存储一部分字段。
那么就是将商品信息表,分成一个商品基本信息表,一个商品详情信息表。
它带来的提升是:
1.为了避免IO争抢并减少锁表的几率。
2.充分发挥热门数据的操作效率。
通常我们按以下原则进行垂直拆分:
-
把不常用的字段单独放在一张表;
-
把text,blob等大字段拆分出来放在附表中;
-
经常组合查询的列放在一张表中;
-
垂直分库:垂直分表性能有一定的上限,毕竟还是在同一个数据库中,同一台服务器。每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。所以,按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。
那么就是将商品的表,放一个数据库;店铺表放一个数据库;区域表放一个数据库。
它带来的提升是:
-
解决业务层面的耦合,业务清晰
-
能对不同业务的数据进行分级管理、维护、监控、扩展等
-
高并发场景下,垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈
-
水平分库:针对商品信息表所在的数据库,2张表的数据量还在增加。单表的数据量也超过了千万。单台也无法支持了。所以,
把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。
垂直分库是把不同表拆到不同数据库中,水平分库是对数据行的拆分,不影响表结构
那么就是将商品信息数据库,将数据划分为2个数据库,2个数据库表结构还是一样的。每个数据库还是2张表。根据商品的ID的单数,双数,将商品信息的数据分为了2部分。
它带来的提升是:
-
解决了单库大数据的压力,性能瓶颈。
-
提高了系统的稳定性及可用性。(稳定性体现在IO冲突减少,锁定减少,可用性指某个库出问题,部分可用)
-
水平分表:如果表的数据量继续增加,继续采用那种水平分库的方式,那么数据库实例会越来越多。难以去维护。所以,
还是针对表,不是针对字段了。还是针对数据,在同一个数据库内,把同一个表的数据按一定规则拆到多个表中。
那么我再将上诉的商品信息2个数据库中,每个数据库的那俩张表的数据,再进行一个拆分。按照店铺的ID的单数,双数,再进行一个划分。也就是,这个商品信息,2个库,每个库2套表(商品基本信息+商品详细信息),表结构一样,数据不一样。
它带来的提升是:
-
优化单一表数据量过大而产生的性能问题
-
避免IO争抢并减少锁表的几率
总结:垂直分表和垂直分库,是从数据库的结构来划分,垂直分表是按照表的字段,垂直分库是按照表的分类。一般是数据库设计的时候考虑这俩种方式。
水平分库和水平分表,是按照数据行的方式去划分,水平分库,将一个表的数据按照规则划分为多个库。水平分表,将一个表的数据按照规则拆分多个表。一般是后期单表数据量大了,采用这俩种方式。不过,单表数据量不是特别大。首先考虑,缓存,读写分离,索引等方案。
这4种方式所带来的问题:
-
事务一致性问题,带来分布式事务的问题。
-
跨数据库实例关联查询。
-
分页,排序也复杂了。
-
主键可能会重复。
-
公共表,比如参数表,联合查询频率较高。