Oracle和MySQL、PostgreSQL特性对比

四 1st, 2011 | Filed under 其他, 数据库技术
随着现代数据库可用特征集的迅速增加,很难区分孰好孰坏。例如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的核心函数中好像不提供这个函数,你当然可以构建自己的存储过程和触发器来做你想做的事情,并把相应的信息填入一张表中,只是相对麻烦一些。
将Mysql、PostgreSQL二个开源数据库和Oracle放在一起对比,多少显得有些不公平,后者是有强大厂商及上千技术人员支持和维护的商用数据库,而前者是开源和免费的产品。但是,这种对比,有助于我们在架构自己的业务和应用时,做出理性的选择。
Del.icio.us Google书签 Digg Live Bookmark Technorati Furl Yahoo书签 Facebook 百度搜藏 新浪 ViVi 365Key 网摘 天极网摘 和讯网摘 博拉网 POCO 网摘 饭否 QQ 书签 Digbuzz 我挖网 Mister Wong
目前还没有任何评论.