和其他數據庫一樣，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 操作。
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 操作表 1：比較 CLOB 和分解式 XML 處理與 pureXML
全部測試均使用以下數據和設置執行：
一個安裝了 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 列的潛在開銷通常會增加。
下一節介紹用於量化這些折衷方案的性能度量指標。