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

2024年 3月 20日 116.0k 0

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

  • 数据量和负载:如果数据量巨大且负载压力较大,单一库单一表可能无法满足性能需求,考虑分库分表。
  • 数据增长:预估数据增长速度和量级,如果数据增长迅速,分库分表可以帮助分散数据,提高系统性能。
  • 查询需求:如果系统中有不同的业务模块,可以通过分库分表来隔离不同业务的数据,简化查询操作。
  • 扩展性和容错性:分库分表可以提高系统的扩展性和容错性,减少单点故障的风险。
  • 数据访问频率:根据数据访问频率的不同,可以将热点数据放在单独的表或库中,提高访问性能。
  • 维护成本:分库分表增加了系统的复杂度,需要额外的维护成本,需权衡成本和收益。
  • 业务需求:根据具体业务需求来考虑是否需要分库分表,以提高系统的灵活性和性能。
  • 在考虑是否需要进行分库分表时,需要综合考虑以上因素,并根据实际情况来做出适当的决策,以优化系统性能和提升用户体验。

    接下来我就从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万条数据!

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

    相关文章

    Oracle如何使用授予和撤销权限的语法和示例
    Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
    下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
    社区版oceanbase安装
    Oracle 导出CSV工具-sqluldr2
    ETL数据集成丨快速将MySQL数据迁移至Doris数据库

    发布评论