“毒蛇”出洞

开篇：润墨网以专业的文秘视角，为您筛选了一篇“毒蛇”出洞范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

IBM的“Viper(毒蛇)”新版数据库带来了许多新的特性和功能，但这些新变化能否被开发者接受，仍需假以时日。

IBM新的DB2 9.1以前代号为“Viper”（毒蛇），它在许多方面对前一个版本做了大大小小的改进，其中包括性能、扩展性及安全等方面。但IBM声称，尤其是其中一项特性：新的XML引擎将在结构化存储管理领域开辟新时代。

原生XML数据库问世已有一段时日，但作为数据管理解决方案，它们往往有所欠缺。它们需要特别的库，而且与关系数据不相兼容。话虽如此，XML仍是存储层次数据的一个重要工具。传统的关系数据库处理层次模型比较困难，而且在这方面的功能非常有限，所以各大数据库厂商一直忙于把XML功能添加到各自的关系数据库产品当中，IBM也不例外。不过，IBM技术的特点在于它能保护原生格式的XML数据。DB2的全新存储引擎名为纯XML（pureXML），先后开发了五年，它如同一只脚径直踏入关系数据库领域，另一只脚踏入XML数据库领域。纯XML可以存储XML文件本身，并且保护了所有属性和层次结构，而不是把XML作为二进制大文件（BLOB）来存储，或者把它解析成关系键/值对。

IBM把这款焕然一新的DB2称为全新的“混合型数据服务器”。既可以偏向于认为结合纯XML的DB2是分为两个部分的单一数据库引擎，也可以认为是两个独立，但完全紧密配合的引擎（参阅插图《透视IBM的混合型数据库》）。有一点可以肯定，这个版本确实提供了令人关注的一些特性。

首先，它能够使用SQL查询来访问XML数据，就像是普通的关系表。除了XML外，还可以使用XQuery来访问关系表，甚至可以使用SQL限制从XQuery表达式取回的数据的范围。DB2允许几乎连续不断地混合使用两种语言。

纯XML引擎还提供更有效的索引功能，因为单个的XML节点不是仅仅作为字符串来存储。已经采用这个新引擎的客户声称，性能比使用微软或者Oracle的引擎大约提升了5%到7%。

与关注XML的这种态度相一致的是，IBM还提供了许多新的开发工具。新的开发工作台（Developer Workbench）取代了原先的开发中心，除了Visual Studio 2005插件方面进行改进外，它还提供了新的XQuery构建器。

有必要迁移吗？

当然，现在的一大问题是，DB2的混合功能到底会吸引多少客户？分析师们对此观点不一。目前，对于IBM是否知道这项新技术带来的确切影响，我心里没谱。就算IBM知道，它也不会告诉世人。

完全可以想象：一些应用软件能够充分利用混合型的XML/关系数据存储区。譬如说，临床数据库可能含有病人的关系表，里面有病人的各种相关信息，外加作为XML存储的药物过敏清单。这种记录可以进行关系建模，但使用XML却是减少联接（join）数量、减少开发工作的一个好方法，因为再也不必维护病人和药物过敏之间的关系了。可以处理类似订单和订单细节的信息，其中每个订单把行项目存储为XML，而不是典型的行项目表。

尽管具有上述潜在优点，但混合使用SQL和XQuery表达式却是另一回事。在两种查询方式之间来回切换变得过于复杂、很难迅速读取。笔者怀疑：大多数开发人员会千方百计避免编写这些类型的混合型应用软件。

考虑到IBM在XML数据方面进行的优化，与任何性能提升一样，读者肯定会问：这对企业来说意味着什么？考虑到目前XML装入四大数据库（注：SQL Server、Oracle、Sybase和DB2）的任何一个引擎速度都相当快，性能提升5%，其实只相当于时间缩短几毫秒。大多数客户甚至不会注意到这样一个差异，更不用说成为使用它的理由了。

纯XML引擎的一项非常值得关注的特性就是，它能保护签名XML文件的数字签名。如果接到数字签名的XML文件，可以把它装入数据库，将来可以随时获取，而数字签名仍将保持原状。微软和Oracle做不到这点，但再强调一下，保护数字签名不是广泛需求。

因而，尽管纯XML很酷，但笔者认为这项特性不会大幅降低总体拥有成本（TCO）。迄今为止，摆这种酷似乎基本上是为了技术而技术。就因为DB2具有某种功能，未必能让它成为最佳策略。

结论：DB2 9.1这款出色的数据库拥有诸多开创性的特性。新的混合型数据引擎提供了真正的原生XML存储，可以检索整个数据存储区，使用SQL或者XQuery，两者可以互换。此外，新的开发工作台因支持创建XQuery表达式而颇受好评。其他新特性包括：行级压缩、扩展性方面的改进，以及高级、细化的访问控制。

扩展性达到新高度

幸好，DB2的XML功能不是新版本的惟一改进之处。扩展性是IBM格外注意的另一个方面。

首先，通过使用比较大的记录标识符，DB2 9.1让管理员可以为内容比以前大得多的系统和用户查询创建临时工作表。单单一个表的大小也已经增加到了惊人的1.1万亿行或16TB，不管先达到哪个极限。当然，这两者都是相当危险的。如果真要创建这么大的对象，可能会遇到严重的性能问题。不过，要是在查询速度缓慢和根本无法查询之间做选择，还是选前者比较明智。

再来说说DB2的查询极限。DB2允许查询内容长达2MB。于是笔者决定试验一下。笔者把查询内容拷贝到Word里面，直到查询长达2MB，结果内容在64页左右。虽然我无法想象这么长的一个查询，但还是假定它对某些人来说是有用的。同样，如果预知自己的表里面的行会超过1万亿，那么使用DB2会让你交好运。

统计视图（statistical view）是DB2 9.1在扩展性方面的另一项特性。查询优化器通常使用统计数据来估计存储在表里面的数据的基数，这个基数是用来为特定查询确定执行计划的主要因素之一。统计视图把这项功能扩大到了视图，这意味着如今视图不仅被认为是导出表（derived table），实际上更像是作为表来对待。IBM不是惟一考虑模糊视图和表之间界线的厂商，却是最先付诸行动的公司。

基于标签的访问控制

自版本8.1以后，Oracle也有高级的行级访问控制特性。DB2 9.1正在迎头赶上，不过采用的方法稍有不同（遗憾的是，SQL Server根本没有类似功能，听说，甚至明年的代号为Katmi的新版SQL Server也没有考虑这项特性）。虽然对行级数据（视图和存储过程）的访问进行控制的传统方法仍在发挥作用，但DB2基于标签的访问控制（LBAC）让人放心不少：因为它可以防止用户避开你所采取的安全措施。

譬如说，使用传统的访问控制，可以创建视图，指定某个用户只能查看某个区域的客户，或者只能查看客户表里面的某一列。不过，知道基本表名称的用户只能对表进行查询，而不是使用视图。另一方面，有了LBAC，可以指定安全策略来控制对特定列甚至特定范围行进行访问。

其他数据库使用传统方法也能获得诸如此类的安全级别，区别在于所需的管理级别。譬如说使用传统方法，可以创建存储过程，为一组用户赋予访问数据的权利。如果出现了另一组用户，可以编写另一个存储过程，为他们同样赋予所需的访问权，依次类推。你必须维护已经编写的所有程序，并且跟踪哪几组用户可以访问每个程序，但优点在于，一个存储过程并不影响其他存储过程，它不需要太多规划。

如果使用LBAC，确实需要明白自己希望安全策略起到怎样的作用。如果出现的一组用户需要不同的访问权，可能需要重新设计整个安全策略以便策略顺利执行。不过就长远而言，LBAC方案所需的日常管理要少得多，这是因为所有工作事先都做好了，不必为维护不同版本的存储过程等内容而操心。每种方案各自都有一席之地，使用LBAC的公司可能会发现自己在结合使用两种方法。

减少数据量

DB2的行级压缩是笔者最喜欢的新特性之一。它实际上是表级压缩，可以直接把存储空间节省45%到75%。

笔者先进行了初始基准测试，就是想了解一下两个完全相同的表在性能上有什么差异，一个表经过压缩，另一个表没有经过压缩。结果发现，两者的性能很相近，但经过压缩的表性能实际上往往胜过没有经过压缩的表（大概是因为后者在内存中的数据更多）。

笔者在进行下一个测试时，把数据库放到了内存只有1GB的服务器上，看看内存较小的系统如何利用压缩机制。笔者发现，在这种情况下，经过压缩的表其表现根本不如在内存为4GB的服务器上来得好。因为DB2把压缩词典放在内存里面，所以，服务器处于忙碌状态时，比较少的内存使得压缩词典被分页到了磁盘上。

不管导致性能降低的实际原因是什么，如果想使用行级压缩，就要确保把数据库放到生产环境之前，先对它进行全面的基准测试。即使有大量的内存，可能也会对各种情况造成性能低下的现象而大吃一惊，如果没有专用的数据库服务器，更是如此。虽然如此，如果非要挑一项DB2领先于其他任何数据库的特性，肯定非这项特性莫属，因为它对最大一部分的用户来说极其有用。可以设想：Oracle和微软都在竭力成为将这项特性投向市场的下一个厂商。

到跳槽的时候了吗？

新的DB2是技术出众的一个版本。它所具有的丰富特性势必会吸引DB2管理员和开发人员。不过，至于这些特性的吸引力是否足以打动忠诚的Oracle数据库管理员改用平台，那还是个未知数。

在XML方面，纯XML引擎大获全胜，但它在商业领域的重要地位仍须拭目以待。可扩展性特性（包括比较大的临时工作区和统计视图）让DB2能够更加吸引高端市场，但未必会吸引比较小的客户。

大多数客户会发现Viper开创性的行级压缩特性可带来最大的回报。不过虽说这项特性无疑会为目前使用DB2的公司降低TCO，但根本不足以成为让客户移植到新平台上的理由。同样对其他众多特性而言――无论是XML查询方面的改进，还是灾难恢复方面的改进，它们都很吸引人，却不是完全创新的。

总之，该版本对于现有的DB2用户来说相当出色，不过在竞争激烈的关系数据库市场，它要费很大的劲才能吸引更多的人转投DB2。DB2的新特性显然彰现了IBM的技术水平，不过它们可能为尚未出现的新特性奠定了基础。但到目前为止，业界还没有感受到许多这些特性具有的价值。也许通过今后几个版本，随着IBM及其客户开始完善这些技术、从事无人能做的工作，DB2的真正回报才会随之显露出来。(编译自《Infoworld》)