Oracle和MySQL、PostgreSQL特性对比

日期：2008-01-03　作者：Sean Hull　来自：linux.chinaunix.net

　　将Mysql、PostgreSQL二个开源数据库和Oracle放在一起对比，多少显得有些不公平，后者是有强大厂商及上千技术人员支持和维护的商用数据库，而前者是开源和免费的产品。但是，这种对比，有助于我们在架构自己的业务和应用时，做出理性的选择。

　　随着现代数据库可用特征集的迅速增加，很难区分孰好孰坏。例如Oracle里就有许多你可能从来都不需要的高级数据仓库特征。此外也可能有一些其它不可或缺的特征比如ACID事务特性。我们来看一看主要的一些特征，比如存储过程，视图，快照，表数据类型和事务等等。同时我们分析一下Postgresql，MySQL和Oracle这几个数据库，然后找出哪个能够满足你的需求。

　　存储过程

　　数据库里的存储应用程序肯定会有它的拥护者和贬低者。在这个问题上我还不清楚自己属于哪一类，所以我尽量对这两个方面都讨论。当你开始在数据库里放置应用程序代码时，你就处于了彻底不可移植的境地。你把应用程序移植到另一个数据库时，那段代码将不得不被重写。但是它对原来数据库的高度专一性意味着它可以利用那个引擎，和那个引擎紧紧捆绑在一起。有时候数据库里的存储代码要明显快得多。在对数据做了修改之后，你不得不更新一百万行的某些数据块。

　　在存储过程里，数据的读入、操纵和更新是一步完成的。然而你要在中间层应用程序中做同样事情的话，你就不得不通过网络发送数据集，完成数据操纵，然后将它发送回来。这不但使任务的速度变慢，而且竞争同一数据的其他事务有可能不得不等待，因为它需要的数据正处于传送和操纵状态。存储代码也可以用来密封特定的请求，这对简化你整体的应用程序是很重要的。这三个数据库都支持存储过程和函数。Oracle还支持包，或者说是存储过程的集合以及几乎没有人用过的各种面向对象特征的集合。还要说明一点，一个数据库引擎实际上是在存储代码和嵌入在里面的SQL代码之间关联转换。 Oracle 9i版本引入了成批绑定技术，所以你能够对许多行进行处理，并且能够一次性更新它们，而不是单个循环迭代。这个特征大幅度改善了性能。

　　视图

　　视图基本上是存储查询，正因为如此执行起来才不会过度复杂。然而当用于查询时，他们必然会使查询复杂化。所以很明显，数据库在视图可用之前一定要支持子查询。Oracle很早就已经有视图了。从5.0版本开始，MySQL也已经支持视图。跟Oracle一样，MySQL也支持UPDATEABLE视图，但是有一些限制。Postgres也支持视图和UPDATEABLE视图。更详细的解释见Complex SQL部分。

　　物化图(快照)

　　不用说，Oracle对它们支持得非常好。作为一种新事物，物化图(我更喜欢快照这个可视化的术语，有点离题了)是一个周期性更新的副本或者是表的子集。可以把视图看做是查询的一个副本。直到下一次刷新，那个副本是静态的，没从主机那儿更新的。通常要在更新频率和支持它的事务日志(比如索引)的维护之间做一个折衷。名义上，MySQL和Postgresql不支持物化图，然而互联网上有它的实现，可能会满足你的需求，你要是选择此方案的话就另外需要一些支持了。一个存储程序创建物化图，另一个存储过程刷新它。在本质上，一个CREATE TABLE语句就是AS SELECT..的拷贝。

　　语言集成

　　如今，基于web的编程应用虽然使用了不同的数据库，却是完全平等的。几乎所有的web编程语言都支持这些数据库类型。Java，PHP，Perl，Python，C#/.NET，等等等等。尽情享受编程的乐趣吧！

　　触发器

　　MySQL，Oracle和Postgres都支持INSERT，UPDATE和DELETE操作的BEFORE和AFTER事件触发器。就我个人而言，除非万不得已我不会使用触发器。因为他们常常被忘记，有时反而给你添乱。少量使用的话，效果反而会很好。

　　安全性

　　所有这三个数据库都有它的脆弱性。软件肯定有一些死角故障隐藏其中，这是它的本性。此外，这三个数据库都会定期发布更新包。然而我个人的感觉是，开源意味着必然有更多的目光，并且经常更多的是挑剔的目光盯在程序上面。而且在开源世界里社区施加的压力要大得多。在商界，当修理费用远远高于等待补丁的费用时，厂家可以并且经常会耍手段。

　　在数据库内部的安全性方面，所有这三个数据库都支持口令登录和数据库内部各种类型的加密。Oracle确有一种新特征叫做虚拟专用数据库，其中表的段和列都可以被编码，对于视图是隐藏的。这对于一些有争议的或是敏感的数据非常有用，DBA和其他管理员对这些数据是无权访问的。

　　结论

　　很明显，这三个数据库平台都有大量的特征，对于同一问题也有不同的解决方案。就安全性，触发器，视图，物化图和存储过程而言，他们提供了许多一样的功能，尽管在性能和配置方面有些差异。在第二部分，我们将讨论数据库真正开始千差万别的一些方式，从索引方面，可能最重要的是从它们的优化引擎方面。

　　在前面对数据库的比较中，我们提到了几种不同的特征，比如触发器，视图和存储过程。虽然在Oracle，Postgresql和MySQL中这几个特征集彼此之间有所不同，但是你遇到的大部分应用都是集中在这几个方面。这一次，我们将讨论这几个平台之间存在明显差异的一些东西，最重要在于它们处理SQL复合语句和优化选择的方式上。

　　SQL复合语句(优化引擎)

　　不管你选择哪个数据库，SQL语言都是你和数据库交互的最基本和最重要的方式。 这也正是这三个平台开始分道扬镳的地方。 Oracle支持大量复杂的查询,几乎是无限多的表和所有类型的联结以及组合。但这些充其量只是冰山一角，Oracle真正的王牌在于它的Cost Based Optimizer(基于代价的优化器)，它分析SQL语句，如果可能的话会重写和简化它，基于代价选择索引，根据驱动表和其他一些神秘的方式来做出决定。

　　读一下MySQL的文档你就会发现性能偏见的来源，这些是厂家细节类型，它使得性能优化和性能调节在任何平台上都很复杂。MySQL能够处理的任何 JOIN或者VIEW语句的固定最大值是61张表。我个人又有点疑问，不管怎么说，应用程序中表太多了处理起来会更困难，所以正如前面所说，确实是优化器而不是能够查询的最大表规格占上风，等等。

　　Postgresql 8.x版支持所有的SQL92规范，几乎没有什么限制。 我再次认为，一种数据库优于其他数据库在于优化程序方面做得好。复合查询很麻烦，所以查询策略就成了你分析性能瓶颈的最好参考。

　　索引类型

　　索引技术对数据库性能来说是很关键的，Oracle在这方面提供了很多的选择。目前存在着太多的索引类型，从标准的B树到反向键，再到基于函数的时常误用的位图索引，甚至index-only表。作为附加技术，DBA还可以使用Oracle Text，它提供了索引能够让你查找CLOB(大字符对象)，而且Oracle Spatial提供了基于位置数据的索引。

　　在MySQL里，我们发现有B树，哈希表，全文和GIS索引(基于位置数据)，还有簇索引，但是如果我在Oracle方面的经验有任何指导作用的话，我可以说这些跟大多数应用程序都是不相关的。大部分时候，B树索引是我在Oracle，MySQL和Postgres应用中能看到的唯一一种索引。除此之外，就算作为示例，基于函数的索引在MySQL中也是没有的，但是它们能够靠创建另一列使用那个函数和一些数据来模拟，然后再增加一个触发器使它更受欢迎。

　　Postgresql提供了B树和哈希表，以及r树和它自己个性化的GiST索引类型，它允许创建用户自定义类型和基于函数的索引。Oracle也提供了一种类似的函数，其中它的基于函数的索引能够用于基于pl/sql的函数，而不仅仅是标准的系统预定义函数，例如那些你可能不会用到的trunc， UPPER函数。但是你要小心了，这样的索引很可能访问速度极慢，当它从你的表中输入输出数据的时候，速度慢得你甚至都可以放慢语速加入讨论了。

　　再次强调一下，Oracle真正胜出的地方就在于它的实现方式和优化器选择索引的策略上。

　　审计

　　Oracle允许你通过审核跟踪设施对表和文件启用审计功能。一旦启用，你可以审计插入，更新或者删除一个特定的表，还可以注册，甚至是某一特定用户对数据库全部的访问。你有相当多的选择权，并且启用很容易。

　　Postgresql也有这个函数，据说跟Oracle的同样灵活、易于配置。

　　另一方面，MySQL的核心函数中好像不提供这个函数，你当然可以构建自己的存储过程和触发器来做你想做的事情，并把相应的信息填入一张表中，只是相对麻烦一些。

　　数据类型

　　Oracle，MySQL和Postgresql都支持4GB大的二进制数据和文本数据。所有我们认识和喜欢用的数据类型它们都支持，比如数字，字符和日期类型。 每一个数据库又在不同程度上提供一些个性化的数据类型，虽然我在应用程序中很少看到它们。

　　我还要说的是，Postgresql和MySQL的资产已经超过了原来的投资，不再害怕实现一个我们经常使用的自动递增列类型。Oracle坚持按部就班地做事，认为这样效率会更好，但是进步很缓慢。Oracle也没有SET数据类型，要是有就好了。它也不没有time-only数据类型，Postgresql和MySQL却都有。但是从功能上来说，你会发现在这三个数据库平台上能够用日期和时间类型来做你想做的任何事情，从时区的处理到时间间隔的处理等等。

　　我喜欢Postgresql和MySQL的另一个地方是它们对多种数学优化数值类型的支持，从smallint到decimal，real，double类型等等。这些利用了下面的体系结构实现，并且和程序设计语言(比如C语言)的类型相匹配。

　　事务支持

　　在数据库领域，适当的事务处理首字母简写为ACID特性，它的意思是原子性(Atomicity)，一致性(Consistency)，隔离性(Isolation)和持久性(Durability)。原子性的意思是事务是一个完整的单元，全部提交或者全部回滚。一致性的意思是从一个合法的状态到另一合法状态，即你实施合适的约束条件能够执行商业逻辑。隔绝性的意思是一个事务看不见另一个事务在做什么，直到它提交。持久性的意思是一旦提交了，改变就是永久性的，关键是你要保护硬件不出故障。

　　关于这个问题我有几点要说，希望没有在此引起文化争战。我看到过许多像这样的陈述，说任何企业类应用决不会使用那些没有实现全部ACID特性的的数据库，而且非事务性的表也是毫无用处的。这些都是愚蠢的结论。例如, Oracle自己数据字典中的性能视图就不是事务性的。原因是什么？如果他们那样做的话系统的整体性能就不可预测了。其次，在那种环境下也不一定要这样做。有许多像那样的应用程序。我曾经阅读过一个航空售票系统，它需要升级增加第二服务器来容纳Oracle。他们正在查找所有相关的许可证代价，包括软件成本的和大块的硬件成本。然后他们再返回检查应用程序。有人想出一个聪明的办法，实现售票点上90%的通信量是在浏览航班(只读)，而实际上只有10%的人正在买票。所以，他们建立了一组低成本的MySQL服务器用于浏览航班，而把订票请求重定向到可靠的Oracle服务器上来处理。这是多么棒的一种混合解决方案啊！

　　我承认MySQL和它的InnoDB表在事务部分已经有了很大改进。那或许可以解释为什么Oracle并购Innobase。仍有一些人坚持说MySQL 只是LDAP或者NFS的一种结构化查询语言界面。然而，MySQL确实已经有了很大进步并且会继续挑战那些贬低者。

　　Postgresql在这方面要健全一些，所以我主要说的是，你将只会看到它和Oracle的性能差异，仅此而已。

　　结论

　　正如你从我们对数据库平台的横向对比中看到的那样，当选择一种数据库平台的时候要考虑很多问题。从特征的完整性到厂家的支持、社区支持，以及性能和优化都要考虑。在你充分了解你所构建的应用和它的真正需求之前不要过多投资。最后说的这些可能是模糊不清的并且难以证实，但是有了一点创造力和对这个问题艰苦的思考，以及一个良好的发展态势，你将会找到一种耗费合理、性能坚固的解决方案。

本文被浏览次

Copyright © 2001-2006 ChinaUnix.net All Rights Reserved

感谢所有关心和支持过ChinaUnix的朋友们

京ICP证041476号