分库分表的概念及应用场景详解

  • 资料
    分库分表的概念及应用场景详解
    分库分表带来的一些问题
    sharding-jdbc水平垂直分库分表环境搭建
    sharding-jdbc水平分库分表实战
    sharding-jdbc垂直分库分表实战

  • 背景
    随着互联网的发展,线上业务越来越普及,用户量也是越来越大,那么必定导致用户量的增加,业务压力增大. 服务器的处理请求压力已经通过分布式微服务解决, 那么存储层的压力也需要有解决方案,那么这个解决方案就是分库分表.

  • 水平分表
    在这里插入图片描述
    水平分表可以很好缓解数据存储大,导致即使使用了索引,那检索很慢的问题. 比如mysql上千万条数据时,使用索引性能也开始下降了,这时候分表,那么每张表只有500万数据,可以很好解决索引瓶颈问题.

  • 垂直分表
    在这里插入图片描述
    垂直分表有两个好处. 可以一定解决索引的瓶颈,因为可以让一颗b+树存储更多的数据,比如有图片大文本数据,垂直分表,就有主从表的概念,这样大大提高检索效率; 可以提高并发操作,可以达到同时修改两张表的数据,不会局限于行锁.

  • 水平分库
    在这里插入图片描述
    水平分库一般不是因为索引瓶颈导致的, 而是因为业务并发量太大造成的, 一个数据库已经不能够及时处理所有的业务请求了,必须将数据库请求进行分摊处理.如果不是因为数据库处理不过来,一般水平分表就够用了,水平分表只是解决存储量大的索引瓶颈问题

  • 垂直分库
    在这里插入图片描述
    垂直分库一般也不是因为索引瓶颈导致的,也是因为业务量大造成的,一般是指单块业务就很大,必须独立使用一台数据库服务才能及时处理. 否则业务量不大情况,所有模块业务表分不同schema即可.

  • 使用场景
    水平分表: 业务并发量不大, 单表数据大,检索数据慢
    垂直分表: 业务并发量不大, 大表,存大文本
    水平分库:业务并发量大,单表数据大
    垂直分库: 业务并发量大, 业务模块分库,单模块业务量大

  • 总结
    1.如果只是数据量大,达到了索引瓶颈,那么只需要分表即可
    2.如果是数据量和并发量都大, 那么达到了io和cpu瓶颈,那么需要分库

猜你喜欢

转载自blog.csdn.net/weixin_38312719/article/details/109011069