分库分表方案-蒲公英云

阅读目录

一、数据库瓶颈
- 1、IO瓶颈
- 2、CPU瓶颈
二、分库分表
- 1、水平分库
- - 几种典型的分片规则
  - 切分共同的问题
  - 切分的一些原则
  - 数据库的切分引申的数据源管理思考
  - 中间件
- 2、水平分表
- 3、垂直分库
- 4、垂直分表
三、分库分表工具
四、分库分表步骤
冗余法
五、分表方案
- 1、垂直分表
- 2、水平分表
- - 1、范围取表方式
  - 2、特定的算法分表(取模、哈希)
- 优缺点
- 范围方式

一、数据库瓶颈

不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。

1、IO瓶颈

第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。

第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。

2、CPU瓶颈

第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。

第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。

二、分库分表

1、水平分库

在这里插入图片描述
概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。

结果：

每个库的结构都一样；
每个库的数据都不一样，没有交集；
所有库的并集是全量数据；

场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。

分析：库多了，io和cpu的压力自然可以成倍缓解。

几种典型的分片规则

按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中。
按照日期，将不同月甚至日的数据分散到不同的库中。
按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中。

如图，切分原则都是根据业务找到适合的切分规则分散到不同的库，下面用用户 ID 求模举例：

在这里插入图片描述
优点：

拆分规则抽象好，join 操作基本可以数据库做。
不存在单库大数据，高并发的性能瓶颈。
应用端改造较少。
提高了系统的稳定性跟负载能力。

缺点：

拆分规则难以抽象。
分片事务一致性难以解决。
数据多次扩展难度跟维护量极大。
跨库 join 性能较差。

切分共同的问题

垂直切分跟水平切分不同的优缺点，会发现每种切分方式都有缺点，但共同的特点缺点有：

引入分布式事务的问题。
跨节点 Join 的问题。
跨节点合并排序分页问题。
多数据源管理问题。

一般来讲业务存在着复杂 join 的场景是难以切分的，往往业务独立的易于切分。如何切分，切分到何种程度是考验技术架构的一个难题。

切分的一些原则

由于数据切分后数据 Join 的难度在此也分享一下数据切分的经验：

第一原则：能不切分尽量不要切分。
第二原则：如果要切分一定要选择合适的切分规则，提前规划好。
第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库 Join 的可能。
第四原则：由于数据库中间件对数据 Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表 Join。

数据库的切分引申的数据源管理思考

主要有两种思路：

A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据
库，在模块内完成数据的整合；
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；

可能 90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候。确实，这是一个非常正确的选择，虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来说，是非常有帮助的。

中间件

mycat 是基于Java开发所设计的，PHP选择第一种比较简单

为了减少业务人员的压力，
常用一些中间件，如 mycat Cobar
其结构大约如下图

在这里插入图片描述
中间件的直接感受
这里简单试用了下，mycat ，使用的例子是其官方例子

过程：
mysql 新建三个库db1,db2,db3
在linux服务器上安装mycat. 配置好mycat对三个库，表的对应，mycat的rules 等.

后续使用时，将mycat 当作mysql来使用即可，
insert 三条数据进 mycat 的 TESTDB 的 travelrecord 表,

结果如下：
三条数据的实际存储位置在db1,db2,db3中

在这里插入图片描述

2、水平分表

相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。

简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。
在这里插入图片描述

3、垂直分库

在这里插入图片描述
概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。

结果：

每个库的结构都不一样；
每个库的数据也不一样，没有交集；
所有库的并集是全量数据；
场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。

分析：到这一步，基本上就可以服务化了。例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

4、垂直分表

在这里插入图片描述
概念：

以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

结果：

每个表的结构都不一样；
每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；
所有表的并集是全量数据；

场景：

系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。

分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。

但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

三、分库分表工具

sharding-sphere：jar，前身是sharding-jdbc；
TDDL：jar，Taobao Distribute Data Layer；
Mycat：中间件

注：工具的利弊，请自行调研，官网和社区优先。

四、分库分表步骤

根据容量（当前容量和增长量）评估分库或分表个数 -> 选key（均匀）-> 分表规则（hash或range等）-> 执行（一般双写）-> 扩容问题（尽量减少数据的移动）。

扩展MySQL：分库分表与分区的区别和思考

冗余法

在这里插入图片描述

五、分表方案

1、垂直分表

垂直分表在业务开发过程中应该是随处可见的，比如：用户相关的表

CREATE TABLE `user` (
  `uid` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `user_name` varchar(50) DEFAULT '' COMMENT '用户登录名',
  `password` char(32) DEFAULT '' COMMENT '用户登录密码',
  `is_del` tinyint(1) unsigned DEFAULT '1' COMMENT '1，正常 2，删除',
  `create_time` char(10) DEFAULT '0' COMMENT '录入时间',
  `update_time` char(10) DEFAULT '0' COMMENT '更新时间',
  PRIMARY KEY (`uid`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户基本表';
CREATE TABLE `user_info` (
  `uid` int(11) unsigned NOT NULL,
  `head_img` varchar(50) DEFAULT '' COMMENT '头像',
  `nick_name` varchar(50) DEFAULT '' COMMENT '昵称',
  `sign_content` varchar(255) DEFAULT '' COMMENT '个性签名',
  `update_time` char(10) DEFAULT '0' COMMENT '更新时间',
  PRIMARY KEY (`uid`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户信息表';
......

如上所见，垂直分表就是把一个实体按照某种属性进行分类划分成多个表。

2、水平分表

1、范围取表方式

比如用户联系信息：我们可以按照范围分表

1-100w: user_info_1
100w-200w: user_info_2

CREATE TABLE `user_info_{
    {1+}}` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `uid` int(11) NOT NULL DEFAULT '0' COMMENT '用户uid',
  `mobile` varchar(20) NOT NULL DEFAULT '' COMMENT '手机号',
  `address` varchar(50) NOT NULL DEFAULT '' COMMENT '住址',
  ......
  `is_del` tinyint(1) unsigned DEFAULT '1' COMMENT '1，正常 2，删除',
  `create_time` char(10) DEFAULT '0' COMMENT '录入时间',
  `update_time` char(10) DEFAULT '0' COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uid_index` (`uid`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户联系信息表';

2、特定的算法分表(取模、哈希)

取模：比如用户 ID%100,分100张表

CREATE TABLE `visit_record_{
    {1-100}}` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `uid` int(11) NOT NULL DEFAULT '0' COMMENT '所属人uid',
  `source_id` int(11) NOT NULL DEFAULT '0' COMMENT '资源id',
  `type_mark` int(10) NOT NULL DEFAULT '0' COMMENT '资源类型',
  ......
  `create_time` char(10) DEFAULT '0' COMMENT '录入时间',
  `update_time` char(10) DEFAULT '0' COMMENT '更新时间',
  PRIMARY KEY (`id`),
 UNIQUE KEY `st_index` (`source_id`,`type_mark`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户资源访问记录';