利用DB2 pureXML管理XML數據實踐
XML 數據用于提高性能和存儲有效性的存儲選項
◆對 DB2 DMS 表空間啟用自動存儲。
◆為 XML 數據使用更大的頁大小，比如 16KB 或 32KB 。
◆如果性能分析需要，就為 XML 數據選擇一個不同的表空間頁大小。
◆很多 XML 文檔足夠小并且能和其它 non-XML 數據存在數據頁上，就為 XML 文檔使用內 嵌存儲。否則文檔存放在表之外，類似于 LOBs，并且通過區(qū)域索引來訪問。
◆使用壓縮來減少 XML 文檔以 inline 方式存放時的空間大小。
在 DB2 數據庫中添加 XML 數據的技術：
◆為了提高你在使用 insert、import 或 load 添加數據時的性能，
◆使用使用較大頁大小的 DMS 表空間，比如 16KB 或 32KB 。
◆提供足夠的緩沖池空間以支持 XML 區(qū)域索引和路徑索引的讀取。
◆如果你有多個用戶定義的 XML 索引，通常最好在添加數據之前定義它們。
◆如果有必要，把行抽取選中的 XML 元素值放入到和 XML 文檔相同的關系列中。關系列 中存放的數據允許簡單、SQL-only 的形式來訪問重要的數據或經常訪問數據條目、可以定義 主鍵、外鍵或其它約束、以及可以定義多列（組合鍵）關系索引。
◆如果更小的片段更適合數據訪問的粒度，就把大型 XML 文檔分割成更小的片段。
◆定義觸發(fā)器來對插入和更新 XML 數據進行自動驗證
有效查詢并更新 XML 文檔的技術：
◆使用 SQL/XML 函數 XMLTABLE 或 XMLQUERY 來從 XML 文檔中抽取數據。
◆在SQL WHERE 子句中使用 XMLEXISTE 謂詞來指定對 XML 數據的謂詞 ，通過檢查更少的行來提高查詢性能。
◆使用一個完全指定的 XML 路徑，而不要使用通配符 * 或 // 來定位到期望的 XML 元素 。這樣做可以提供更好的性能，因為 DB2 可以跳過 XML 文檔中不相關的部分直接找到期望的 XML 元素。
◆出于增加商業(yè)洞察力和最大化一個混合數據庫服務器的價值的需要，你在查詢中需要要 對 XML 和關系數據進行連接。
◆當在一個 XML 文檔中更新多個元素時，把更新合并到一個轉換描述中以獲得最佳的更新 性能
◆在查詢中聲明名稱空間，更新 XML 索引以匹配你的 XML 商業(yè)數據。這個讓你能從多個 或復雜的域中處理 XML 文檔。
為什么使用 XML
XML 提供了一個普通而具有彈性的方法來在不同的系統(tǒng)、應用程序和組織之間交換數據。 使用 XML，數據是在一個可擴展自描述格式下進行維護，以提供給所有涉及的商業(yè)需求。 XML 文檔是用標簽來描述它們包含的數據值，并且通過嵌套標簽來表示數據條目間的層次關系。 XML 可以描述高度結構化的數據并通過 XML 模式來保持結構，但是它也能描述半結構化的數 據，這些數據普遍存在于內容為導向的應用程序。
以服務為導向的架構（SOA）、企業(yè)應用程序整合（EAI）、企業(yè)信息整合（EII）、Web 服 務、企業(yè)消息總線和很多依賴于 XML 作為底層數據交換技術的標準化成就。
就像行業(yè)這樣的機構使用標準化的 XML 模式來促進信息交換并且發(fā)展那些模式來滿足變化 中的商業(yè)需求。這些努力包括在保險行業(yè)中的 ACORD、金融行業(yè)中的 FpML 和 FIXML、供應 鏈管理中的 違規(guī)廣告、零售商業(yè)中的 ARTS、衛(wèi)生保健中的 HL7、商業(yè)報告里的 XBRL 和在印 刷行業(yè)中用于授權、管理和發(fā)布文檔的 DITA 以及整個網絡。
這類具體行業(yè)創(chuàng)新（比如管理需求）在驅動 XML 發(fā)展。越來越多的企業(yè)事務通過基于網絡 接口和電子表格來操作。政府代理和商業(yè)企業(yè)對保留原始訂單、請求、申明、交易或簽名承擔 更多的責任。 XML 提供了一個簡單的方法來抓取并維護和那些電子交易相關的數據。事實上 ，XML 文檔常常在基于消息的事務系統(tǒng)中表現(xiàn)事務記錄。
XML 和關系數據的優(yōu)缺點
作為一個自描述數據格式，XML 允許不同的數據（有模式或沒有）在不犧牲搜索或聚合能 力的情況下被同時存在一個文檔中或某一行中。應用程序可以在對底層數據庫模式不進行任何 改變的情況下發(fā)展他們自己的 XML 模式。然而，對于 XML 的這種擴展意味著比起存儲在關系 表中的數據在檢查和解釋 XML 數據時會花費更多的 CPU 和 I/O 資源 – 這可能不切實際。
對更多的剛性模式定義，關系模式需要更少的解釋并允許更多的優(yōu)化數據操作。就像這樣 ，他可以提供非常高的性能，不過卻不能滿足應用程序需要的模式彈性。關系型數據模型非常 適合有穩(wěn)定數據結構和可預知訪問形式的應用程序。 XML 更適合有復雜多變數據結構以及混 有結構化和非結構化信息的應用程序。
在某些情況下，XML 提供的性能好處超過了關系模型正好是因為它的彈性。關系型數據庫 經常需要標準化來使商業(yè)數據適應簡單平坦的結構。對復雜商業(yè)數據的標準化需要在數據存取 的時候進行轉化，并經常在關系型數據庫中導致多路的連接需求。 XML 可以在一個文檔中更 自然的表現(xiàn)復雜的商業(yè)對象以及對象間的所有關系。在一個 XML 文檔中的層次本質上就是預 先計算的相關數據條目之間的連接。
在選擇一個數據模式時的另外一個考慮是應用程序使用數據。就算數據源自 XML，如果數 據后來的處理取決于存儲在表格中的數據—例如，在一個數據倉庫中應用關系行在線分析處理 （OLAP）的數據—那么把這些數據存入關系格式而非 XML 可能是正確的選擇。
關系數據模式問題的 XML 解決方案
為了最大的可能范圍，存儲數據的模型應該和你數據的最高值和最關鍵的使用模式相匹配 。如果數據被模式化成為自然表格，比起 XML 這通常表現(xiàn)為關系型格式更好。然而，有些情 況下關系型模式不是最好的選擇而且有時用來存儲數據甚至是很差的選擇。下面是用 XML 表 現(xiàn)比用關系型格式更好一些情況。
當模式不穩(wěn)定時
關系型數據的問題：如果數據模式經常改變，那么在關系表結果中表現(xiàn)的數據，更改關系 模式將產生成本和開銷。一些模式的表格更改在關系型數據庫中是無痛的，比如在表中增加一 個新列、把模式的其它表加入進來，還有就是刪除一列或更改一列的類型。不過模式的其它表 要更改（比如把一個表正?；M多個表中）會非常困難。首先要改變表然后應用程序需要改變 訪問的 SQL 語句。
XML 數據解決方案：模式中易變的那一部分可以作為一個單獨的 XML 列存在。 XML 天然 的自描述和易擴展功能可以無縫的處理模式變化和改進。 XML 文檔格式中的改變是在不需要 在數據庫中更改表或者列并且通常不需要破壞現(xiàn)有 XML 查詢。
當數據是自然的層次時
關系型數據的相關問題：天然分層或遞歸數據在關系模式中常常很難表現(xiàn)。例如包括原料 賬單、工程對象或生物學數據。一個原料清單可以存進一個關系型數據庫，不過可能需要遞歸 SQL 來把它部分或全部重新構建。
XML 數據解決方案：因為 XML 是一個層次型數據庫模式，它可以非常自然的表現(xiàn)本身就是 層次型的商業(yè)數據。如果相同數據表現(xiàn)為表格形式需要，使用 XML 可以用簡單、導行的數據 訪問來代替復雜的一系列操作。
當數據表現(xiàn)商業(yè)對象時
關系型數據的問題：如果應用程序數據要表現(xiàn)商業(yè)對象，比如保險保單，它經常從保留有 數據條目和一個詳細聲明的組合中得到好處，而不是把它們分散到一系列表中。這對一個保單 的那些本身沒有有效商業(yè)含義并且只能在有上下文的完整表單中被解釋的單獨的數據條目來說 尤其如此。通過數十個關系型表來正常化這個保單意味著應用程序處理一個復雜的并且對于他 們的商業(yè)來說是不成體系的數據。這增加了負載和出錯的幾率。
XML 數據的解決方案：XML 讓你可以表現(xiàn)非常復雜的商業(yè)對象比如緊密相關的文檔以及截 然不同的文檔同時還抓取所有組成商業(yè)對象的數據條目之間的關系。以一個在表中單獨一行里 的 XML 文檔來表現(xiàn)每個保單（商業(yè)對象）為應用程序開發(fā)人員提供了非常直觀的存儲模型并 可以快速進行應用程序開發(fā)。
當對象有稀疏的屬性時
關系型數據的問題：某些程序有非常多的可能屬性，它們大多數很稀疏，例如，可以適應 非常少的對象。一類例子是一個產品編目，這里不同產品屬性數目非常多，包括：大小、顏色 、重量、長度、高度、原料、款式、編織方法、伏特、決議、放水以及無止境的其它屬性。對 于任何產品，只和這些屬性的子集相關。一個可能的關系型方法是存儲這些數據時一個屬性一 列，這意味著表中包含 NULL 值得單元占非常大的比例。這是不期望的并且是低效率的。對這 些稀疏數據的另一個不同的關系型方法是一個有 3 列的表，對每個產品 ID 存儲了幾對名字 / 值。這意味著屬性的名字不是列名不過是在 VARCHAR 列中的值。這使得關系型數據不能精 確的估計可選約束和生成一個有效的查詢計劃。要定義并執(zhí)行一個約束同樣非常困難，比如對 一個特定屬性的唯一性約束。
XML 數據解決方案：XML 的美妙之處就是元素和屬性是可選的，例如，如果不需要應用一 個特定的產品他們完全可以省略。無論是 NULL 值還是名稱以及值都不需要。 XML 模式可以 定義非常多的可選元素，卻對所有對象只使用它們中的一部分。在一個關系型表中每一行必須 有相同的列， XML 列中的 XML 文檔每一行可以有不同的元素。同樣，如果這個元素只有很小 的百分比，這個可選元素的 XML 索引可能非常小。這對每一行都有嚴格輸入的關系型索引的 一個很明顯的優(yōu)勢。
當數據需要交換時
關系數據的問題：如果你從關系表中導出一批記錄并把它們發(fā)送到另外一個應用程序或組 織中，接收者不能在沒有額外數據來描述這一列的情況下解釋數據。如果你的關系模式從你上 次發(fā)送數據開始已經改變的情況下，尤其如此。
XML 數據解決方案：XML 是自描述數據。 XML 標簽是描述它們嵌套值的元數據。
DB2 pureXML 超過其它存儲選項的優(yōu)勢
因為 XML 已經日益變成企業(yè)運營的關鍵，XML 文檔是一種資產共享、保持、搜索、保護和 更新并保持完全的事務一致性?；谒挠猛荆琗ML 數據也可能需要與其它數據進行轉換、審 計和整合。為了達到這些要求，把 XML 數據在 DB2 數據庫中存成自然層次格式，這有很多好 處，包括：
◆注意 XML 數據的內部結構。這對在數據庫中以字符或二進制大對象（CLIBs 或 BLOBs） 的形式來存儲 XML 文檔具有優(yōu)勢。準確的說，你可以很容易使用 XQuery、XPath 和 SQL/XML 利用 XML 結構來查詢 XML 數據，而且你可以通過對 XML 數據創(chuàng)建索引來提高查詢性能。另 外，你可以很容易的使用 SQL、XQuery 和 XSLT 來更新、轉換并發(fā)布 XML 數據。
◆維護 XML 數據的層次和靈活的性質。這在分解（切割）XML 文檔到關系型表中，在這里 管理員映射 XML 元素和屬性到關系列中。在分解后，XML 文檔之被存儲在這些表中并且沒有 最初的標簽。分解常常需要大量的表，而且實際使用中非常復雜。查詢分解后的 XML 文檔可 能需要復雜的 SQL 連接，這很難開發(fā)和調試。改變 XML 模式常常會破壞對關系數據庫模式的 映射。這會使維護變得昂貴和耗時，并違背了出于靈活性而選擇 XML 的初衷。這也是為什么 DB2 pureXML 允許你適應一個 XML 列來存儲和查詢基于不同 XML 模式的 XML 文檔，或一個 XML 模式的不同版本。
◆在一個數據庫中整合 XML 文檔和關系數據。這比在兩個數據庫中分別存儲關系數據和 XML 文檔 -XML-only 數據庫更有優(yōu)勢。后者需要技巧和人力來操作并維護兩個數據庫系統(tǒng)而 不僅僅是一個。同樣，從兩個數據庫中聯(lián)合數據，通常需要應用程序有額外的邏輯，而這常常 很困難且效率低。當你在一個 DB2 數據庫中同時存儲 XML 和關系數據時，可以在查詢中聯(lián)合 兩種類型的數據，甚至可以根據需要把一種轉數據換成另外一種。這樣做更加劃算而且比起使 用兩個不同的數據庫，它提供了更好的性能。
DB2 pureXML 的最佳實踐：概述
DB2 pureXML 功能提供了在存儲、索引、驗證和查詢 XML 數據上成熟的能力 – 并完全整 合了 DB2 關系型數據管理功能。本文描述了以有效并高效的方式使用 pureXML 的原則。本文 的目標不是介紹 pureXML 功能或者它們如何工作。相反本文提供了保證高性能 pureXML 的指 南，也示范了如何開發(fā) pureXML 功能來有效的解決特定的商業(yè)問題。
我們使用一個現(xiàn)實世界的應用程序場景來安排最佳實踐和本文中的例子。這是來自金融行 業(yè)的場景而且是基于 XML 格式的叫做 FpML（金融產品標記語言）的“金融衍生交易”的交易 和管理。你不需要一個金融專家來理解這個場景。雖然我們只使用這個特定的場景，最佳實踐 同樣應用到其它 XML 使用情況，比如 XML 表格處理、訂單管理系統(tǒng)、XML 在健康保健和電子 病歷，和其它情況
本文的主題是根據數據庫對象的生命周期粗略組織的。我們這個章節(jié)從查看應用程序需要 的數據和表開始。然后我們討論 DB2 對 XML 數據（第 4 章）的存儲選項。之后 , 第 5 章 提供了添加 XML 數據到 DB2 數據庫的竅門和技巧。在第 6 章我們提供了更有效查詢 XML 數 據的指南和例子。為了提高查詢性能，定義和使用 XML 索引的最佳實踐在第 7 章中進行了介 紹。 XML 名稱空間和 XML 更新在第 8 章和第 9 章中分別有所討論。第 10 章和 11 章涵蓋 了對數據庫管理員（DBAs）以及應用程序開發(fā)的附加的主題。最后，12 章以總結最重要的指 南作為結束。
簡單場景：FpML 形式中的金融衍生交易
一個“金融衍生交易”是一個基于（起源于）其它一些金融資產的金融交易，比如股票、 指數、利率、流通、或其它的。在一個金融衍生交易中，根據影響底層資產的市場條件，當事 人雙方同意交易現(xiàn)金。通常情況下，一方利用交易以減輕風險；另外一方利用這個交易來獲得 立即的收入（通過費用或額外費用）或對未來市場情況將提供收益進行投機。讓我們看一個例 子：
YourWord Investments 和 MyGlobal Back 達成了一個外匯兌換交易。他們商議在 10 月 25 號 YourWord 將支付 71,900,000 人民幣給 MyGlobal，并且 MyGlobal 將支付 10,000,000 美元給 YourWorld 。如果 1 美元兌換人民幣從現(xiàn)在到 10 月 25 日其間低于 7.19，MyGlobal 將從這次交易中獲利 .MyGlobal 可能會使用這個交易來避免美元下降的風險 。 YourWorld 可以投機美元將增值，或從 MyGlobal 收取進行交易的前期費用。
衍生交易的奇妙之處是（a）有很多不同的類型和變化，（b）一個特定交易的狀態(tài)往往需 要單獨談判而且很復雜，（c）一個衍生交易的生命周期可以是從幾天到數年的范圍而且它們 的條件可以隨時間而改變。金融企業(yè)發(fā)現(xiàn)在定義一個可以捕捉到衍生交易高度變化標準的數據 格式時需要 XML 的靈活性和可擴展性。結果就是，他們開發(fā)了 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 到關系型表的連接來把相關交易和貨幣信 息聯(lián)系起來。
清單 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 表的內容
<Party>
<PtyID>510026</PtyID>
<ShortName>MIB</ShortName>
<Name>MyGlobal International Bank</Name>
<Status>Active</Status>
<Address>
<Street>498 Wall Street</Street>
<City>New York</City>
<Country>USA</Country>
</Address>
<Rating>
<RatingDate>2006-05-16</RatingDate>
<RatingValue>Baa1</RatingValue>
</Rating>
</Party>
<Party>
<PtyID>67781</PtyID>
<ShortName>NVB</ShortName>
<Name>National Village Bank</Name>
<Status>Active</Status>
<Address>
<Street>1805 Back Street</Street>
<PostalCode>EC3M 4TD</PostalCode>
<City>London</City>
<Country>UK</Country>
</Address>
<Rating>
<RatingDate>2006-06-01</RatingDate>
<RatingValue>Aa</RatingValue>
</Rating>
</Party>
<Party>
<PtyID>99114</PtyID>
<ShortName>YWI</ShortName>
<Name>YourWorld Investments</Name>
<Status>Active</Status>
<Address>
<POBox>98765</POBox>
<PostalCode>100027</PostalCode>
<City>Beijing</City>
<Country>China</Country>
</Address>
<Rating>
<RatingDate>2007-01-15</RatingDate>
<RatingValue>Aaa</RatingValue>
</Rating>
<Rating>
<RatingDate>2005-04-21</RatingDate>
<RatingValue>Aa</RatingValue>
</Rating>
</Party>清單 4 顯示 FpML 文檔表現(xiàn)先前我們描述過的 YourWorld Investment 和 MyGlobal International Bank 之間的貨幣兌換交易。交易以 tradeHeader 元素開始，以“ party1 ”和“ party2 ”標記兩個交易方，并把他們和他們的交易 IDs 以及交易日期聯(lián)系起 來。在 FpML 文檔的最底部，“ party1 ”和“ party2 ”是映射到具體的標識符“ 510026 ”和“ 99114 ”他們引用 PARTIES 表中交易方信息。交易具體的主要部分在 fxSingleLeg 元素中。 FX 是聲明外匯交易，有兩個元素叫 exchangedCurrency1 和 exchangedCurrency1 。第一個表示 YourWorld 支付 CNY 71,900,000 給 MyGlobal，第二個顯示 MyGlobal 支付 10,000,000 給 YourWorld.
為了更清楚的表示，我們已經從 FpML 樣本數據刪除了所有名稱空間。我們將在本文后面 部分重新訪問名稱空間。
清單 4. FpML格式中的一個利率衍生工具
<FpML>
<trade>
<tradeHeader>
<partyTradeIdentifier>
<partyReference href="party1"/>
<tradeId tradeIdScheme="http://www.MyGlobal.com/trade-id">MyGlobal941</tradeId>
</partyTradeIdentifier>
<partyTradeIdentifier>
<partyReference href="party2"/>
<tradeId tradeIdScheme="http://www.YourWorld.com/trade-id">YWI0089</tradeId>
</partyTradeIdentifier>
<tradeDate>2001-10-23Z</tradeDate>
</tradeHeader>
<fxSingleLeg>
<exchangedCurrency1>
<payerPartyReference href="party2"/>
<receiverPartyReference href="party1"/>
<paymentAmount>
<currency>CNY</currency>
<amount>71900000</amount>
</paymentAmount>
</exchangedCurrency1>
<exchangedCurrency2>
<payerPartyReference href="party1"/>
<receiverPartyReference href="party2"/>
<paymentAmount>
<currency>USD</currency>
<amount>10000000</amount>
</paymentAmount>
</exchangedCurrency2>
<valueDate>2001-10-25Z</valueDate>
<exchangeRate>
<quotedCurrencyPair>
<currency1>CNY</currency1>
<currency2>USD</currency2>
<quoteBasis>Currency2PerCurrency1</quoteBasis>
</quotedCurrencyPair>
<rate>7.91</rate>
</exchangeRate>
</fxSingleLeg>
</trade>
<party id="party1">
<partyId>510026</partyId>
</party>
<party id="party2">
<partyId>99114</partyId>
</party>
</FpML> |
清單 5 顯示一個 FpML 文檔的其它例子。這個文檔是一個 “隔夜拆借存款”。 National Village Bank 對來自于 YourWorld Investment 的 25,000,000 歐元存款支付 3% 固定貸款 利率。
清單 5. 在 FpML 中的一個“隔夜拆借存款”例子
<FpML>
<trade>
<tradeHeader>
<partyTradeIdentifier>
<partyReference href="party1"/>
<tradeId tradeIdScheme="http://www.YourWorld.com/trade-id">YWI7623</tradeId>
</partyTradeIdentifier>
<partyTradeIdentifier>
<partyReference href="party2"/>
<tradeId tradeIdScheme="http://www.NationalV.com/swaps/trade-id">69197</tradeId>
</partyTradeIdentifier>
<tradeDate>2002-02-14Z</tradeDate>
</tradeHeader>
<termDeposit>
<productType>Overnight Term Deposit</productType>
<initialPayerReference href="party1"/>
<initialReceiverReference href="party2"/>
<startDate>2002-03-15Z</startDate>
<maturityDate>2002-03-16Z</maturityDate>
<dayCountFraction>ACT/360</dayCountFraction>
<principal>
<currency>GBP</currency>
<amount>35000000.00</amount>
</principal>
<fixedRate>0.03</fixedRate>
</termDeposit>
</trade>
<party id="party1">
<partyId>99114</partyId>
</party>
<party id="party2">
<partyId>67781</partyId>
</party>
</FpML>
這兩個列子（清單 4 和清單 5）讓你對 FpML 衍生數據有了一個概念。 FpML 模式定義了 大約 1800 個不同的 XML 元素和超過 600 種類型。任何一個實例文檔都只包含了其中的一部 分。然而，一個關系型數據庫模式在沒有 XML 列的情況下需要至少 400 到 500 個表才能顯 示任意可能的 FpML 文檔。這是令人恐怖的復雜度，而且通常被認為不可管理。這是為什么 XML 是必須的。
OurTRADES 表包含了 5 個 FpML 文檔，包括上面的兩個。完整的數據樣例可以在一個 DB2 命令行（CLP）腳本中下載。
為 XML 存儲選擇正確的存儲選項
正確的配置存儲選項對于最大化 DB2 數據庫性能非常重要。在這個章節(jié)，我們討論數據庫 的表空間類型、XML 數據在數據庫中存儲的頁面大小、以及在數據庫中存儲 XML 數據的方法 。
提示：在 DB2 9.5 中 XML 在一個 DB2 表空間中消耗的存儲空間是原始 XML 數據以文本 格式在操作系統(tǒng)中占用空間的 0.7 到 1.5 倍。要得到更精確的評估，比如插入 1000 個有代 表性的文檔到一個空表中并抓取一個 DB2 表的快照來查看這個表已使用的頁數。
為 XML 數據選擇表空間類型和頁大小
數據庫管理表空間（DMS）提供了比系統(tǒng)管理 ( 操作系統(tǒng)管理 ) 表空間（SMS）更高的性 能。這對關系型數據尤其如此，對 XML 讀寫訪問上更是如此。最新創(chuàng)建的表空間默認是 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 頁面同樣可以做很好 的折衷，而且你會發(fā)現(xiàn) 32KB 頁面對關系數據和索引有的訪問有負面影響。這這種情況下，你 可以考慮使用其它的頁面大小。
XML 和關系數據使用不同的表空間和頁大小
在清單 1 中的 CREATE TABLE 語句把表中的 XML 數據和關系型數據都存在了相同表空間 里。這意味著它們使用相同的頁面大小和緩沖池。在表空間中，關系數據是存儲在基本數據頁 面上，同時 XML 數據是存在另外的 XML 數據域（XDA）里的頁面中。這是因為就像大對象 （LOBs），XML 文檔可能很大，不能放在表的一個數據頁中的一行里。這種默認的規(guī)劃對于大 多數應用場景提供了很好的性能。這個選項，叫做“基礎內嵌表”，將在下面章節(jié)中進行介紹 ，你應該對在同時存儲 XML 文檔和關系型數據的數據頁面上選擇這個選項。然而，默認情況 下關系型數據和 XML 數據是分開存儲的。
提示：如果你已經完成了性能分析并發(fā)現(xiàn)你需要對 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; |
除非明確指定，新表空間都是創(chuàng)建為有大行 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 字節(jié)的文檔都將以嵌入方式存儲。這里指定的大小是參照 XML 在 DB2 中解析后的大小 ，不是 XML 文本文檔在你文件系統(tǒng)中的大小。嵌入長度必須小于頁面大小減去本頁中其它列 之后的大小。
提示：通常你應該尋求嵌入最多或全部文檔。如果你在表中只有一個 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 |
提示：
如果你的系統(tǒng)是 I/O 限制而非 CPU 限制，壓縮 XML 數據可以提供極大的性能提升。然而 ，要注意內置文檔會顯著的增加在你頁面中的行的大小。這反過來減少了每一頁中的行數。只 訪問表中關系列的查詢現(xiàn)在需要讀取比沒有嵌入文檔要多很多的頁面。這會造成比沒有使用 XML 嵌入文檔情況下更多的 I/O 以及更低的查詢性能。如果你的查詢通常總是查詢 XML 列， 那么對你沒有影響，然而，如果你有很多不涉及 XML 列的查詢，你應或許不應該選擇“內置 ”存儲。
【編輯推薦】
