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

核心提示： 和其他数据库一样，DB2® V8 XML Extender 提供了两种针对 XML 的存储和访问模型：XML 文档可作为未解析文本完整地存储在 CLOB 列中，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

CLOB 中的 XML	DB2 9 pureXML
将 XML 插入到 XML Extender CLOB 列	将 XML 插入到 XML 列
对 CLOB 进行完整的文档检索	对 XML 列进行完整的文档检索
在 CLOB 中使用 XML Extender “提取”功能查询 XML（在查询时解析 XML）	对 XML 列进行 XQuery 操作
分解到关系表的 XML	DB2 9 pureXML
使用 DB2 9 的新分解特性，将 XML 分解到关系表	将 XML 插入到 XML 列
发布 SQL/XML，从关系数据构建 XML 文档 （例如之前分解的 XML）	对 XML 列进行 XQuery 操作

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

一个安装了 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 列插入的影响（无索引或索引表）

单用户数据库应用程序非常少见，因此考察并发工作负载的性能行为十分重要。我们将插入测试修改为使用 10 个各自具有到数据库的独立连接的并发线程，每个线程连续插入 10,000 个文档。 图 3 显示增加的工作负载密度大大影响了 CLOB 性能。虽然 CLOB 插入的速度在单用户测试中是 XML 插入的两倍（图 1），但是它们在多用户测试中却慢了两倍(207%)。这是因为 CLOB 插入从并行性中的获益不如 XML 列插入多。随着并发程度的提高，XML 列缓冲的插入比 CLOB 的并发直接写入更具伸缩性。

图 3：XML 和 CLOB 列的多用户插入性能比较

图 4 表明并发性加速对 XML 列的作用要远远高于对 CLOB 列的作用。将单用户 XML 插入用作 100% 基线，我们的系统和配置允许 10 个并发插入流在 18％ 的时间内插入相同的 100,000 个文档，速度快了 5 倍。CLOB 插入无法从并发性中获得相同的益处，是基线的37%，仅是非并发 CLOB 插入的 1.4 倍。

图 4：XML 和 CLOB 列插入的并发加速

我们还使用了 1000、5000、10,000 和 50,000 个文档进行了全部这些插入测试。正如所料，CLOB 和 XML 列占用的插入时间和插入的文档数成线性比例。因此为了简便起见，我们省略了相应的图表。

CLOB 和 XML 列的 XML 查询比较

为了评估 XML 和 CLOB 列之间的查询性能差异，本文设计了 5 个查询来涵盖以下常见的搜索和检索情况：

对全部文档进行全文档检索，无谓词

对匹配某个标准的一个文档进行全文档检索（一个谓词）

对匹配某个标准的多个文档进行全文档检索（多个谓词）

对全部文档进行部分检索

对匹配某个标准的全部文档进行部分检索

这些操作使用如下 5 个查询实现：

Q1 (Select*)：选择全部 XML 文档（选择 <table>中的全部文档）

Q2 (1Pred1Doc)：返回一个给定帐号的客户文档

Q3 (5PredSome)：返回全部主要地址在加利福尼亚、拥有美元帐户、尚未达到高级客户级别的女性客户的客户文档

Q4 (PartialAll)：返回每个客户的姓名及其帐户的余额总数

Q5 (PartialSome)：获取全部在其任意帐户中持有 IBM 股票的客户的主要电子邮件地址

对于 CLOB 来说，这些查询使用具有 XML Extender 提取函数的 SQL 表示。 对于 XML 列来说，这些查询使用 XQuery 表示法。无论 XQueries 是嵌入在 SQL 中还是单独执行，在我们的测试中并没有性能区别。全部查询和某些示例数据在 可下载的 zip 文件 中提供。

图 5 显示了对 pureXML 和 CLOB 进行的全部 5 个测试查询的查询性能（占用时间）。您可看到 pureXML 查询的速度可以很轻松地达到 CLOB 列中的 XML 速度的 20、30 或 40 倍。这些是没有用于表空间的系统文件缓存的默认设置的结果。图 6 包括具有 文件系统缓存的相同结果。文件系统缓存仅对查询 Q1（检索全部文档，无谓词运算）有较大影响。在没有文件系统缓存的情况下，XML 和 CLOB 列的 Q1 执行效果类似，不在缓冲池进行缓冲的 CLOB 列略微落后(10%)。文件系统缓存大大改进了 CLOB 检检索性能（参见 图 6），因此查询 Q1 速度能够达到 XML 列的两倍以上。这是因为从 XML 列读取数据需要串行化或将已解析的 XML 转换回文本格式。在没有文件系统缓存的情况下，XML 列在 DB2 缓冲池进行缓冲而 CLOB 列则不是，从而可降低开销。

图 5：查询性能，无索引，无文件系统缓存

对于查询 2 到查询 5，文件系统缓存的影响不大。这些查询通常需要子文档级访问来运算谓词和提取文档片段。这是 pureXML 的真正的妙处所在：XML 以已解析格式存储，因此在查询执行时不需要解析。在我们的测试中，这会获得 7 到 44 倍的性能加速。

图 6：查询性能，无索引，有文件系统缓存

XML 列和 CLOB 列之间的查询响应时间差异随着需要解析（针对 CLOB）或遍历（针对 pureXML）的数据量的增加而显著增加，注意到这一点是很重要的。图 7 显示查询响应时间作为表中文档数（范围从 1,000 到 100,000）的函数（不使用索引或索引表）。

图 7：查询 2 的性能作为数据量的函数

XML Extender 提供索引表的概念来加速对 XML 文档的搜索，以便避免针对谓词运算的 XML 分析。在插入时，特定元素和属性被提取到关系表。您已经知道这会给 CLOB 插入增加巨大开销，但是这也会使索引表被有效地搜索，并和包含 CLOB 的主表结合。我们的 5 个测试查询中的 3 个（q2、q3 和 q5）包含过滤谓词，这些谓词能够从索引表查找中获益。索引表能够避免许多针对 CLOB 的 XML 解析，这通常能够使 CLOB 查询速度快 100 倍或更多。

在 图 8 中，让我们将其和能够提供类似获益的具有实际 XML 索引的 pureXML 进行比较。图 8 中的全部 6 个示意条都代表不大于一秒的占用时间。而具有索引的 pureXML 的速度是具有索引表的 CLOB 列的速度的 6 到 35 倍。造成这种情况有多种原因。pureXML 索引直接指向具有对应文档的行。在使用索引表的情况下，DB2 首先对索引表执行索引查找，然后将对应的行和包含 CLOB 的主表相结合。查询 Q3 (5PredSome) 具有多个谓词、使用 3 个索引表和主表，因此它需要计算一个 4 路结合。Query Q5 对谓词使用索引表，但是需要提取函数（具有 XML 分析）来检索客户电子邮件地址。

图 8：具有索引 (pureXML) 和索引表 (CLOB) 的谓词运算

图 8 说明，即使索引表能够降低必须解析的 CLOB 数，DB2 9 中的 XML 索引也能够类似地降低必须针对谓词运算进行遍历的文档数。因此，使用索引和索引表通常能够缩短 XML 和 CLOB 的绝对占用时间，但是不会消除 XML 相对 CLOB 列较大的相对性能优势。

对 CLOB 和 XML 使用 10 个用户进行多用户查询测试。因为 CLOB 和 pureXML 存储之间的相对性能差异类似于上述单用户测试，所以这里省略了测试结果。

比较分解式存储和 XML 列

将 XML 数据分解到关系表仍然是常见的一种需求。一个典型原因是现有应用程序可能还不能理解 XML，因而需要关系格式的数据。这包括遗留 SQL 应用程序、打包业务应用程序以及 BI 和报告工具。DB2 9 中的注释 XML 模式分解（“新分解”）解决了较老的 XML Extender 分解的功能和性能限制。下一节比较了新的 DB2 9 分解性能和 DB2 9 中的 pureXML 技术。

对这些测试使用了和之前测试相同的客户数据。因为存在各种重复的元素，所以需要 12 个表中共 87 个列来代表传统关系模式中的 XML 数据。此模式如 图 9 所示，图 9 指示了在分解了 100,000 个客户文档之后，每个表中的列数和行数。总之，这些表包含 350 万个关系行，来代表这 100,000 个 XML 文档。图 9 中的箭头指示一对多关系。全部主键和外键均定义了索引，来支持 12 个表之间有效的结合。

图 9：使用关系模式持有分解式 XML 数据

比较分解方法和具有 pureXML 插入的关系表

使用此关系模式（具有DB2 9 中新的注释模式分解）分解 100,000 个文档的速度比将相同的 XML 文档插入 XML 列慢了 1.75 倍（参见 图 10）。此操作在每个文档之后执行，这是 OLTP 应用程序的典型操作。

图 10：比较 pureXML 插入和 DB2 9 分解（在每个文档之后执行）

如果降低执行的频率，就能提高 XML 列相当于分解的性能优势。每隔一个文档执行可使 XML 插入比分解快 2.56 倍（在我们的场景和配置中）。对于大量的插入或导入操作来说，如果每隔 50 或 100 个文档执行一次，可使 XML 列插入比分解快 4 到 5 倍（参见 图 11）。XML 列插入能够从较大的间隔中获得比分解（每个日志 I/O 请求有更多的日志页面）更多的益处。

图 11：比较 pureXML 插入和 DB2 9 分解（不同的执行间隔）

在执行间隔为 50 的情况下，图 12 比较了 DB2 9 中新的注释模式分解与 V8 中的 XML Extender 分解和 pureXML 插入。在我们的测试中，新的分解比 XML Extender 分解快 7 倍，pureXML 插入甚至比 V8 分解快 30 倍。

图 12：比较 DB2 V8 XML Extender 分解和 DB2 9 技术（执行间隔 = 50）

比较分解数据上和 pureXML 列上的 XML 查询

假设您需要为面向 XML 的应用程序和 web 服务（需要 XML 格式的查询结果）提供服务。如果 XML 数据被分解到关系表，那么关系查询结果必须被转换回 XML。为了实现此目的，可在 SQL 查询的 SELECT 从句中使用 SQL/XML 发布函数来构建结果集所需的 XML 标签。

图 9 中定义了关系模式的 5 个 SQL 查询，它们逻辑上等效于 XML 列的 5 个 XQueries。这些 SQL 查查询使用传统关系谓词，结合一些或全部表，并使用 SQL/XML 发布函数来返回和 XQueries 相同的 XML 结果。图 13 中显示了相关的性能结果。

Query Q2 (1Pred1Doc) 基于一个帐号查找仅返回一个文档。在两种情况下（pureXML 和发布）都具有帐号的索引来改进查询性能。虽然 SQL/XML 查询速度很快，但是仍然比 XML 列的 XQuery 慢 75 倍。这是因为 XQuery 仅需通过索引定位文档然后串行化文档，而 SQL/XML 发布必须结合全部 12 个关系表并构建 XML 文档。

Queries Q1 (Select*) 和 Q3 (5PredSome) 返回许多文档，因此增加了从关系数据构建 SQL/XML 文档的成本。Query Q4 (PartialAll) 从每个 XML 文档读取几个值，并根据这些值构建全新的文档。当使用 pureXML 存储上的 XQuery 时，值从 XML 列中读取，构建使用 XQuery 来完成。当使用分解式数据的 SQL/XML 发布时，值从关系列中读取，构建使用 SQL/XML 来完成。两种情况下的瓶颈都是构建操作。这就是两种版本的 Q4 执行结果类似的原因。

图 13：比较 pureXML XQuery 和分解式数据的 SQL/XML 发布

Q5 (PartialSome) 使用多个谓词来返回仅具有一个元素的少量 XML 文档。在这种情况下，使用 SQL/XML 的成本不太高，因为它仅针对每个结果行构建一个因素，仅结合 12 个表中的 3个。因为关系数据搜索从某种程度上比 XML 数据搜索速度快，所以其性能比分解式数据好（在我们的设置中比 XQuery 速度快 20 倍）。

结束语

虽然对于单用户工作负载来说，CLOB 插入的速度可能快于 pureXML 插入的速度，但是典型业务场景下的密集并发插入可使 CLOB 插入速度比插入到 XML 列的速度慢 2 或 2.5 倍。如果在每个文档后执行插入操作，那么 pureXML 插入速度约比 DB2 9 中的新分解解决方案快 60% 到 70%。 对于执行频率低的大量插入或导入来说，pureXML 获取 XML 数据的速度比分解甚至快了 4 到 5 倍。这些测试使用了 DB2 9 中的新分解解决方案，此解决方案的速度比 V8 中的 XML Extender 分解速度快了 7 到 8 倍。

XML 类型列中 XML 数据的 XQuery 速度比 CLOB 的对应查询（需要在查询时进行 XML 解析）速度快了 40 倍。“pureXML 查询”和“CLOB 查询”之间的绝对性能差异，随查询数据量的增加而（线性）增加。

分解式数据的 pureXML XQuery 和 SQL/XML Publishing 之间的相对性能差异主要取决于需要标记为 XML 的关系数据量，以及所需要的连接（JOIN）操作数。当必须检索复杂的数据时，XQuery 明显优于发布查询。在我们的一些测试中，从 DB2 pureXML 存储检索 XML 数据能够比从关系表中构建 XML 数据快 50 到 100 倍。然而，无需复杂结合的简单搜索查询（返回的结果带有少量或没有 XML 标签）在 SQL 中速度更快。应用程序仍然需要在查询性能和插入性能之间权衡，并评估两者的混合使用。图 14 中总结了 XML 插入的性能。

图 14：XML 插入性能总结 (commitcount =1)

请注意：本文中的全部性能结果都是在隔离的实验室环境（具有特定硬件、操作和数据库配置）下获得的。在不同的环境下进行的不同测试所获得的结果可能和本文获得的结果有或多或少的性能差异。

虽然我们的全部测量仅使用了 DB2，但是许多与 CLOB 和分解式 XML 存储有关的性能问题，是其各自的一般概念（将 XML 存储为文本或将其转换为关系数据模型）所固有的。因此，您可在支持这些概念的其他 DBMS 环境下发现类似的性能特征。对此类问题感兴趣的读者可以在自己的环境下探索此类问题，并可将本文中的材料用作开发自己的测试的基础。