464-MySQL(分库分表)

数据库架构演变

刚开始多数项目用单机数据库就够了，随着服务器流量越来越大，面对的请求也越来越多，我们做了数据库读写分离， 使用多个从库副本（Slave）负责读，使用主库（Master）负责写，master和slave通过主从复制实现数据同步更新，保持数据一致。slave 从库可以水平扩展，所以更多的读请求不成问题。
但是当用户量级上升，写请求越来越多，怎么保证数据库的负载足够？(主库的磁盘大小和磁盘I/O都受不了，把这个表分在多台数据库服务器里面进行写入）
增加一个Master是不能解决问题的， 因为数据要保存一致性，写操作需要2个master之间同步，相当于是重复了，而且架构设计更加复杂。
这时需要用到分库分表（sharding），对写操作进行切分。

库表问题

单库太大
单库处理能力有限、所在服务器上的磁盘空间不足、遇到IO瓶颈，需要把单库切分成更多更小的库
单表太大
CURD效率都很低、数据量太大导致索引膨胀、查询超时，需要把单表切分成多个数据集更小的表
线程表的拆分算法：server.xml，schema.xml，分表的算法在rule.xml（根据时间把表的数据拆分到不同的表，或者是根据一致性哈希，或者直接取模，通过 Id（主键）和要分表的个数 进行取模）

需求原理

分库分表对于客户端来说，操作的还是mycat，操作的都是一台代理服务器，操作的是逻辑库表，最终，分库分表映射到真实的库表。通过mycat代理服务器去select查询，可能在多个机器上查询，因为分库分表了。

拆分策略

单个库太大，先考虑是表多还是数据多：
如果因为表多而造成数据过多，则使用垂直拆分，即根据业务拆分成不同的库
如果因为单张表的数据量太大，则使用水平拆分，即把表的数据按照某种规则（rule.xml定义的拆分的算法）拆分成多张表（逻辑上还是同一张表）
分库分表的原则应该是先考虑垂直拆分，再考虑水平拆分。

垂直拆分

分库分表和读写分离可以共同进行。

server.xml
配置了2个逻辑库：

schema.xml

2给逻辑库对应2个数据节点，然后对应不同的真实的物理机器。然后对应不同的真实库表（mytest 1 mytest 2)。

分成了不同机器上的不同的库，各包含一部分表，他们原来是合在一块的，在一台机器上，现在做了垂直的拆分。
在客户端上，就需要去连接不同的逻辑库了，根据业务操作不同的逻辑库。

然后配置了linux下的写库和Windows下的写库，两台机器把库平分了，分担了原来单机的压力。分库伴随着分表（从业务上对表拆分）。

垂直分表

也就是“大表拆小表”，基于列字段进行。
一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。
一般是针对几百列的这种大表，也避免查询时，数据量太大造成的“跨页”问题。

垂直分库

垂直分库针对的是一个系统中的不同业务进行拆分。 比如用户User一个库，商品Product一个库，订单Order一个库， 切分后，要放在多个服务器上，而不是一个服务器上。想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前， 全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。 所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。
数据库业务层面的拆分，和服务的“治理”，“降级”机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。 数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。 数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈。

水平拆分

server.xml

USERDB是逻辑库
schema.xml

user表示一个普通的表，直接放在数据节点dn1上，放在一台机器上，这张表不用进行拆分，对应的linux下的mysql server
student表的主键是id，根据id拆分，放在dn1和dn2上，最终这个表要分在两台机器上，在物理上分开了，但是在逻辑上还是一个，这些操作（往哪里增加，在2台机器上查询然后合并）这些都是由mycat做好的。 拆分的规则是取余（mod - long)
每次插入用id模上 存在机器的个数（2）

图解如下：

注意一下：我们还要改个配置文件：rule.xml

数字默认是3，我们要把3改为2，因为我们现在的数据节点是2个，模上2

水平拆分的测试

我们先确认一下配置是否拿过来了


配置文件修改后，之前的配置文件都备份起来了，拿了个新的
检查一下末尾有没有错误

日志没有发现错误，mycat启动成功，加载了对于水平拆分的配置文件。


拆分只是内容上的拆分，名字也可以是一样的。

打开我们linux下的MySQL

打开我们Windows下的MySQL

验证配置上映射的主机确实有test1 test2
因为student在这两个机器上都存储，所以在这两个机器上都创建这张表
数据的增删改查都是在中间件mycat上完成

我们进行操作：

我们分别在linux和Windows下的mysql查看


我们再插入2条：

查看：

在mycat查询的时候只需要这样输入就可以了:
我们配置的是表拆分后放在这2个数据节点上，查询的时候mycat会根据配置在两个库上查询并且合并。

水平分表

针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈，不建议采用。

水平分库分表

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

分库分表的实践

我们先把从库关闭了。关闭I/O线程和SQL线程。验证分库分表不需要主从复制。分库分表和主从复制可以共同进行，我们为了更好验证结果。