使用 DB2 pureXML 管理 XML 数据的最佳实践

内容提要

本文 为使用 DB2 pureXML™ 来有效的解决商业问题和在企业应用程序中高性能的管理 XML 数据提供了原理和指南。在样例中举例说明了基于真实世界金融应用场景的最佳实践，并示范了如果执行这个指南。这个例子可以很容易被应用于其它类型的 XML 应用程序。下面是一些本文中的最佳实践的描述。

XML 数据用于提高性能和存储有效性的存储选项

• 对 DB2 DMS 表空间启用自动存储。
• 为 XML 数据使用更大的页大小，比如 16KB 或 32KB 。
• 如果性能分析需要，就为 XML 数据选择一个不同的表空间页大小。
• 很多 XML 文档足够小并且能和其它 non-XML 数据存在数据页上，就为 XML 文档使用内嵌存储。否则文档存放在表之外，类似于 LOBs，并且通过区域索引来访问。
• 使用压缩来减少 XML 文档以 inline 方式存放时的空间大小。

在 DB2 数据库中添加 XML 数据的技术：

• 为了提高你在使用 insert、import 或 load 添加数据时的性能，
  • 使用使用较大页大小的 DMS 表空间，比如 16KB 或 32KB 。
  • 提供足够的缓冲池空间以支持 XML 区域索引和路径索引的读取。
  • 如果你有多个用户定义的 XML 索引，通常最好在添加数据之前定义它们。
• 如果有必要，把行抽取选中的 XML 元素值放入到和 XML 文档相同的关系列中。关系列中存放的数据允许简单、SQL-only 的形式来访问重要的数据或经常访问数据条目、可以定义主键、外键或其它约束、以及可以定义多列（组合键）关系索引。
• 如果更小的片段更适合数据访问的粒度，就把大型 XML 文档分割成更小的片段。
• 定义触发器来对插入和更新 XML 数据进行自动验证

有效查询并更新 XML 文档的技术：

• 使用 SQL/XML 函数 XMLTABLE 或 XMLQUERY 来从 XML 文档中抽取数据。
• 在 SQL WHERE 子句中使用 XMLEXISTE 谓词来指定对 XML 数据的谓词，通过检查更少的行来提高查询性能。
• 使用一个完全指定的 XML 路径，而不要使用通配符 * 或 // 来定位到期望的 XML 元素。这样做可以提供更好的性能，因为 DB2 可以跳过 XML 文档中不相关的部分直接找到期望的 XML 元素。
• 出于增加商业洞察力和最大化一个混合数据库服务器的价值的需要，你在查询中需要要对 XML 和关系数据进行连接。
• 当在一个 XML 文档中更新多个元素时，把更新合并到一个转换描述中以获得最佳的更新性能
• 在查询中声明名称空间，更新 XML 索引以匹配你的 XML 商业数据。这个让你能从多个或复杂的域中处理 XML 文档。

  为什么使用 XML

  XML 提供了一个普通而具有弹性的方法来在不同的系统、应用程序和组织之间交换数据。使用 XML，数据是在一个可扩展自描述格式下进行维护，以提供给所有涉及的商业需求。 XML 文档是用标签来描述它们包含的数据值，并且通过嵌套标签来表示数据条目间的层次关系。 XML 可以描述高度结构化的数据并通过 XML 模式来保持结构，但是它也能描述半结构化的数据，这些数据普遍存在于内容为导向的应用程序。

  以服务为导向的架构（SOA）、企业应用程序整合（EAI）、企业信息整合（EII）、Web 服务、企业消息总线和很多依赖于 XML 作为底层数据交换技术的标准化成就。

  就像行业这样的机构使用标准化的 XML 模式来促进信息交换并且发展那些模式来满足变化中的商业需求。这些努力包括在保险行业中的 ACORD、金融行业中的 FpML 和 FIXML、供应链管理中的 違規廣告、零售商业中的 ARTS、卫生保健中的 HL7、商业报告里的 XBRL 和在印刷行业中用于授权、管理和发布文档的 DITA 以及整个网络。

  这类具体行业创新（比如管理需求）在驱动 XML 发展。越来越多的企业事务通过基于网络接口和电子表格来操作。政府代理和商业企业对保留原始订单、请求、申明、交易或签名承担更多的责任。 XML 提供了一个简单的方法来抓取并维护和那些电子交易相关的数据。事实上，XML 文档常常在基于消息的事务系统中表现事务记录。

  XML 和关系数据的优缺点

  作为一个自描述数据格式，XML 允许不同的数据（有模式或没有）在不牺牲搜索或聚合能力的情况下被同时存在一个文档中或某一行中。应用程序可以在对底层数据库模式不进行任何改变的情况下发展他们自己的 XML 模式。然而，对于 XML 的这种扩展意味着比起存储在关系表中的数据在检查和解释 XML 数据时会花费更多的 CPU 和 I/O 资源 – 这可能不切实际。

  对更多的刚性模式定义，关系模式需要更少的解释并允许更多的优化数据操作。就像这样，他可以提供非常高的性能，不过却不能满足应用程序需要的模式弹性。关系型数据模型非常适合有稳定数据结构和可预知访问形式的应用程序。 XML 更适合有复杂多变数据结构以及混有结构化和非结构化信息的应用程序。

  在某些情况下，XML 提供的性能好处超过了关系模型正好是因为它的弹性。关系型数据库经常需要标准化来使商业数据适应简单平坦的结构。对复杂商业数据的标准化需要在数据存取的时候进行转化，并经常在关系型数据库中导致多路的连接需求。 XML 可以在一个文档中更自然的表现复杂的商业对象以及对象间的所有关系。在一个 XML 文档中的层次本质上就是预先计算的相关数据条目之间的连接。

  在选择一个数据模式时的另外一个考虑是应用程序使用数据。就算数据源自 XML，如果数据后来的处理取决于存储在表格中的数据—例如，在一个数据仓库中应用关系行在线分析处理（OLAP）的数据—那么把这些数据存入关系格式而非 XML 可能是正确的选择。

  关系数据模式问题的 XML 解决方案

  为了最大的可能范围，存储数据的模型应该和你数据的最高值和最关键的使用模式相匹配。如果数据被模式化成为自然表格，比起 XML 这通常表现为关系型格式更好。然而，有些情况下关系型模式不是最好的选择而且有时用来存储数据甚至是很差的选择。下面是用 XML 表现比用关系型格式更好一些情况。

  当模式不稳定时

  关系型数据的问题：如果数据模式经常改变，那么在关系表结果中表现的数据，更改关系模式将产生成本和开销。一些模式的表格更改在关系型数据库中是无痛的，比如在表中增加一个新列、把模式的其它表加入进来，还有就是删除一列或更改一列的类型。不过模式的其它表要更改（比如把一个表正常化进多个表中）会非常困难。首先要改变表然后应用程序需要改变访问的 SQL 语句。

  XML 数据解决方案：模式中易变的那一部分可以作为一个单独的 XML 列存在。 XML 天然的自描述和易扩展功能可以无缝的处理模式变化和改进。 XML 文档格式中的改变是在不需要在数据库中更改表或者列并且通常不需要破坏现有 XML 查询。

  当数据是自然的层次时

  关系型数据的相关问题：天然分层或递归数据在关系模式中常常很难表现。例如包括原料账单、工程对象或生物学数据。一个原料清单可以存进一个关系型数据库，不过可能需要递归 SQL 来把它部分或全部重新构建。

  XML 数据解决方案：因为 XML 是一个层次型数据库模式，它可以非常自然的表现本身就是层次型的商业数据。如果相同数据表现为表格形式需要，使用 XML 可以用简单、导行的数据访问来代替复杂的一系列操作。

  当数据表现商业对象时

  关系型数据的问题：如果应用程序数据要表现商业对象，比如保险保单，它经常从保留有数据条目和一个详细声明的组合中得到好处，而不是把它们分散到一系列表中。这对一个保单的那些本身没有有效商业含义并且只能在有上下文的完整表单中被解释的单独的数据条目来说尤其如此。通过数十个关系型表来正常化这个保单意味著应用程序处理一个复杂的并且对于他们的商业来说是不成体系的数据。这增加了负载和出错的几率。

  XML 数据的解决方案：XML 让你可以表现非常复杂的商业对象比如紧密相关的文档以及截然不同的文档同时还抓取所有组成商业对象的数据条目之间的关系。以一个在表中单独一行里的 XML 文档来表现每个保单（商业对象）为应用程序开发人员提供了非常直观的存储模型并可以快速进行应用程序开发。

  当对象有稀疏的属性时

  关系型数据的问题：某些程序有非常多的可能属性，它们大多数很稀疏，例如，可以适应非常少的对象。一类例子是一个产品编目，这里不同产品属性数目非常多，包括：大小、颜色、重量、长度、高度、原料、款式、编织方法、伏特、决议、放水以及无止境的其它属性。对于任何产品，只和这些属性的子集相关。一个可能的关系型方法是存储这些数据时一个属性一列，这意味着表中包含 NULL 值得单元占非常大的比例。这是不期望的并且是低效率的。对这些稀疏数据的另一个不同的关系型方法是一个有 3 列的表，对每个产品 ID 存储了几对名字 / 值。这意味着属性的名字不是列名不过是在 VARCHAR 列中的值。这使得关系型数据不能精确的估计可选约束和生成一个有效的查询计划。要定义并执行一个约束同样非常困难，比如对一个特定属性的唯一性约束。

  XML 数据解决方案：XML 的美妙之处就是元素和属性是可选的，例如，如果不需要应用一个特定的产品他们完全可以省略。无论是 NULL 值还是名称以及值都不需要。 XML 模式可以定义非常多的可选元素，却对所有对象只使用它们中的一部分。在一个关系型表中每一行必须有相同的列， XML 列中的 XML 文档每一行可以有不同的元素。同样，如果这个元素只有很小的百分比，这个可选元素的 XML 索引可能非常小。这对每一行都有严格输入的关系型索引的一个很明显的优势。

  当数据需要交换时

  关系数据的问题：如果你从关系表中导出一批记录并把它们发送到另外一个应用程序或组织中，接收者不能在没有额外数据来描述这一列的情况下解释数据。如果你的关系模式从你上次发送数据开始已经改变的情况下，尤其如此。

  XML 数据解决方案：XML 是自描述数据。 XML 标签是描述它们嵌套值的元数据。

  DB2 pureXML 超过其它存储选项的优势

  因为 XML 已经日益变成企业运营的关键，XML 文档是一种资产共享、保持、搜索、保护和更新并保持完全的事务一致性。基于它的用途，XML 数据也可能需要与其它数据进行转换、审计和整合。为了达到这些要求，把 XML 数据在 DB2 数据库中存成自然层次格式，这有很多好处，包括：

  • 注意 XML 数据的内部结构。这对在数据库中以字符或二进制大对象（CLIBs 或 BLOBs）的形式来存储 XML 文档具有优势。准确的说，你可以很容易使用 XQuery、XPath 和 SQL/XML 利用 XML 结构来查询 XML 数据，而且你可以通过对 XML 数据创建索引来提高查询性能。另外，你可以很容易的使用 SQL、XQuery 和 XSLT 来更新、转换并发布 XML 数据。
  • 维护 XML 数据的层次和灵活的性质。这在分解（切割）XML 文档到关系型表中，在这里管理员映射 XML 元素和属性到关系列中。在分解后，XML 文档之被存储在这些表中并且没有最初的标签。分解常常需要大量的表，而且实际使用中非常复杂。查询分解后的 XML 文档可能需要复杂的 SQL 连接，这很难开发和调试。改变 XML 模式常常会破坏对关系数据库模式的映射。这会使维护变得昂贵和耗时，并违背了出于灵活性而选择 XML 的初衷。这也是为什么 DB2 pureXML 允许你适应一个 XML 列来存储和查询基于不同 XML 模式的 XML 文档，或一个 XML 模式的不同版本。
  • 在一个数据库中整合 XML 文档和关系数据。这比在两个数据库中分别存储关系数据和 XML 文档 -XML-only 数据库更有优势。后者需要技巧和人力来操作并维护两个数据库系统而不仅仅是一个。同样，从两个数据库中联合数据，通常需要应用程序有额外的逻辑，而这常常很困难且效率低。当你在一个 DB2 数据库中同时存储 XML 和关系数据时，可以在查询中联合两种类型的数据，甚至可以根据需要把一种转数据换成另外一种。这样做更加划算而且比起使用两个不同的数据库，它提供了更好的性能。

    DB2 pureXML 的最佳实践：概述

    DB2 pureXML 功能提供了在存储、索引、验证和查询 XML 数据上成熟的能力 – 并完全整合了 DB2 关系型数据管理功能。本文描述了以有效并高效的方式使用 pureXML 的原则。本文的目标不是介绍 pureXML 功能或者它们如何工作。相反本文提供了保证高性能 pureXML 的指南，也示范了如何开发 pureXML 功能来有效的解决特定的商业问题。

    我们使用一个现实世界的应用程序场景来安排最佳实践和本文中的例子。这是来自金融行业的场景而且是基于 XML 格式的叫做 FpML（金融产品标记语言）的“金融衍生交易”的交易和管理。你不需要一个金融专家来理解这个场景。虽然我们只使用这个特定的场景，最佳实践同样应用到其它 XML 使用情况，比如 XML 表格处理、订单管理系统、XML 在健康保健和电子病历，和其它情况

    本文的主题是根据数据库对象的生命周期粗略组织的。我们这个章节从查看应用程序需要的数据和表开始。然后我们讨论 DB2 对 XML 数据（第 4 章）的存储选项。之后 , 第 5 章提供了添加 XML 数据到 DB2 数据库的窍门和技巧。在第 6 章我们提供了更有效查询 XML 数据的指南和例子。为了提高查询性能，定义和使用 XML 索引的最佳实践在第 7 章中进行了介绍。 XML 名称空间和 XML 更新在第 8 章和第 9 章中分别有所讨论。第 10 章和 11 章涵盖了对数据库管理员（DBAs）以及应用程序开发的附加的主题。最后，12 章以总结最重要的指南作为结束。

    简单场景：FpML 形式中的金融衍生交易

    一个“金融衍生交易”是一个基于（起源于）其它一些金融资产的金融交易，比如股票、指数、利率、流通、或其它的。在一个金融衍生交易中，根据影响底层资产的市场条件，当事人双方同意交易现金。通常情况下，一方利用交易以减轻风险；另外一方利用这个交易来获得立即的收入（通过费用或额外费用）或对未来市场情况将提供收益进行投机。让我们看一个例子：

    YourWord Investments 和 MyGlobal Back 达成了一个外汇兑换交易。他们商议在 10 月 25 号 YourWord 将支付 71,900,000 人民币给 MyGlobal，并且 MyGlobal 将支付 10,000,000 美元给 YourWorld 。如果 1 美元兑换人民币从现在到 10 月 25 日其间低于 7.19，MyGlobal 将从这次交易中获利 .MyGlobal 可能会使用这个交易来避免美元下降的风险。 YourWorld 可以投机美元将增值，或从 MyGlobal 收取进行交易的前期费用。

    衍生交易的奇妙之处是（a）有很多不同的类型和变化，（b）一个特定交易的状态往往需要单独谈判而且很复杂，（c）一个衍生交易的生命周期可以是从几天到数年的范围而且它们的条件可以随时间而改变。金融企业发现在定义一个可以捕捉到衍生交易高度变化标准的数据格式时需要 XML 的灵活性和可扩展性。结果就是，他们开发了 FpML 。 FpML 本质上是定义了 XML 元素和属性如何用来描述金融衍生交易的一个 XML 模式。 International Swaps and Derivatives Association, Inc (ISDA) 代表一个投资银行组织管理 FpML 标准使市场在场外进行衍生交易。更多金融衍生交易和 FpML 的信息参考【 8 】和【 9 】。

    样本数据和表

    本文的样本数据库由 3 个表组成，见清单 1。

    
    清单 1. 定义样本表
    

    create table trades (tradeId integer, tradedoc XML); create table parties(partyInfo XML); create table currencies(symbol char(4), name varchar(30), USDvalue double, lastUpdated timestamp);

    
    

    所有的表定义和命令以使用样本数据来填充它们，以及需要本文中显示的其它语句可以在 中以文本文件的形式下载。

    TRADES 表包含 FpML 文档和每个文档的交易 ID 。每个交易文档涉及两个交易方使文档中用 PRTYID 元素的值。更多关于各个部分详细信息都以 XML 格式存放在 PARTIES 表中。我们可以从一个 TRADES 和 PARTIES 之间的 XML 到 XML 连接中找到相关交易的详细资料，反之亦然。很多 FpML 交易通过标记来引用具体货币。额外的货币信息在关系型中可以在 CURRENCIES 表中，如清单 2 所示。我们需要 XML 到关系型表的连接来把相关交易和货币信息联系起来。

    
    清单 2. currency表中的内容
    

    SYMBOL NAME USDVALUE LASTUPDATED ------ ------------------------------ -------- ------------------- USD US Dollar 1.000 2008-02-05-15.15.57 EUR Euro 1.460 2008-02-05-15.15.59 GBP Great Britain Pounds 1.960 2008-02-05-15.16.23 JPY Japanese Yen 0.009 2008-02-05-15.15.53 CNY Chinese Yuan (Renminbi, RMB) 7.190 2008-02-05-15.16.13

    
    

    我们的 PARTIES 表包含 3 行，每一行有一个 XML 文档。他们描述了与金融衍生交易的例子有关的各参与方。下表显示 3 个缔约方的 XML 文档：

    
    清单 3. Parties 表的内容
    

    510026MIBMyGlobal International BankActive 498 Wall StreetNew YorkUSA 2006-05-16Baa167781NVBNational Village BankActive 1805 Back StreetEC3M 4TDLondonUK 2006-06-01Aa99114YWIYourWorld InvestmentsActive 98765100027BeijingChina 2007-01-15Aaa2005-04-21Aa

    
    

    清单 4 显示 FpML 文档表现先前我们描述过的 YourWorld Investment 和 MyGlobal International Bank 之间的货币兑换交易。交易以 tradeHeader 元素开始，以“ party1 ”和“ party2 ”标记两个交易方，并把他们和他们的交易 IDs 以及交易日期联系起来。在 FpML 文档的最底部，“ party1 ”和“ party2 ”是映射到具体的标识符“ 510026 ”和“ 99114 ”他们引用 PARTIES 表中交易方信息。交易具体的主要部分在 fxSingleLeg 元素中。 FX 是声明外汇交易，有两个元素叫 exchangedCurrency1 和 exchangedCurrency1 。第一个表示 YourWorld 支付 CNY 71,900,000 给 MyGlobal，第二个显示 MyGlobal 支付 10,000,000 给 YourWorld.

    为了更清楚的表示，我们已经从 FpML 样本数据删除了所有名称空间。我们将在本文后面部分重新访问名称空间。

    
    清单 4. FpML格式中的一个利率衍生工具
    

    MyGlobal941YWI00892001-10-23ZCNY71900000USD100000002001-10-25ZCNYUSDCurrency2PerCurrency17.9151002699114

    
    

    清单 5 显示一个 FpML 文档的其它例子。这个文档是一个 “隔夜拆借存款”。 National Village Bank 对来自于 YourWorld Investment 的 25,000,000 欧元存款支付 3% 固定贷款利率。

    
    清单 5. 在 FpML 中的一个“隔夜拆借存款”例子
    

    YWI7623691972002-02-14ZOvernight Term Deposit2002-03-15Z2002-03-16ZACT/360GBP35000000.000.039911467781

    
    

    这两个列子（清单 4 和清单 5）让你对 FpML 衍生数据有了一个概念。 FpML 模式定义了大约 1800 个不同的 XML 元素和超过 600 种类型。任何一个实例文档都只包含了其中的一部分。然而，一个关系型数据库模式在没有 XML 列的情况下需要至少 400 到 500 个表才能显示任意可能的 FpML 文档。这是令人恐怖的复杂度，而且通常被认为不可管理。这是为什么 XML 是必须的。

    OurTRADES 表包含了 5 个 FpML 文档，包括上面的两个。完整的数据样例可以在一个 DB2 命令行（CLP）脚本中下载。

    为 XML 存储选择正确的存储选项

    正确的配置存储选项对于最大化 DB2 数据库性能非常重要。在这个章节，我们讨论数据库的表空间类型、XML 数据在数据库中存储的页面大小、以及在数据库中存储 XML 数据的方法。

    提示：在 DB2 9.5 中 XML 在一个 DB2 表空间中消耗的存储空间是原始 XML 数据以文本格式在操作系统中占用空间的 0.7 到 1.5 倍。要得到更精确的评估，比如插入 1000 个有代表性的文档到一个空表中并抓取一个 DB2 表的快照来查看这个表已使用的页数。

    为 XML 数据选择表空间类型和页大小

    数据库管理表空间（DMS）提供了比系统管理 ( 操作系统管理 ) 表空间（SMS）更高的性能。这对关系型数据尤其如此，对 XML 读写访问上更是如此。最新创建的表空间默认是 DMS 。推荐使用 DMS 表空间与自动存储，所以 DMS 容器根据需要增长而不需要人工干预。如果一个 XML 文档太大而不能放入这个表空间的单个页面中，DB2 会把这个文档分别存入多个域中，这样就存入多个页面中了。很显然你的应用程序可以让 DB2 处理最大 2G 的 XML 文档。

    通常，一个文档的域的数目越低性能越好，尤其对于插入和读取整个文档。如果文档不能放入一个页面中，每个文档拆分的数目取决于页大小（4KB，8KB，16KB 或 32KB）。你的表空间页大小越大，每个文档可能被拆分的数目就越小。例如，假设一个文档跨了 40 个 4k 页。相同的文档在 8KB 表空间中可能只需要 20 页，或 10 个 16KB 页，5 个 32KB 页，因为多个小的文档可以存储在一个页面中所以不会有空间浪费。

    提示：大多数 XML 应用程序最好在 16KB 和 32KB 页面上运行。如果大多数文档非常小（比如小于 4KB）16KB 页面可以提供良好的性能，因此在一个页面中存放多个文档。更大的文档最好使用 32KB 页面保存。对于我们的 FpML 场景，需要 16KB 页面。如果你对关系型数据和 XML 数据使用同样的页面，或者数据和索引也存放在相同页面，16KB 页面同样可以做很好的折衷，而且你会发现 32KB 页面对关系数据和索引有的访问有负面影响。这这种情况下，你可以考虑使用其它的页面大小。

    XML 和关系数据使用不同的表空间和页大小

    在清单 1 中的 CREATE TABLE 语句把表中的 XML 数据和关系型数据都存在了相同表空间里。这意味著它们使用相同的页面大小和缓冲池。在表空间中，关系数据是存储在基本数据页面上，同时 XML 数据是存在另外的 XML 数据域（XDA）里的页面中。这是因为就像大对象（LOBs），XML 文档可能很大，不能放在表的一个数据页中的一行里。这种默认的规划对于大多数应用场景提供了很好的性能。这个选项，叫做“基础内嵌表”，将在下面章节中进行介绍，你应该对在同时存储 XML 文档和关系型数据的数据页面上选择这个选项。然而，默认情况下关系型数据和 XML 数据是分开存储的。

    提示：如果你已经完成了性能分析并发现你需要对 XML 数据使用一个大页面，而关系型数据和索引需要小页面，你可以使用不同的表空间来满足它们。在你定义一个表的时候，你可以指定“长型”数据到一个有不同页面大小的单独的表空间。长型数据包括 LOB 和 XML 数据。

    下面的例子定义了两个缓冲池和两个表空间，缓冲池和表空间都分别有 4KB 页和 32KB 页。注意，一个表空间总是需要一个匹配页大小的缓冲池。我们的 3 个表所在的 relData 表空间是 4KB 页面。所有的列都存在这个表空间中，除了 XML 列。它们被存储在 xmlData 表空间的 32KB 页面中。

    
    清单 6. XML 和关系型数据存放在不同页大小的表空间中的例子
    

    create bufferpool bp4k pagesize 4k; create bufferpool bp32k pagesize 32k; create tablespace relData pagesize 4K bufferpool bp4k; create tablespace xmlData pagesize 32K bufferpool bp32k; create table trades (tradeId integer, tradedoc XML) in relData long in xmlData; create table parties(partyInfo XML) in relData long in xmlData; create table currencies(symbol char(4), name varchar(30), USDvalue double, lastUpdated timestamp) in relData;

    
    

    除非明确指定，新表空间都是创建为有大行 IDs 的 DMS 表空间。这意味着一个 4KB 页大小的表空间可以存储多达 2TB 的数据并支持在 32KB 大小的页面存放 2335 行记录。

    内置并压缩 XML 数据

    DB2 VERSION 9.5 也允许你“内置”存储 XML 数据并压缩。

    提示：如果某些或你的所有 XML 文档都足够小，就可以在基础表页面里把它们放进相应的行对象中，就可以把 XML 数据内置到关系行中。这样做也提供了对 XML 数据的更直接访问并避免了重定向到 XDA 对象中。如果在 XML 列中的一些文档仍然太大而不能内置，它们通常被存储在“外部” XDA 对象中。内置可以显著的减少域索引，因为嵌入文档不需要任何域索引输入。它们总是组成一个单独的内置域。嵌入文档也可以使用普通的 DB2 深度行压缩来压缩，如图 7 所示：

    
    清单 7. 嵌入及压缩 XML 存储的定义
    

    create table trades (tradeId integer, tradedoc XML in line length 16000) in relData compress yes;

    
    

    在这个例子中，XML 列使用 INLINE LENGTH 16000 定义 . 这意味着任何等于或小于 16000 字节的文档都将以嵌入方式存储。这里指定的大小是参照 XML 在 DB2 中解析后的大小，不是 XML 文本文档在你文件系统中的大小。嵌入长度必须小于页面大小减去本页中其它列之后的大小。

    提示：通常你应该寻求嵌入最多或全部文档。如果你在表中只有一个 XML 字段，达到这个目的的最简单的方法是设置内置长度为这一行中的最大可能值。 DB2 不会允许你定义一个太长的嵌入长度。选择一个较大的嵌入长度将不会浪费任何空间，因为只有存储文档真正需要的空间才会被使用。然而，指定一个较大的内置长度可以阻止你在以后添加新列到这个表中。

    嵌入 XML 数据总是以这个表的关系型列存放在相同表空间中，并且不能存在一个有不同页面大小的其它表空间中。

    因为我们的样本表示定义时指定了 COMPRESS YES，关系数据和内置 XML 文档会被压缩。以 60%-70% 的比例压缩内置 XML 数据并不罕见。下面的语句可以用来检查 PRODUCT 表的压缩比率：

    
    清单 8. 用来检查数据压缩率的管理函数
    

    select tabname,pages_saved_percent,bytes_saved_percent from table(sysproc.admin_get_tab_compress_info('MYSCHEMA','TRADES','ESTIMATE')) as t

    
    

    提示：
    如果你的系统是 I/O 限制而非 CPU 限制，压缩 XML 数据可以提供极大的性能提升。然而，要注意内置文档会显著的增加在你页面中的行的大小。这反过来减少了每一页中的行数。只访问表中关系列的查询现在需要读取比没有嵌入文档要多很多的页面。这会造成比没有使用 XML 嵌入文档情况下更多的 I/O 以及更低的查询性能。如果你的查询通常总是查询 XML 列，那么对你没有影响，然而，如果你有很多不涉及 XML 列的查询，你应或许不应该选择“内置”存储。

    
    

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15082138/viewspace-590675/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15082138/viewspace-590675/