【分库分表】理论基础

目录

为什么要分库分表

垂直分

垂直分库

垂直分表

垂直切分优缺点

优点

缺点

水平分

水平分库

水平分表

水平切分优缺点

优点 

缺点


为什么要分库分表

分库分表是一种场景解决方案,它的出现是为了解决一些场景问题的

  • 单表过大的话,读请求进来,查数据需要的时间会过长,当一张表的数据达到几千万时,查询一次所花的时间会变长。业界公认MySQL单表容量在 1千万 以下是最佳状态,因为这时它的BTREE索引树高在3~5之间。

  • 读请求过多,单节点IO压力太大,IO压力太大会造成什么?可能会造成IO阻塞,造成响应速度变慢。

分库分表有两种维度,一种维度是分库,另一种维度是分表。分的话有两种分法,一种是水平分,另一种是垂直分。

垂直分

垂直切分又可以分为: 垂直分库垂直分表

垂直分库

就是根据业务耦合性,将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似,按业务分类进行独立划分。与"微服务治理"的做法相似,

每个微服务使用单独的一个数据库。

一开始我们是单体服务,所以只有一个数据库,所有的表都在这个库里。

后来因为业务需求,单体服务变成微服务治理。所以将之前的一个商品库,拆分成多个数据库。每个微服务对于一个数据库。

垂直分表

把一个表的多个字段分别拆成多个表,一般按字段的冷热拆分,热字段一个表,冷字段一个表。从而提升了数据库性能。

一开始商品表中包含商品的所有字段,但是我们发现:

  1. 商品详情和商品属性字段较长
  2. 商品列表的时候我们是不需要显示商品详情和商品属性信息,只有在点进商品商品的时候才会展示商品详情信息

所以可以考虑把商品详情和商品属性单独切分一张表,提高查询效率。

垂直切分优缺点
优点
  • 解决业务系统层面的耦合,业务清晰 
  • 与微服务的治理类似,也能对不同业务的数据进行分级管理、维护、监控、扩展等 
  • 高并发场景下,垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点
  • 分库后无法Join,只能通过接口聚合方式解决,提升了开发的复杂度 
  • 分库后分布式事务处理复杂 
  • 依然存在单表数据量过大的问题(需要水平切分)

水平分

当一个应用难以再细粒度的垂直切分或切分后数据量行数巨大,存在单库读写、存储性能瓶颈,这时候就需要进行水平切分了。

水平切分也可以分为:水平分库水平分表

水平分库

上面虽然已经把商品库分成3个库,但是随着业务的增加一个订单库也出现QPS过高,数据库响应速度来不及,一般mysql单机也就1000左右的QPS,如果超过1000就要考虑分库。

水平分表

 一般我们一张表的数据不要超过1千万,如果表数据超过1千万,并且还在不断增加数据,那就可以考虑分表。

水平切分优缺点
优点 
  • 不存在单库数据量过大、高并发的性能瓶颈,提升系统稳定性和负载能力
  • 应用端改造较小,不需要拆分业务模块
缺点
  • 跨分片的事务一致性难以保证
  • 跨库的Join关联查询性能较差 
  • 数据多次扩展难度和维护量极大
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hrhcode

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值