MySQL vs PostgreSQL
2006-08-17 17:17
459 查看
作者 正文
andyyehoo
SunOne Server
性别:
年龄:26
十二宫图:
加入时间: 2003/12/26
文章: 141
来自: 广州
我相反，还是支持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）
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-14 20:31:29 标题:
--------------------------------------------------------------------------------
MySQL 3.X的时代InnoDB就是支持数据库事务的，这已经是年代很久远的事情了；
国际化支持不好，不知道你从何说起；
子查询现在早已支持；
文件管理并不简陋，相反很强大（去看InnoDB文档）
大文本字段你难道不用text？
引用:
“高级复制，是否支持集群，是否具备联机备份和恢复”这些高级功能正如无明说的，以性能为代价。mysql把这些功能都实现了，它以前被人最称道的速度优势，还存在么？
请看我最前面帖子设定的评价标准，我什么时候把速度放进我的评价标准了？
MySQL InnoDB在开源数据库中在我提到的综合评价标准来说，是最符合的，而PostgreSQL则不及格。
BTW：Yahoo的服务器数据库全部都是用MySQL InnoDB。
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-14 21:30:13 标题:
--------------------------------------------------------------------------------
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 的那个免费版本。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-14 22:48:40 标题:
--------------------------------------------------------------------------------
引用:
我的意见是你对那种数据库最熟悉，就坚持使用下去，直到有一天你发现这种数据库完全无法解决你要解决的某个特定问题。现在 MySQL 究竟是哪些方面的问题不能解决？针对这个特定的问题（例如：吞吐量、并发连接）找到一种更好的解决方案。这种解决方案可能是 PostgreSQL，可能是 Ingres、也有可能是 Sybase 的那个免费版本
MySQL和PostgreSQL我都用了好多年了，这两个我都很熟悉。熟悉归熟悉，但不是我选择数据库的标准，我选择数据库的标准是看能否满足我需要的功能，能否符合我的评价标准！
MySQL5现在也具备视图存储过程触发器功能（MySQL5 InnoDB甚至开始支持分布式事务），单纯从数据库开发方面的功能来说，MySQL只比PostgreSQL多，而不会少。
现在MySQL解决不了的问题，其他开源数据库一样解决不了，只能寻求高端商业数据库。更何况选择一种数据库作为你的业务支撑系统来运行，也绝对不是什么到时候想换就可以换的。
上一次由robbin于2005-5-14 周六, 下午10:55修改，总共修改了2次
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-14 23:10:21 标题:
--------------------------------------------------------------------------------
robbin，你还是需要再把你的评价标准详细说一下，或者给个链接，才可能继续讨论下去的。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 00:16:12
4000
标题:
--------------------------------------------------------------------------------
dlee 写道:
robbin，你还是需要再把你的评价标准详细说一下，或者给个链接，才可能继续讨论下去的。
目标是选择支撑J2EE应用的关系数据库，要求比较好的负载能力，比较全的数据库标准支持，比较好的数据库管理工具和高级特性。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 00:27:34 标题:
--------------------------------------------------------------------------------
关于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
至于这个上面带上负载能力的测试也表明了这一点。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 01:01:09 标题:
--------------------------------------------------------------------------------
这个是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
引用:
InnoDB 是 MySQL 上第一个提供外键约束的引擎，除了提供事务处理外，InnoDB 还支持行锁，提供和 Oracle 一样的一致性的不加锁读取，能增加并发读的用户数量并提高性能，不会增加锁的数量。
InnoDB 的设计目标是处理大容量数据时最大化性能，它的 CPU 利用率是其他所有基于磁盘的关系数据库引擎中最有效率的。
InnoDB 的一些物理设计仿照了 Oracle ，因此，能够获得和 Oracle 可以类比的性能
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-15 09:55:20 标题:
--------------------------------------------------------------------------------
是的，我也觉得并发的 select 才是最重要的，而并发的 insert/update/delete 相对来说是比较少的。比如这个论坛，潜水员那么多，这些人成天看贴不回贴（没天良啊），同时打开多个页面，经常 refresh，这些其实全部都是 select 操作。针对 select 提供最佳的性能才是我们最应该关心的。
由此我想到，由于 OLAP 操作几乎全部都是 select，对于事务的要求非常少，因此可能 MySQL 比 PostgreSQL 更适合这类分析型的应用。
提高数据库的性能，除了对数据库本身调优以外，用好的方法开发应用才是最重要的。这里子查询是一个非常关键的特性，很多时候可以取代没有必要的表连接。
由 robbin 的介绍知道，MySQL 今年的进步确实是非常大的，提供视图/存储过程/触发器可以说迈上了一个新的高度。一个新的企业级数据库已经隐然出现。以前选择 PostgreSQL 主要还是因为 MySQL 的功能太简单，感觉不够专业。不过现在 MySQL 已经不是昔日吴下的阿蒙了。Yahoo 选择的 PHP 和 MySQL，给了这些开源技术极大的支持。其实做网站，LAMP 确实也是一种不错的选择。
返回顶端
robbin
论坛管理员
性别:
年龄:30
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 10:42:49 标题:
--------------------------------------------------------------------------------
和你说的恰巧相反，事实上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.javaeye.com/viewtopic.php?t=5322
操作系统Kernel从2.4升级到2.6以后（主要是增加了NPTL），Java应用服务器的网络处理性能提升了5倍之多！ （网络处理性能代表了高并发情况下的负载能力和响应能力）
我虽然没有对MySQL做过同样的测试，但是可以想像得到，在Linux Kernel2.6下面，MySQL的多线程性能的提升也肯定非常可观。因此在Kernel2.6下面，多线程的程序和多进程程序的负载能力和响应能力的差距恐怕就更加大了。
返回顶端
buaawhl
Java Virtual Machine
性别:
年龄:29
十二宫图:
加入时间: 2004/07/07
文章: 787
时间: 2005-5-15 13:21:05 标题:
--------------------------------------------------------------------------------
我对 Open Source License 理解不深。以前在自己做试验的一些小东西中，都使用MySQL数据库。
后来，一个技术上经常交流的同事告诉我说，MySQL DB 和 MySQL JDBC Lib 都是 GPL的。这意味着使用它，就要开源，或者付费获得Commercial License。PostgreSQL是BSD的，最自由，限制最少。
为了保险起见，我就转向了PostgreSQL，并开始关注论坛上关于Open Source License的讨论。并决定，自己发布的Small Open Source things 都要是BSD。
返回顶端
chikaiwang
Caucho Resin
性别:
年龄:27
十二宫图:
加入时间: 2004/09/26
文章: 16
时间: 2005-5-15 14:36:02 标题:
--------------------------------------------------------------------------------
Use it like this if you want to move your database to an Oracle:
>mysqldump -u root --password="root" --compatible=oracle ejbtest > ejbtest.sql.oracle
我太爱Ｍｙｓｑｌ了，现在可以不用ｐｏｗｅｒｄｅｓｉｇｎ来转换符合某一特定数据库的ｄｄｌ。
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-15 21:36:13 标题:
--------------------------------------------------------------------------------
robbin，你啊，总是喜欢不把别人的话完全看清楚。我也没有说过 MySQL 不适合 OLTP 啊，呵呵。甚至没有误导群众的任何动机。
这里有一个最新的测试数据：
http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres
我们假设这里的数据是真实的，作者是有良心的，没有任何偏向。我们来做一个分析：
对于 insert 操作，MySQL MyISAM 性能最好，而 MySQL InnoDB 性能最差，PostgreSQL 打开 fsync 和关闭 fsync 的性能处于 MySQL 两种 table 类型之间。
对于 select 操作，MySQL InnoDB 性能最好，MySQL 的两种 table 类型的性能都要比 PostgreSQL 打开或者关闭 fsync 的性能要好。
加上 order by 以后，MySQL 两种 table 类型做 select 的性能仍然比 PostgreSQL 要好。
对于 delete 操作，MySQL MyISAM 性能最好，MySQL InnoDB 性能最差。
这个测试是非常简单的。从某个侧面证实了 MySQL 的 select 操作的性能确实要比 PostgreSQL 好的多，因此 MySQL 非常适合做 OLAP 一类的应用。而使用 InnoDB 的 MySQL 在 insert 和 delete 时的性能优势并没有充分体现出来。
这个测试其实是非常简单的。robbin 我们有空了可以使用 MySQL 5.0 和 PostgreSQL 8.01 再测试一下。在测试之前别忘记对于 MySQL 和 PostgreSQL 都做一些调优。
这里还有一篇很老的文章，里面说了什么时候应该选择 PostgreSQL，这些建议在当时（2002 年）都是非常正确的，对于今天的情况我来逐一做个评价：
http://builder.com.com/5100-6388-1050671.html
Complex database design
有多复杂？MySQL 5.0 推出以后，也可以支持相当复杂的数据库设计了。
Moving away from Oracle, Sybase, or MSSQL
这是因为 MySQL 5.0 正式版本（不要推荐我们在企业应用中使用 alpha 版或者 beta 版）还没有推出，一般用户还无法使用视图/存储过程/触发器。我的亲身经历可以证明，由于 PostgreSQL 存储过程的 PL/pgSQL 语言与 Oracle 的 PLSQL 的语法非常接近，因此将 Oracle 的存储过程或触发器移植到 PostgreSQL 上面是非常容易的事情。而且 PostgreSQL 和 Oracle 一样都是基于对象的数据库，其文档中对于一些概念的描述非常相似。所以熟悉 Oracle 的开发人员转向 PostgreSQL 是非常容易的。
Complex rule sets (i.e., business rules)
PostgreSQL 可以定义非常复杂的 SQL 重写规则，但是我们一般不常使用这个功能。
Use of procedural languages on the server Transactions
PostgreSQL 支持用多种语言开发存储过程，包括 PL/pgSQL, PL/Tcl, PL/Perl, PL/Python, PL/PHP, PL/Java 等等，这极大地方便了不同语言的开发人员。
Use of stored procedures
存储过程 MySQL 5.0 马上就会提供，我们期待着它能给我们带来惊喜。
Use of geographical data
地理数据我们几乎从来不会用到。
R-Trees (i.e., used on indexes)
R-Tree 有什么意义？哪位科班出身的网友帮我解释一下。
这篇文章虽然很老，但是其中提出的选择方法还是有指导意义的。作者认为在性能非常重要的场合，应该选择 MySQL。但是选择 PostgreSQL 这些考虑因素，将随着 MySQL 5.0 的推出，提供大量新的企业级特性后不再那么重要。其实我觉得大部分场合下，性能往往才是第一考虑的因素。性能只是一个方面，高可用性也是非常重要的方面。在这方面 MySQL 现在走在了 PostgreSQL 的前面。
说到这里我又要开始捣浆糊了，robbin 一定会皱眉头的。其实 MySQL 和 PostgreSQL 都是非常优秀的开源软件，我们都应该支持，都有必要去深入研究。正是因为这两大对手多年来的竞争和对决，我们才有了今天的方便。
另外关于 buaawhl 所说的 License 问题，这个问题确实是一些大公司（例如富士通）选择 PostgreSQL 的主要原因。MySQL JDBC Driver 的高版本也使用了 GPL 授权，这意味着通过其连接 MySQL，也需要公布你的源代码。 http://dev.mysql.com/downloads/connector/j/ ac84
3.1.html
看仔细这段话：
引用:
NOTE: By downloading the software from this page, you acknowledge that the software available from here is licensed under the GPL. We advise that you review the GPL before downloading.
If you need commercial, non-GPL, licenses, you can order them online.
MySQL 的双 License 的含义是：要么选择 GPL，为开源事业作贡献；要么就付钱购买商业的 License。没有其它的选择。这合理吗？当然很合理，天下哪里有什么免费的午餐？不过 MySQL 的商业 License 是非常便宜的，所以不必太担心。请看：
http://china.nikkeibp.co.jp/china/news/com/200402/com200402030111.html
QT 的策略同样也是这样，GPL 和商业 License 并行。这就是游戏规则，我们必须要遵守。
http://www.mysql.com/network/faq.html#8.5
引用:
ISVs and Resellers, who are embedding and reselling the MySQL database server as part of their own commercial solutions, can purchase a MySQL commercial license.
另外关于 MySQL 的 License 问题，需要仔细看一下这篇文档：
http://www.mysql.com/company/legal/licensing/faq.html
上一次由dlee于2005-5-15 周日, 下午11:43修改，总共修改了5次
返回顶端
Airate
JBoss
加入时间: 2004/09/10
文章: 36
时间: 2005-5-15 22:42:01 标题:
--------------------------------------------------------------------------------
两个几乎都没接触过，不过刚刚在huihoo上看到这两个链接
MySQL General Information
Comparison of Oracle, MySQL and PostgreSQL DBMS
http://www.huihoo.com/postgresql/mysql-vs-pgsql.html
为什么选用PostgreSQL，而不是Oracle？
http://www.huihoo.com/postgresql/pgsql-advocacy.html
返回顶端
robbin
论坛管理员
性别:
年龄:30
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 23:23:58 标题:
--------------------------------------------------------------------------------
buaawhl 写道:
我对 Open Source License 理解不深。以前在自己做试验的一些小东西中，都使用MySQL数据库。
后来，一个技术上经常交流的同事告诉我说，MySQL DB 和 MySQL JDBC Lib 都是 GPL的。这意味着使用它，就要开源，或者付费获得Commercial License。PostgreSQL是BSD的，最自由，限制最少。
为了保险起见，我就转向了PostgreSQL，并开始关注论坛上关于Open Source License的讨论。并决定，自己发布的Small Open Source things 都要是BSD。
Linux就是GPL License，那么是不是大家一用Linux操作系统，上面跑的什么程序都必须开源了呢？
andyyehoo
SunOne Server
性别:
年龄:26
十二宫图:
加入时间: 2003/12/26
文章: 141
来自: 广州
我相反，还是支持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）
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-14 20:31:29 标题:
--------------------------------------------------------------------------------
MySQL 3.X的时代InnoDB就是支持数据库事务的，这已经是年代很久远的事情了；
国际化支持不好，不知道你从何说起；
子查询现在早已支持；
文件管理并不简陋，相反很强大（去看InnoDB文档）
大文本字段你难道不用text？
引用:
“高级复制，是否支持集群，是否具备联机备份和恢复”这些高级功能正如无明说的，以性能为代价。mysql把这些功能都实现了，它以前被人最称道的速度优势，还存在么？
请看我最前面帖子设定的评价标准，我什么时候把速度放进我的评价标准了？
MySQL InnoDB在开源数据库中在我提到的综合评价标准来说，是最符合的，而PostgreSQL则不及格。
BTW：Yahoo的服务器数据库全部都是用MySQL InnoDB。
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-14 21:30:13 标题:
--------------------------------------------------------------------------------
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 的那个免费版本。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-14 22:48:40 标题:
--------------------------------------------------------------------------------
引用:
我的意见是你对那种数据库最熟悉，就坚持使用下去，直到有一天你发现这种数据库完全无法解决你要解决的某个特定问题。现在 MySQL 究竟是哪些方面的问题不能解决？针对这个特定的问题（例如：吞吐量、并发连接）找到一种更好的解决方案。这种解决方案可能是 PostgreSQL，可能是 Ingres、也有可能是 Sybase 的那个免费版本
MySQL和PostgreSQL我都用了好多年了，这两个我都很熟悉。熟悉归熟悉，但不是我选择数据库的标准，我选择数据库的标准是看能否满足我需要的功能，能否符合我的评价标准！
MySQL5现在也具备视图存储过程触发器功能（MySQL5 InnoDB甚至开始支持分布式事务），单纯从数据库开发方面的功能来说，MySQL只比PostgreSQL多，而不会少。
现在MySQL解决不了的问题，其他开源数据库一样解决不了，只能寻求高端商业数据库。更何况选择一种数据库作为你的业务支撑系统来运行，也绝对不是什么到时候想换就可以换的。
上一次由robbin于2005-5-14 周六, 下午10:55修改，总共修改了2次
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-14 23:10:21 标题:
--------------------------------------------------------------------------------
robbin，你还是需要再把你的评价标准详细说一下，或者给个链接，才可能继续讨论下去的。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 00:16:12
4000
标题:
--------------------------------------------------------------------------------
dlee 写道:
robbin，你还是需要再把你的评价标准详细说一下，或者给个链接，才可能继续讨论下去的。
目标是选择支撑J2EE应用的关系数据库，要求比较好的负载能力，比较全的数据库标准支持，比较好的数据库管理工具和高级特性。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 00:27:34 标题:
--------------------------------------------------------------------------------
关于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
至于这个上面带上负载能力的测试也表明了这一点。
返回顶端
robbin
论坛管理员
性别:
年龄:30
十二宫图:
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 01:01:09 标题:
--------------------------------------------------------------------------------
这个是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
引用:
InnoDB 是 MySQL 上第一个提供外键约束的引擎，除了提供事务处理外，InnoDB 还支持行锁，提供和 Oracle 一样的一致性的不加锁读取，能增加并发读的用户数量并提高性能，不会增加锁的数量。
InnoDB 的设计目标是处理大容量数据时最大化性能，它的 CPU 利用率是其他所有基于磁盘的关系数据库引擎中最有效率的。
InnoDB 的一些物理设计仿照了 Oracle ，因此，能够获得和 Oracle 可以类比的性能
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-15 09:55:20 标题:
--------------------------------------------------------------------------------
是的，我也觉得并发的 select 才是最重要的，而并发的 insert/update/delete 相对来说是比较少的。比如这个论坛，潜水员那么多，这些人成天看贴不回贴（没天良啊），同时打开多个页面，经常 refresh，这些其实全部都是 select 操作。针对 select 提供最佳的性能才是我们最应该关心的。
由此我想到，由于 OLAP 操作几乎全部都是 select，对于事务的要求非常少，因此可能 MySQL 比 PostgreSQL 更适合这类分析型的应用。
提高数据库的性能，除了对数据库本身调优以外，用好的方法开发应用才是最重要的。这里子查询是一个非常关键的特性，很多时候可以取代没有必要的表连接。
由 robbin 的介绍知道，MySQL 今年的进步确实是非常大的，提供视图/存储过程/触发器可以说迈上了一个新的高度。一个新的企业级数据库已经隐然出现。以前选择 PostgreSQL 主要还是因为 MySQL 的功能太简单，感觉不够专业。不过现在 MySQL 已经不是昔日吴下的阿蒙了。Yahoo 选择的 PHP 和 MySQL，给了这些开源技术极大的支持。其实做网站，LAMP 确实也是一种不错的选择。
返回顶端
robbin
论坛管理员
性别:
年龄:30
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 10:42:49 标题:
--------------------------------------------------------------------------------
和你说的恰巧相反，事实上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.javaeye.com/viewtopic.php?t=5322
操作系统Kernel从2.4升级到2.6以后（主要是增加了NPTL），Java应用服务器的网络处理性能提升了5倍之多！ （网络处理性能代表了高并发情况下的负载能力和响应能力）
我虽然没有对MySQL做过同样的测试，但是可以想像得到，在Linux Kernel2.6下面，MySQL的多线程性能的提升也肯定非常可观。因此在Kernel2.6下面，多线程的程序和多进程程序的负载能力和响应能力的差距恐怕就更加大了。
返回顶端
buaawhl
Java Virtual Machine
性别:
年龄:29
十二宫图:
加入时间: 2004/07/07
文章: 787
时间: 2005-5-15 13:21:05 标题:
--------------------------------------------------------------------------------
我对 Open Source License 理解不深。以前在自己做试验的一些小东西中，都使用MySQL数据库。
后来，一个技术上经常交流的同事告诉我说，MySQL DB 和 MySQL JDBC Lib 都是 GPL的。这意味着使用它，就要开源，或者付费获得Commercial License。PostgreSQL是BSD的，最自由，限制最少。
为了保险起见，我就转向了PostgreSQL，并开始关注论坛上关于Open Source License的讨论。并决定，自己发布的Small Open Source things 都要是BSD。
返回顶端
chikaiwang
Caucho Resin
性别:
年龄:27
十二宫图:
加入时间: 2004/09/26
文章: 16
时间: 2005-5-15 14:36:02 标题:
--------------------------------------------------------------------------------
Use it like this if you want to move your database to an Oracle:
>mysqldump -u root --password="root" --compatible=oracle ejbtest > ejbtest.sql.oracle
我太爱Ｍｙｓｑｌ了，现在可以不用ｐｏｗｅｒｄｅｓｉｇｎ来转换符合某一特定数据库的ｄｄｌ。
返回顶端
dlee
Java Virtual Machine
性别:
加入时间: 2003/09/18
文章: 1086
来自: 上海
时间: 2005-5-15 21:36:13 标题:
--------------------------------------------------------------------------------
robbin，你啊，总是喜欢不把别人的话完全看清楚。我也没有说过 MySQL 不适合 OLTP 啊，呵呵。甚至没有误导群众的任何动机。
这里有一个最新的测试数据：
http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres
我们假设这里的数据是真实的，作者是有良心的，没有任何偏向。我们来做一个分析：
对于 insert 操作，MySQL MyISAM 性能最好，而 MySQL InnoDB 性能最差，PostgreSQL 打开 fsync 和关闭 fsync 的性能处于 MySQL 两种 table 类型之间。
对于 select 操作，MySQL InnoDB 性能最好，MySQL 的两种 table 类型的性能都要比 PostgreSQL 打开或者关闭 fsync 的性能要好。
加上 order by 以后，MySQL 两种 table 类型做 select 的性能仍然比 PostgreSQL 要好。
对于 delete 操作，MySQL MyISAM 性能最好，MySQL InnoDB 性能最差。
这个测试是非常简单的。从某个侧面证实了 MySQL 的 select 操作的性能确实要比 PostgreSQL 好的多，因此 MySQL 非常适合做 OLAP 一类的应用。而使用 InnoDB 的 MySQL 在 insert 和 delete 时的性能优势并没有充分体现出来。
这个测试其实是非常简单的。robbin 我们有空了可以使用 MySQL 5.0 和 PostgreSQL 8.01 再测试一下。在测试之前别忘记对于 MySQL 和 PostgreSQL 都做一些调优。
这里还有一篇很老的文章，里面说了什么时候应该选择 PostgreSQL，这些建议在当时（2002 年）都是非常正确的，对于今天的情况我来逐一做个评价：
http://builder.com.com/5100-6388-1050671.html
Complex database design
有多复杂？MySQL 5.0 推出以后，也可以支持相当复杂的数据库设计了。
Moving away from Oracle, Sybase, or MSSQL
这是因为 MySQL 5.0 正式版本（不要推荐我们在企业应用中使用 alpha 版或者 beta 版）还没有推出，一般用户还无法使用视图/存储过程/触发器。我的亲身经历可以证明，由于 PostgreSQL 存储过程的 PL/pgSQL 语言与 Oracle 的 PLSQL 的语法非常接近，因此将 Oracle 的存储过程或触发器移植到 PostgreSQL 上面是非常容易的事情。而且 PostgreSQL 和 Oracle 一样都是基于对象的数据库，其文档中对于一些概念的描述非常相似。所以熟悉 Oracle 的开发人员转向 PostgreSQL 是非常容易的。
Complex rule sets (i.e., business rules)
PostgreSQL 可以定义非常复杂的 SQL 重写规则，但是我们一般不常使用这个功能。
Use of procedural languages on the server Transactions
PostgreSQL 支持用多种语言开发存储过程，包括 PL/pgSQL, PL/Tcl, PL/Perl, PL/Python, PL/PHP, PL/Java 等等，这极大地方便了不同语言的开发人员。
Use of stored procedures
存储过程 MySQL 5.0 马上就会提供，我们期待着它能给我们带来惊喜。
Use of geographical data
地理数据我们几乎从来不会用到。
R-Trees (i.e., used on indexes)
R-Tree 有什么意义？哪位科班出身的网友帮我解释一下。
这篇文章虽然很老，但是其中提出的选择方法还是有指导意义的。作者认为在性能非常重要的场合，应该选择 MySQL。但是选择 PostgreSQL 这些考虑因素，将随着 MySQL 5.0 的推出，提供大量新的企业级特性后不再那么重要。其实我觉得大部分场合下，性能往往才是第一考虑的因素。性能只是一个方面，高可用性也是非常重要的方面。在这方面 MySQL 现在走在了 PostgreSQL 的前面。
说到这里我又要开始捣浆糊了，robbin 一定会皱眉头的。其实 MySQL 和 PostgreSQL 都是非常优秀的开源软件，我们都应该支持，都有必要去深入研究。正是因为这两大对手多年来的竞争和对决，我们才有了今天的方便。
另外关于 buaawhl 所说的 License 问题，这个问题确实是一些大公司（例如富士通）选择 PostgreSQL 的主要原因。MySQL JDBC Driver 的高版本也使用了 GPL 授权，这意味着通过其连接 MySQL，也需要公布你的源代码。 http://dev.mysql.com/downloads/connector/j/ ac84
3.1.html
看仔细这段话：
引用:
NOTE: By downloading the software from this page, you acknowledge that the software available from here is licensed under the GPL. We advise that you review the GPL before downloading.
If you need commercial, non-GPL, licenses, you can order them online.
MySQL 的双 License 的含义是：要么选择 GPL，为开源事业作贡献；要么就付钱购买商业的 License。没有其它的选择。这合理吗？当然很合理，天下哪里有什么免费的午餐？不过 MySQL 的商业 License 是非常便宜的，所以不必太担心。请看：
http://china.nikkeibp.co.jp/china/news/com/200402/com200402030111.html
QT 的策略同样也是这样，GPL 和商业 License 并行。这就是游戏规则，我们必须要遵守。
http://www.mysql.com/network/faq.html#8.5
引用:
ISVs and Resellers, who are embedding and reselling the MySQL database server as part of their own commercial solutions, can purchase a MySQL commercial license.
另外关于 MySQL 的 License 问题，需要仔细看一下这篇文档：
http://www.mysql.com/company/legal/licensing/faq.html
上一次由dlee于2005-5-15 周日, 下午11:43修改，总共修改了5次
返回顶端
Airate
JBoss
加入时间: 2004/09/10
文章: 36
时间: 2005-5-15 22:42:01 标题:
--------------------------------------------------------------------------------
两个几乎都没接触过，不过刚刚在huihoo上看到这两个链接
MySQL General Information
Comparison of Oracle, MySQL and PostgreSQL DBMS
http://www.huihoo.com/postgresql/mysql-vs-pgsql.html
为什么选用PostgreSQL，而不是Oracle？
http://www.huihoo.com/postgresql/pgsql-advocacy.html
返回顶端
robbin
论坛管理员
性别:
年龄:30
加入时间: 2003/09/07
文章: 2257
来自: 上海
时间: 2005-5-15 23:23:58 标题:
--------------------------------------------------------------------------------
buaawhl 写道:
我对 Open Source License 理解不深。以前在自己做试验的一些小东西中，都使用MySQL数据库。
后来，一个技术上经常交流的同事告诉我说，MySQL DB 和 MySQL JDBC Lib 都是 GPL的。这意味着使用它，就要开源，或者付费获得Commercial License。PostgreSQL是BSD的，最自由，限制最少。
为了保险起见，我就转向了PostgreSQL，并开始关注论坛上关于Open Source License的讨论。并决定，自己发布的Small Open Source things 都要是BSD。
Linux就是GPL License，那么是不是大家一用Linux操作系统，上面跑的什么程序都必须开源了呢？
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- PostgreSQLvs MySQL
- SQLite vs MySQL vs PostgreSQL:关系型数据库比较
- SQLite vs MySQL vs PostgreSQL：关系型数据库比较
- 毕业设计之外文翻译---SQLite vs MySQL vs PostgreSQL:关系型数据库管理系统的比较
- Oracle 10g vs PostgreSQL 8 vs MySQL 5（外围特性评比）
- MySQL InnoDB vs PostgreSQL (转载)
- mysql vs postgresql vs sqlite vs mysql
- Benchmarking PostgreSQL vs. MySQL performance
- MySQL vs PostgreSQL
- SQLite vs MySQL vs PostgreSQL:关系型数据库比较
- PostGIS/PostgreSQL vs. MySql vs. SQL Server
- Mysql VS Postgresql
- SQLite vs MySQL vs PostgreSQL:关系型数据库比较
- postgresql vs mysql on enterprise solutions
- PostgreSQL VS MySQL's Storage EngineSss..
- liunx底下db数据库比较 SQLite vs MySQL vs PostgreSQL vs Mongodb
- SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems
- MySQL vs. PostgreSQL
- SQLite vs MySQL vs PostgreSQL
- SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems