✅到底有没有必要分库分表,如何考量的

本文涉及的产品
RDS AI 助手,专业版
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介: 是否需要分库分表取决于数据量、负载、增长速度、查询需求、扩展性、容错性和维护成本。当单表数据量接近2000万时,由于B+树结构,查询效率可能下降。B+树的高度和数据页限制了单表容量,通常保持在3-4层,以保证查询性能。以3层B+树、16KB数据页和1KB/行数据为例,可存约2000万条数据。权衡业务需求和技术因素,适时决定是否分表。

关于是否需要进行分库分表,可以根据以下考量因素来决定:

  1. 数据量和负载:如果数据量巨大且负载压力较大,单一库单一表可能无法满足性能需求,考虑分库分表。
  2. 数据增长:预估数据增长速度和量级,如果数据增长迅速,分库分表可以帮助分散数据,提高系统性能。
  3. 查询需求:如果系统中有不同的业务模块,可以通过分库分表来隔离不同业务的数据,简化查询操作。
  4. 扩展性和容错性:分库分表可以提高系统的扩展性和容错性,减少单点故障的风险。
  5. 数据访问频率:根据数据访问频率的不同,可以将热点数据放在单独的表或库中,提高访问性能。
  6. 维护成本:分库分表增加了系统的复杂度,需要额外的维护成本,需权衡成本和收益。
  7. 业务需求:根据具体业务需求来考虑是否需要分库分表,以提高系统的灵活性和性能。

在考虑是否需要进行分库分表时,需要综合考虑以上因素,并根据实际情况来做出适当的决策,以优化系统性能和提升用户体验。

接下来我就从B+树的角度分析为什么单表2000万要考虑分表?

高手回答

在理论上,只要磁盘空间足够,单表存储数据量可以很大。然而,随着数据量的增加,查询效率可能会下降。根据实际经验,单表可以容纳约2000万数据而不影响查询效率,这个数字看似是一个经验值,但实际上背后有一定的计算逻辑。

首先,需要考虑单表能够容纳多少数据不需要分库分表,这取决于记录大小、存储引擎设置、硬件配置等多种因素。如果我们必须进行数据计算,可以从B+树存储的角度来进行分析。

B+树的高度限制

B+树乃InnoDB存储引擎所用索引之构,众所周知,数据积蓄愈多,B+树之高度则逐渐攀升。若B+树高度过巍,查询时往往须跨越较多层级,致使查询效能逐渐衰退。是以,B+树之高度限制乃单表容量之瓶颈。为维护查询效率,一般主张将B+树高度限制于三至四层之内,以获更敏捷之查询性能。

数据页

众所周知,InnoDB中数据页默认大小为16KB,每个B+树节点对应一个数据页,包括根节点、内部节点和叶子节点。B+树的内部节点映射至数据页,其中存放着主键以及指向子节点(即其他数据页)的指针。而叶子节点则包含实际数据行,每行数据存储于一个数据页中。

大致估算

在此基础上,结合B+树的高度、结构以及数据页大小,我们能够估算单表的数据量。

众所周知,B+树的叶子节点和非叶子节点所存储内容不同,因此需要进行区分计算。

我们能轻而易举得出以下公式:

可存记录数 = 叶子节点数量 * 每个叶子节点可容纳的记录数。

叶子节点数量 = 根节点以下第一级非叶子节点的数量 ^(树高度-1)

最终我们只需计算出非叶子节点的数量、每个叶子节点可容纳的数量以及树的高度即可。

非叶子节点的数量

在一个根节点中,能够扩展多少个子节点呢?

我们已知一个根节点的存储容量为16KB,作为非叶子节点,只需存储一个bigint类型的主键(8字节)和一个默认6字节的指针。因此,可以存储:

16 * 1024 / (8 + 6) ≈ 1170

因此,一个根节点可以扩展出1170个位于第二层的子节点,而对于三层B+树,则会有两层非叶子节点。因此,最终可关联出 1170 * 1170 = 1,368,900 个叶子节点。

叶子节点的存储行数

考虑到一个叶子节点的大小为16KB,其可存储的数据量取决于单行数据的大小。假设每行数据占用1KB,则该叶子节点可以容纳16行数据;如果每行数据量为500字节,那么该叶子节点可以容纳32行数据。

估算结果

根据上述计算方法,假设每条数据的存储空间为1KB,那么在一个3层高的B+树结构中,最终的可存储数据量为:

1170 1170 16 = 21,902,400,即约2000万条数据!

综上所述。你知道你的系统到底需不需要分库分表了吗?

如有问题,微信搜索【码上遇见你】。

相关文章
|
Java 中间件 数据库连接
分库分表的4种方案
分库分表的4种方案
2164 0
|
SQL 关系型数据库 MySQL
将MySQL 数据迁移到 PostgreSQL
将MySQL 数据迁移到 PostgreSQL 可以采用以下步骤: 安装 PostgreSQL 数据库:首先,需要安装 PostgreSQL 数据库。可以从官方网站(https://www.postgresql.org/)下载最新版本的 PostgreSQL,并根据官方指南进行安装。 创建 PostgreSQL 数据库:在 PostgreSQL 中创建与 MySQL 数据库相对应的数据库。可以使用 pgAdmin 或命令行工具(如 psql)来创建数据库。例如,如果在 MySQL 中有一个名为 "mydb" 的数据库,那么可以在 PostgreSQL 中创建一个具有相同名称的数据库。 导
5697 0
|
算法 Unix API
指数退避(Exponential backoff)在网络请求中的应用
## 一、背景 最近做云服务 API 测试项目的过程中,发现某些时候会大批量调用 API,从而导致限流的报错。在遇到这种报错时,传统的重试策略是每隔一段时间重试一次。但由于是固定的时间重试一次,重试时又会有大量的请求在同一时刻涌入,会不断地造成限流。 这让我回想起两年前在查阅[Celery Task 文档](http://docs.celeryproject.org/en/latest
14098 1
|
4月前
|
消息中间件 监控 Kubernetes
别再乱排查了!Kafka 消息积压、重复、丢失,根源基本都是 Rebalance!
大家好,我是小富~分享一次Kafka消息积压排查经历:消费者组因Rebalance导致消费能力骤降。本文详解Rebalance触发场景(消费者变更、分区扩容、订阅变化、超时等),剖析其引发的消息积压、重复消费、丢失等问题根源,并提供优化方案:调优超时参数、手动提交offset、启用粘性分配策略、保障消费幂等性。掌握这些,轻松应对Kafka常见故障!
794 0
|
SQL 运维 NoSQL
【若依RuoYi-Vue | 项目实战】帝可得后台管理系统(一)
在学习完 若依环境搭建 和 若依二次开发案例 后,我们将基于若依脚手架完成一个关于智能货柜的项目实战——帝可得!帝可得是一个基于物联网概念下的智能售货机运营管理系统。本文将带领大家使用若依框架从0到1进行项目开发与测试。
3574 1
【若依RuoYi-Vue | 项目实战】帝可得后台管理系统(一)
|
缓存 监控 算法
小米面试题:多级缓存一致性问题怎么解决
【10月更文挑战第23天】在现代分布式系统中,多级缓存架构因其能够显著提高系统性能和响应速度而被广泛应用。
961 3
|
Java 测试技术 数据库
Spring事务传播机制(最全示例)
在使用Spring框架进行开发时,`service`层的方法通常带有事务。本文详细探讨了Spring事务在多个方法间的传播机制,主要包括7种传播类型:`REQUIRED`、`SUPPORTS`、`MANDATORY`、`REQUIRES_NEW`、`NOT_SUPPORTED`、`NEVER` 和 `NESTED`。通过示例代码和数据库插入测试,逐一展示了每种类型的运作方式。例如,`REQUIRED`表示如果当前存在事务则加入该事务,否则创建新事务;`SUPPORTS`表示如果当前存在事务则加入,否则以非事务方式执行;`MANDATORY`表示必须在现有事务中运行,否则抛出异常;
1499 4
Spring事务传播机制(最全示例)