比较 XML 数据库方法

【 tulaoshi.com - Web开发 】

　　在 XML 数据库发展的早期，在所谓的原生 XML 数据库（NXD）和支持 XML 的常规关系数据库管理系统（RDBMS）之间存在很大的差异。NXD 针对存储 XML 文档做了优化，而老式的 RDBMS 只对可能包含 XML 的常规二进制大对象（BLOB）增加了一些语法改进。

　　现在，NXD 仍然是 NXD，但是更先进了。与此同时，成熟 RDBMS 的供应商努力改进了 XML 文档的存储方法。XML 片段不再被存储到 BLOB 中，而是存储在树结构中。典型的 XML 文档的基本性质就是采用树结构，所以这一改进大大提高了 RDBMS 处理 XML 文档的能力。

　　从早期实现到现在的成熟解决方案之间的这段时间里，在 XML 文档的查询语言标准化方面有了一些重要的进展 —— 其中最重要的是 XQuery 1.0 和 XML Path Language (XPath) 2.0。XQuery 的概念经过了多年开发；最终结果与早期版本有相似之处，但是更加成熟。与 Structured Query Language (SQL) 一样，XQuery 也重视促进供应商独立性和重用。

　　为什么需要 XML 数据库？

　　常规数据库可以存储高度结构化的数据和非结构化数据。这两种数据都需要使用不会频繁变化的数据结构。但是，关系数据库的弱势在于存储半结构化文档方面。与结构化数据不同，这些文档在文档元素的次序和元素相互嵌套的方式方面有很大的自由度。与非结构化数据不同，可以使用描述性标签对元素进行分类。这些元素往往是细粒度的。

　　能够在关系结构中存储半结构化数据吗？当然可以，但是最终很可能形成频繁变化的特殊数据结构，因为一般化的数据结构会丧失标签的描述性；或者使用内容管理系统使用的那种抽象模型，但是这会把数据与元数据混在一起。

　　另一方面，XML 格式非常适合描述半结构化数据。另外，可以轻松地维护数据模型。添加新的元素名并不会改变数据结构 —— 它总是树结构。只需修改 XML 模式，XML 模式描述在树结构中使用和关联元素名的方式。

　　对于工作履历、产品说明和客户订单等文档，XML 可能是最合适的格式。同时，XML 也能够描述结构化和非结构化数据。

　　那么，还需要关系数据库吗？

　　在创建新的软件解决方案时，答案可能是 “不需要”。如果您有一个能够存储半结构化数据的解决方案，那么也能用它存储结构化和非结构化数据。用一个存储解决方案存储所有数据，就能够方便地连接和查询所有数据，这比集成多个存储源中的数据容易得多。

　　但是准确地说，如果要对这个问题回答 “不需要”，那么您的大多数数据应该是半结构化的文档。但是，如果大多数数据更适合采用高度结构化的实体-关系模型，数据不太像文档并且关系更复杂，那么选择 NXD 可能并不合适。

　　那么，如何判断数据的性质呢？另外，如果结构化、半结构化和非结构化数据的数量大体相当，那么怎么办呢？对于这些不确定的情况，好消息是当今的传统数据库已经能够很好地处理 XML 文档或 XML 文档的片段了。在不同的数据库中，访问这些 XML 片段的方式可能有所差异。但是，它们有一点是相同的：它们都使用 XQuery 1.0 规定的构造。

　　解决方案

　　市场上的一些产品以不同的方式实现 XML 数据库，包括 Xindice、Tamino、X-Hive、Oracle 和 Microsoft® SQL Server。但是，我不打算在本文中讨论这些产品。完整全面地比较所有产品是不可能的；另外，本文发表在 IBM 的网站上，而 IBM 是提供 XML 数据库解决方案的厂商之一，因此在此对各种产品发表评论也不容易获得您的信任。虽然我是一名独立的作家，但并不能保证中立性问题。

　　我能做的是讨论具备 pureXML 特性的 IBM DB2 Express-C 并与典型的 NXD 做比较。我选择开放源码项目 eXist-DB 作为 NXD 的代表。eXist 和 DB2 Express-C 都是免费的，都提供了大量用户友好的功能。

　　如果您需要存储非常多的数据，那么我建议您购买 DB2 的商业版本。您可能觉得 DB2 过分繁杂，但是可以先在桌面计算机或笔记本上安装 DB2 Express-C，体会一下 pureXML 功能，这是很容易的。尽管 eXist 没有商业版本，但是如果 eXist 的功能无法满足性能和可伸缩性需求，Mark Logic 是不错的替代产品。可以使用 30 天试用许可证评估 Mark Logic，也可以使用存储空间限制为 100MB 的社区版本。

　　我可以想像到读者需要对 DB2 和 Oracle 等相似产品的比较。但是，在网上可以找到对这两个产品的各种评论。更基础性的讨论是对 DB2 Express-C 中的 pureXML 特性与 eXist-DB 或 Mark Logic 做比较。

　　原生 XML 数据库

　　与大多数产品类别名称一样，原生 XML 数据库 这个词也有点儿容易引起误解。它引出了几个问题：什么是数据库？什么是原生 XML？DB2 是 NXD 吗？

　　根据 Wikipedia 上的说法，“计算机数据库是存储在计算机系统中的记录或数据的结构化集合。” 原生 XML 是使用与 XML 相关的技术，但是不与非 XML 技术混合使用。这意味着能够使用 XQuery 和 XPath 而不需要借助于 SQL。IBM 预料到人们会问 DB2 是否是原生 XML，所以把 DB2 的 XML 特性命名为 pureXML。我将在 下一节 讨论 pureXML 的定义。

　　在比较 NXD 和支持 XML 的 RDBMS 时，我认为典型的 NXD 也可以被看作文档存储库。但是，Alfresco 和 Magnolia 等产品使用了文档存储库 这个词，而这些产品是在现有数据库之上建立的，它们缺少 eXist 和 Mark Logic 提供的那种基础结构，尤其是以高效的方式执行 XQuery 的能力。它们主要关注比较高层的功能，比如工作流和用户友好的界面。NXD 把这些功能留给产品的用户去开发。它们只提供低层的文档存储库 API，比如 Web-based Distributed Authoring and Versioning (WebDAV) 或定制的 REST 式连接器。

　　因此，典型 NXD 的特点是以高效的方式存储 XML 文档。它提供 XQuery 技术和基本的文档存储库功能层。

　　NXD 往往是面向资源的，这实际上意味着可以使用 Uniform Resource Identifiers (URI) 标识存储库中存储的内容。可以通过 HTTP 或 WebDAV 使用相同的 URI 访问数据，这就消除了连接问题。

　　但是，把数据视为资源也有缺点。文档相互分隔导致很难在多个文档的数据之间建立关系。如果一个文档包含其他文档引用的可靠数据，就很难维护引用完整性。比较大的 XML 数据库供应商提供了对多个文档的数据实施约束的特性。但是，这个特性还没有标准化。

　　pureXML

　　尽管 IBM 避免使用 “原生 XML 数据库” 这个术语，但是仍然希望他们的解决方案能够体现 XML 的本质。DB2 Express-C 并不是典型的 NXD，但是它具备 NXD 的一些特点。从某个角度来看，DB2 像是常规的 RDBMS 加上支持 XML 的列。如果您只需要使用关系数据库，而不打算使用 XML 技术，那么只需忽略支持 XML 的列。但是，如果需要 XML 特性，支持 XML 的列就能够提供相当好的 XML 功能。

　　pureXML 这个名称有两方面的意义：

　　XML 数据按照原生的树格式与关系数据分开存储。

　　可以通过单一 XML 接口访问所有数据，包括关系数据和 XML 数据。

　　XQuery 1.0 不仅能够查询 XML 文档。IBM 提供的 XQuery 函数允许查询关系数据，并与来自支持 XML 的列的 XML 结果组合在一起。可以以 XML 格式返回组合数据的结果。

　　DB2 是纯粹的数据库基础结构。与许多 NXD 不同，它不提供基本的文档存储库功能层。这并不意味着不能使用 DB2 实现文档存储库。目前，Alfresco 等大多数文档存储库都是在非 XML RDBMS 之上实现的，而不是依赖于 NXD。使用 DB2 作为这些存储库的基础至少不会损害它们目前提供的功能，而且有可能使用 XML 存储功能提供更灵活的数据模型。

　　Alfresco 等产品可能需要过一段时间才能利用 pureXML 等特性。原因在于这些产品不愿意与单一数据库产品捆绑在一起。尽管 XQuery 1.0 已经发布了，但是在数据库产品中使用 XQuery 语言的方式仍然不够标准化。对于这些产品，比较安全的做法是推迟使用 XML 数据库的新功能，等到 XQuery 和连接协议的使用方式比较统一了，再采用这些新功能；目前，只使用 WebDAV 或关系数据库连接器等比较统一的实现。

　　在什么情况下可以使用 DB2 的 pureXML 功能？

　　答案很简单。大多数 IT 解决方案已经在关系数据库方面投入了大量资金。即使关系数据库缺少解决方案所需的灵活性，与替代技术相比，它们仍然更成熟，更适合满足复杂的业务需求。

　　即使公司希望采用 XML 技术，也不太可能愿意放弃多年来在关系数据库上的开发成果并用 NXD 替代它。另外，尽管可以在保留现有关系数据库的同时使用 NXD，但是这会在集成多个数据源的数据方面产生新的难题。考虑一下事务处理和引用完整性，就能够明白这有多么困难。尽管这些问题不是无法解决的，但是能够处理这些问题的综合解决方案可以避免许多麻烦。

　　pureXML 技术能够把关系数据和 XML 数据组合在一起，这有助于更顺利地迁移到 XML 技术，或者进行部分迁移。

　　结束语

　　尽管 XML 文档能够描述结构化数据，但是对于描述多个文档中的结构化数据之间的关系和维护引用完整性，包含许多 XML 文档的 NXD 可能不是最好的解决方案。即使能够管理这些关系（比如使用 XPointer），使用方式也不是标准化的。

　　最好的建议是，用合适的工具做合适的事。但是，同时使用 NXD 和 RDBMS 会产生集成难题。DB2 的 pureXML 特性能够把关系数据和 XML 数据两方面的优势结合在一起，能够同时存储结构化和半结构化数据。对于非结构化数据的存储，NXD 和 RDBMS 是同样合适的。

　　如果您需要的实际上是文档存储库，而不是数据库，那么应该问另外一个问题。您的需求主要关注文档存储库的前端功能，还是后端功能？如果需要大量最终用户功能，比如管理界面、工作流和可视化，那么市场上有许多产品提供这种支持，比如 Alfresco。如果您更关心强大的查询机制（比如 XQuery 和全文搜索）和高效地存储半结构化数据，那么 eXist 或 Mark Logic 等 NXD 可能是您需要的。

　　数据库解决方案领域由几个大型供应商控制着。IBM 是其中之一。NXD 仍然是一个有许多小公司参与竞争的市场。这些小公司是否能够在竞争中生存下去，它们是否会被大公司收购（比如 EMC 收购了 X-Hive），它们是否会丧失市场份额，这些都无法确定。目前的趋势很明显，RDBMS 供应商不愿意把市场份额让给 NXD，它们会提供完全成熟而且更全面的 XML 解决方案，以此满足客户的需要。