DB2 9中15个pureXML性能最佳实践

核心提示：我们还可以决定为每个雇员使用一个 XML 文档（细粒度），并使用一个附加的“dept” 属性，DB2 9中15个pureXML性能最佳实践(2)，表明他或她属于哪个部门，如果雇员本身使用经常独立于同部门其他雇员被访问和处理的业务对象，以便于进行高效的XML 存储访问，因此，那么这会是一个很好的选

我们还可以决定为每个雇员使用一个 XML 文档（细粒度），并使用一个附加的“dept” 属性，表明他或她属于哪个部门。如果雇员本身使用经常独立于同部门其他雇员被访问和处理的业务对象，那么这会是一个很好的选择。但是，如果应用程序常常一起处理一个部门中的所有雇员，那么每个部门一个文档会更好一些。

尤其是，我们不推荐将很多独立的业务对象成批地放入一个文档中。DB2 使用XML数据上的索引对文档进行过滤。因此，XML 文档的粒度越细，从基于索引的访问中得到的好处就越大。而且，如果应用程序使用DOM解析器来摄取从DB2 检索的XML，那么小型文档可以带来更好的性能。

与 XML 文档设计相关的一个常见的问题是，何时使用属性，何时使用元素，以及这里做出的选择对性能有怎样的影响。与其说这是一个性能问题，不如说这是一个数据建模问题。这个问题像 XML的先驱 SGML 一样古老，而且曾经历过热烈的辩论，只是最后也没有广泛地达成一致。然而，与此有关的一个重要事实是，XML 元素比属性更灵活，因为XML 元素可以重复和嵌套。例如，在我们的部门文档中，我们使用一个 “phone” 元素，如果一个雇员有多个电话号码，那么可以让这个元素出现多次。而且，当以后需要将电话号码拆成数段时，这个元素还是可扩展的。即 “phone” 元素可以有表示国家代码、区代码、分机号等等的子元素。如果“phone” 是雇员元素的一个属性，那么对于每个雇员，它只能出现一次，我们也不能为之添加子元素，这将妨碍模式随时间而变化。虽然不用属性也可以对所有数据进行建模，但是对于预先知道不会重复（对于每个元素而言），也没有任何子字段的数据项，使用属性仍是最直观的选择。属性有助于使 XML 变得更短，因为属性只需一个标记，而元素则需要一对开始标记和结束标记。在DB2中，查询、谓词和索引定义中都可以使用属性，就像使用元素一样容易。由于属性的可扩展性不如元素，DB2 可以应用某些存储和访问优化。这应该看作是额外的性能收益，而不是将属性转换成元素的决定因素，尤其是当数据建模确实倾向于使用元素的时候更是如此。

总而言之，应该根据预期的访问的主要粒度来选择XML 文档的粒度。如果仍然心存犹豫，那么倾向于较细的粒度和较小的XML 文档要稳妥些。

提示2：为了取得更好的XML性能，使用DMS和更大的页

数据库管理的表空间（DMS）可以比系统管理的表空间（SMS）提供更高的性能。对于关系数据是如此，对于XML的读和写访问更是如此。在DB2 9中，缺省情况下，新创建的表空间是DMS。还建议将DMS 表空间与自治存储一起使用，使 DMS 容器可以随需增长，而不需要人为干预。如果XML 文档太大，一个表空间中的一个页面容纳不下，那么 DB2 就将该文档划分成多个区域，然后将它们分开存储到多个页面上。这一点对于应用程序而言是透明的，这也使得 DB2 可以处理 2 GB的XML 文档。

通常，每个文档划分成的区域越少，性能就越好，对于插入和全文搜索更是如此。如果一个文档大小超出了一个页面，每个文档分成的子块的数量取决于页宽（4KB、8KB、16KB或32KB）。表空间的页宽越大，每个文档划分成的子块数量就越小。例如，假设一个给定的文档要划分到 40 个 4KB的页面上。那么，同样是这个文档，可以存储在20 个 8KB的页面上，或者存储在10 个 16KB的页面或 5 个 32KB的页面上。如果XML 文档远小于所选择的页宽，那么就不会浪费空间，因为多个小的文档可以存储在一个页面上。

经验法则是，为XML数据选择一个不小于平均预期文档大小的两倍而且不超过 32 KB 最大值的页宽。如果为关系数据和 XML数据，或者为数据和索引使用单一的页宽，那么 32KB的页宽对于XML数据而言可能有利，但是不利于关系数据和索引的访问。在这种情况下，16KB或8KB的页宽对于两者而言都是较好的选择。

提示3：必要时，如何将XML数据放入一个单独的表空间中

如果您做了性能分析，发现对于XML数据需要大的页宽，而对于关系数据或索引则需要小的页宽，那么可以使用不同的表空间来实现这一点。当定义一个表时，可以将“long”数据定向到一个具有不同页宽的单独的表空间中。long数据包括 LOB和 XML数据。

下面的例子定义了两个缓冲池和两个表空间，一个表空间的页宽为4KB，另一个表空间的页宽为32KB。（注意，一个表空间总是要有一个缓冲池，且缓冲池要有一个匹配的页宽。）表 product被分配到具有 4KB 页面的表空间 "relData"。它的所有列被存储在那个表空间中，只有 XML 列 "description" 存储在表空间 "xmldata"中的32KB的页面上。

清单 1. 两个缓冲池和两个表空间的定义

create bufferpool bp4k pagesize 4k;
create bufferpool bp32k pagesize 32k;
create tablespace relData
pagesize 4K
managed by automatic storage
bufferpool bp4k;
create tablespace xmlData
pagesize 32K
managed by automatic storage
bufferpool bp32k;
create table product(pid bigint, name varchar(20), brand varchar(35),
　　　　　　　　　　 category integer, price decimal, description XML)
　　　 in relData
long in xmlData;

DB2 9中的缺省表空间有所变化。除非显式指定，否则新创建的表空间都是具有较大行ID的DMS。这意味着，一个具有 4KB 页面的表空间可以增长到 2TB，而不是DB2 8中的64GB，具有 32KB 页面的表空间可以增长到 16TB，而不是512GB。而且，每个页面 255 行的限制也去掉了，32KB的页面上允许至多 2335 行。因此，每页的行数限制本身不再是为关系数据使用小型页面的理由。

总而言之，在为XML数据选择不同的表空间时，仍应按常理来考虑。更少的缓冲池和表空间，以及更少的页宽种类，可以导致更简单的物理数据库设计，从而更容易管理、维护和调优。因此，要避免引入多种页宽，除非您知道这样做确实可以带来性能好处。

提示4：如何配置 DB2，以便快速地成块插入XML数据

DB2 9 支持两种将XML数据从文件系统转移到 DB2 表中的选项：插入和导入。从性能和调优的角度来看，这两种选项具有类似的特征，因为导入实用程序实际上是执行一系列的插入。不管是应用程序执行批量插入（可能通过并发插入线程），还是使用导入，下面的性能指南都适用：

务必使用具有较大页宽的DMS 表空间（见 提示2），这是一个关键的先决条件。

即使没有在要成批插入数据的表上定义任何索引，DB2 pureXML 存储机制仍然会透明地维护所谓的区域和路径索引，以便于进行高效的XML 存储访问。因此，应提供足够的缓冲池空间来支持索引读操作。