はじめに

いよいよ DB2 9 がリリースされました。その最新機能、pureXML® をテストする時です。ここでは、証券取引をシミュレートした環境を選びました。この処理プロファイルには、次のような特徴があります。

• トランザクション・ボリュームと並行性が高い
• トランザクション・サイズが小さい
• 小さな XML 文書を大量に処理する
• XML 文書構造がさまざまである。このテストには、金融業界の FIX (Financial Information eXchange) 標準の XML 実装、FIXML に準拠したデータが含まれています。

通常、XML アプリケーションは、次のいずれか一方のグループに分類できることを思い出してください。

• データ指向 (サイズが小さく、量は多い。このテストではこれを使います)
• 文書指向 (サイズが大きく、量はさまざま)

さらに、XML を扱うデータベース・アプリケーションは非常に多様です。その一例として、下記をあげることができます。

• リレーショナル・データを XML として公開する
• XML フルテキスト検索を利用したコンテンツ管理と文書管理
• 多様なデータ・ソースの統合
• フォーム処理
• Web サービスや SOA (service-oriented architecture) のためのバックエンド・サポート
• (特に金融業界での) メッセージ・ベースのトランザクション処理と XML ベースの OLTP (online transaction processing)

この記事では、データ指向の金融アプリケーションをシミュレートした、XML ベースのトランザクション処理シナリオでのパフォーマンス測定の結果を示します。TPoX ベンチマークを使って、このシナリオをシミュレートして測定を行います。テスト用の機器には、AIX 5.3 と TotalStorage DS8100 ディスク・システムを備えた、最新の POWER5 サーバー (p5 560Q) が含まれています。

DB2 9 と XML

DB2 9 での新たな XML サポートには、純 XML ストレージ、XML 索引、XQuery、SQL/XML、そして高度な XML スキーマ処理などが含まれています。「純」の意味は、商用リレーショナル・データベースでの従来の技術とは異なり、XML 文書が型注釈付きのツリーとして保管、処理されるということです。特に pureXML は、XML を大きなオブジェクト (BLOBS や CLOB) として保管したり、あるいは XML を一連のリレーショナル表に分割したりする方式とは大幅に異なります。詳細については、以前の記事、「What's new in DB2 Viper (US)」(developerWorks、2006 年 2 月) と「Native XML Support in DB2 Universal Database」(PDF 224KB)を参照してください。

Adobe® Reader®が必要

上に戻る

テスト・シナリオ: オンライン証券会社

このテスト・シナリオは、オンラインの証券会社をモデル化しています。私達はこれまで、金融関係の企業が XML を採用する際のサポートを経験してきました。この経験は、私達がそうした企業のデータや処理の特性を理解する上で役立っています。このシナリオは意図的に単純化されていますが、それでも文書やトランザクション、XML スキーマなどを十分に表現しています。

このシナリオでの主な論理データ・エンティティーは下記のとおりです (図 1)。

• 顧客 (Customer): 1 件の顧客は、1 つあるいは複数の口座を持つことができます。
• 口座 (Account): 各口座には、1 つあるいは複数の持ち株を含みます。
• 持ち株 (Holding): 証券の口数。
• 証券 (Security): 持ち株の識別子 (例えば株式の名前など)。
• 注文 (Order): 各注文は、1 つの口座に対して 1 つの証券を購入、あるいは売却します。

文書の処理方法とサイズは、次のようにタイプによって異なります。

• 各顧客に対して CustAcc 文書があり、この文書は、その顧客に関する顧客情報のすべてと口座情報、そして持ち株情報を含んでいます。CustAcc 文書のサイズは、4KB から 20KB の範囲です。
• 注文は FIXML 4.4 を使って表現されます。FIXML は、買い注文や売り注文などの取引関係のメッセージ用の業界標準 XML スキーマです (www.fixprotocol.org)。Order 文書のサイズは 1KB から 2KB です。Order 文書には多くの属性があり、データ・ノードが高い割合を占めています。
• 証券文書 (20833 で固定) は、米国で取引される株と投資信託の大部分を表現しており、実際の証券シンボルと証券名を使います。この文書のサイズは 3KB と 10KB の範囲です。

上記の 3 つのスキーマすべてに対して、インスタンス文書を生成するために Toxgene データ・ジェネレーターが使われています。Toxgene データ・ジェネレーターに関する詳細は、ToXgene - the ToX XML Data Generator (US)を参照してください。

上に戻る

TPoX ベンチマーク

TPoX ベンチマークは、最近 http://tpox.sourceforge.net/ (US) でオープンソースとして公開されました。このベンチマークは前のセクションで説明した金融シナリオをシミュレートしており、XQuery や SQL/XML、 XML の挿入、更新、削除、XML 索引、そして並行性などの側面に焦点を当てています。Java で作成されたワークロード・ドライバーは、ワークロードを実行し、パフォーマンスの測定データを収集します。このベンチマークのフル・パッケージは、このベンチマークの Web サイトからダウンロードすることができます。このパッケージには runall.ksh と呼ばれるスクリプトが含まれており、これを使うと XML データを生成でき、またこの記事で解説するすべての実験を再現することができます。また setenv.ksh スクリプトを使うと、特定のマシンで TPoX を実行するように構成することができます。

上に戻る

テスト機器と構成

テストに使われた機器は次のとおりです。

• プロセッサー: ミッドレンジ IBM System p5 560Q の 8 プロセッサー LPAR (logical partition) を使った IBM System p5 560Q。これら 8 つのコアは 1.5GHz で実行しています。
• メモリー: 32GB
• オペレーティング・システム: AIX 5L v5.3 TL04 (システム・タイプ: 9116-561, 2 つの クワッド・コア・チップ・モジュール)
  • 同時マルチスレッドにより、16 の並行実行スレッドあるいは論理プロセッサーを実現。
  • マルチパス SDD (subsystem device driver) をインストール。この機能により、高度なデータ可用性や、ストレージ・サーバー上のファイバー・チャネル・アダプター全体に渡る動的 I/O ロード・バランシングなどの機能を利用でき、ストレージ・サーバーへのアクセスが改善されます。
• ストレージ: 4 台のファイバー・チャネル・アダプターによって LPAR に付加された IBM TotalStorage DS8100

AIX の構成

DB2 をインストールする際、オペレーティング・システムのパラメーターに関して必要な調整は、すべて自動的に行われます。任意のファイルシステム・キャッシングに使用されるメモリー量を適切にコントロールするために、次の仮想メモリー管理パラメーターが設定されています。

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

これらのパラメーターを設定する前に、AIX の仮想メモリー・マネージャーをよく理解しておくようにお勧めします。これらの設定は、他のパラメーター、特に lru_file_repage との関係を考慮して行う必要があります。この XML OLTP 環境では、こうした特定の設定を使用しましたが、これをすべての DB2 環境に対する一般的な推奨条件と考えるべきではありません。

データ・ロード中に入力ファイルをキャッシュしようとする動作を意図的に避けるために、mount コマンドの -o cio オプションを使って、JFS2 ファイルシステムの並行 I/O 機能と未処理の XML 入力ファイルを含むファイルシステムがマウントされています。

ストレージの構成

TotalStorage DS8100 に関しては、標準構成のデフォルトが使われています。DS8100 は基本的に、内部に POWER5 eServer p5 570 を持っています。この前身モデルである、SSA ループの ESS とは異なり、DS8100 ディスク・インターコネクトは高速データ・アクセスと高可用性を実現するために、Switched FC-AL (Fiber Channel Arbitrated Loop) を採用しています。DS8100 は合計 128 台のディスクで構成され、そこに 16 のボリュームが作成されています。このプールから、8 つのボリューム (64 ディスク) が、この LPAR に割り当てられています。4 つのボリュームはサイズが 388GB であり、それぞれ 6 + パリティー + スペアーを使用しています。残りの 4 つのボリュームのサイズは 452GB であり、それぞれ 7 + パリティーを使用しています。また、1 つのボリューム・グループ (VG) が作成され、この VG の中に 8 つのボリュームすべてが含まれます。DB2 データベースの全ストレージ・コンポーネントは、表スペースやログ、バックアップを含め、この VG に対して定義されています。表 1 は、こうした構成の要素を要約したものです。

DB2 の構成

DB2 9 には、新たなオートノミック自己調整機能を含め、いくつかの新機能が含まれています。このテストでは、こうしたオートノミック機能のうち、下記の機能を利用しています。

• オートノミック・ストレージ管理
• 自己調整型メモリー管理

DB2 のSTMM (self-tuning memory manager) が有効になっているため、STMM は広範な DB2 構成パラメーターの設定が最適になるよう、常に調整しています。テスト実行中に STMM が管理し、変更する DB2 の構成パラメーターの内、重要なものをいくつかあげたものが表 2 です。重要なことは、STMM がこうした値を、実行されるワークロードのタイプ (挿入のみ、クエリーのみ、あるいは混合ワークロードなど) に応じて自律的に変更したということです。

これによって DBA 用のデータベース構成タスクはごくわずかになり、それを要約したものが表 3 です。

上に戻る

ワークロード

次の 3 つの XML ワークロードが設計され、実行され、そして測定されました。

• 挿入 (書き込み専用)
• クエリー (読み取り専用)
• 混合 (読み書き)

どのワークロードも、並行性が高いことを特徴としています。これらのワークロードは Java ドライバーによって実行され、このドライバーが 1 対 n の並行スレッドを作成します。各スレッドは、データベースに接続して (考える間もなく) トランザクション・ストリームを送信するユーザーをシミュレートしています。各ストリームは、トランザクション・テンプレートのリストから選択されたトランザクションをランダムに重み付けしたシーケンスです。各トランザクションには重みが割り当てられ、この重みによって、多様なワークロードにおけるそのトランザクションの割合が決定されます。実行時には、トランザクションのパラメーター・マーカーは、(構成可能な) ランダムな値の配分と入力リストから得られる、具体的な値に置き換えられます。

挿入ワークロード: 書き込み専用

挿入ワークロードは、約 100GB の生の XML データをデータベースに追加します。

• 6 百万の CustAcc 文書
• 3 千万の Order 文書
• 20,833 の Security 文書

まず、83 件の並行ユーザーによって、すべての証券が挿入されます。CustAcc 文書と Order 文書は、挿入パフォーマンスがスケーラブルであることを検証するためのステージで挿入されます。各ステージでは 100 件の並行ユーザーが使われています (表 4)。

クエリー・ワークロード: 読み取り専用

挿入ワークロードによってデータベースにデータが追加された後、読み取り専用ワークロードがデータベースに対して実行されます。このワークロードは 7 つの XML クエリーから構成され、並行性レベルをさまざまに変化させて実行されます (使用する並行ユーザーの件数を、25、50、75、100、125、150 と変化させます)。テストの実行時間は、これらの 6 回のテスト実行それぞれに対して 1 時間です。

これら 7 つのクエリーは、次のような共通の特性を持っています。

• 標準に準拠した SQL/XML 表記 (例えば XQuery を埋め込んだ SQL など) で、パラメーター・マーカーを利用して書かれています。詳細については「Advancements in SQL/XML (US)」(PDF 192KB)を参照してください。
• SQL/XML 述部 XMLEXISTS を使用して、また XQuery で表記された 1 つまたは複数の条件に基づいて、XML 文書を選択します。
• SQL/XML 関数 XMLQUERY を使用して、XML 文書の全体または一部を取得します。あるいは、データベースに保管されている文書とは別の新しい結果文書を作成します。
• XML データの中の名前空間に対応した XML 名前空間を使います。
• 1 つまたは複数の XML 索引を活用して、表スキャンを完全に回避します。
• 7 つのクエリーのワークロード中での重み付けは、すべて同じです。

Adobe® Reader®が必要

これら 7 つのクエリーを、それぞれの際立った特長と、それぞれが対象とする表の面から比較したものが表 5 です。

混合ワークロード: 読み書き

混合ワークロードは読み取り専用のワークロードと同じく、6 百万の CustAcc 文書と 3 千万の注文というベース・データに対して、また 25、50、75、100、125、150 と変化する並行ユーザー数により、さまざまな平行性レベルで実行されます。これらのテスト実行それぞれに対して、テスト時間は 1 時間です。

混合ワークロードの構成は以下のとおりです。

• 70% が読み取り操作: クエリー
• 30 % が書き込み操作: 6% が更新、12% が文書削除、12% が挿入

クエリーは上記の読み取り専用ワークロードとまったく同じでしたが、更新、削除、挿入のトランザクションを定義する際には、次ような観察結果を参考にしています。

• 顧客の口座は取引 (注文の実行) を反映して更新されますが、必ずしも各注文の直後に更新されるわけではありません (CustAcc の更新は 3%)
• Order 文書は、このシナリオでは更新されません (従って注文トランザクションは更新されません)
• 証券価格は営業日の日中、定期的に更新されます (証券の更新は 3% )
• 顧客の回転率は低い (CustAcc の挿入が 2%、CustAcc の削除が 2%)
• 新規注文は常に入りますが、古い注文はやがて、そして新規注文と同じ速さでシステムから削除されます (注文挿入が 10%、注文削除が 10%)
• 証券の数は固定しています (削除トランザクションも挿入トランザクションもありません)

こうした目標を組み合わせて適用した結果、表 6 の組み合わせのトランザクションが作成されました。

更新トランザクションは、まず XQuery 述部に基づいて特定の文書を読み取ります。そしてその文書を使って、データベース中にある、その文書のオリジナル・コピーを更新します。実際には、文書は読み取りと更新のステップの間に変更されますが、この記事の目的から見ると重要なことではありません。そのため、ここでは簡単にするためにそれを省略してあります。

挿入は、XML スキーマに対する検証なしに実行されます。

データベース中の文書は、ランダムに選択され、更新、削除操作が行われます。新たに挿入される Order 文書と CustAcc 文書はどれも、挿入された直後から継続するトランザクションによって、更新、あるいは削除が可能です。

上に戻る

結果

データベース設定とすべてのワークロードは、中断のない 1 つのシーケンスとして実行されます。その結果、23 時間ノン・ストップのシステム・テストとなりました (表 7)。

挿入ワークロードの結果

36,020,833 の文書を挿入するまでの合計時間は 約 160 分であり、その結果、平均スループットは3770 挿入/秒となりました。スループットは、下記のようにサイズによって異なりました。

• Order 文書 (1K から 2K) を挿入する場合は平均 5320 挿入/秒
• 口座文書 (3K から 10K) を挿入する場合は平均 1550 挿入/秒

どちらの挿入速度も、量としてはおよそ毎時 30GB です。図 2 は、注文数が 3 千万文書まで増えても注文挿入速度がほぼ一定であることを示しています。

クエリー・ワークロードの結果

クエリー・ワークロードのパフォーマンスは、ユーザー数が増えるに従って、また CPU 利用率が高まるに従って高まりました。予想したとおり、CPU 利用率が 100% に近付くと、スループットは平坦になります。最高のスループットは、ユーザーが 150 の場合の 5480 クエリー/秒であり、その際の CPU 利用率は 96% でした (図 3)。

ユーザー数を 175 に増加しても、既にマシンの容量一杯であったため、大幅に高いスループットは得られませんでした。

混合ワークロードの結果

混合ワークロードの場合も、最高パフォーマンスは並行ユーザーの数が 150 の場合に得られました (図 4)。この場合のスループットは 1980 トランザクション/秒です。予想したとおり、混合ワークロードのスループットは、クエリーのみのワークロードや挿入のみのワークロードよりも低くなっています。

上に戻る

まとめ

パフォーマンスに関するこのテストの目的は、最新の IBM サーバー・ハードウェア、ストレージ、AIX オペレーティング・システム、そして XML ワークロード用の DB2 9 ソフトウェアを使用した場合の操作パフォーマンスの特性を示すことでした。この目的を実現するために、TPoX ベンチマークを使用しました。すべてのテストにおいて、DB2 の新たな STMM 機能と自動ストレージ機能を使用しました。

このワークロード・シナリオは、メッセージ・ベースのトランザクション処理や大量の小さな XML 文書を処理する Web サービス・アプリケーションなど、重要な XML アプリケーションをよく表現しているものと思います。ここでは金融業界を選択しましたが、その理由は私達がこの業界で豊富な経験を持っていること、またこの業界が、成熟し、標準化された XML スキーマである FIXML を採用しているためです。

テスト結果を要約すると、

• 全体としてのテスト時間は、データベースの作成を含めて 23 時間でした。
• テスト・データは、6 百万の CustAcc 文書、3 千万の Order 文書、そして 20,833 の Security 文書から構成されています。
• テストは、並行ユーザー数を 25、50、75、100、125、150 として行われました。
• 挿入のスループット (tps: transactions per second) は文書サイズによって異なりますが、あるサイズまでは、直線的に変化します。スループット量は、文書サイズによらず毎時 30GB で一定でした (下記)。
  • 1550 tps (4K から 20Kの CustAcc 文書に対して)
  • 5320 tps (1K から 2K の Order 文書に対して)
• クエリーのスループットは、下記のように並行ユーザー数が増加するに従って高まります。
  • 25 ユーザーでは 2000 tps
  • 150 ユーザーでは 5500 tps (CPU 利用率最大、I/O 待ち時間はほぼゼロ)
• 混合トランザクションのスループットも、同じくユーザー数が増加するに従って高まり、約 2000 tps で平坦になります。
  • 25 ユーザーでは 1000 tps
  • 150 ユーザーでは2000 tps (CPU 利用率は約 42％、I/O 待ち時間は約 50%)

上に戻る

謝辞

著者らは、このプロジェクト全体を成功に導き、またこの記事への協力をいただいた Sunil Kamath と Punit Shah の両氏に感謝いたします。

参考文献

学ぶために

• 「Transaction Processing over XML (TPoX) benchmark (US)」を読んでください。TpoX、オンライン証券会社のシナリオに基づくベンチマーク、そしてデータベースでさまざまな XML 新機能を利用する方法について学ぶことができます。
  
  
• 「DB2 9 - pureXML and storage compression (US)」を読んでください。pureXML によって XML とリレーショナル・データとをシームレスに統合できるため、アプリケーション開発をスピードアップできること、その他さまざまなことを学ぶことができます。
  
  
• 「Native XML Support in DB2 Universal Database (US)」 (PDF 224KB) (2005年、第 31 回 VLDB Conference の議事録) は、プログラミング言語のエクステンションの要約を提供しています。
  
  
• 「What's new in DB2 Viper: XML to the Core (US)」(developerWorks、2006年2月) は、現在は DB2 でベータ版となっている新しい XML 技術について、概要を説明しています。
  
  
• 「Toxgene Data Generator (US)」を読み、合成 XML 文書を大量に一貫して生成できるテンプレート・ベースのジェネレーター、ToXgene について学んでください。
  
  
• 「Advancements in SQL/XML (US)」(PDF 192KB) (Sigmod Record、33(3)、2004年) を読み、SQL/XML の第 2 版に追加されている新機能について学んでください。
  
  
• IBM System p5 560Q ミッドレンジ・サーバーは、抜群のコストとパフォーマンス、メインフレームに匹敵する信頼性と可用性機能、また 16 コアまでのスケーラビリティーを備えています。
  
  
• IBM Totalstorage DS8100 シリーズは、高容量ストレージ・システムとして、何世代も飛躍した高いパフォーマンス、スケーラビリティー、弾力性、そして高い価値を実現するために設計されています。
  
  
• developerWorks の Information Management ゾーンを訪れ、IBM の広範な情報管理製品群に関するスキルを磨いてください。
  
  
• developerWorks technical events and webcasts (US) で最新情報を入手してください。
  
  

製品や技術を入手するために

• 皆さんの次期開発プロジェクトを IBM trial software (US) を利用して構築してください。developerWorks から直接ダウンロードすることができます。
  
  

議論するために

• ディスカッション・フォーラム (US)に参加してください。
  
  
• developerWorks blogs (US) から developerWorks のコミュニティーに加わってください。
  
  

著者について

Irina Kogan は IBM Toronto Lab のソフトウェア・エンジニアであり、開発者と顧客の両方と共に DB2 での XML パフォーマンスに関する業務を行っています。彼女が関心を持っている領域は、XML ストレージや構成の更新、XQuery、OLTP、ベンチマーク開発などです。彼女は York University でコンピューター・サイエンスの学位と修士号を取得しています。修士研究では、データベースにおけるセマンティック整合と適切な設計原則に取り組みました。2004 年に IBM に入社する前には、ドイツの Siemens で XML とJava の開発に従事していました。

Nicola 博士は、IBM Silicon Valley Lab の XML データベース・パフォーマンスの技術リーダーです。彼の業務は、XQuery、SQL/XML、また DB2 ネイティブの XML 機能を含め、DB2 での XML パフォーマンスのあらゆる側面を対象としています。Nicola 博士は DB2 XML 開発チームや XML を使用する顧客やビジネス・パートナーと緊密に業務を進めながら、XML ソリューションの設計や実装、最適化に協力しています。IBM に入社する前には、Informix Software でデータ・ウェアハウスのパフォーマンスに関する業務を行っていました。また、分散データベースや複製データベースに関する研究と業界プロジェクトにも 4 年間携わっていました。彼は、1999年にドイツの Technical University of Aachen でコンピューター・サイエンスの博士号を取得しています。

Berni Schiefer は DB2 distinguished engineer です。彼は、BCU を含む、DB2 のパフォーマンス・ベンチマークとソリューション開発に責任を持っています。彼は 1985 年に IBM Toronto Lab に入社しました。DB2 に関する業務を担当するまでは、IBM Almaden Research Lab で実験的リレーショナル・データベース、SQL/DS と Starburst に取り組んできました。現在の業務の主眼は、プロセッサーやパフォーマンス、XML、Linux、仮想化、オートノミックなどを特に重視しつつ、先進技術を DB2 に導入することです。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• テスト・シナリオ: オンライン証券会社
• TPoX ベンチマーク
• テスト機器と構成
• ワークロード
• 結果
• まとめ
• 謝辞
• 参考文献
• 著者について
• コメント