大表的数据库设计

Question

我正在处理一个 200GB 以上的大表，大约有 10 亿行。

我正在考虑将表拆分为较小的表，然后在查询时加入结果。

我们主要是在那张桌子上阅读，偶尔写作。

这是个好主意吗？或者，这是我不需要担心的事情吗？

我的数据库服务器有 4CPU 和 32GB RAM。

我有主键作为索引以节省空间。目前，没有问题。但是，我只是在考虑是早点拆分还是保持这种方式。拆分为较小的表，例如每个 2.5 亿行而不是普通的 10 亿行表，有什么优点和缺点？你认为我的 32GB RAM 能够处理它吗？

Answer 1

有几种模式可用于在多个物理表中拆分单个逻辑实体。

垂直分区将一些列放在一个表中，将一些列放在另一个表中。如果需要，可以有多个这样的附加表。所有这些表共享相同的主键。一起使用的列存储在一起，因此一页读取读取所有必需的值。优点是每页有更多行，因此扫描和聚合需要更少的 IO。有时决定哪些列应该放在一起可能很棘手。随着分区数量的增加，每个 INSERT 都会成比例地变得更加昂贵。

水平分区按键范围分割数据。例如，姓氏以 A 到 M 开头的所有用户进入表 User_1，N 到 Z 进入 User_2。应用程序确定在运行时使用哪个子表，通常是通过算法或通过查找，尽管现在大多数 DBMS 将其作为内置功能提供，通过 DDL 实现，对应用程序透明。如果您在数据写入中有热点，这可以分散痛苦。优化器可以从范围扫描中消除整个分区，从而提高响应时间。加载和删除整个分区可能是非常快速的元数据操作。

分片是键范围被移动的地方，不仅仅是移动到不同的表，而是移动到 DBMS 的一个完全不同的实例。应用程序决定连接到哪个实例，具体取决于键范围。这是一种横向扩展技术。一些 DBMS 支持将此作为一项功能，例如用于 MariaDB 的 Galera。显而易见的成本是运行其他实例的额外硬件，跨所有节点复制参考数据以维持 RI 和应用程序复杂性。

当然，这些技术可以组合使用，因此可以对表进行水平和垂直分区。

拆分的一般优点：

• 索引可能会变浅，从而节省索引查找的成本。
• 每个分区可以写入单独的磁盘，分散 IO 负载。

缺点包括：

• 应用复杂度
• 确保数据完整性将更加困难
• 升级变得更加棘手。
• 清除数据越来越难以正确处理。

基本上，如果您没有问题，并且没有看到有人来，请不要打扰。使用 DBMS 功能的水平分区是唯一值得考虑作为先发制人措施的方法。即便如此，它也需要重新写入 200GB。你有磁盘和服务窗口来完成这个吗？