目录
个人感觉公司中如果数据量超级大的话,那么公司一定很有钱,大概率不会选择分库分表,直接使用分布式数据库了
大前提
移动互联网时代,海量的用户每天产生海量的数量,比如:用户表、订单表、交易流水表。
- 以支付宝用户为例,8亿;微信用户更是10亿。
- 订单表更夸张,比如美团外卖,每天都是几千万的订单。
- 淘宝的历史订单总量应该百亿,甚至千亿级别,这些海量数据远不是一张表跟不Hold不住啊
- 事实上MySQL单表可以存储10亿级数据,只是这时候性能比较差,业界公认MySQL单表容量在1KW以下是最佳状态,因为这时它的BTREE索引树高在3~5之间。
这篇文章的主干如下
1、分库分表之前出现的问题?
2、怎么分库分表?
3、分库分表的规则
这篇文章会围绕这些问题给出解答
一、单库单表出现的问题
假设你要设计一个电商网站,在一开始,用户表、订单表、交易流水表等等各种表都在同一个数据库中,每个表都包含了大量的字段。在用户量比较少,访问量也比较少的时候,单库单表不存在问题。
但是公司可能发展的比较好,用户量开始大量增加,业务也越来越繁杂。一张表的字段可能有几十个甚至上百个,单表高达几千万数据,单个数据库中存在很多这样的表。对于一个数据库的压力就太大了,一张表的压力也比较大。试想一下,我们在一张几千万数据的表中查询数据,压力本来就大,如果这张表还需要关联查询,那时间等等各个方面的压力就更大了。
(1)单库太大:数据库中的表太多IO次数多,CPU负荷比较大
(2)单表太大 :一张表的数据量太多,字段太多,查询起来太困难
这个时候我们就得思考如何解决这个问题了
二、主从复制架构
单库单表满足不了我们的需求,我们可以考虑使用读写分离,我们将数据库的读操作和写操作进行分离,使用多个从库副本进行负责读,使用主库负责写,从库从主库同步更新数据,保持数据一致。
读写分离的操作可以解决一定的问题,但是我们的用户非常多的时候,我们单表的数据量达到了上亿条数据,这个时候我们的写操作会越来越多,一个主库(Master)不能满足要求了,那就把主库拆分,这时候为了保证数据的一致性就要开始进行同步,此时会带来一系列问题:
(1)写操作拓展起来比较困难,因为要保证多个主库的数据一致性。
(2)复制延时:意思是同步带来的时间消耗。
(3)锁表率上升:读写分离,命中率少,锁表的概率提升。
(4)表变大,缓存率下降:此时缓存率一旦下降,带来的就是时间上的消耗。
注意,此时主从复制还是单库单表,只不过复制了很多份并进行同步。
主从复制架构随着用户量的增加、访问量的增加、数据量的增加依然会带来大量的问题,那就要考虑换一种解决思路。就是今天所讲的主题,分库分表。
三、分库分表(本期主角!!!)
概述
适用场景
分库分表的方式方法
一般就是垂直切分和水平切分,这是一种结果集描述的切分方式,是物理空间上的切分。分库分表的顺序应该是先垂直再水平(个人认为,因为垂直分更简单——手动狗头)
1、分表
(1)垂直分表
表中的字段比较多,一般将不常用的、数据量大的、长度较长的拆分到“扩展表”中。一般来说加表的字段可能有几百列,此时是按照字段进行数竖直切。注意垂直分是列多的情况。
(2)水平分表
单表的数据量太大。按照某种规则(RANGE,HASH取模等),切分到多张表里面去。 但是这些表还是在同一个库中,所以库级别的数据库操作还是有IO瓶颈。这种情况是不建议使用的,因为数据量是逐渐增加的,当数据量增加到一定的程度还需要再进行切分。比较麻烦。
2、分库
(1)垂直分库
一个数据库的表太多。此时就会按照一定业务逻辑进行垂直切,比如用户相关的表放在一个数据库里,订单相关的表放在一个数据库里。注意此时不同的数据库应该存放在不同的服务器上,此时磁盘空间、内存、TPS等等都会得到解决。
(2)水平分库
水平分库理论上切分起来是比较麻烦的,它是指将单张表的数据切分到多个服务器上去,每个服务器具有相应的库与表,只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力,突破IO、连接数、硬件资源等的瓶颈。
四、分库分表后出现的问题
1、联查数据困难
虽然说联查数据困难,但是也可以说是根本不可能,两个互相关联的表可能分布在不同的数据库,甚至不同的服务器中
2、需要支持事务
分库分表后,就需要支持分布式事务了。数据库本身为我们提供了事务管理功能,但是分库分表之后就不适用了。如果我们自己编程协调事务,代码方面就又开始了麻烦。
3、跨库join
分库分表后表之间的关联操作将受到限制,我们无法join位于不同分库的表,也无法join分表粒度不同的表, 结果原本一次查询能够完成的业务,可能需要多次查询才能完成。 我们可以使用全局表,所有库都拷贝一份。(可以在程序中封装代码或者中间件分装解决)
4、结果合并麻烦
比如我们购买了商品,订单表可能进行了拆分等等,此时结果合并就比较困难。