数据库架构演变
刚开始多数项目用单机数据库就够了,随着服务器流量越来越大,面对的请求也越来越多,我们做了数据库读写分离, 使用多个从库副本(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线程。验证分库分表不需要主从复制。分库分表和主从复制可以共同进行,我们为了更好验证结果。