PostgreSQL和MySQL的可伸缩性限制

Question

我听说非切分关系数据库(如MySQL或PostgreSQL )的性能超出了10 TB。

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

Answer 1

你的问题没有简单的答案，但以下是一些需要考虑的问题。

首先，规模并不是唯一需要担心的问题。你处理你的数据的方法是。如果您有500个表30 TB的数据，并且您正在执行简单的OLTP，并且很少报告，我认为您不会有太多的问题。在PostgreSQL上有32 on数据库。然而，同时，性能会有所下降，因为它必须击中磁盘的一切。类似地，如果您有50 db的if数据，但通常命中的数据集约为100 db，那么您可以构建一个具有足够RAM的服务器，以便将数据库的这一部分保存在内存中，并且您是黄金级的。

另一方面，如果您试图从1TB数据中提取模式(最常见的值)，那么无论您使用的是哪个系统，无论是否切分，这都是痛苦的。(编辑:实际上，切分可能会使这个问题变得更糟。)

在MySQL和PostgreSQL上使用大型数据库会遇到的主要问题是，两者都不支持查询内并行。换句话说，查询是以单个线程作为单个块运行的，它不能被分解成碎片并单独运行。当对大量数据运行大型分析查询时，这通常是一个问题。这就是Postgres和Green Plum来拯救的地方，因为它们将存储与执行分离开来，并且可以在协调器级别完成这一任务。注意，Postgres和Green Plum本质上在内部使用切分，但是协调器在全球范围内强制执行所有一致性。

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

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

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

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

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

然而，如果仔细关注基本原理(包括索引、自动真空、这些索引如何在低级别上工作等)和足够的计算资源，这些都是完全可管理的(我估计，在Pg中，这些资源可以管理到30 to范围内)。

Edit2:一旦您进入100 to，什么工作将取决于您的数据集。我现在正在做一个不能扩展到这个范围的工作，因为它将首先达到PostgreSQL中每个表的32 in的极限。