PostgreSQL 和 MySQL 的可扩展性限制

Question

我听说非分片关系数据库（如 MySQL 或 PostgreSQL）的性能“突破”超过 10 TB。

我怀疑这样的限制确实存在，因为人们不会想出 Netezza、Greenplum 或 Vertica 等，但是我想问这里是否有人参考了任何研究论文或正式案例研究，其中量化了这些限制。

Answer 1

你的问题没有简单的答案，但这里有一些事情需要考虑。

首先，规模并不是唯一需要担心的事情。你用你的数据做什么。如果您有 500 个表 30 TB 的数据，并且您正在做简单的 OLTP 并且报告很少，我认为您不会有太多问题。PostgreSQL 上有 32TB 的数据库。然而，与此同时，性能会有所下降，因为它必须在所有东西上都打磁盘。类似地，如果您有 50TB 的数据，但通常的命中集约为 100GB，那么您可以构建一个具有足够 RAM 的服务器以将数据库的那部分保留在内存中，这样您就很成功了。

另一方面，如果您试图从 1TB 数据中取出模式（最常见的值），则无论您使用什么系统，无论是否进行分片，这都将是痛苦的。（编辑：实际上，分片可能会使这个问题变得更糟。）

您将在 MySQL 和 PostgreSQL 上遇到巨大数据库的主要问题涉及都不支持查询内并行性的事实。换句话说，一个查询是由单个线程作为单个块运行的，它不能分解成多个部分并单独运行。在对大量数据运行大型分析查询时，这通常是一个问题。这就是 Postgres-XC 和 Green Plum 派上用场的地方，因为它们将存储与执行分开，并且可以在协调器级别执行此操作。请注意，Postgres-XC 和 Green Plum 本质上在内部使用分片，但协调器在全局范围内强制执行所有一致性。

使用查询内并行性，您可以分解查询，让不同的处理器/磁​​盘 I/O 通道运行它的一部分，并报告返回的结果集片段以进行组装并传递回应用程序。同样，这通常对分析负载而不是事务处理负载最有帮助。

第二件事是某些系统，如 Vertica 或 Greenplum，将信息列存储在一起。从 OLTP 的角度来看，这使得系统更难使用并降低了那里的性能，但它大大提高了大型分析工作负载的性能。所以这是一个特定于工作负载的权衡。

所以答案是，一旦您的大小超过 1-2 TB，您可能会发现自己面临着系统和工作负载之间的许多权衡。同样，这特定于数据库、工作集的大小等。然而，此时您真的必须使用雪花系统，即独特的并为您的工作负载量身定制的系统。

这当然意味着限制通常是不可量化的。

编辑：我现在使用了一个 9TB 的数据库，该数据库在 PostgreSQL 中处理决策支持和事务处理工作负载的混合。最大的挑战是，如果您的问题涉及数据集的大部分，您将不得不等待一段时间才能得到答案。

然而，通过仔细关注基本原理（包括索引、自动清理、它们如何在低级别上工作等）和足够的计算资源，这些是完全可以管理的（我估计在 Pg 中可以很好地管理到 30TB 范围内）。

Edit2：一旦您达到 100TB，尽管有效将取决于您的数据集。我现在正在研究一个不会扩展到这个范围的，因为它首先会达到 PostgreSQL 中每表 32TB 的限制。