PostgreSQL和MySQL的可伸缩性限制

概述我听说非分片关系数据库(如 MySQL或PostgreSQL)的性能“突破”超过10 TB. 我怀疑这样的限制确实存在,因为人们不会提出Netezza,Greenplum或Vertica等,但是我想问一下这里是否有人参考任何研究论文或正式案例研究,这些限制是量化的. 你的问题没有简单的答案,但这里有几点需要考虑. 首先,规模并不是唯一需要担心的问题.您对数据的处理方式是.如果您有500个表30 T 我听说非分片关系数据库(如 MySQL或Postgresql)的性能“突破”超过10 TB.

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

你的问题没有简单的答案,但这里有几点需要考虑.

首先,规模并不是唯一需要担心的问题.您对数据的处理方式是.如果您有500个表30 TB的数据,并且您使用非常少的报告进行简单的olTP,我认为您不会遇到太多问题. Postgresql上有32TB数据库.但是,与此同时,性能会有所下降,因为它必须在所有内容上打磁盘.类似地,如果你有50TB的数据,但通常命中设置大约100GB,那么你可以构建一个具有足够RAM的服务器,以将数据库中的那部分保留在内存中并且你是金色的.

另一方面,如果您尝试从1TB数据中获取模式(最常见的值),那么您使用的系统无关紧要,无论是否有分片都会很痛苦. (编辑：实际上,Sharding可能会使这个问题变得更糟.)

您将在MysqL和Postgresql上使用大型数据库遇到的主要问题涉及到这两个问题都不支持内部查询并行性.换句话说,查询由单个线程作为单个块运行,并且不能分解为多个块并单独运行.在大量数据上运行大型分析查询时,这通常是一个问题.这是Postgres-XC和Green Plum因为将存储与执行分开而拯救的地方,并且可以在协调员级别执行此 *** 作.请注意,Postgres-XC和Green Plum基本上在内部使用分片,但协调器在全局范围内强制执行所有一致性.

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

第二件事是,一些系统,如Vertica或Greenplum将信息列存储在一起.这使得系统从olTP角度更难以使用并降低了性能,但它大大提高了大型分析工作负载的性能.因此,这是特定于工作负载的权衡.

所以答案是,一旦你的规模超过1-2 TB,你可能会发现自己面临着系统和工作负载之间的一些权衡.同样,这是特定于数据库,工作集的大小等.但是在这一点上,你真的必须使用雪花系统,即独特的雪花系统,并根据您的工作量量身定制.

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

编辑：我现在使用的是一个9TB数据库,它可以处理Postgresql中决策支持和事务处理工作负载的混合.唯一最大的挑战是,如果您遇到大量数据集的问题,则必须等待一段时间才能得到答案.

然而,仔细关注基本原理(包括索引,autovacuum,这些如何在低级别上工作等)和足够的计算资源,这些都是完全可管理的(我估计在Pg的30TB范围内可以很好地管理).

编辑2：一旦你达到100TB虽然有效取决于你的数据集.我正在研究一个不会扩展到这个范围的因为它将首先在Postgresql中达到每个表限制32TB.

总结

以上是内存溢出为你收集整理的PostgreSQL和MySQL的可伸缩性限制全部内容，希望文章能够帮你解决PostgreSQL和MySQL的可伸缩性限制所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。