一、为什么要分库分表
数据库架构演变
刚开始多数项目用单机数据库就够了,
随着服务器流量越来越大,面对的请求也越来越多,我们做了数据库读写分离.
使用多个从库副本(Slave)负责被读的请求,使用主库(Master)负责写入的请求, master和slave通过主从复制实现数据同步更新,保持数据一致。(这一点十分的重要,否则用户读取的数据不是最新的)
slave 从库可以水平扩展,所以更多的读请求也不是问题.
但是随着写请求越来越多,怎么保证数据库的负载足够?
增加一个Master是不能解决问题的, 因为数据要保存一致性,写操作需要2个master之间要进行数据的同步,
如果往2个master中都写数据, 那么相当于是重复了,而且这样架构设计也是非常复杂的.
这时需要用到分库分表(sharding),把库和表存放在不同的MySQL Server上,每台服务器可以均衡写请求的次数
二、库表太大产生的问题
- 单库太大:单库处理能力有限、所在服务器上的磁盘空间不足、遇到IO瓶颈,需要把单库切分成更多更小的库
- 单表太大:CRUD效率都很低,数据量太大导致索引文件过大,磁盘IO加载索引花费时间,导致查询超时。所以只用索引还是不行的,需要把单表切分成多个数据集更小的表。 MyCat提供的分表算法都在rule.xml,可以根据不同的分表算法进行拆分,比如根据时间拆分、一致性哈希、直接用主键对分表的个数取模等
拆分策略
单个库太大,先考虑是表多还是数据多:
- 如果因为表多而造成数据过多,则使用垂直拆分,即根据业务拆分成不同的库
- 如果因为单张表的数据量太大,则使用水平拆分,即把表的数据按照某种规则(mycat/conf/rule.xml定义的分表算法)拆分成多张表
分库分表的原则应该是先考虑垂直拆分,再考虑水平拆分
三、垂直拆分
分库分表和读写分离可以共同进行
1. 垂直分库
server.xml
<user name="root">
<property name="password">123456</property>
<property name="schemas">USERDB1,USERDB2</property>
</user>
配置了USERDB1、USERDB2这两个逻辑库
schema.xml
<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://io.mycat/">
<!-- 逻辑数据库 -->
<schema name="USERDB1" checkSQLschema="false" sqlMaxLimit="100" dataNode="dn1" /> <!-- 两个逻辑库对应两个不同的数据节点 -->
<schema name="USERDB2" checkSQLschema="false" sqlMaxLimit="100"dataNode="dn2" />
<!-- 存储节点 -->
<dataNode name="dn1" dataHost="node1" database="mytest1" /> <!-- 两个数据节点对应两个不同的物理机器 -->
<dataNode name="dn2" dataHost="node2" database="mytest2" /> <!-- USERDB1对应mytest1,USERDB2对应mytest2 -->
<!-- 数据库主机 -->
<dataHost name="node1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native">
<heartbeat>select user()</heartbeat>
<writeHost host="192.168.131.129" url="192.168.131.129:3306" user="root" password="123456" />
</dataHost>
<dataHost name="node2" maxCon="1000" minCon="10" balance="0"writeType="0" dbType="mysql" dbDriver="native">
<heartbeat>select user()</heartbeat>
<writeHost host="192.168.0.6" url="192.168.0.6:3306" user="root" password="123456" />
</dataHost>
</mycat:schema>
两个逻辑库对应两个不同的数据节点,两个数据节点对应两个不同的物理机器
mytest1和mytest2分成了不同机器上的不同的库,各包含一部分表,它们原来是合在一块的,在一台机器上,现在做了垂直的拆分。
客户端就需要去连接不同的逻辑库了,根据业务操作不同的逻辑库
然后配置了两个写库,两台机器把库平分了,分担了原来单机的压力。分库伴随着分表,从业务上对表拆分
2. 垂直分表
垂直分表,基于列字段进行。一般是针对几百列的这种大表,也避免查询时,数据量太大造成的“跨页”问题。
一般是表中的字段较多,将不常用的, 数据较大,长度较长(比如text类型字段)的拆分到扩展表。访问频率较高的字段单独放在一张表
分表
1/垂直分表
垂直分表,基于列字段进行。
一般是针对几百列的这种大表宽表,也避免查询时,数据量太大造成的“跨页”问题。
一般是表中的字段较多,将不常用的, 数据较大,长度较长(比如text类型字段)的拆分到扩展表。
访问频率较高的字段单独放在一张表
2/水平分表
针对数据量巨大的单张表(比如订单表),按照某种规则(RANGE、HASH取模等),切分到多张表里面去。
但是这些表还是在同一个库中,所以库级别的数据库操作还是有IO瓶颈,不建议采用
将单张表的数据切分到多个服务器上去,每个服务器具有一部分库与表,只是表中数据集合不同。
水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力,突破IO、连接数、硬件资源等的瓶颈
总结:分库分表
- 垂直分库:按照业务将表进行分类,分布到不同的数据库上面。这种方式需要解决跨库带来的所有复杂问题,如事务一致性问题。
- 水平分库:将表水平切分后按某个字段的某种规则分到不同的数据库,使得每个库具有相同的表,但表中的数据不相同。水平分库一般是伴随水平分表进行的。
- 垂直分表:将原始数据按照列拆分成多个表,每个表只包含某些列。这种策略通常用于处理包含大量无关字段的表,以减少每个表的列数,提高查询效率。
- 水平分表:将原始数据按照行拆分成多个表,每个表只包含某些行。这种策略通常用于处理数据量大的表,以提高并发访问的能力。