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

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

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

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

相关文章
|
6月前
|
存储 缓存 负载均衡
数据库分库分表:提升系统性能的必由之路
数据库分库分表:提升系统性能的必由之路
186 1
|
Java 中间件 数据库连接
分库分表的4种方案
分库分表的4种方案
931 0
|
弹性计算 Java 关系型数据库
分库分表比较推荐的方案
ShardingSphere 绝对可以说是当前分库分表的首选!ShardingSphere 的功能完善,除了支持读写分离和分库分表,还提供分布式事务、数据库治理等功能。另外,ShardingSphere 的生态体系完善,社区活跃,文档完善,更新和发布比较频繁
188 0
|
数据库
分库分表是一种数据库优化方式
分库分表是一种数据库优化方式
67 1
|
存储 负载均衡 Java
Java开发中应对海量数据的分库分表方案探究
在实际的Java开发中,当面临海量数据存储和处理的情况时,单一数据库可能无法满足性能和扩展需求。这时,分库分表方案成为一种常用的解决方案。本文将介绍分库分表的基本概念,并探究其在Java开发中的具体应用和实践。
264 0
|
存储 SQL 运维
2、【ShardingSphere】做优化上来就分库分表?请慎重分库分表
读写分离,基本是目前商业开发最可靠的手段了。让我们有了更好的数据查询效率。最大的缺陷在于读写分离会增加MySQL服务器的预算。同时MySQL在高并发的情况下,slave也会有延迟,错误等。
303 0
|
存储 算法 数据库
一次难得的分库分表实践(上)
一次难得的分库分表实践
|
SQL 存储 缓存
扛不住了,老大让我感觉上分库分表方案
扛不住了,老大让我感觉上分库分表方案
扛不住了,老大让我感觉上分库分表方案
|
SQL 调度 数据库
也谈分库分表在实际应用的实践(下)
也谈分库分表在实际应用的实践(下)
229 0
也谈分库分表在实际应用的实践(下)
|
消息中间件 中间件 数据库
也谈分库分表在实际应用的实践(上)
也谈分库分表在实际应用的实践(上)
148 0
也谈分库分表在实际应用的实践(上)
下一篇
无影云桌面