MySQL vs PostgreSQL

我相反，还是支持postgresSql，尤其是linux下，window下的8.0刚刚出来，可能要稍微等一段时间才能下定论。

以前不用mysql的原因有几个：

1、没事务
2、没子查询
3、国际化支持不好
4、varchar只能255
5、文件管理太简陋

现在5不知道改进了多少呢？反正在postgreSqL7.3中，这几个问题都不存在，都是很好的解决了，我们又是linux服务器，所以没有什么好说的，绝对是postgreSqL。“高级复制，是否支持集群，是否具备联机备份和恢复”这些高级功能正如无明说的，以性能为代价。mysql把这些功能都实现了，它以前被人最称道的速度优势，还存在么？再说了，postgreSQL从7就支持事务了，一直到8，经历几个版本，都在不断优化中，现在已经很成熟了，难道mysql能够一步到位？比postgreSql好？恐怕还要假以时日了。

另外，热备份和恢复的功能，在postgreSqL8中应该已经实现了，可以去看看它的what's new中的Point-In-Time Recovery，如果我没理解错，应该就是了。postgreSQL也不是吃素的，相信下个大版本，集群功能会加上的，那么我觉得它就是个perfect的数据库了。（什么？要收费了？被收购了？转商业软件了？噢～～～，my god）

MySQL 3.X的时代InnoDB就是支持数据库事务的，这已经是年代很久远的事情了；
国际化支持不好，不知道你从何说起；
子查询现在早已支持；
文件管理并不简陋，相反很强大（去看InnoDB文档）
大文本字段你难道不用text？



请看我最前面帖子设定的评价标准，我什么时候把速度放进我的评价标准了？

MySQL InnoDB在开源数据库中在我提到的综合评价标准来说，是最符合的，而PostgreSQL则不及格。

BTW：Yahoo的服务器数据库全部都是用MySQL InnoDB。

robbin，其实我认为 PostgreSQL 和 MySQL 的前途都是非常光明的，因为我对开源软件的进化速度有信心。PostgreSQL 和 MySQL 作为两种最受人关注的开源数据库，目前都进入了良性发展的阶段。

PostgreSQL 相比 MySQL 来说确实是在开发方面的优势更大些，主要的优势你都知道（当然，也要看这些功能你是否需要。比如，假设你一行存储过程都不想写，并且认为存储过程是邪恶的东西。即使不想写存储过程，触发器仍然是非常有用的东西，可以省很多事）。在开源数据库中，PostgreSQL 的高可用性不像你现在了解的那么差，可能还是因为你对于这种数据库的了解不是非常多。国外有很多为 PostgreSQL 提供高可用性服务的公司，日本用 PostgreSQL 的公司也非常多，富士通给 PostgreSQL 提供了大量的投资。

这里不是讨论 PostgreSQL 的专业地方，在国内至少应该到
http://www.pgsqldb.org
去讨论。站长何伟平自己开了一家提供 PostgreSQL 企业级服务的公司。
http://www.toping.com.cn
但是站长不知道因为什么原因，把论坛的搜索功能关闭了，让人感觉太小气了一些。另外，ChinaUnix 的 PostgreSQL 版也是一个讨论的好地方。

在这个页面上，有一些介绍 PostgreSQL 高可用性的项目。
http://my.so-net.net.tw/seiliki/pgsql-advocacy2.html
我以前在公司主要使用 Oracle/Sybase，对于 PostgreSQL 的高可用性研究不多，将来有时间了可以对这些项目做一些评估。

我的意见是你对那种数据库最熟悉，就坚持使用下去，直到有一天你发现这种数据库完全无法解决你要解决的某个特定问题。现在 MySQL 究竟是哪些方面的问题不能解决？针对这个特定的问题（例如：吞吐量、并发连接）找到一种更好的解决方案。这种解决方案可能是 PostgreSQL，可能是 Ingres、也有可能是 Sybase 的那个免费版本。

MySQL和PostgreSQL我都用了好多年了，这两个我都很熟悉。熟悉归熟悉，但不是我选择数据库的标准，我选择数据库的标准是看能否满足我需要的功能，能否符合我的评价标准！

MySQL5现在也具备视图存储过程触发器功能（MySQL5 InnoDB甚至开始支持分布式事务），单纯从数据库开发方面的功能来说，MySQL只比PostgreSQL多，而不会少。

现在MySQL解决不了的问题，其他开源数据库一样解决不了，只能寻求高端商业数据库。更何况选择一种数据库作为你的业务支撑系统来运行，也绝对不是什么到时候想换就可以换的。

robbin，你还是需要再把你的评价标准详细说一下，或者给个链接，才可能继续讨论下去的。

目标是选择支撑J2EE应用的关系数据库，要求比较好的负载能力，比较全的数据库标准支持，比较好的数据库管理工具和高级特性。

关于MySQL数据库，很多人的认识有个误区：

认为MySQL速度快只不过是因为不支持事务，所以才快；如果MySQL也带事务的话，肯定会慢很多


这里有一个MySQL和PostgreSQL对比的benchmark：

http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres

我对这个benchmark的对比本身根本不感兴趣，因为这只是一个单进程的测试，而我关心的是高并发高负载情况下的数据库表现出来的性能和负载能力。但是一个非常有趣的结果是，可以对比一下MyISAM和InnoDB的表现。

我们知道一个业务系统对数据库发送的SQL中超过90%都是select语句，而update，insert和delet总共只占不到10%，因此数据库系统的性能主要取决了select的性能。

而我们看看那个测试结果select查询下MyISAM和InnoDB的表现，就会发现InnoDB的速度并不比MyISAM慢！这也证明了当MySQL使用事务的情况下，查询速度根本没有任何损失（CPU负载会高一些），从而破除了第一个误解。

事实上，由于InnoDB是row level lock，在高并发环境下，带事务支持的MySQL查询速度反而要比不带事务的MySQL查询速度快很多，嘿嘿，这恐怕是大家意想不到的吧。

事实上MySQL InnoDB在负载能力和查询速度上都是非常不错的（这恐怕也是Yahoo用MySQL InnoDB而不用PostgreSQL的原因），

http://www.innodb.com/bench.php

至于这个上面带上负载能力的测试也表明了这一点。

这个是eweek的测试报告：

http://www.eweek.com/article2/0,4149,293,00.asp

中文翻译：

http://www.freelamp.com/1015136602/index_html

InnoDB的介绍：

http://www.freelamp.com/1015398272/index_html
http://www.freelamp.com/1015470737/index_html

是的，我也觉得并发的 select 才是最重要的，而并发的 insert/update/delete 相对来说是比较少的。比如这个论坛，潜水员那么多，这些人成天看贴不回贴（没天良啊），同时打开多个页面，经常 refresh，这些其实全部都是 select 操作。针对 select 提供最佳的性能才是我们最应该关心的。

由此我想到，由于 OLAP 操作几乎全部都是 select，对于事务的要求非常少，因此可能 MySQL 比 PostgreSQL 更适合这类分析型的应用。

提高数据库的性能，除了对数据库本身调优以外，用好的方法开发应用才是最重要的。这里子查询是一个非常关键的特性，很多时候可以取代没有必要的表连接。

由 robbin 的介绍知道，MySQL 今年的进步确实是非常大的，提供视图/存储过程/触发器可以说迈上了一个新的高度。一个新的企业级数据库已经隐然出现。以前选择 PostgreSQL 主要还是因为 MySQL 的功能太简单，感觉不够专业。不过现在 MySQL 已经不是昔日吴下的阿蒙了。Yahoo 选择的 PHP 和 MySQL，给了这些开源技术极大的支持。其实做网站，LAMP 确实也是一种不错的选择。

和你说的恰巧相反，事实上MySQL InnoDB更适合OLTP，PostgreSQL更适合OLAP。

InnoDB在很多方面有点类似Oracle，例如InnoDB数据库文件的管理方式，InnoDB的内存管理，日志机制，锁定机制和读一致性等等都和Oracle非常相似，这也是我为什么在上一个帖子说InnoDB终于让我找到了一点Oracle感觉的原因。

MySQL和PostgreSQL相比较来说，MySQL的优点在于多线程实现机制带来的高性能和高负载能力，PostgreSQL的优点在于数据库标准支持更加完善。

在OLTP型应用中，主要是大量密集的并发访问请求，但是每个请求的SQL不会特别复杂，执行简单的SQL返回结果就结束了，因此OLTP要求数据库必须具备非常好的并发负载能力和足够快的查询响应性能。处理请求的数据库进程(或线程)应该占用尽量少的内存，尽量少的资源消耗，而数据库服务器必须能够负载尽量多的数据库进程(或线程)。因此OLTP适合采用线程模型。

在OLAP型应用中，则很少有并发的请求，主要是少量的长期连接，这些连接必须具备足够的内存来缓存复杂查询的中间结果，要求数据库具备更好的数据处理和分析功能，而对并发性能，查询响应速度并不敏感，因此OLAP适合采用进程模型。

事实上Oracle数据库的数据库实例可以同时提供两种不同的数据处理模型：即多线程数据库模型（MTS）和专用数据库模型（Dedicate）。Dedicate模型下每个数据库连接启动一个Oracle进程，占用较多的内存，执行一个长久连接，进行复杂的数据分析操作；MTS模型下，Oracle会专门启动两个用来处理线程调度的进程，一个称为Shadow进程，一个称为Dispatcher进程，每个数据库连接不会单独启动一个Oracle进程，而是这两个进程启动内部的线程来处理。

Dedicate下数据库进程内存充足，资源消耗多，可以长期运行执行复杂的运算，但是每个进程的创建，以及进程消耗的资源都是非常客观的；
MTS下数据库线程消耗资源非常少，数据库服务器能够负载远远超过dedicate下的连接请求数量。

MySQL和PostgreSQL的情况就很类似Oracle两种不同的运行方式：MySQL是多线程模型，类似Oracle的MTS，每个数据库线程消耗很少的资源，数据库服务器能够负载很多的并发连接线程；而PostgreSQL类似Oracle的Dedicate，每个数据库进程消耗比较多的资源，负载能力比较差，但是复杂查询的执行效果更好。

特别值得一提的是，在以前的Linux操作系统下，传统的多线程程序并不能够表现出比多进程程序优越得多的性能。这是因为Linux操作系统不支持内核级多线程，只支持用户级多线程，在Linux的内核中用轻量级进程来模拟线程，映射到用户级线程上。

但是Linux Kernel 2.6引入的NPTL改变了这一状况（事实上我把NPTL看成Linux在服务器操作系统领域的一次里程碑式的进步）。NPTL使得内核支持多线程，极大的提高了多线程程序的性能。关于NPTL给多线程程序带来的巨大的性能提升，我这里就有一个活生生的例子，请看：

http://forum.iteye.com/viewtopic.php?t=5322

操作系统Kernel从2.4升级到2.6以后（主要是增加了NPTL），Java应用服务器的网络处理性能提升了5倍之多！ （网络处理性能代表了高并发情况下的负载能力和响应能力）

我虽然没有对MySQL做过同样的测试，但是可以想像得到，在Linux Kernel2.6下面，MySQL的多线程性能的提升也肯定非常可观。因此在Kernel2.6下面，多线程的程序和多进程程序的负载能力和响应能力的差距恐怕就更加大了。