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

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 是否需要分库分表取决于数据量、负载、增长速度、查询需求、扩展性、容错性和维护成本。当单表数据量接近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万条数据!

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

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

相关文章
|
5月前
|
存储 缓存 负载均衡
数据库分库分表:提升系统性能的必由之路
数据库分库分表:提升系统性能的必由之路
179 1
|
Java 中间件 数据库连接
分库分表的4种方案
分库分表的4种方案
825 0
|
弹性计算 Java 关系型数据库
分库分表比较推荐的方案
ShardingSphere 绝对可以说是当前分库分表的首选!ShardingSphere 的功能完善,除了支持读写分离和分库分表,还提供分布式事务、数据库治理等功能。另外,ShardingSphere 的生态体系完善,社区活跃,文档完善,更新和发布比较频繁
177 0
|
6月前
|
关系型数据库 MySQL 数据处理
分库分表知识总结(一)之解决问题
分库分表知识总结(一)之解决问题
64 1
|
11月前
|
数据库
分库分表是一种数据库优化方式
分库分表是一种数据库优化方式
66 1
|
存储 算法 数据库
一次难得的分库分表实践(上)
一次难得的分库分表实践
|
SQL 存储 缓存
扛不住了,老大让我感觉上分库分表方案
扛不住了,老大让我感觉上分库分表方案
扛不住了,老大让我感觉上分库分表方案
|
消息中间件 中间件 数据库
也谈分库分表在实际应用的实践(上)
也谈分库分表在实际应用的实践(上)
142 0
也谈分库分表在实际应用的实践(上)
|
SQL 调度 数据库
也谈分库分表在实际应用的实践(下)
也谈分库分表在实际应用的实践(下)
224 0
也谈分库分表在实际应用的实践(下)
|
消息中间件 缓存 运维
架构方案设计系列:数据库缓存数据一致性方案
在我们的实际项目中,在一些QPS比较高的场景下,经常引入缓存来缓解数据库的查询压力,以缓存的空间来换取查询效率的提升。但是一旦引入了缓存,就一定会遇到缓存中的数据与数据库中的数据如何保持一致的问题,本文就是针对两者之间的数据一致性问题进行分析,一步一步分析以及解决。
架构方案设计系列:数据库缓存数据一致性方案

热门文章

最新文章

  • 1
    非阻塞 I/O:异步编程提升 Python 应用速度
    10
  • 2
    2024 Mysql基础与进阶操作系列之MySQL触发器详解(20)作者——LJS[你个小黑子这都还学不会嘛?你是真爱粉嘛?真是的 ~;以后请别侮辱我家鸽鸽]
    5
  • 3
    2024 RedisAnd Mysql基础与进阶操作系列(16-1)作者——LJS[你个小黑子这都还学不会嘛?你是真爱粉嘛?真是的 ~;以后请别侮辱我家鸽鸽]
    4
  • 4
    2024Mysql And Redis基础与进阶操作系列(13)作者——LJS[你个小黑子这都还学不会嘛?你是真爱粉嘛?真是的 ~;以后请别侮辱我家鸽鸽]
    7
  • 5
    2024Mysql And Redis基础与进阶操作系列(10)作者——LJS[你个IKUN还学不会嘛?你是真爱粉嘛?真是的 ~;以后别侮辱我家鸽鸽]
    6
  • 6
    2024 RedisAnd Mysql基础与进阶操作系列(15)作者——LJS[你个小黑子这都还学不会嘛?你是真爱粉嘛?真是的 ~;以后请别侮辱我家鸽鸽]
    5
  • 7
    2024Mysql And Redis基础与进阶操作系列(9)作者——LJS[含MySQL存储过程之局部、系统变量、参数传递、流程控制-判断/case具体详步骤;注意点及常见报错问题所对应的解决方法]
    8
  • 8
    2024 Mysql基础与进阶操作系列之MySQL触发器详解(21)作者——LJS[你个小黑子这都还学不会嘛?你是真爱粉嘛?真是的 ~;以后请别侮辱我家鸽鸽]
    8
  • 9
    2024 RedisAnd Mysql基础与进阶操作系列(19)作者——LJS[你个小黑子这都还学不会嘛?你是真爱粉嘛?真是的 ~;以后请别侮辱我家鸽鸽]
    7
  • 10
    2024 RedisAnd Mysql基础与进阶操作系列(18)作者——LJS[你个小黑子这都还学不会嘛?你是真爱粉嘛?真是的 ~;以后请别侮辱我家鸽鸽]
    5