参考文章:分库分表的概念及应用场景详解_star++的博客-CSDN博客
随着互联网的发展,线上业务越来越普及,用户量也是越来越大,那么必定导致用户量的增加,业务压力增大. 服务器的处理请求压力已经通过分布式微服务解决, 那么存储层的压力也需要有解决方案:分库分表。
下面举例说明数据库表的几种拆分方式:
如:user表。
1、水平分表
user表 水平拆分后,分为:user1、user2 两张表,拆分后的两张表结构相同。
水平分表可以很好缓解数据存储大,导致即使使用了索引,那检索很慢的问题。比如mysql上千万条数据时,使用索引性能也开始下降了,这时候分表,那么每张表只有500万数据,可以很好解决索引瓶颈问题。
2、垂直分表
user表 垂直拆分后,分为:user1、user2 两张表,拆分后的两张表结构不同。即:将user表进行细化拆分, user1 :年龄信息,user2:img信息。
垂直分表有两个好处:
1、可以一定程度上解决索引的瓶颈,因为可以让一颗b+树存储更多的数据,比如有图片大文本数据,垂直分表,就有主从表的概念,这样大大提高检索效率;
2、可以提高并发操作,可以达到同时修改两张表的数据,不会局限于行锁。
3、水平分库
user表 水平分库后,分为:DB1库的user表、DB2库的user 表,拆分后的两张表结构相同。
水平分库一般不是因为索引瓶颈导致的, 而是因为业务并发量太大造成的, 一个数据库已经不能够及时处理所有的业务请求了,必须将数据库请求进行分摊处理.如果不是因为数据库处理不过来,一般水平分表就够用了,水平分表只是解决存储量大的索引瓶颈问题
4、垂直分库
垂直分库:将用户模块、订单模块 放在不同的库里。
垂直分库一般也不是因为索引瓶颈导致的,也是因为业务量大造成的,一般是指单块业务就很大,必须独立使用一台数据库服务才能及时处理. 否则业务量不大情况,所有模块业务表分不同schema即可。
5、使用场景
水平分表:业务并发量不大, 单表数据大,检索数据慢;
垂直分表:业务并发量不大, 大表,存大文本;
水平分库:业务并发量大,单表数据大;
垂直分库:业务并发量大, 业务模块分库,单模块业务量大。
6、总结
1、如果只是数据量大,达到了索引瓶颈,那么只需要分表即可;
2、如果是数据量和并发量都大, 那么达到了io和cpu瓶颈,那么需要分库。
7、分库分表带来的问题
7.1、分布式事务问题
数据库的事务只是在本地是有效的,能保证结点本身的的操作是一个事务.当多个数据库时,数据库之间是不可见的,所以存在分库时数据不一致性问题。
7.2、跨结点关联查询问题
当垂直分库的时候,比如订单和支付是不同模块,那么这个时候想查看订单详情,那么需要关联查询,那么再也不能像单库那样,直接使用join就能达到预期效果了。
7.3、跨结点排序,分页,max,min,count等问题
当水平分库的时候,每个数据库结点都是保存一部分数据,那么排序,分页,max,min,count是对整体数据的操作,也不能像单库那样,直接使用order by, limit, max,min,count(*)就能解决了
7.4、主键重复问题
当水平分表分库的时候,主键的生成策略就没用了,水平分库分表就不能依赖表本身主键生成策略了,否则很可能发生重复。
7.5、公共表问题
一些共用表,比如一些常量表,是多个数据库结点都要使用到的,但是不需要分库分表的。
7.6、总结
虽然分库分表可以给我们解决数据库性能问题,但是也会给我们带来上面的五个问题,可能在开发当中需要解决,这些解决方案在一些中间件已经帮我们解决了,我们只需要使用这些中间件的方案即可。