PostgreSQL和MySQL的可扩展性限制

#1 楼

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

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

另一方面，如果您尝试从1TB数据中提取该模式（最常见的值），则无论使用什么系统都没有关系，无论是否使用分片，这都会很痛苦。 （实际上，分片实际上可能会使这个问题变得更糟。）

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

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

第二件事是某些系统（例如Vertica或Greenplum）将信息列存储在一起。从OLTP的角度来看，这使系统更难使用，并降低了那里的性能，但是却大大提高了大型分析工作负载的性能。因此，这是特定于工作负载的折衷。

所以答案是，一旦大小超过1-2 TB，您可能会发现自己在系统和工作负载之间面临许多折衷。同样，这是特定于数据库，工作集的大小等的。但是，在这一点上，您确实必须使用雪花系统，即针对您的工作负载量身定制的雪花系统。

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

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

但是要特别注意基础知识（包括索引，自动清理） ，这些文件如何在较低的级别上工作等等）和足够的计算资源，这些文件是完全可管理的（我估计在Pg的30TB范围内可以很好地管理）。

Edit2：一旦转到100 TB虽然有效，但这取决于您的数据集。我现在正在开发一个不会扩展到该范围的文件，因为它将首先在PostgreSQL中达到每表32TB的限制。