分库分表系列:分库分表的前世今生
大家好,我是【架构摆渡人】,一只十年的程序猿。这是分库分表系列的第一篇文章,这个系列会给大家分享很多在实际工作中有用的经验,如果有收获,还请分享给更多的朋友。
其实这个系列有录过视频给大家学习,但很多读者反馈说看视频太慢了。也不好沉淀为文档资料,希望能有一系列文字版本的讲解,要用的时候可以快速浏览关键的知识点。那么它就来了,我再花点时间写成几篇连续的文章供大家学习。
什么是分库分表?
一般,一个应用刚开始开发的时候,都是连接一个数据库。因为这个时候业务并不复杂,处于起步阶段。当然重构类的除外,重构类的是已经很明确的需求,业务也比较成熟。
分库分表从字面去理解,就是将库进行拆分,将表进行拆分。至于拆分的方式可以有多种,拆分的粒度也可以自行控制。
起步阶段,一个数据库,如下图所示:
分库后的效果,如下图所示:
将一个库进行拆分,必然有一定的理由和动机,那么为什么要分库分表呢?
为什么要分库分表?
性能问题
当数据库中的数据越来越多,请求量越来越高,性能会成为瓶颈。如果有个别SQL写的不好,没有走索引,则会出现全表扫描的情况,占用数据库的资源,影响其他请求。
存储空间不够
数据库部署在一台服务器上面,磁盘的空间是有限的,随着数据量的增多,磁盘的可用空间将会越来越少。如果不进行拆分,那么数据往哪写?
可用性更高
如果你只有一个库,当这个库出现问题的时候,所有的业务也就处于不能提供服务的状态。如果拆了10个库,10个库在不同的服务器上,即使某一个库出现问题,也不会影响所有的业务。
业务划分
当所有的业务表都在一个库中,本身就会存在资源抢占和相互影响的情况。同时也不利于多团队的开发,大家的表都在一起,万一误操作了怎么办。这么多表,哪些是我的,哪些是你的?
分库分表的方式有哪些?
什么是垂直拆分?
垂直拆分就是把一个数据库拆分成多个数据库的操作。假设你的数据库中有用户表,商品表,订单表等。这些是属于不同的业务场景,就算不从性能的角度考虑,也要进行拆分,这个就是根据业务进行划分,这就是垂直拆分的一种。
进行垂直拆分之后结构更清晰了,数据库的整体性能也上来了。以前一个库要顶住1W的QPS,现在平摊到三个数据库上面了,每个数据库只需要顶住3K多就够了,前提是你这3个数据库必须是独立的实例。
垂直拆分,也同时了解决了存储的问题,整体的存储空间其实也拆分开了。
什么是水平拆分
水平拆分跟垂直拆分可以进行互补,垂直拆分主要是容量和业务划分的拆分。水平拆分主要就是为了解决容量和性能问题的拆分。
比如你拆了订单库,商品库,用户库。但是订单库还是在一个数据库上面,他的性能和存储还是有瓶颈的。此时就要进行水平拆分了,水平拆分就是把一个订单库,拆分成多个库,一个订单表拆分成多个表。
订单库从一个库一个表拆分成多个库多个表,如下图所示:
总结
今天主要跟大家讲了下背景,以及为什么要做分库分表。让大家有个整体的概念,这样后面学习起来就会比较容易了。
虽然我们知道要做分库分表,但是在分的时候该怎么分呢?垂直和水平如何搭配,才能干活不累呢?请关注我,下篇文章为你揭秘。