分库分表基础知识

分库分表概述

分库分表本质上就是为了解决由于库表数据量过大而导致数据库性能降低的问题; 核心操作:

  • 将原来独立的数据库拆分成若干数据库组成;

  • 将原来的大表(存储近千万数据的表)拆分成若干个小表;

目的:使得单一数据库、单一数据表的数据量变小,从而达到提升数据库性能的目的

 

举例

假设我们有一个在线电商系统,其中有一个名为"订单"的表,记录了所有用户的订单信息,包括订单号、用户ID、商品ID、订单时间、订单状态等。随着时间推移,订单表中的数据量逐渐增加,可能会达到数百万行甚至数亿行。

  1. 系统瓶颈和容量限制: 当订单表中的数据量增长到一定程度时,单个数据库服务器可能无法再容纳更多的数据,因为数据库的存储容量有限。此时,即使我们购买更多的存储设备,也会面临数据库连接数和处理能力的限制。例如,数据库服务器可能无法处理大量并发的查询请求,从而导致系统响应变慢或者请求被拒绝。

  2. 大表查询性能问题: 随着订单数据的增长,订单表可能会变得非常庞大。当执行查询操作时,数据库需要扫描整个大表来找到匹配的记录,这可能会导致查询性能急剧下降。例如,如果我们想要查找某个用户的所有订单记录,即使我们在用户ID列上创建了索引,数据库仍然需要花费大量的时间来扫描大表。

  3. 商家模块中的大表关联查询问题: 在商家模块中,可能需要进行一些复杂的查询操作,例如查找某个商家的所有订单记录,并统计其销售额。如果订单表非常大,而且商家信息存储在另一个表中,那么进行这种大表关联查询可能会非常耗时,导致系统响应变慢。

由此而来-分库分表

  • 分库分表是为了解决由于数

  • 据量过大而导致数据库性能降低的问题;

  • 分库分表是将原来独立的数据库拆分成若干数据库,将独立的大表拆分成若干小表过程;

  • 分库分表最终使得单一数据库、单一数据表的数据量变小,从而达到提升数据库性能的目的;

 

分库分表方式

 

1、垂直分表

1.1 垂直分表定义

  • 垂直分表就是在同一数据库内将一张表照指定字段分成若干表,每张表仅存储其中一部分字段;

  • 垂直分表拆解了原有的表结构,拆分的表之间一般是一对一的关系;

 

1.2 垂直分表场景示例

1.2.1 场景说明

下边通过一个商品查询的案例讲解垂直分表,通常在商品列表中是不显示商品详情信息的,如下图:

 

说明:

  • 用户浏览商品列表时只对感兴趣商品查看商品详情:商品描述信息被访问的频次较低,且该字段占用存储空间较大

  • 商品表字段出现部分字段访问频次不一致的情况:商品名称、商品图片、商品价格等其他字段数据访问频次较高

由于这两组数据的特性不一样,因此我们可以考虑将商品信息表拆分如下,将访问频次低的商品描述信息单独存放在一张表中,访问频次较高的商品基本信息单独放在一张表中

1.2.2 垂直分表优势
  • 充分提高了热点数据的操作效率,商品信息的操作的高效率不会被商品描述的低效率所拖累(冷热数据分离);

  • 避免了IO过度争抢并减少锁表的几率,查看商品详情的用户与商品信息浏览互不影响;

1.2.3 垂直分表原则
  • 把不常用的字段单独放在一张表;(因为数据库加载数据时,会将表整整行的信息加载)

  • 把text(大文本存储),blob(图片、视频类存储)等大字段拆分出来放在附表中(阿里开发手册严禁使用text等大字段);

  • 经常组合查询的列放在一张表中,避免多表联查,性能最高;

2、垂直分库

2.1 垂直分表存在的问题

  • 经过垂直分表后表的查询性能确实得到了一定程度的提升,但数据始终限制在同一台机器内,因此因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘;

  • 单台服务器的性能瓶颈(比如:CPU、内存、网络IO、磁盘等)通过垂直分表始终得不到突破;

2.2 垂直分库定义

垂直分库是指按照业务将表进行归类,然后把不同类的表分布到不同的数据库上面,而每个库又可以放在不同的服务器上,它的核心理念是-专库专用

2.3 示例场景

经过思考,我们可以将原有的卖家库,拆分为分为商品库和店铺库,并把这两个库分散到不同服务器上,如下图:

 

注意事项:

由于商品信息与商品描述业务耦合度较高,因此一起被存放在商品库(避免跨库联查); 店铺信息相对独立,因此可单独被存放在店铺库下; 对于地理区域表,因为商品信息和店铺信息都需要,且地理区域是不经常变动的常量表但是会存在与其他表联查的情况,所以可以将它作为公共表分别等量部署到不同的数据库节点下; 以上操作就可以称为垂直分库。

 

2.4垂直分库优势

垂直分库带来的提升是:

  • 通过不同表的业务聚合(聚合为库),使得数据库维护更加清晰;

  • 能对不同业务的数据进行分级管理、维护、监控、扩展等;

  • 高并发场景下,垂直分库在一定程度上提高了磁盘IO和数据库连接数,并改善了单机硬件资源的瓶颈问题;

 

3、 水平分表

3.1水平分表定义

  • 水平分表就是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中,表的结构没有变化;

  • 水平分表解决单表数据量大的问题;

3.2 水平分表示例

为解决单表数据量大的问题,我们可把商品库内的表进行水平拆分,得到若干相同表结构的小表;

需要注意的是各个小表存储的数据不同,且数据依旧保存在同一个数据库内;

如下图:

 

分表算法说明:

如果商品ID为双数,将此操作映射至商品信息1表;如果商品ID为单数,将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息[商品ID%2 + 1];

这种操作就叫做:水平分表。

3.3 水平分表优势

水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中,它带来的提升是:

  • 优化单一表数据量过大而产生的性能问题;

  • 避免IO争抢并减少锁表的几率;

整体看,水平分表仅仅解决了单表数据量过大的问题,但是没有解决单库数据量过大的问题;

4、水平分库

4.1 水平分库定义

  • 水平分库可以看做是水平分表的进一步拆分,是把同一个表的数据按一定规则拆到不同的数据库中,每个库又可以部署到不同的服务器上;

  • 水平分库解决了单库数据量大的问题,突破了服务器物理存储的瓶颈;

4.2 水平分库示例场景

经过垂直分库和水平分表后,数据库性能问题得到一定程度的解决,但是随着业务量的增长,商品库单库存储数据已经超出预估。

假如当前有8w店铺,每个店铺平均150个不同规格的商品,那商品数量得往1200w+上预估,并且商品库属于访问非常频繁的资源,单台服务器已经无法支撑

此时该如何优化?

目前情况是那怕再次垂直分库也无法解决数据瓶颈问题。我们可以尝试水平分库,将商品ID为单数的和商品ID为双数的商品信息分别放在两个不同库中;

 

说明:

如果商品ID为双数,将此操作映射至【商品库-1】; 如果店铺ID为单数,将操作映射至【商品库-2】; 此操作要访问数据库名称的表达式为:商品库_(商品ID%2 + 1); 这种操作就叫水平分库。 总之,水平分库后,各个库保存的表结构是一致的,但是表中内容不一样;

 

4.3 水平分库优势

水平分库带来的提升是:

  • 解决了单库大数据,高并发的性能瓶颈问题;

  • 提高了系统的稳定性及可用性;

总之,当一个应用难以再细粒度的垂直切分,或切分后数据量行数巨大,存在单库读写、存储性能瓶颈,这时候就需要进行水平分库了,经过水平切分的优化,往往能==解决单库存储量及性能瓶颈==。但由于同一个表被分配在不同的数据库,需要额外进行数据操作的路由工作,因此大大提升了系统复杂度

分库分表小结

分库分表方式:垂直分表、垂直分库、水平分库和水平分表

垂直分表:可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表,这样既能使业务清晰,还能提升部分性能。拆分后,尽量从业务角度避免联查,否则性能方面将得不偿失【同一库中将单张表按照字段拆分成若干表,拆分后表的记录行数不变】。

垂直分库:可以把多个表按业务耦合松紧归类,分别存放在不同的库,这些库可以分布在不同服务器,从而使访问压力被多服务器负载,大大提升性能,同时能提高整体架构的业务清晰度,不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。 【根据业务将表分组形成不同的库,这些库又可以部署到不同的数据库中-专库专用

水平分表:可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中,每个表只有这个表的部分数据,这样做能小幅提升性能,它仅仅作为水平分库的一个补充优化。【同一数据库中将大表拆分成若干小表,每张表的结构一致,但保存的数据不同

水平分库:可以把表的数据(按数据行)分 到多个不同的库,每个库只有这个表的部分数据,这些库可以分布在不同服务器,从而使访问压力被多服务器负载,大大提升性能。它不仅需要解决跨库带来的所有复杂问题,还要解决数据路由的问题(数据路由问题后边介绍)。

最佳实践:

一般来说,在系统设计阶段就应该根据业务耦合松紧来确定垂直分库,垂直分表方案。当然在数据量及访问压力不是特别大的情况,首先考虑缓存、读写分离、索引技术等方案。若数据量极大,且持续增长,再考虑水平分库水平分表方案。

总之,基于开发和维护成本比考虑,非必须,不要对数据库做分库分表处理!

 

  • 26
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值