« 如何更改控制文件自动备份的路径 | Blog首页 | 2007 年终总结-Eygle.Com的发展历程 »

旧文:2006数据库技术回顾与展望

题记：翻到一篇去年为《程序员》杂志写的一篇文章，发表在《程序员》2007年第一期上，收录在这里，回顾以及纪念。这篇文章是对2006年数据库技术发展的一点总结，今年回顾2007年数据库市场发展时又想到了这篇文章。
---------------------------------------------------------------------------------------
自从1970年E.F.Codd 博士发表那篇著名的论文（A Relational Model of Data for Large Shared Data Banks）以来，关系数据库的发展已经经历了一个漫长的历史过程:关系数据库理论早已成熟，而关系型数据库技术却只是在完善的道路上不断前行。

关系型数据库将会走向何方？这么多年来一直是大家广为关注的话题。长期以来，关系型数据库一直向着容纳更多、需求更少、应用更高等方向发展。

数据库的发展方向之一----容纳更多
所谓容纳更多，也就是将更多样的数据存入数据库之中，不断扩展数据库的存储能力。从早期的文本数据到现在的音频、视频数据，各类文档、非结构化XML数据等，几乎所有的数据都可以被存储在数据库之中。

从这个意义上说XML数据也只是数据库向存储更多方向发展的一个产物。

在2006年，数据库领域一个令人瞩目的事件是IBM发布了DB2 V9 Viper数据库版本，在这一数据库版本中，IBM引入PureXML 支持，这意味着XML数据将以其自身固有的分层格式进行存储和查询；通过将原生XML带入传统的关系型数据库中，使 得关系型数据可以和非关系型数据在同一数据库中并存，IBM期望通过XML数据的灵活性来弥补关系型数据库在这方面的不足。

而且依托于IBM的种种技术创新，新的XML技术和传统的以大对象方式存储具有本质的区别，这更被看作关系型数据库向传统数据库的一种回归。从这个意义上说，IBM在2006年引导了数据库市场的一时之风。

我们来看一些分析数据，根据Gartner公司的统计数据，在2005年，Oracle的全球市场份额为48.6%，IBM的市场份额为22%，微软的市场份额为15% （下表所示市场规模单位为百万美元，数据来自Gartner公司官方网站）：

而根据最近国内统计公司易观国际的统计数据，在2006年第三季度，国内市场的数据库市场规模达到4.63亿元，具体份额分布情况为：Oracle占有39%，IBM占有26%，微软为17.8% （统计数据来自互联网）

如果Q3国内的统计数据基本准确的话，我们仅通过两个统计数据粗略类比一下比例份额：Oracle份额有所下降，DB2取得了一些增长;

那么这可能说明IBM的DB2 V9 Viper在国内已经取得了一定的进展，有的用户已经逐渐开始尝试这一全新的数据库版本。

伴随IBM铺天盖地的宣传攻势，可能有用户已经向DB2倾斜 ; 可是长期的趋势有待更全面的统计数据。

数据库行业的领先者Oracle在2006年并未发布新的软件版本，自2004年Oracle10g开始推出以来，Oracle一直在对这一版本进行不断修正，在2005年Oracle发布了Oracle10g Release 2版本；而在2006年，Oracle在服务方面进行了大规模的调整，这包括使用Oracle自己的HTML DB技术重构了Metalink站点（Oracle的技术支持站点）、修改用户注册和激活方式等，在新的模式下，服务过期的用户将会无法访问Metalink的资源，而在此之前，服务过期的用户是可以访问Metalink获得文档资源或下载补丁的；据统计，这一修正已经促使了很多用户续签或再次购买Oracle的技术服务。所以我们猜测Oracle在2006年的营收方面仍然会有不俗的表现。

在2006 Oracle OpenWorld技术大会上，Oracle又一强势举动是宣布提供企业级别的Linux 支持服务，并且很快发布了打上了Oracle Logo的Enterprise Linux，这也就意味着Oracle已经开始染指操作系统，强化并完善其战略布局。

自从Oracle随Oracle10g发布了群集支持软件CRS(Cluster Ready Services-Oracle的群集支撑软件)以后，大家一直在猜测Oracle进军操作系统的步伐，现在Oracle已经做出反映。

虽然Oracle在2006年并没有推出强势的数据库功能以抗衡IBM的PureXML技术，但是Oracle在完善战略布局，加强服务等方面的确取得了重大进步。在2006年Oracle最大的举措就是通过完善服务、升级软件来进一步稳固自己的市场。

数据库的发展方向之二----需求更少

随着关系型数据库的不断成熟，数据库向着需求更少的方向发展。所谓需求更少是指数据库以更少的相对资源消耗、更高的性能运行，并且随着技术的不断进步，数据库变得更加智能，维护和使用将更加简单。

在这一方面，Oracle数据库一直走在前列，从Oracle9i开始，Oracle一直致力于是数据库软件更加自动化，在这一原则的支撑下，Oracle不断实现了诸如自动PGA管理、自动SGA管理、自动段空间管理（ASSM）、自动存储管理（ASM）等等新特性，这些新特性切实降低了DBA的工作量，使得数据库的管理更加简单；而IBM DB2也一直在加强这方面的功能，IBM的SMART技术（Self-Managing And Resource Tuning -自我管理和资源调优）正是在这些方面的增强。在DB2 V9中IBM同样推出了一系列的自动化特性，包括自动数据库管理功能、自动统计数据收集等功能，但是这些特性相较Oracle而言是来之甚晚的，所以在2006年IBM主推的是XML这一重大改进。

根据Oracle公司在2006年10月举行的OpenWorld大会上公布的统计数据，自Oracle10g发布以来，仅有约一半的用户升级到Oracle10g，其他用户仍然维持在原来的版本运行 ; 所以IBM的Viper能否得到用户的认可取得成功，还有待检验。

在2006年的OpenWorld大会上，Oracle展示了新的数据库版本Oracle11g（正式版本可能不叫这个名字），从公开的有限的资料看，在这一版本中，Oracle在易用性方面做出了进一步的增强。这包括最受瞩目的在线应用升级等特性，Oracle期待通过Hot Patching等功能实现Oracle数据库的无宕机(No Downtime) 维护，Oracle所作的所有增强都是用户最为需要的。

一直以来，用户最关心的是XML技术的性能问题，由于在转换过程中，大量标签、标记的引入，XML会带来大量的冗余数据，从而影响性能，那么XML数据库的性能到底如何？我们可以从IBM官方的测试数据来获取一点直观的印象 :

IBM工程师通过一个测试场景对金融公司在线经纪业务进行建模。

处理器：IBM System p5 560Q， 8处理器的逻辑分区（LPAR），1.5GHz 频率 内存 : 32GB 操作系统 : AIX 5L v5.3 TL04 存储 : IBM TotalStorage DS8100

测试插入工作负载的结果

插入36,020,833个文档花费的总时间大约是160分钟，产生的平均吞吐量是每秒3770个插入。吞吐量随文档的大小而变化 :

订单文档(1K到2K)以平均每秒 5320个插入的吞吐量插入。
帐号文档(3K到10K)以平均每秒1550个插入的吞吐量插入。

插入这两种文档的数据量速度都是大约每小时30GB。下图显示随着订单数量增长到300万个文档，订单插入的速度几乎保持不变(见下表)。

测试查询工作负载的结果

查询工作负载随着 CPU 利用率接近 100%，吞吐量曲线逐渐变平。最好的吞吐量出现在有 150 个用户的情况下，在 CPU 利用率为 96% 时达到每秒 5480 个查询(见下表)。

测试混合工作负载的结果
混合工作负载最好的性能也出现在有 150 个并发用户时，吞吐量是每秒 1980 个事务(见下表)。

大家可以根据自己的业务规模、设备性能大致估算出自己系统的性能指标。随着硬件系统的不断升级，性能也许不再是人们主要关心的问题。

通常我们认为，技术的进步有两种，一种是用户推动的变革、一种是由厂商推动的革新。前者为用户所接受是顺理成章的，而后者则会相对困难。

从目前的情况来看，Oracle为用户所不断推动，而2006年，IBM一直在不遗余力的推动其XML新特性，至于结果怎样，也许只有时间能够告诉我们。

数据库的发展方向之三----应用更高

随着数据库技术的不断完善，用户数据的不断积累，用户的需求也不断提高，在此之上，更高级的应用应运而生，这包括已经成熟的数据仓库应用、广为接受的商业智能（BI）应用、以及方兴未艾的SOA等。

当数据库能够容纳几乎所有数据之后，我们必然面临的一个问题是如何快速获得我们需要的数据，这也就需要另外一项高级增强----面向搜索的增强或者说面向需求的增强----数据分析和挖掘。

微软公司2006年12月发布的Vista操作系统中，微软已经将搜索框加入到开始菜单的最初始位置，让用户最先接触到搜索，最快的找到用户的数据 ;2006年，Google获得了飞速发展，Google带给我们的最大便利就是快速的获取数据。

那么无疑，关系型数据库和相关应用也必然朝着这个方向不断发展和完善。

By eygle on 2008-01-08 14:39 | Comments (0) | Advanced | OraNews | 1736 |

Database