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

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

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

  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万条数据!

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

责任编辑:武晓燕 来源: 码上遇见你
相关推荐

2021-09-08 22:25:49

手机内存技术

2019-12-06 14:50:49

APP录音隐私

2023-11-07 08:45:25

Go透明文件夹语言

2012-09-21 09:16:48

开源云平台云计算OpenStack C

2015-04-09 13:32:16

编程编程前途

2024-04-25 08:16:06

InnodbReadMVCC

2018-04-14 08:19:43

携号转网运营商网络

2024-05-24 11:54:11

2022-07-11 08:16:47

NewSQL关系数据库系统

2022-07-14 10:00:21

数据价值

2020-07-28 09:04:09

NewSQL分库分表

2020-07-30 17:59:34

分库分表SQL数据库

2023-10-30 09:02:13

前端Rust

2019-11-12 09:54:20

分库分表数据

2024-11-22 15:32:19

2024-07-26 00:16:11

2017-07-20 17:10:38

数据库DB分库sharding

2022-12-27 10:02:38

MVCC机制Innodb

2018-03-14 09:49:35

数据库迁移

2021-08-31 20:21:11

VitessMySQL分库
点赞
收藏

51CTO技术栈公众号