传统的方式下，开发人员对XML 的存储和访问一般通过两种方式，这也是目前开发人员基于Oracle数据库可以采取的两种方式：
（1） 将XML保存为大对象CLOB/BLOB 或者 Varchar。保存样例如下：
大对象的方式将XML作为黑盒处理，丢掉了XML原有的结构化的嵌套信息，当人们需要对XML的内容作访问的时候，不得不把黑盒的内容拉出来进行解析处理。解析的方法包括DOM解析和SAX解析。DOM解析的结果是一棵内存中跟XML结构相对应的树结构，需要占用大量的系统资源尤其内存资源，在数据量大的情况下内存容易成为瓶颈从而难以保证效率，其好处是之后对XML树结构的遍历和查询比较方便。SAX解析是基于XML标签事件的，在资源消耗上比DOM解析少很多，处理速度比DOM解析更快，但由于SAX解析并不维护内存中的树结构，所以对XML的内容查询不够方便和灵活。如果应用本身对XML节点的查询需求更多一些，采用DOM解析的方式更方便。
将XML保存为大对象的方式，丢弃了XML自身的一些信息。后续对XML内容的访问完全依赖于开发人员的编码工作，无论实现上文的DOM解析还是SAX解析代码量都不可小视，在生产环境中如何保证良好的性能也是人们所担心的。
（2） 将XML经过Shredding（拆分）的方式，映射到关系型的数据库。
过去由于缺乏对XML层次模型支持的技术，人们通过拆分的方式变相实现对XML层次数据模型的支持。示例如下：
对任意一个XML文档结构，至少需要一到多个具有关联关系的二维表来描述。为了实现对XML文档内容的查询，需要把二维表Join起来再检索。XML文档原本能够很好地去适应需求的变化，这种适应只需要通过对XML节点的调整（在相应层次的增加或减少）。通过关系表关联等价的实现面对需求的变化实现起来很被动，调整的代价不菲，任何开发人员都不愿意在项目实施中或实施后再去调整底层表结构。
应该说，这两种传统的实现方式跟基于何种数据库本身没有必然联系。无论是Oracle 9i, 10g 还是DB2 8, DB29 中，开发人员都可以使用任意一种方式通过数据库来管理XML。尤其Clob大对象的方式，无论是存储到Oracle还是DB2，数据库只是一个存储的池子，后续处理完全依赖于开发人员的编码工作。从早先的版本起，各个数据库内部尝试用拆分的方式存储和管理XML数据模型。 包括DB2 8的XML Extender， 也包括Oracle的10g. 这种通过拆分方式支持XML的数据库被称之为 XML-Enabled 数据库，特点是通过关系数据模型变相支持XML，自然有很多技术上的局限性。由数据库自动进行拆分的方式，要求XML文档事先必须是有Schema的；拆分成表的批量处理方式必然会导致数据库内部有很多空字段，带来存储上的浪费；满足大数据量的查询性能容易成为瓶颈；关于XML查询和索引的支持都会有很多局限性。后面会做具体技术点的比较。
2006年7月DB2 9 正式发布，其中最重要的技术突破就是对XML的支持,被称之为Native的XML Support。所谓Native，意味着：
（1）不需要在XML层次模型跟其他模型之间作转换
（2）不需要拆分
（3）不需要存成大对象文本串。
XML数据模型在DB2 9中被真正地作为层次模型来支持。从磁盘上的最小的存储单元开始，保存的就是XML对应的树结构。这棵树类似于XML经过DOM解析后得到的树结构。（实际上XML 文档被插入DB2 9的时候是通过SAX解析的方法被解析的，而之后存储到磁盘上的效果遍历起来如同DOM树一样方便）。下面这张图简单示意了XML在DB2 9中的存储机制。
基于树形结构的存储，DB2 9 直接支持国际标准的XML查询语言Xquery（包含Xpath标准的支持）。先前开发人员需要很多Coding 才能实现的XML解析和查询工作现在直接通过调用一条Xquery即可实现。除了存储机制，查询机制，配套的还有XML的索引机制，XML Schema的管理机制等。由于对XML的Native支持，DB2 9 不再是单纯的关系型数据库，而是同时支持关系型和层次性数据模型的混合型数据库。一方面继承原有的二维数据库技术，支持标准的SQL查询二维表；另一方面一套完善的XML Native 技术，支持标准的Xquery查询XML层次模型；同时二维的SQL查询和层次的Xquery查询还可以互相嵌套实现两种数据模型的关联查询。
DB2 9 是第一个能同时支持关系型又能支持层次型的混合型数据库。混合型的引擎面向过去，能够兼容老的基于关系型数据库设计的系统；面向未来，能够很好的适应未来IT和业务系统灵活多变的业务需求，发挥XML的灵活性优势。
下面，我们从技术点和性能两大方面对比DB2 9与Oracle 10g XML技术的差异。前面已经分析过Oracle通过大对象和拆分两种方式来支持XML的存储。我们分别针对两种方式来跟DB2 9的Native XML技术作比较。
（一） Oracle基于大对象CLOB的存储方式
|
XML操作
|
DB2 9 Native XML
|
Oracle非结构化大对象存储
|
|
存储方式
|
预先解析，磁盘上存储类似XML DOM树结构
|
CLOB
|
|
查询的时候是否需要解析？
|
不需要
|
需要
|
|
支持任意节点或属性上的索引？
|
支持
|
不支持重复出现节点上的索引
|
|
XML存储字段允许多个Schema ?
|
允许
|
允许
|
|
XML文档可以没有Schema ?
|
允许
|
允许
|
|
XML的灵活性？
|
允许
|
允许
|
|
子文档更新
|
支持
|
需要解析 编码
|
|
全文索引支持
|
通过NSE实现，可以支持XPATH路径确定的子文档上的全文检索
|
通过CTX支持全文索引；但不能够针对XPATH子树检索
|
（二）Oracle基于拆分的存储方式
|
XML技术点
|
DB2 9
|
Oracle 10g
结构化存储
|
|
存储
|
Native (层次)
|
(对象-)关系
|
|
XML文档没有Schema
|
允许 J
|
不允许 L
|
|
每个字段是否支持多个Xml Schema?
|
允许 J
|
不允许 L
|
|
Schema发生变化 灵活性
|
支持 J
|
不支持 L
|
|
Native XQuery 查询
|
支持 J
|
不支持 L
(需要翻译成SQL)
|
|
支持任意 XQuery
|
支持
|
否 (需转成SQL或借助外部Java引擎)
|
|
需要多次Join获取文档内容
|
不需要 J
|
需要 L
|
|
任意节点属性上创建索引包括重复节点
|
支持 J
|
很困难/做不到
|
|
子文档更新
|
9.5版本支持
|
转化成SQL更新
|
注：在 Oracle 数据库 10g 第 2 版中，Oracle 也引入了XQuery 引擎，但存储结构等没有发生变化。
由于Oracle目前对XML支持的能力跟DB2 不采取Native XML的方式路线基本一致。我们做了DB2 9 自身Native XML方式跟Clob和拆分方式的比较，大概来了解不同技术实现下性能的大概差异，由于具体测试的细节很多，这里只摘取几个结果的汇总比较，具体可参考PDF Performance文档：
以下测试结果是基于大批量XML的事务处理的场景下得出，其中包括符合金融规范FIXML的数据。
（1） Clob与 Native XML方式下插入性能的比较：
DB2 Native XML方式下插入需要解析，CLOB插入不需要，但是CLOB方式下为了维护索引所需要的Side Table也需要较多代价。单个用户插入下我们看到维护Side Table的Clob方式效率更低。
另外XML 列可以利用缓冲池，而CLOB则不可以。所以并发插入的情况下Native XML比Clob有更好的表现。
（2） Clob与 Native XML方式下并发查询性能的比较：
Native XML 方式下查询不需要解析，Clob方式下查询需要解析，对资源和时间的消耗都成本不菲。Native方式有明显的优势。
（3） Shredding 拆分方式与Native方式插入性能比较
（4） Shredding 拆分方式与Native方式查询性能比较
最后，引用一个SOA环境下 开发周期比较测试，对比不同XML技术对开发人员的影响：
|
测试项目
|
采用传统关系型技术
|
采用 DB2 9 pureXML 技术
|
|
开发获取和搜索XML信息的业务流程
|
CLOB: 8 小时
Shred: 2 小时
|
30 分钟
|
|
I/O读写数据相关的代码量 (减少65%)
|
100
|
35
|
|
增加新的数据字段
|
1 周
|
5 分钟
|
|
查询
|
24 - 36 小时
|
20 秒 - 10 分钟
|
|
查询未解析的XML元素
|
1 周
|
½ 天
|
SQL Server 2005继续采用Blob保存XML数据并新增了一个XML数据类型，增加了对XQuery和XPath的优化，而且由于在.Net平台对于XML的读取采用了一贯的“Stream”（流）方式，因此相对于应用开发而言效率的损失不够明显，但如果作为混合SQL与XQuery查询时，由于要同时囊括多个XML字段的检索，因此效率较之结构化存储会存在很大的差距。
与其它数据库的XML功能相比，DB2 pureXML在以下领域具有显著优势：
存储：DB2 的pureXML 技术将以节点级（而非文档级）粒度存储 XML。在数据库中，物理存储层的主要存储单元是节点。每一页中都存在一个节点，而其它的节点则来自相同或不同的文档。每个节点不仅连结其父节点，还连结其子节点。因此，浏览到某个节点的父项、同级项或子项的效率都非常高，只要下一个引用的节点在同一页，其遍历速度将比指针的遍历速度还要快。 无需重写整个文档即可增加或减少节点，或者将节点重新部署到其它页。
索引机制：管理着数百万的 XML 文档的 XML 应用程序并不罕见；因此要提供高查询性能就要为大量的 XML 数据编制索引。DB2 支持在 XML 列上建立路径特定的索引，因此元素和属性常用作谓词且可以编制跨文档连接的索引。
新的 XML 值索引可有效评估XML 模式表达式，从而提高 XML 文档的查询性能。与传统的关系索引相比较，在关系索引中，索引键由用户指定一个或多个表格列组成，而 XML 值索引则使用特定的 XML 模式表达式（XPath 的子集，XPath 不包含谓词等等）来编制路径和 XML 文档（存储在一个 XML 列中）中的值的索引。如果值不是在文档中指定的，则该索引还可以在插入的时通过模式来填充默认的属性和元素值。创建索引时，您可以指定要编制索引的路径和索引类型。可以编制与存储在该列中的 XML 文档中的路径表达式以及路径表达式集匹配的任何节点的索引，而且该索引可以直接指向存储中的节点（它与其父节点和子节点连接以便于快速浏览）。索引条目并不是提供访问文档开头的索引，而是包含实际文档节点的位置信息。因此，该索引可以快速直接访问文档中的节点，并避免文档遍历。
查询：XQuery，即查询 XML 数据的一种新语言，用于处理不同的模式，包含诸如序列（而非 SQL 中的集）、多嵌套序列和稀疏属性。XQuery 还可以支持不同种类的模式以及动态的结构更改。
IBM 实施不包含独立的 XQuery 或 XPath 处理程序。基本的 XQuery 和 XPath 直接嵌入到查询引擎中。该查询编译器自身是双语的，带有两个可互操作的查询语言解析程序 — 一个用于 SQL，另一个用于 XQuery — 以产生查询图表模型（用于处理关系和 XML 数据）的新变量。因为中间的查询表达法是中性语言，XQuery、SQL 以及 XQuery 与 SQL的组合将编译成同样的中间表达法，经过同样的重写和转化，以类似的方式优化并产生类似的可执行代码。无论使用什么语言来指定查询设计，此过程都将产生最优的互操作查询设计。
因为这两个解析程序可以相互操作，所以您可以在同一语句中混合使用 SQL 和 XQuery，从而使搜索功能更强大：在 XML 文档中进行查询并从 SQL 返回其片断。
扫一扫
364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
