分库分表(个人总结)

目录

大前提

一、单库单表出现的问题

二、主从复制架构

三、分库分表(本期主角!!!)

概述

适用场景

分库分表的方式方法

1、分表

2、分库

四、分库分表后出现的问题

个人感觉公司中如果数据量超级大的话,那么公司一定很有钱,大概率不会选择分库分表,直接使用分布式数据库了


大前提

移动互联网时代,海量的用户每天产生海量的数量,比如:用户表、订单表、交易流水表。

  • 以支付宝用户为例,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、结果合并麻烦

比如我们购买了商品,订单表可能进行了拆分等等,此时结果合并就比较困难。

个人感觉公司中如果数据量超级大的话,那么公司一定很有钱,大概率不会选择分库分表,直接使用分布式数据库了

  • 32
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值