数据库分库分表策略的具体实现方案

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用版 2核4GB 50GB
简介: 版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_34173549/article/details/79879588 一、MySQL扩展具体的实现方式随着业务规模的不断扩大,需要选择合适的方案去应对数据规模的增长,以应对逐渐增长的访问压力和数据量。
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_34173549/article/details/79879588

一、MySQL扩展具体的实现方式

随着业务规模的不断扩大,需要选择合适的方案去应对数据规模的增长,以应对逐渐增长的访问压力和数据量。

关于数据库的扩展主要包括:业务拆分、主从复制,数据库分库与分表。这篇文章主要讲述数据库分库与分表

(1)业务拆分

在 大型网站应用之海量数据和高并发解决方案总结一二 一篇文章中也具体讲述了为什么要对业务进行拆分。

业务起步初始,为了加快应用上线和快速迭代,很多应用都采用集中式的架构。随着业务系统的扩大,系统变得越来越复杂,越来越难以维护,开发效率变得越来越低,并且对资源的消耗也变得越来越大,通过硬件提高系统性能的方式带来的成本也越来越高。

因此,在选型初期,一个优良的架构设计是后期系统进行扩展的重要保障。

例如:电商平台,包含了用户、商品、评价、订单等几大模块,最简单的做法就是在一个数据库中分别创建users、shops、comment、order四张表。

这里写图片描述

但是,随着业务规模的增大,访问量的增大,我们不得不对业务进行拆分。每一个模块都使用单独的数据库来进行存储,不同的业务访问不同的数据库,将原本对一个数据库的依赖拆分为对4个数据库的依赖,这样的话就变成了4个数据库同时承担压力,系统的吞吐量自然就提高了。

这里写图片描述

(2)主从复制

1、MySQL5.6 数据库主从(Master/Slave)同步安装与配置详解

2、MySQL主从复制的常见拓扑、原理分析以及如何提高主从复制的效率总结

3、使用mysqlreplicate命令快速搭建 Mysql 主从复制

上述三篇文章中,讲述了如何配置主从数据库,以及如何实现数据库的读写分离,这里不再赘述,有需要的选择性点击查看。

这里写图片描述

上图是网上的一张关于MySQL的Master和Slave之间数据同步的过程图。

主要讲述了MySQL主从复制的原理:数据复制的实际就是Slave从Master获取Binary log文件,然后再本地镜像的执行日志中记录的操作。由于主从复制的过程是异步的,因此Slave和Master之间的数据有可能存在延迟的现象,此时只能保证数据最终的一致性。

(3)数据库分库与分表

我们知道每台机器无论配置多么好它都有自身的物理上限,所以当我们应用已经能触及或远远超出单台机器的某个上限的时候,我们惟有寻找别的机器的帮助或者继续升级的我们的硬件,但常见的方案还是通过添加更多的机器来共同承担压力。

我们还得考虑当我们的业务逻辑不断增长,我们的机器能不能通过线性增长就能满足需求?因此,使用数据库的分库分表,能够立竿见影的提升系统的性能,关于为什么要使用数据库的分库分表的其他原因这里不再赘述,主要讲具体的实现策略。请看下边章节。

二、分表实现策略

关键字:用户ID、表容量

对于大部分数据库的设计和业务的操作基本都与用户的ID相关,因此使用用户ID是最常用的分库的路由策略。用户的ID可以作为贯穿整个系统用的重要字段。因此,使用用户的ID我们不仅可以方便我们的查询,还可以将数据平均的分配到不同的数据库中。(当然,还可以根据类别等进行分表操作,分表的路由策略还有很多方式)

接着上述电商平台假设,订单表order存放用户的订单数据,sql脚本如下(只是为了演示,省略部分细节):

CREATE TABLE `order` (
  `order_id` bigint(32) primary key auto_increment,
  `user_id` bigint(32),
   ...
) 
  • 1
  • 2
  • 3
  • 4
  • 5

当数据比较大的时候,对数据进行分表操作,首先要确定需要将数据平均分配到多少张表中,也就是:表容量

这里假设有100张表进行存储,则我们在进行存储数据的时候,首先对用户ID进行取模操作,根据 user_id%100 获取对应的表进行存储查询操作,示意图如下:

这里写图片描述

例如,user_id = 101 那么,我们在获取值的时候的操作,可以通过下边的sql语句:

select * from order_1 where user_id= 101
  • 1

其中,order_1是根据 101%100 计算所得,表示分表之后的第一章order表。

注意:

在实际的开发中,如果你使用MyBatis做持久层的话,MyBatis已经提供了很好得支持数据库分表的功能,例如上述sql用MyBatis实现的话应该是:

接口定义:


/**
  * 获取用户相关的订单详细信息
  * @param tableNum 具体某一个表的编号
  * @param userId 用户ID
  * @return 订单列表
  */
public List<Order> getOrder(@Param("tableNum") int tableNum,@Param("userId") int userId);
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

xml配置映射文件:

<select id="getOrder" resultMap="BaseResultMap">
    select * from order_${tableNum}
    where user_id = #{userId}
  </select>
  • 1
  • 2
  • 3
  • 4

其中${tableNum} 含义是直接让参数加入到sql中,这是MyBatis支持的特性。

注意:

另外,在实际的开发中,我们的用户ID更多的可能是通过UUID生成的,这样的话,我们可以首先将UUID进行hash获取到整数值,然后在进行取模操作。
  • 1

三、分库实现策略

数据库分表能够解决单表数据量很大的时候数据查询的效率问题,但是无法给数据库的并发操作带来效率上的提高,因为分表的实质还是在一个数据库上进行的操作,很容易受数据库IO性能的限制。

因此,如何将数据库IO性能的问题平均分配出来,很显然将数据进行分库操作可以很好地解决单台数据库的性能问题。

分库策略与分表策略的实现很相似,最简单的都是可以通过取模的方式进行路由。

还是上例,将用户ID进行取模操作,这样的话获取到具体的某一个数据库,同样关键字有:

用户ID、库容量

路由的示意图如下:

这里写图片描述

上图中库容量为100。

同样,如果用户ID为UUID请先hash然后在进行取模。

四、分库与分表实现策略

上述的配置中,数据库分表可以解决单表海量数据的查询性能问题,分库可以解决单台数据库的并发访问压力问题。

有时候,我们需要同时考虑这两个问题,因此,我们既需要对单表进行分表操作,还需要进行分库操作,以便同时扩展系统的并发处理能力和提升单表的查询性能,就是我们使用到的分库分表。

分库分表的策略相对于前边两种复杂一些,一种常见的路由策略如下:

1、中间变量 = user_id%(库数量*每个库的表数量);
2、库序号 = 取整(中间变量/每个库的表数量);
3、表序号 = 中间变量%每个库的表数量;
  • 1
  • 2
  • 3

例如:数据库有256 个,每一个库中有1024个数据表,用户的user_id=262145,按照上述的路由策略,可得:

1、中间变量 = 262145%(256*1024)= 1;
2、库序号 = 取整(1/1024)= 0;
3、表序号 = 1%1024 = 1;
  • 1
  • 2
  • 3

这样的话,对于user_id=262145,将被路由到第0个数据库的第1个表中。

示意图如下:

这里写图片描述

五、分库分表总结

关于分库分表策略的选择有很多种,上文中根据用户ID应该是比较简单的一种。其他方式比如使用号段进行分区或者直接使用hash进行路由等。有兴趣的可以自行查找学习。

关于上文中提到的,如果用户的ID是通过UUID的方式生成的话,我们需要单独的进行一次hash操作,然后在进行取模操作等,其实hash本身就是一种分库分表的策略,使用hash进行路由策略的时候,我们需要知道的是,也就是hash路由策略的优缺点,优点是:数据分布均匀;缺点是:数据迁移的时候麻烦,不能按照机器性能分摊数据。

上述的分库和分表操作,查询性能和并发能力都得到了提高,但是还有一些需要注意的就是,例如:原本跨表的事物变成了分布式事物;由于记录被切分到不同的数据库和不同的数据表中,难以进行多表关联查询,并且不能不指定路由字段对数据进行查询。分库分表之后,如果我们需要对系统进行进一步的扩阵容(路由策略变更),将变得非常不方便,需要我们重新进行数据迁移。


最后需要指出的是,分库分表目前有很多的中间件可供选择,最常见的是使用淘宝的中间件Cobar。

GitHub地址:https://github.com/alibaba/cobara

文档地址为:https://github.com/alibaba/cobar/wiki

关于淘宝的中间件Cobar本篇内容不具体介绍,会在后边的学习中在做介绍。

另外Spring也可以实现数据库的读写分离操作,后边的文章,会进一步学习。

六、总结

上述中,我们学到了如何进行数据库的读写分离和分库分表,那么,是不是可以实现一个可扩展、高性能、高并发的网站那?很显然还不可以!一个大型的网站使用到的技术远不止这些,可以说,这些都是其中的最基础的一个环节,因为还有很多具体的细节我们没有掌握到,比如:数据库的集群控制,集群的负载均衡,灾难恢复,故障自动切换,事务管理等等技术。因此,还有很多需要去学习去研究的地方。

总之:

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
12天前
|
存储 关系型数据库 MySQL
MySQL数据库碎片化:隐患与解决策略
UUID作为主键可能导致MySQL存储碎片,影响性能。频繁的DML操作、字段长度变化和非顺序插入(如UUID)都会造成碎片。碎片增加磁盘I/O,降低查询效率,浪费空间,影响备份速度。建议使用自增ID,固定长度字段,并适时运行OPTIMIZE TABLE来减少碎片。
|
9天前
|
关系型数据库 大数据 数据库
数据库索引的优化策略与实践
数据库索引在提升查询效率中起到关键作用,本文探讨了多种数据库索引优化策略及其实际应用,旨在帮助开发者更好地设计和管理数据库索引,提升系统性能和用户体验。
|
14天前
|
数据处理 数据库 索引
数据库索引策略如何影响数据的读取效率?
【7月更文挑战第3天】数据库索引策略如何影响数据的读取效率?
10 2
|
14天前
|
存储 数据处理 数据库
数据库索引策略如何影响数据更新操作的性能?
【7月更文挑战第3天】数据库索引策略如何影响数据更新操作的性能?
17 1
|
14天前
|
监控 关系型数据库 MySQL
数据库索引策略
【7月更文挑战第3天】数据库索引策略
17 1
|
16天前
|
消息中间件 存储 数据库
微服务架构下的数据库设计策略
【6月更文挑战第30天】在分布式系统和微服务架构的浪潮中,传统的单一数据库模式已不再适应快速迭代和高并发的需求。本文将深入探讨在微服务环境下如何进行有效的数据库设计,包括数据一致性、可伸缩性以及安全性等方面的考量。通过分析不同的数据存储方案和同步策略,我们将为后端开发者提供一套实用且高效的数据库设计方案。
15 1
|
3天前
|
存储 监控 测试技术
现代数据库系统的性能优化策略与实践
随着数据量和复杂性的不断增加,现代数据库系统的性能优化成为软件工程中至关重要的一环。本文探讨了几种有效的性能优化策略,并结合实际案例展示了这些策略在提升数据库系统效率方面的应用。
|
9天前
|
SQL 缓存 Java
使用Hibernate实现复杂数据库查询优化策略
使用Hibernate实现复杂数据库查询优化策略
|
9天前
|
SQL 缓存 Java
使用Hibernate实现复杂数据库查询优化策略
使用Hibernate实现复杂数据库查询优化策略
|
15天前
|
安全 数据库 数据安全/隐私保护
探索微服务架构下的数据库设计策略
在微服务架构下,数据库设计是实现高效、可扩展和易于维护的关键因素之一。本文将深入探讨在微服务架构中如何进行有效的数据库设计,包括数据一致性的保障、数据库性能优化以及安全性考量。通过引用最新的科研研究、实验证据和权威统计数据,结合逻辑严密的分析,本文旨在为后端开发者提供一套科学严谨的数据库设计策略指南。
13 0