一尘不染

Postgres 9.1与Mysql 5.6 InnoDB?

mysql

一个简单的问题-2012年对于要求与ACID兼容的中型/大型数据库,哪个会更好?

我已经阅读了所有有关MySQL和pgSQL的文章(大部分),但其中大多数文章分别与版本4,5.1和7,8有关,并且过时(2008、2009)。现在已经快到2012年了,所以我想我们可以尝试重新审视这个问题。

基本上,我想知道PostgreSQL中是否有任何东西超过了MySQL的易用性,可用性和更大的开发人员/知识基础。

MySQL的查询优化器仍然很愚蠢吗?在非常复杂的查询上它仍然超级慢吗?

打我!:)

PS。而且不要将我发送到Google或Wiki。我正在寻找一些特定的要点而不是概述+我更信任StackOverflow,而不是一些随机页面,其中“聪明的家伙”光芒四射。

附录

项目规模 :假设一个订购系统每个帐户每天大约有10-100个订单/天,几千个帐户,最终每个帐户可以有数百到数千个用户。

擅长 :适应不断增长的需求和不断变化的需求时,要具有面向未来的灵活性。性能对于降低硬件部门的成本也很重要。熟练劳动力的可用性也是一个因素。

OLTP或OLAP :OLTP


阅读 310

收藏
2020-05-17

共1个答案

一尘不染

MySQL的查询优化器仍然很愚蠢吗?在非常复杂的查询上它仍然超级慢吗?

所有
查询优化器有时都是愚蠢的。在大多数情况下,PostgreSQL并不那么愚蠢。PostgreSQL的一些最新SQL功能(窗口函数,带有查询的递归等)非常强大,但是如果您使用的是愚蠢的ORM,则可能无法使用。

项目规模:假设一个订购系统每天每个帐户大约10-100个订单,成千上万个帐户,最终每个用户可以拥有数百到数千个用户。

听起来不那么大-完全在一个大盒子里。

擅长:适应不断增长的需求和不断变化的需求,它具有面向未来的灵活性。

PostgreSQL拥有强大的开发团队,并拥有广泛的贡献者社区。发行政策是严格的,仅在关键发行版本中有错误修正。始终跟踪9.1.x的最新版本以获取错误修复。

过去,MySQL对版本号的态度较为宽松。甲骨文负责可能会改变这种情况。我对各种分叉的政策不熟悉。

性能对于降低硬件部门的成本也很重要。

如果硬件竟然是这个规模的项目中的主要组件,我会感到惊讶。

熟练劳动力的可用性也是一个因素。

那是您的关键决定者。如果您有一群经验丰富的Perl + PostgreSQL黑客闲着闲逛,请使用它。如果您的员工知道Lisp和MySQL,请使用它。

OLTP或OLAP:OLTP

PostgreSQL在OLTP上一直很强大。

我个人的观点是PostgreSQL邮件列表中充满礼貌,乐于助人,知识渊博的人。您可以直接与拥有Terabyte数据库的用户和建立代码主要部分的黑客联系。支持的质量确实非常出色。

2020-05-17