12张图把分库分表讲的明明白白!

2024-03-17 22:59

本文主要是介绍12张图把分库分表讲的明明白白!,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章来源:https://juejin.cn/post/7085132195190276109

目录

  1. 什么是分库分表

  2. 为什么需要分库分表

  3. 如何分库分表?

  4. 什么时候开始考虑分库分表

  5. 分库分表会导致哪些问题

  6. 分库分表中间件简介


1. 什么是分库分表

分库:就是一个数据库分成多个数据库,部署到不同机器。

13a0fd5c323ad3b6fa5f851fa3a80e07.jpeg

分表:就是一个数据库表分成多个表。

f619accc0885b24e894804b19502fdf0.jpeg


2. 为什么需要分库分表

2.1 为什么需要分库呢?

如果业务量剧增,数据库可能会出现性能瓶颈,这时候我们就需要考虑拆分数据库。从这几方面来看:

  • 磁盘存储

业务量剧增,MySQL单机磁盘容量会撑爆,拆成多个数据库,磁盘使用率大大降低。

  • 并发连接支撑

我们知道数据库连接是有限的。在高并发的场景下,大量请求访问数据库,MySQL单机是扛不住的!当前非常火的微服务架构出现,就是为了应对高并发。它把订单、用户、商品等不同模块,拆分成多个应用,并且把单个数据库也拆分成多个不同功能模块的数据库(订单库、用户库、商品库),以分担读写压力。


2.2 为什么需要分表?

数据量太大的话,SQL的查询就会变慢。如果一个查询SQL没命中索引,千百万数据量的表可能会拖垮这个数据库。

即使SQL命中了索引,如果表的数据量超过一千万的话,查询也是会明显变慢的。这是因为索引一般是B+树结构,数据千万级别的话,B+树的高度会增高,查询就变慢啦。

小伙伴们是否还记得,MySQL的B+树的高度怎么计算的呢? 顺便复习一下吧

InnoDB存储引擎最小储存单元是页,一页大小就是16k。B+树叶子存的是数据,内部节点存的是键值+指针。索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中,进而再去数据页中找到需要的数据,B+树结构图如下:

04e00a83c0e2bf504e139a253a0f7e36.jpeg

假设B+树的高度为2的话,即有一个根结点和若干个叶子结点。这棵B+树的存放总记录数为=根结点指针数*单个叶子节点记录行数。

  • 如果一行记录的数据大小为1k,那么单个叶子节点可以存的记录数  =16k/1k =16.

  • 非叶子节点内存放多少指针呢?我们假设主键ID为bigint类型,长度为8字节(面试官问你int类型,一个int就是32位,4字节),而指针大小在InnoDB源码中设置为6字节,所以就是 8+6=14 字节,16k/14B =16*1024B/14B = 1170

因此,一棵高度为2的B+树,能存放1170 * 16=18720条这样的数据记录。

同理一棵高度为3的B+树,能存放1170 *1170 *16 =21902400,大概可以存放两千万左右的记录。B+树高度一般为1-3层,如果B+到了4层,查询的时候会多查磁盘的次数,SQL就会变慢。

因此单表数据量超过千万,就需要考虑分表啦。


3. 如何分库分表


3.1 垂直拆分

4855c4e7117f52995e4881c226cbabe0.jpeg

3.1.1 垂直分库

在业务发展初期,业务功能模块比较少,为了快速上线和迭代,往往采用单个数据库来保存数据。数据库架构如下:

bd556c9ca4d5bdf01dedae786360dbed.jpeg

但是随着业务蒸蒸日上,系统功能逐渐完善。这时候,可以按照系统中的不同业务进行拆分,比如拆分成用户库、订单库、积分库、商品库,把它们部署在不同的数据库服务器,这就是垂直分库

垂直分库,将原来一个单数据库的压力分担到不同的数据库,可以很好应对高并发场景。数据库垂直拆分后的架构如下:

9f31e8e98d08edcb5f49144210b0a053.jpeg



3.1.2 垂直分表

如果一个单表包含了几十列甚至上百列,管理起来很混乱,每次都select *的话,还占用IO资源。这时候,我们可以将一些不常用的、数据较大或者长度较长的列拆分到另外一张表。

比如一张用户表,它包含user_id、user_name、mobile_no、age、email、nickname、address、user_desc,如果email、address、user_desc等字段不常用,我们可以把它拆分到另外一张表,命名为用户详细信息表。这就是垂直分表

a7c40d521edfea1f19dbe33d11326bc8.jpeg


3.2 水平拆分

3.2.1 水平分库

水平分库是指,将表的数据量切分到不同的数据库服务器上,每个服务器具有相同的库和表,只是表中的数据集合不一样。它可以有效的缓解单机单库的性能瓶颈和压力。

用户库的水平拆分架构如下:

0a06ecdbcac19058430f86fbdb811571.jpeg


3.2.2 水平分表

如果一个表的数据量太大,可以按照某种规则(如hash取模、range),把数据切分到多张表去。

一张订单表,按时间range拆分如下:

6670f411c6e6bdb82c3422f397645815.jpeg


3.3. 水平分库分表策略

分库分表策略一般有几种,使用与不同的场景:

  • range范围

  • hash取模

  • range+hash取模混合


3.3.1 range范围

range,即范围策略划分表。比如我们可以将表的主键,按照从0~1000万的划分为一个表,1000~2000万划分到另外一个表。如下图:

4a953ca083f4fa96feaa29a08a1c7994.jpeg

当然,有时候我们也可以按时间范围来划分,如不同年月的订单放到不同的表,它也是一种range的划分策略。

这种方案的优点:

  • 这种方案有利于扩容,不需要数据迁移。假设数据量增加到5千万,我们只需要水平增加一张表就好啦,之前0~4000万的数据,不需要迁移。

缺点:

  • 这种方案会有热点问题,因为订单id是一直在增大的,也就是说最近一段时间都是汇聚在一张表里面的。比如最近一个月的订单都在1000万~2000万之间,平时用户一般都查最近一个月的订单比较多,请求都打到order_1表啦,这就导致表的数据热点问题。

3.3.2 hash取模

hash取模策略:指定的路由key(一般是user_id、订单id作为key)对分表总数进行取模,把数据分散到各个表中。

比如原始订单表信息,我们把它分成4张分表:

d189e068e2923129c6a47073b1298924.jpeg

  • 比如id=1,对4取模,就会得到1,就把它放到第1张表,即t_order_0;

  • id=3,对4取模,就会得到3,就把它放到第3张表,即t_order_2;

这种方案的优点:

  • hash取模的方式,不会存在明显的热点问题。

缺点:

  • 如果一开始按照hash取模分成4个表了,未来某个时候,表数据量又到瓶颈了,需要扩容,这就比较棘手了。比如你从4张表,又扩容成8张表,那之前id=5的数据是在(5%4=1,即第一张表),现在应该放到(5%8=5,即第5张表),也就是说历史数据要做迁移了


3.3.3 range+hash取模混合

既然range存在热点数据问题,hash取模扩容迁移数据比较困难,我们可以综合两种方案一起嘛,取之之长,弃之之短。

比较简单的做法就是,在拆分库的时候,我们可以先用range范围方案,比如订单id在04000万的区间,划分为订单库1,id在4000万8000万的数据,划分到订单库2,将来要扩容时,id在8000万~1.2亿的数据,划分到订单库3。然后订单库内,再用hash取模的策略,把不同订单划分到不同的表。

00028341ce90b5319b2ca37d2f9ac19a.jpeg


4. 什么时候才考虑分库分表呢?

4.1 什么时候分表?

如果你的系统处于快速发展时期,如果每天的订单流水都新增几十万,并且,订单表的查询效率明变慢时,就需要规划分库分表了。一般B+树索引高度是2~3层最佳,如果数据量千万级别,可能高度就变4层了,数据量就会明显变慢了。不过业界流传,一般500万数据就要考虑分表了。


4.2 什么时候分库

业务发展很快,还是多个服务共享一个单体数据库,数据库成为了性能瓶颈,就需要考虑分库了。比如订单、用户等,都可以抽取出来,新搞个应用(其实就是微服务思想),并且拆分数据库(订单库、用户库)。


5. 分库分表会导致哪些问题

分库分表之后,也会存在一些问题:

  • 事务问题

  • 跨库关联

  • 排序问题

  • 分页问题

  • 分布式ID


5.1 事务问题

分库分表后,假设两个表在不同的数据库,那么本地事务已经无效啦,需要使用分布式事务了。


5.2 跨库关联

跨节点Join的问题:解决这一问题可以分两次查询实现


5.3 排序问题

跨节点的count,order by,group by以及聚合函数等问题:可以分别在各个节点上得到结果后在应用程序端进行合并。


5.4 分页问题

  • 方案1:在个节点查到对应结果后,在代码端汇聚再分页。

  • 方案2:把分页交给前端,前端传来pageSize和pageNo,在各个数据库节点都执行分页,然后汇聚总数量前端。这样缺点就是会造成空查,如果分页需要排序,也不好搞。


5.5 分布式ID

据库被切分后,不能再依赖数据库自身的主键生成机制啦,最简单可以考虑UUID,或者使用雪花算法生成分布式ID。


6. 分库分表中间件

目前流行的分库分表中间件比较多:

  • cobar

  • Mycat

  • Sharding-JDBC

  • Atlas

  • TDDL(淘宝)

  • vitess

d8916a2362d15b79a7a09e1b79834382.jpeg

这篇关于12张图把分库分表讲的明明白白!的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/820456

相关文章

分库分表核心理念

文章目录 分库,分表,分库分表什么时候分库?什么时候分表?什么时候既分库又分表?横向拆分 & 纵向拆分 分表算法Range 范围Hash 取模一致性 Hash斐波那契散列 严格雪崩标准(SAC)订单分库分表实战全局 ID 的生成UUID基于某个单表做自增主键雪花算法时间回拨问题 分库分表迁移停机迁移方案双写迁移方案 分库分表带来的问题参考 & 推荐文章 分库,分表,分库分表

基于shard-jdbc中间件,实现数据分库分表

一、水平分割 1、水平分库 1)、概念: 以字段为依据,按照一定策略,将一个库中的数据拆分到多个库中。 2)、结果 每个库的结构都一样;数据都不一样; 所有库的并集是全量数据; 2、水平分表 1)、概念 以字段为依据,按照一定策略,将一个表中的数据拆分到多个表中。 2)、结果 每个表的结构都一样;数据都不一样; 所有表的并集是全量数据; 二、Shard-jdbc 中间件 1、架构图 2、特点

基于Shard-Jdbc分库分表,数据库扩容方案

一、数据库扩容 1、业务场景 互联网项目中有很多“数据量大,业务复杂度高,需要分库分表”的业务场景。 这样分层的架构 (1)上层是业务层biz,实现业务逻辑封装; (2)中间是服务层service,封装数据访问; (3)下层是数据层db,存储业务数据; 2、扩容场景和问题 当数据量持续新增,面临着这样一些需求,两台数据库无法容纳,需要数据库扩容,这里选择2台—扩容到3台的模式,如下图

分库分表:应对大数据量挑战的数据库扩展策略

随着互联网技术的发展,数据量的爆炸性增长给数据库系统带来了前所未有的挑战。为了有效管理大规模数据并保持高性能,分库分表成为了一种常见的数据库扩展策略。本文将探讨分库分表的概念、动机、实施策略以及潜在的挑战和解决方案。 什么是分库分表? 分库分表是一种数据库架构设计策略,它将数据分散存储在多个数据库(分库)和多个表(分表)中。这种方法可以提高数据库的可伸缩性、可用性和性能。 为什么需要分库分表

图解!24张图彻底弄懂九大常见数据结构!(转)

对于学习数据结构,打牢基础的小伙伴来说,是篇相当棒的文章,值得学习 文章链接:图解!24张图彻底弄懂九大常见数据结构! 事情发展就是这样,也许很啰嗦。 大致就是公司A(工作4年7个月)-->B(试用期2星期)-->C(3月20日至今)。B公司开始挖我。 纠结

一文读懂数据库分库分表

阅读此文你将了解: 什么是分库分表以及为什么分库分表如何分库分表分库分表常见几种方式以及优缺点如何选择分库分表的方式 数据库常见优化方案 对于后端程序员来说,绕不开数据库的使用与方案选型,那么随着业务规模的逐渐扩大,其对于存储的使用上也需要随之进行升级和优化。 随着规模的扩大,数据库面临如下问题: 读压力:并发QPS、索引不合理、SQL语句不合理、锁粒度写压力:并发QPS、事务、锁粒

强!分库分表与分布式数据库技术选项分析

点击上方“朱小厮的博客”,选择“设为星标” 后台回复"1024"领取公众号专属资料 来源:rrd.me/gEhKy 最近经常被问到分库分表与分布式数据库如何选择,网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章,但有些观点与判断是我觉得是偏激的,脱离环境去评价方案好坏其实有失公允。 本文通过对两种模式关键特性实现原理对比,希望可以尽可能客观、中立的阐明各自真实

阿里面试题:分库分表无限扩容后的瓶颈以及解决方案

点击上方“朱小厮的博客”,选择“设为星标” 后台回复"书",获取 后台回复“k8s”,可领取k8s资料 前言 像我这样的菜鸟,总会有各种疑问,刚开始是对 JDK API 的疑问,对 NIO 的疑问,对 JVM 的疑问,当工作几年后,对服务的可用性,可扩展性也有了新的疑问,什么疑问呢?其实是老生常谈的话题:服务的扩容问题。 正常情况下的服务演化之路 让我们从最初开始。 单体应用 每个创业公司基本都

分表实战二

关于如何生成表?查询如何确定表?考虑后期容错,先用hook来实现自动创建表和自动获取查询表 利用behavior在必要的模块进行hook监听 更改文件 app/tags.php…/behavior/HouseBehavior.phpapp/houserent/controller/TestController.php 代码如下 app/tags.php …/behavior/Hou

分表实战一

现在单表超过一千万记录,虽然索引完全使用,依旧会出现慢查询。日增平均40万。 数据库要重新设计,目的提高查询速度,只查询热数据。 设计思路 根据热数据时效性,保持在近三个月内,计划一年生成6张表。利用union来查询,当前月在内的近三个月或四个月的数据。牵扯查询尽量使用索引。 如何生成表? 比如2020年,生成20200102,20200304,20200506,20200708,