Oracle、MySQL和PostgreSQL的功能比较

时间:2021-07-12 06:34:30

  本文在安全、触发器、视图、物化视图和存储过程方面对Oracle、MySQL和PostgreSQL进行了比较……
  【IT专家网独家】随着现代数据库中可以被使用的功能的蓬勃发展,已经很难将它们从数据库中分离出来。例如在Oracle中有许多高级的数据仓库功能,这些功能你可能永远都不需要。此外,还可能有一些其它的功能例如你不能没有的ACID遵从性事务。我们将介绍主要的功能,例如存储过程、视图、快照、表数据类型、事务等等。我们将对比Postgresql、MySQL和Oracle,看哪些能够满足你的需要。

  存储过程

  有人支持、也有人反对在数据库中保存应用程序代码。在这个问题上我保持基本公正的态度,所以我会试着从双方来讨论。当你开始将应用程序代码放置到数据库中时,你就变得极其不轻便。在你将你的应用转向另一个数据库时,这个代码将会被重写。但是它放置在数据库上意味着它还可以充分利用和紧密连接这个引擎。在某些情况下在数据库中存储代码可以显著的提高速度。比如你在对数据进行了某些策略后需要更新百万行的数据中的绝大部分。

  在一个存储过程中数据是在一步中被读取、操纵和更新的。而如果你在应用程序代码的中间层做相同的操作,那么你需要将数据通过网络传送过去,进行操作和将它发送回来。这不只会减慢这一个任务,其它在竞争和它使用的相同的数据的操作很可能就要等待了,因为这个数据处于传送过程中,而且将被执行操作。此外,存储过程的代码可以提供服务对特定的请求进行封装,这对简化你的整个应用程序来说是非常宝贵的。这三个数据库都支持存储过程和函数。Oracle还支持存储过程的包或集合,还包括各种面向对象的功能,这些功能几乎没有人使用过。一个数据库引擎实际上在存储过程和内嵌在那里的SQL代码之间进行上下文切换。在9i中,Oracle推出了批量绑定,这样你就可以对行的大型集合进行操作,并一次就更新整个集合,而不是在每个循环迭代中进行更新。这个功能甚至还可以非常显著的进一步提高性能。

  视图

  视图是基本的存储查询,正因为如此,它执行起来不是特别复杂。然而在查询中使用视图时,它们必定会使查询更加复杂。所以很明显,使用数据库中的视图之前,要更新子查询。Oracle显然提供视图有段时间了。在MySQL5.0中,也支持视图了。像Oracle一样,MySQL也支持UPDATEABLE视图,不过有些限制。Postgres也支持视图和UPDATEABLE视图。详见复杂SQL那一节。

  物化视图(快照)

  物化视图在Oracle中默认模式下支持的很好。作为回顾,记住一个物化视图(我更喜欢更加形象的术语“快照”,我离题了)是一个定期更新的拷贝或是一个表的子集。想象一个视图使用它的查询填充一个镜像拷贝。直到下一次刷新,这个拷贝是静态的,不随主本的更新而更新。通常会在更新的频率和支持它的处理日志(很像一个索引)的维护间做个权衡。名义上,MySQL和Postgresql不支持物化视图,但是在网上有这个的实现,它可以满足你的需求,如果你采用这个方法,你还需要一些支持。用一个存储过程创建物化视图,而另一个刷新它。大致上是CREATE TABLE my_copy AS SELECT。。。

  语言集成

  今天,基于web 的应用程序编程真的是一个平等的世界。几乎所有流行的web 语言都支持所有的数据库类型。Java、PHP、Perl、Python、C#/.NET 等等。这世界让你随心所欲。

  触发器

  MySQL、Oracle和Postgres都在INSERT、UPDATE和DELETE上支持BEFORE & AFTER事件触发器。我个人偏向于除非绝对必要,不然不使用触发器。它们正在逐渐被遗忘,但有时又会出现给你制造麻烦。不过如果谨慎的使用它们,它们会是很有用的。

  安全

  所有这三个数据库都有它们的漏洞。软件中有地方隐藏着错误真的是很正常的。而且,这三个数据库都有定期发布的更新补丁。不过我个人觉得,开源意味着必定有更多的眼光,而通常是批评的眼光在看待这个代码。而且,在开源世界里,社会压力要大的多。在商业领域,当修复比所知的等待修复的成本更昂贵的时候,供应商可能、并通常会加快速度。

  在数据库中的安全方面,这三个数据库都采用密码登录和在数据库中对各种类型进行加密。Oracle最近提供了一个叫做虚拟专用数据库(virtual private database)的功能,在它里面数据表的某些部分和字段可以被加密,并隐藏起来不被看到。这对于数据库管理员和其他管理员不应该有权限访问的有争议的或敏感数据来说,非常有用。

  总结

  我们这三个数据库平台很显然有很多功能,和用于相同问题的不同解决方法。在安全、触发器、视图、物化视图和存储过程方面,它们提供了许多相同的功能性,尽管在性能和可配置性方面不尽相同。在第二部分我们将讨论在索引方面这些数据库真正开始显著不同的一些地方,不过可能最重要的是在它们的优化引擎方面。

  【IT专家网独家】在我们的数据库比较的上一节中,我们介绍了各种知识例如触发器、视图和存储过程。尽管在Oracle、Postgresql和MySQL数据库中的功能设置肯定是各不相同的,但是这些内容已经可以满足你的大多数日常所需了。在这一节,我们将介绍一些关于平台间在处理复杂SQL和优化选择方面的不同,这些不同更加显著,也更加重要。

  复杂SQL(优化引擎)

  SQL是你与你的数据库交互的基础和最关键的方法,无论你选择哪个。这三个平台也恰恰是从它开始真正分离。Oracle支持非常复杂的查询、几乎不限制表的个数、所有的类型的连接和合并。虽然Oracle有很多功能,但是它真正宝贵的却是它基于成本的优化器,它可以分析SQL、如果可能的话进行重写和简化、基于成本选择索引、决定对表的操作和它之中的所有其它的各种功能。

  阅读MySQL的文档,你会发现对偏向于性能的描述和供应商定义的细节使优化器和性能调整在任何平台上都很复杂。MySQL规定的最大规模是在任何连接或在一个视图中表的最大数目为61个。再一次的,我个人觉得无论如何在任何一个应用中这么多表的一个查询将是难以使用的,所以正如上面提到的,目前更适用的是优化器而不是查询最大表规格,等等。

  8.x版本的Postgresql支持所有SQL92规范,几乎没有任何限制。再一次的,我认为你会看到的一个数据库优于其它的数据库的方面就是在优化方面。复杂的查询会变得凌乱,并且查询计划是你在诊断性能瓶颈时的最好的朋友。

  索引类型

  索引技术对于数据库性能是至关重要的,而Oracle有大量的选项可供选择。有非常多的不同的索引类型,包括标准的二进制树、转换键的、基于功能的、常被错误使用的位图索引,甚至还有索引表。随着附加项技术的发展,数据库管理员有了可用的提供索引的Oracle文本,它允许你搜索CLOB(字符大对象),并且Oracle Spatial提供用于基于位置的数据的索引。

  在MySQL中,我们发现有二进制树、哈希、纯文本和GIS索引(对于基于位置的数据)。还有集群索引,但是如果说我在Oracle方面的经验给我任何指导的话,那么就是大多数应用通常是不相关的。因此,大多数情况下我在Oracle、MySQL或Postgres应用中看到的只有二进制树索引。另外,尽管像在MySQL中基于功能的索引是不可用的,但是他们可以通过创建另一个保存使用这个函数的数据的列来进行模拟,然后添加一个触发器来将安装它。

  Postgresql提供二进制树和哈希,还有R树,和它自己定制的GiST索引类型,GiST索引类型允许使用用户定义的类型和允许创建基于功能的索引。Oracle提供了一个类似的功能性类型,它的基于功能的索引可以用于基于pl/sql的功能而不只是标准的预定义系统功能,例如你本来可能会使用的trunc、UPPER。要小心像这样的索引可能访问起来非常缓慢,你可能在谈论到要录入或移除数据时,甚至不希望听到“慢”这个词。

  它确实实现了,并且优化器选择索引的方式优于Oracle

  审计

  Oracle使你可以对一个表或一个文件进行审计,通过审查索引工具。一旦允许了,你可以审查对某一个表的插入、更新或删除,或者登录,或甚至是某一特定用户的所有访问。它有许多选项,并且设置为可用的是非常简单的。

  Postgresql也有这个功能,并且它看起来和Oracle的一样灵活和可配置的。

  另一方面MySQL看起来没有提供这个功能,但是你当然可以创建你自己的存储过程和触发器来做你想做的,并录入相关的信息到数据表里,这只需要一点额外的工作。

  数据类型

  Oracle、MySQL和Postgresql都支持最大达到4GB的大型的二进制和文本数据。我们所知道并喜欢的所有的数据类型也是非常有用的,例如数字、字符和日期。每一个都在一定程度上提供一些定制数据类型,尽管我很少看到在应用中使用这些。

  现在我要讲的一件事是Postgresql和MySQL已经超过了过去的基础,不用担心它们实现我们经常使用的一个良好的自增长列类型。Oracle的争论是按顺序来做这项工作更加有效,但是是静态的。Oracle也没有SET数据类型,这个数据类型很重要。它也没有只有时间的时间数据类型,这个数据类型Postgresql和MySQL都有。但是你会发现你能在这三个数据库品平台上做所有你想做的关于日期和时间的操作,从对时区的操作到对间隔的处理,等等。

  另外一个我喜欢Postgresql和MySQL的理由是它们支持各种优秀的数学数字类型,从smallint到decimal、real、double,等等。这些利用了基本的架构实现,与编程语言中可用的数据类型相匹配,例如C语言。

  对事务的支持

  在数据库领域,适当的事务操作遵守了acronym到ACID,这意味着原子性、一致性、隔离性和持久性。原子性意思是一个事务是一个完整的单元,所有都被提交或所有都被回滚。一致性意思是你从一个*VALID*状态转移到另一个,例如你执行适当的约束来加强业务逻辑。隔离性意思是一个事务不能看到另一个事务在做什么,直到它完成了(提交了)。持久性意思是一旦提交了,这个变更就是永久的,并且是防止你硬盘失败的*至关重要的*。

  关于这个问题我有一些事情要说,希望能够避免争论。我看到像“任何企业级应用绝不会使用一个没有实现完全的ACID遵从性的数据库,而且非事务型的表是完全没有用的”这样的说法已经消失了。这些都是愚蠢的说法。例如,Oracle在它的数据字典中的它本身的性能视图就不是事务型的。其次,它们在那个环境中根本没有必要。有许多应用是这样的。我看过一个航空票务系统,它需要定期升级和添加第二个服务器用于放置Oracle。他们看了这个软件的所有相关的许可成本和大型设备的硬件成本。然后他们回头看这个应用。有些人正确的认识到在航空网站上90%的操作是浏览航班(只读),而仅仅10%才是真正的购买机票。所以,他们建立了一组低成本的MySQL服务器用于浏览航班,而变更旅程请求则提交给大型的Oracle服务器来执行票务操作。多么好的一个结合解决方案!

  是的,MySQL在事务方面的InnoDB表方面已经走了很长一段路。这也许可以解释为什么Oracle购买Innobase。一些人仍然认为MySQL只是一个用于LDAP或NFS的SQL接口。但是,MySQL确实走了很长的路并且将继续挑战反对它的人。

  在这点上Postgresql更完整,所以我会说你能看到的主要是和Oracle的性能方面的不同,这就是它的问题。

  总结

  正如你在我们的数据库平台的多个部分中看到的,选择一个数据库平台时要考虑很多事情。从功能完整性,到供应商支持和共同支持,到性能和优化。在你充分了解你在构建的应用和它真正需要什么之前,不要投资过多。到了最后你可能觉得这些比较模糊,并且难以确定,但是有了一点创造性,仔细思考这个主题,并且拥有一个好的开发环境,你就应该能够得出一个成本高效并强大的解决方案来。