和其他數據庫一樣，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操作。
表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操作
全部測試均使用以下數據和設置執行：
一個安裝了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列的潛在開銷通常會增加。
下一節介紹用於量化這些折衷方案的性能度量指標。
比較CLOB插入和XML插入
在第一個測試中，我們順序插入 100,000個具有或不具有索引的文檔，像許多 OLTP應用程序那樣在每個文檔之後提交。圖 1中的結果顯示了XML和CLOB列插入之間的相對占用時間（越低越好）。將XML插入的占用時間用作比較基線(100%)，維護 6個XML 索引僅需很小的開銷（在我們的場景中是5%）。
圖 1：比較XML和CLOB列的單用戶插入性能
CLOB和XML列的XML查詢比較
為了評估 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：查詢性能，無索引，無文件系統緩存
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)的謂詞運算
如果降低執行的頻率，就能提高 XML列相當於分解的性能優勢。每隔一個文檔執行可使 XML插入比分解快 2.56 倍（在我們的場景和配置中）。對於大量的插入或導入操作來說，如果每隔 50 或 100個文檔執行一次，可使 XML列插入比分解快 4 到5 倍（參見 圖 11）。XML列插入能夠從較大的間隔中獲得比分解（每個日志 I/O 請求有更多的日志頁面）更多的益處。
圖 11：比較pureXML插入和DB2 9分解（不同的執行間隔）
結束語
雖然對於單用戶工作負載來說，CLOB插入的速度可能快於pureXML插入的速度，但是典型業務場景下的密集並發插入可使 CLOB插入速度比插入到XML列的速度慢 2 或 2.5 倍。如果在每個文檔後執行插入操作，那麼 pureXML插入速度約比 DB2 9中的新分解解決方案快 60% 到70%。 對於執行頻率低的大量插入或導入來說，pureXML 獲取 XML數據的速度比分解甚至快了4 到5 倍。這些測試使用了DB2 9中的新分解解決方案，此解決方案的速度比 V8中的XML Extender分解速度快了7 到8 倍。
XML 類型列中 XML數據的XQuery 速度比 CLOB的對應查詢（需要在查詢時進行XML 解析）速度快了40 倍。“pureXML查詢”和“CLOB查詢”之間的絕對性能差異，隨查詢數據量的增加而（線性）增加。
分解式數據的pureXML XQuery和SQL/XML Publishing 之間的相對性能差異主要取決於需要標記為XML的關系數據量，以及所需要的連接（JOIN）操作數。當必須檢索復雜的數據時，XQuery 明顯優於發布查詢。在我們的一些測試中，從 DB2 pureXML存儲檢索 XML數據能夠比從關系表中構建XML數據快 50 到100 倍。然而，無需復雜結合的簡單搜索查詢（返回的結果帶有少量或沒有 XML 標簽）在SQL中速度更快。應用程序仍然需要在查詢性能和插入性能之間權衡，並評估兩者的混合使用。圖 14中總結了XML插入的性能。
圖 14：XML插入性能總結(commitcount =1)
