Oracle和MySQL、PostgreSQL特性对比(续)

上一篇 / 下一篇  2007-12-12 10:32:57 / 个人分类:数据库

  在前面对数据库的比较中,我们提到了几种不同的特征,比如触发器,视图和存储过程。虽然在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的性能差异,仅此而已。

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


TAG: 数据库

 

评分:0

我来说两句

Open Toolbar