为了评估 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 数据
