DB2 9 pureXML 与 CLOB 或分解式 XML 存储之间的性能对比

和其他数据库一样，DB2® V8 XML Extender 提供了两种针对 XML 的存储和访问模型：XML 文档可作为未解析文本完整地存储在 CLOB 列中，也可以被映射和分解到一套关系表中。这两种选择都有一些已知的性能限制。DB2® 9 中新的 pureXML™ 技术试图通过以其固有的层次格式存储和查询 XML 的方式来消除这些限制。本文描述了一系列度量方法，这些方法用于确定 pureXML 是否能够提供性能优势，并量化 pureXML 和 CLOB 或分解式存储之间的性能差异。

简介

DB2® 9 中的 pureXML™ 技术旨在为 XML 数据管理提供最高级别的性能。本文比较了 pureXML™ 技术与字符型大对象 (CLOB) 和分解式 XML 存储的性能。许多数据库系统允许将 XML 数据存储为 CLOB 格式，或将数据“分解”到关系表中。DB2® V8 也支持这两种选择（通过 XML Extender），DB2 9 中仍然提供了 XML Extender，来实现向后兼容性。然而，它们将被 pureXML 特性所取代。

DB2 XML Extender 包括一套存储过程、用户定义的函数 (UDF)，以及用户定义的数据类型 (UDT)（这些类型将 XML 功能添加到核心 DB2 引擎之上）。XML Extender 的过程和 UDF 中配有 XML 解析器和特定于 XML 的逻辑，因而能够执行由传统 DB2 引擎特性支持的 XML 存储和检索。您能够使用 XML Extender 的 XML Extender Column 或 XML Extender Collection 特性。

XML Extender Column 允许将 XML 文档完整地存储为未解析的纯文本。此过程非常简单，但是忽略了 XML 文档的内部结构。您可选择将 CLOB 列、VARCHAR 列或文件系统内的文件用作基础存储。在 VARCHAR 列中，XML Extender 仅能存储最大 3KB 的文档 —— 许多应用程序很难保证满足此限制。高水平的数据库管理员 (DBA) 能够将此限制提高到 32k，但是通常情况下即使是这个最大值，应用程序也无法保证能够满足。外部文件存储更为灵活，但是无法从数据库管理的持久性和完整性中获益。这就是 CLOB（能够存储最大 2GB 的文档）成为 XML Extender Column 的最常用选择的原因。本文将在后面探究 XML Extender CLOB 列的性能。

XML Extender Collection 允许将 XML 数据转换为关系格式。这需要从预期的 XML 结构到数据库模式中的关系表集合的固定映射。基于此映射，存储过程从 XML 文档中提取原子数据值，并将其插入到传统关系行和列中。此过程称为分解（"shredding" 或 decomposition）。它涉及 XML 解析，并将单一逻辑 XML 文档插入翻译为一系列 SQL 行插入。在实际应用程序中，它能够轻松使用数十个关系表来代表原始 XML 结构中的全部一对多关系。因此，映射很快就变得复杂起来，XML 插入性能也相应受到影响。一旦使用关系格式的数据可用，纯 SQL 就可用于数据访问和操作。然而，原始 XML 文档的重构也非常昂贵。它需要以多路方式加入和生成合适的 XML 标签。这些标签可由标准化的 SQL/XML 发布函数 定义，来重构原始文档或新的不同文档。但是，XML Extender Collection 无法保留原始 XML 文档的任何数字签名。

以关系格式提供 XML 数据仍然是一个重要的需求。最常见的原因是需要向仅使用关系数据的遗留 SQL 应用程序、打包业务应用程序和商业智能 (BI) 工具馈送数据。因此，DB2 9 提供了新的 “分解” 解决方案，这种解决方案也称为 “注释模式分解” 或“新分解”，这种解决方案的速度是 XML Extender Collection 分解速度的 7 到 8 倍。本文将在后面比较这种新的高速分解方案和 IBM DB2 9 中的 IBM pureXML™ 支持的性能。

DB2 9 中的 新 pureXML 技术 和 CLOB 或分解式 XML 存储有非常大的区别。它不将文档存储为纯文本，也不将 XML 映射到关系或对象关系表。相反，它使用其固有的层次格式（这种格式匹配 XML 数据模型）存储 XML。每个 XML 文档均是定义良好的元素和属性树，并使用树遍历来表示 XML 查询。因此，对应的层次存储和处理格式会让 XML 数据管理更为有效，这一点很自然。为了详细解释此观点，本文将比较 DB2 9 中的 pureXML 和基于 CLOB 和分解式 XML 处理的性能。

测试设置

表 1 总结了本文进行的比较。本文对比了 CLOB 和分解式存储的关键 XML 操作与对应的 pureXML 操作。

表 1：比较 CLOB 和分解式 XML 处理与 pureXML

全部测试均使用以下数据和设置执行：

一个安装了 IBM® AIX® 5.2 (64位) 和单一 DB2 9 实例的 4-CPU pSeries 系统

使用了 1,000 到 100,000 个 CustAcc 文档（4kb 到 20kb 大小），这些文档来自文章 “DB2 9 XML 性能特征” 中的金融场景

页面大小为 32kb 的数据库管理的 (DMS) 表空间

全部表空间均使用 no file system caching 选项定义，除非另外声明（用于某些 CLOB 存储测试）

全部表空间分布在 10 个物理磁盘上，数据库日志位于独立的等量列中

全部测试均使用了相同的数据库配置和调优，来确保性能比较的公平性和有效性

比较 CLOB 和 pureXML 列

这种比较是很有趣的，因为对于当今相当多的 XML 应用程序来说，CLOB 列是 XML 存储最常用的选择。在 DB2 9 出现之前，没有更好的备选方案。CLOB 存储和 pureXML 处理之间的基本区别在于 XML 解析及其对插入和查询性能的巨大影响。

如果 XML 文档被插入到 CLOB 列中，那么它们就是作为未解析文本对象插入的。避免在插入时进行 XML 解析对性能有益，对于 CPU-bound 型系统尤其如此。然而，如果不进行 XML 解析，XML 文档的结构会被完全忽略。因此数据库无法对存储的文本对象执行智能和有效的搜索和提取操作。惟一的补救方法是，在执行查询时调用 XML 解析器来“搜索” XML 文档，以便找到符合搜索条件的内容。XML 解析巨大的 CPU 占用率通常会导致很低的搜索和提取性能。只有盲目、全面的文档检索（这会再次忽略内部 XML 结构）能够快速从 CLOB 列读取 XML 文档。

DB2 9 中的 pureXML 技术在插入时（而不是查询时）解析 XML 文档。XML 文档以已解析的格式被存储和查询，这在 DB2 9 中使用一种新的数据类型 “XML” 来表示。这种已解析格式使用节点树结构，有别于 XML 文档的文本表示。搜索和提取操作的执行无需进行 XML 解析，这会获得巨大的性能益处，因为 XML 解析开销发生在插入时。类似地，对 XML 列进行文档检索需要串行化，即，将已解析的 XML 格式转换回其原始文本表示。当从 CLOB （在 CLOB 中 XML 本来就是以文本形式存储的）读取完整的 XML 文档时，不存在此开销。

总之，CLOB 存储为插入和全文档检索操作提供了优秀的性能，这通常是以搜索和提取性能下降为代价的。DB2 9 中的 XML 数据类型牺牲了某些插入和检索性能，来获得更高的搜索和提取性能。这是一种合理的折衷方案，因为业务数据的搜索和分析频率要高于插入频率。通常是一次插入、多次搜索。另外，因为 XML 列在缓冲池中缓存而 CLOB 列不是，所以 XML 列的潜在开销通常会增加。

下一节介绍用于量化这些折衷方案的性能度量指标。

比较 CLOB 插入和 XML 插入

在第一个测试中，我们顺序插入 100,000 个具有或不具有索引的文档，像许多 OLTP 应用程序那样在每个文档之后提交。图 1 中的结果显示了 XML 和 CLOB 列插入之间的相对占用时间（越低越好）。将 XML 插入的占用时间用作比较基线 (100%)，维护 6 个 XML 索引仅需很小的开销（在我们的场景中是 5%）。

图 1：比较 XML 和 CLOB 列的单用户插入性能

向 CLOB 列插入相同的 XML 数据约占用一半的时间(53%)。这是因为避免了 XML 解析和对 XML 数据的进一步处理。简单地说，XML Extender “索引表”对应 CLOB 列，真正的 XML 索引对应 XML 列。在插入时维护索引表需要 XML 解析和额外的关系插入，因为选择的 XML 元素和属性值是分别提取和存储的。因此，插入占用时间至少等于 pureXML 插入的占用时间，在我们的场景中甚至高出了 23%。。

图 1 中的试验对 DB2 表空间使用了 no file system caching 选项。如果您允许 DMS 表空间容器使用文件系统缓冲（图 2），那么 XML 插入性能仅有少量改进，而 CLOB 插入性能却会下降。因为 CLOB 插入使用直接写入的方式，所以无需文件系统缓存，而仅有纯开销。然而，如果不涉及 XML 解析，那么文件系统缓存能够帮助提高对 CLOB 列的读操作。

图 2：文件系统缓存对 XML 和 CLOB 列插入的影响（无索引或索引表）