PureXML能成为IBM Viper的“杀手锏”吗?
【IT168 技术评论】数据库巨头IBM公司于2006年7月14日在京与全球同步发布了第9代最新数据库。这个开发代码为“Viper”的产品,被视为IBM欲一统全球数据库市场的信号。
美国工程院院士、IBM中国软件开发中心总经理郑妙勤说,目前关系型数据库是市场主流,但面对越来越复杂的层次型数据管理需求,它越来越难适应,而DB29则将两种数据库特性融合一起,是业界第一个同时支持两种数据管理的混合数据库。郑妙勤所说的这个第一,真的能成为IBM Viper的杀手锏吗?通过以下分析,也许我们会得出一些结论。
IBM为何要加强Viper的XML功能?
在数据库的发展史上,IBM一直扮演着举足轻重的角色。在上世纪中叶,即计算机发明后的十年中,数据存储还停留在顺序存储的阶段。直到1956年,IBM生产出第一个磁盘驱动器(Model 305 RAMAC)之后,数据存储才进入随机存储时代。但是那时的随机存储只是直接和硬件打交道,或者是直接使用编程语言来操作数据,并没有一套用于管理数据的DBMS。但是随机存储器的诞生为日后的DBMS的诞生铺平的道路。
世界上第一个DBMS是通用电气公司的发明的IDS,它是一个网状数据库,由于它只能使用在通用电气的主机上,并且只能通过编程来建立表。因此,它并未得到广泛的应用。
但随着要处理的数据越来越多,数据量越来越大,因此,这就需要更强大、更容易使用的DBMS。因此,IBM在1966年与另外一家公司合作开发出了世界上第一个被广泛使用的层次型数据库----IMS。IMS的诞生标志着数据库管理系统进入了第一个成熟期。虽然IMS可以很好地解决数据集中存放和共享问题,但同时又会带来另外一些问题。由于层次型数据库是以树型结构存储的,这就使其在数据抽象和独立性上有所欠缺。
基于上述原因,IBM研究员E.F.Codd于1970年首次提出了关系数据库模型,并发表了一篇论文。这篇论文也被认为是数据库历史上的一个里程碑。但由于IBM的固执和保守,以及当时层次型数据库正在鼎盛时期,因此,IBM并为采纳E.F.Codd的建议并着手研制自己的关系型数据库。事隔几年之后,新成立的Oracle公司推出了自己的关系型数据库管理系统Oracle,一跃成为关系型数据库的老大。而IBM也痛失了一次千载难逢的机会(当然,这并不是IBM最后一次失去机会,以后的PC机之战以及Windows和OS/2之争也使IBM受到了重创,要不是半个多实纪的资本沉淀以及多元化的业务,恐怕IBM这个名子已经消失很久了,就象当年的王安公司一样)。
幸好IBM后来认识到了这一点,在1983年正式推出它的第一个关系型数据库产品----DB2。转眼20多年去了,关系数据库市场已经非常成熟了。从最初的几十种关系数据库产品已经逐渐变成以Oracle、DB2以及后起之秀SQL Server为主的三分天下的局面。
随着21世纪的到来,网络被越来越多地应用到日常工作中,人们在日常交流中需要通过网络进行大量的信息交换。但遗憾的是,关系模型无法很好地描述在信息交换中产生的大量的非结构化和半结构化的数据。
于是人们就需要一种能很好地描述这些信息的模型,从而更好地满足信息交换的需要。其中XML的诞生成为了人们关注的焦点。可XML存储格式是采用树型的层次存储格式,这种格式并不容易使用关系模型去处理。因此,也有人提出设计一种完全基于XML格式的数据库。对此,有很多专家持反对意见。因为,关系型数据库已经使用了几十年了,而且关系模型在处理数据上有着得天独厚的优势,并且几十年前从层次型数据库转为关系统型数据库就是因为层次型数据库在数据独立性和抽象性上的不足。如果再完全使用层次型数据库(XML),这不是进入死循环了吗?
因此,又有很多人提出要使关系模型和层次模型共存。其实Oracle、IBM和SQL Server很早就在一定程度上支持了关系数据库和XML共存。但它们都是将XML保存在Blob类型字段中,或是将XML以关系模型保存在数据库中。如果这样话,就失去了层次模型的优势。
也许是因为IBM对层次模型的情有独中,或是为了一血前耻,当然,更可能的是为了重新拿回本该早就属于IBM的关系型数据库老大的位置。IBM花了5年的时间,终于解决了关系模型和层次模型共存,并且使其保持各自优势的难题,这就是PureXML技术。并将这项技术加到ibm新推出的DB2 9中。
【IT168 技术评论】
XML将使Viper具有哪些优势?
IBM Viper是世界是第一个引入了PureXML技术的关系型数据库。但是IBM花了这么大力气来研究PureXML技术,到底能给IBM Viper带来什么呢?
对于数据来说,最重要的应用就是查询。而对于非结构化或半结构化数据来说,如果数据量很大话,查询速度是很慢的。而PureXML最独特的地方是将XML以原始形式保存在数据库中,并且可以为XML的结点建立索引,这将大大提高查询的速度。 在查询数据时,用户可以选择使用SQL、XQuery(一种新的用于查询XML的语言)或SQL和XQuery混合的方式查询数据。这将大大提高查询的灵活性。
具调查询显示,在各种数据中,大概有80%-85%是非结构化数据,如Word、PDF等。在以前,对这些数据进行文档管理,要么将其当成文件保存,并将路径等信息保存在数据库中;要么就是将这些数据作为二进制保存在BLOB类型的字段中。而IBM Viper将改变这一切,可以将这些文档转化为XML格式的文件,并以原始的形式保存的数据中,这样在调用这些文档时,不必将其全部打开,即可以通过XQuery查询其中的一部分。
由于引入了PureXML技术,对XML数据的增删改将变得非常迅速,这就给DBA管理非结构化数据带来非常大的方便。同时,IBM Viper提供了大量处理原生XML的工具和库,这就使非结构化数据在网络之间的传播,以及其它的工具处理XML数据变得非常方便、快速。
因此,总结起来,带有PureXML技术的IBM Viper将给它带来以下三点优势。
1. 通过索引技术提高非结构化数据的查询速度。
2. 将过去的关系型数据库只能处理大约20%的结构化数据提高到今天的80%。
3. 由于XML在IBM Viper中是以原生形式保存的,因此,在处理和在网络中传输时,将会非常方便和快速。
【IT168 技术评论】
IBM能靠Viper力拔头酬吗?
IBM虽然第一个推出了带有PureXML技术的关系数据库,但是技术的成功并不等于商业的成功。翻开沉封的历史,你就会发现历史上有很多例子证明了这一点。其中IBM也曾不止一次地错失良机。在关系数据库上的失误成就了Oracle;在操作系统上的失误成就了Microsoft;在PC机上的失误成就了Compad。
尽管IBM凭着自己多年的技术和资本沉淀,以及那巨无霸似的身躯,终于在关系数据库领域和Oracle可以平起平坐了。但据市场调研公司Gartener的调查得知,虽然IBM db2目前的市场份额和Oracle不相上下,但是Oracle和SQL Server的增长率都比IBM db2快。这就表明如果IBM db2不提高它的增长率的话,可能有一天会被Oracle,甚至是SQL Server远远甩在后面。
IBM Viper的竞争主要集中在两个阵营,一个是以Microsoft为首的Windows阵营,另外一个是以开源为代表的非Windows阵营。
在Windows阵营,IBM db2、Oracle和SQL Server三分天下。IBM db2和Oracle的市场占有率差不多,SQL Server的市场占有率比Oracle和IBM db2低一些。但SQL Server却是这三个数据库系统中增长最快的。据市场调查得知,在2004年,SQL Server在一年内增长18%,而Oracle和db2的增长率分别为15.6%和5.8%(这还是在SQL Server2005推出之前)。虽然Microsoft在技术上有一定的不足,但依靠着操作系统的优势,仍然可以保持着快速的增长势头,因此,SQL Server在Windows阵营必将成为db2和Oracle最强有力的竞争对手。
在非Windows阵营主要是db2和Oracle的竞争。自从Oracle推出第一个关系型数据库到现在,在关系数据库领域从未失去它的优势,虽然db2和Oracle的市场占有率都在不断上升,但是Oracle的增长要比db2快。因此,db2要想在非Windows阵营胜过Oracle,恐怕还要在db2上下更大的工夫才行。
自从XML逐渐成为下一代数据库的标志后,Oracle和SQL Server都在自已的数据库中加入了处理XML的功能,虽然并不是以原始形态保存的,但它们的处理速度也是非常快的。据测试,Oracle可以通过事务以每秒2500条数据的速度处理XML。Oracle数据库主管也曾说过,XML以什么形式存储并不重要,而在于你用这些数据来做什么。看来IBM要想说服Oracle以及SQL Server用户改用db2,还要费一翻口舌。
未来的DBMS将走向何方?
从第一个关系型数据库系统诞生到现在已经有30多年的时间了,关系数据库技术已经非常成熟了。但是随着数据的多元化以及网络的兴起,关系数据库已不能完全满足人们的需要了。因此,一种非结构化的数据存储形式被逐渐应用到了关系型数据库中,这就是XML技术。并且可以通过XQuery查询XML数据。但是XML也属于层次数据的一种,因此,也不能代替关系型数据库。IBM Viper是第一个找到关系模型和层次模型之间的平衡点的数据库,使这两种数据库模型完美地共存。这将使数据库技术进入一个新的时代—“混合型”数据库时代。“混合型”数据库可以将关系模型和层次模型的优点同时展现给用户。现在虽然Oracle和SQL Server还未完全做到一点,但不远的将来,这两种数据库也会拥有同样或类似的功能。到那时,将会再度燃起新一轮的战争—“混合型”数据库之战。