DB2 9 XML 性能特征

了解一個使用 DB2® 9 XML、IBM POWER5+、AIX 5.3 和 TotalStorage DS8100 的模擬證券經紀事務處理環境的性能和可伸縮性。這個場景使用了 FIXML 模式，這是一個金融業標準。

簡介

既然 DB2 9 發布了，現在是時候對它的最新特性之一 —— pureXML® 進行測試驅動了。為此，建立了一個模擬的經紀業務環境。這個環境具有以下特征：

• 高事務量和并發性
• 小的事務大小
• 大量小型 XML 文檔
• 可變的 XML 文檔結構 —— 測試包含符合 FIXML 的數據，FIXML 是 Financial Information eXchange（FIX）標準的金融業 XML 實現。

請記住，XML 應用程序大致分成以下兩類：

• 面向數據的（高數據量，小文檔，這個測試就是針對這種情況）
• 面向文檔的（可變數據量，大文檔）

另外，涉及 XML 的數據庫應用程序也是各種各樣的，包括以下情況：

• 以 XML 形式發布關系數據
• 用 XML 全文本搜索進行內容和文檔管理
• 合并不同的數據源
• 表單處理
• 對 Web 服務和面向服務體系結構（SOA）的后端支持
• 基于消息的事務處理和基于 XML 的在線事務處理（OLTP），尤其是在金融業中

本文在一個基于 XML 的事務處理場景中進行性能度量，這個場景模擬一個面向數據的金融應用程序。測試設備包括最新的 POWER5 服務器（p5 560Q）以及 AIX 5.3 和 TotalStorage DS8100 磁盤系統。

DB2 9 和 XML

DB2 9 中新的 XML 支持包括純 XML 存儲、XML 索引、XQuery、SQL/XML 和高級的 XML 模式處理。“純” 意味著以標注上類型的樹的形式存儲和處理 XML 文檔，這與商業關系數據庫中以前的任何技術都不同。尤其是，pureXML 與將 XML 存儲為大對象（BLOB 或 CLOB）或者將 XML 分解到關系表中的技術有顯著差異。更多的信息請參考以前的文章 “What's new in DB2 Viper” （developerWorks，2006 年 2 月）和 “Native XML Support in DB2 Universal Database”。

回頁首

測試場景：在線經紀業務

這個測試場景對在線經紀業務進行建模。我們曾經幫助金融公司采用 XML。這些經歷幫助我們理解了他們的數據和處理特征。這個場景有意地進行了簡化，但是在文檔、事務和 XML 模式方面仍然具有代表性。

這個場景中主要的邏輯數據實體如下（見圖 1）：

• Customer： 一個客戶可以有一個或多個帳號（account）。
• Account： 每個帳號包含一個或多個持有物（holding）。
• Holding： 某一證券 的數量。
• Security： 某一持有物的標識符（例如，股票名稱）。
• Order： 為一個帳號 買賣一種證券 的訂單。

文檔處理和大小因文檔類型而異：

• 對于每個客戶，有一個 CustAcc 文檔，其中包含這個客戶的所有客戶信息、帳號信息和持有物信息。CustAcc 文檔的大小在 4KB 和 20KB 之間。
• 使用 FIXML 4.4 表示訂單。FIXML 是用于交易相關消息（比如買賣訂單）的行業標準 XML 模式（www.fixprotocol.org）。訂單文檔的大小是 1KB 到 2KB。訂單文檔有許多屬性，而且數據節點的比例很高。
• 證券文檔（20833 個）使用實際的證券符號和名稱，表示在美國交易的大多數股票和共同基金。它們的大小在 3KB 和 10KB 之間。

使用 Toxgene 數據生成器為這三個模式生成實例文檔。關于 Toxgene 數據生成器的更多信息，請參考 ToXgene - the ToX XML Data Generator。

回頁首

測試設備和配置

測試在以下設備上運行：

• 處理器： IBM System p5 560Q，使用 8 個處理器的邏輯分區（LPAR），這是一個中等的 IBM System p5 560Q。8 個處理器以 1.5GHz 的頻率運行。
• 內存： 32GB
• 操作系統： AIX 5L v5.3 TL04（系統類型：9116-561，兩個 4 芯片模塊）
  • 并發多線程提供 16 個并發執行線程或邏輯處理器。
  • 安裝了一個多路徑子系統設備驅動程序（SDD）。這個特性可以改進存儲服務器訪問，比如改進數據可用性和存儲服務器上跨光纖通道適配器的動態 I/O 負載平衡。
• 存儲： IBM TotalStorage DS8100，通過 4 個光纖通道適配器連接到 LPAR。

AIX 配置

在安裝 DB2 期間，會自動執行所有必需的操作系統參數調整。設置了以下的虛擬內存管理參數，從而更好地控制文件系統緩存使用的內存量：

vmo -o minperm%=5
            vmo -o maxclient%=15
            vmo -o maxperm%=15
            

另外，為了防止在數據裝載期間試圖緩存輸入文件，在掛裝命令中使用 -o cio 選項，用 JFS2 文件系統的并發 I/O 特性掛裝包含原始 XML 輸入文件的文件系統。

存儲配置

使用 TotalStorage DS8100 的標準默認配置。DS8100 在內部基本上是一個 POWER5 eServer p5 570。與之前的 ESS 使用 SSA 循環不同，DS8100 磁盤互連是一個 Switched Fiber Channel Arbitrated Loop（FC-AL），可以提供更快的數據訪問和高可用性。DS8100 配置了 128 個磁盤，在這些磁盤上創建了 16 個卷。在其中，8 個卷（64 個磁盤）分配給這個 LPAR。4 個卷使用 6+Parity+Spare 設置為 388GB。另外 4 個卷使用 7+Parity 設置為 452GB。創建了一個跨越所有 8 個卷的卷組（VG）。在這個卷組上定義了 DB2 數據庫的所有存儲組件，包括表空間、日志和備份。表 1 總結了配置。

DB2 配置

DB2 9 包含許多新特性，包括新的自治自調整功能。在這個測試中，利用了其中幾種自治功能，包括：

• 自動存儲管理
• 自調整內存管理

因為啟動了 DB2 的自調整內存管理器（STMM），它會連續調整一系列 DB2 配置參數的設置。在測試運行期間 STMM 管理和調整的一些關鍵的 DB2 配置參數見表 2。要意識到的重要情況是，STMM 會根據正在運行的工作負載類型（比如純插入、純查詢或混合型工作負載）自主地修改這些值。

DBA 只需要執行很少的數據庫配置任務，見表 3。

回頁首

工作負載

設計、執行并度量了三種 XML 工作負載：

• 插入（只寫）
• 查詢（只讀）
• 混合（讀-寫）

這些工作負載都具有很高的并發性。工作負載由一個 Java 驅動程序執行，這個程序產生一個到 n 個并發線程。每個線程模擬一個用戶，該用戶連接到數據庫并提交一個事務流，而不考慮次數。每個事務流是以加權方式從一系列事務模板中隨機選擇的一系列事務。每個事務被分配一個權重，這個權重決定這個事務在工作負載中的百分比。在運行時，事務中的參數標志替換為具體的值，這些值是從可配置的隨機值分布和輸入列表中提取的。

插入工作負載：只寫

插入工作負載用大約 100GB 的原始 XML 數據填充數據庫：

• 600 萬個 CustAcc 文檔
• 3000 萬個訂單
• 20833 種證券

首先，83 個并發用戶插入所有證券。然后，分階段插入 CustAcc 和訂單文檔，從而檢驗插入性能是可伸縮的。在每個階段使用 100 個并發用戶，見表 4。

查詢工作負載：只讀

在插入負載填充數據庫之后，對數據庫執行一個只讀的工作負載。這個工作負載由 7 個 XML 查詢組成，使用 25、50、75、100、125 和 150 個并發用戶以不同的并發度執行。測試的時間長度是這 6 個測試各運行一個小時。

7 個查詢都具有以下特征：

• 它們都是用符合標準的 SQL/XML 表示法編寫的，比如帶有嵌入式 XQuery 的 SQL，利用了參數標志。更多信息請參考 Advancements in SQL/XML。
• 它們使用 SQL/XML 謂詞 XMLEXISTS 根據一個或多個條件選擇 XML 文檔，條件用 XQuery 表示法表示。
• 它們使用 SQL/XML 函數 XMLQUERY 檢索完整的或部分 XML 文檔，或者構造與數據庫中存儲的文檔不同的結果文檔。
• 它們使用與 XML 數據中的名稱空間對應的 XML 名稱空間。
• 它們利用一個或多個 XML 索引完全避免表掃描。
• 這 7 個查詢在工作負載中具有同樣的權重。

表 5 顯示這 7 個查詢的特征差異和它們涉及的表。

混合工作負載：讀/寫

與只讀工作負載相似，混合工作負載針對填充的 600 萬個 CustAcc 文檔和 3000 萬個訂單執行，并使用 25、50、75、100、125 和 150 個并發用戶產生不同的并發度。測試的時間長度是每個測試各運行一個小時。

混合工作負載由以下操作組成：

• 70% 的讀操作：查詢
• 30% 的寫操作：6% 的更新操作，12% 的文檔刪除操作，12% 的插入操作。

查詢與上面的只讀工作負載中的查詢完全一樣，下面是定義更新/刪除/插入事務時考慮的情況：

• 更新客戶帳號以反映交易（訂單的執行），但是不需要在每個訂單之后立即執行（3% 的 CustAcc 更新）
• 在我們的場景中不更新訂單文檔（因此沒有訂單更新事務）
• 在交易時間定期更新證券的價格（3% 的證券更新）
• 客戶的插入和刪除少（2% 的 CustAcc 插入，2% 的 CustAcc 刪除）
• 新訂單不斷到達，舊訂單從系統中刪除，兩者的速率是相同的（10% 的訂單插入，10% 的訂單刪除）
• 證券種類的數量是固定的（沒有刪除和插入事務）

通過考慮這些目標，產生了表 6 所示的事務組合。

更新事務首先根據一個 XQuery 謂詞讀取一個特定文檔，然后使用它更新數據庫中這個文檔的原副本。在實際情況下，在讀取和更新步驟之間會更新文檔，但是這與本文的目的沒什么關系，因此為了簡化省略了這個步驟。

在執行插入時不進行 XML 模式檢驗。

更新和刪除操作所針對的文檔是在數據庫中隨機選擇的。每個新插入的訂單和 CustAcc 文檔馬上可以被后續的事務更新或刪除。

回頁首

結果

數據庫設置和所有工作負載不間斷地連續執行。23 小時的不間斷系統測試的結果見表 7。

插入工作負載的結果

插入 36,020,833 個文檔花費的總時間大約是 160 分鐘，產生的平均吞吐量是每秒 3770 個插入。吞吐量隨文檔的大小而變化：

• 訂單文檔（1K 到 2K）以平均每秒 5320 個插入的吞吐量插入。
• 帳號文檔（3K 到 10K）以平均每秒 1550 個插入的吞吐量插入。

插入這兩種文檔的數據量速度都是大約每小時 30GB。圖 2 顯示隨著訂單數量增長到 300 萬個文檔，訂單插入的速度幾乎保持不變。

查詢工作負載的結果

查詢工作負載的性能隨著用戶數量的增加和更好地利用 CPU 而增加。正如預期的，隨著 CPU 利用率接近 100%，吞吐量曲線逐漸變平。最好的吞吐量出現在有 150 個用戶的情況下，在 CPU 利用率為 96% 時達到每秒 5480 個查詢，見圖 3。

將用戶數量增加到 175 并不會使吞吐量顯著提高，因為機器已經達到滿負荷了。

混合工作負載的結果

混合工作負載最好的性能也出現在有 150 個并發用戶時，見圖 4。吞吐量是每秒 1980 個事務。正如預期的，混合工作負載的吞吐量比純查詢和純插入工作負載低。

回頁首

結束語

這次性能研究的目的是，在使用最新的 IBM 服務器硬件、存儲、AIX 操作系統和 DB2 9 軟件的情況下，演示 XML 工作負載的操作性能特征。所有測試都使用 DB2 新的 STMM 和自動存儲特性。

我們覺得，對于包含基于消息的事務處理的 XML 應用程序以及處理大量小 XML 文檔的 Web 服務應用程序，這個工作負載場景是有代表性的。選擇金融業是因為我們在這方面有經驗，而且它采用了一種成熟的標準化的 XML 模式 —— FIXML。

下面對測試的情況做一下總結：

• 總測試時間為 23 小時，包括創建數據庫。
• 測試數據由 600 萬個 CustAcc 文檔、3000 萬個訂單文檔和 20833 個證券文檔組成。
• 測試分別采用 25、50、75、100、125 和 150 個并發用戶。
• 插入吞吐量（每秒事務數，即 tps）隨文檔的大小而變化，但是在一個大小內是線性的。吞吐數據量穩定在每小時 30GB，與文檔大小無關：
  • 1550 tps（CustAcc 文檔，4K 到 20K）
  • 5320 tps（訂單文檔，1K 到 2K）
• 查詢吞吐量隨并發用戶數量伸縮：
  • 25 個用戶時 2000 tps
  • 150 個用戶時 5500 tps（CPU 利用率最大，I/O 等待時間接近零）
• 混合事務吞吐量也隨并發用戶數量伸縮，直到大約 2000 tps：
  • 25 個用戶時 1000 tps
  • 150 個用戶時 2000 tps（~42% 的CPU 利用率，~50% 的 I/O 等待時間）。

回頁首

致謝

作者感謝 Sunil Kamath 和 Punit Shah 對這個項目和本文的貢獻。