レベル: 中級 Matthias Nicola (mnicola@us.ibm.com), DB2/XML Performance, IBM Silicon Valley Laboratory
Vitor Rodrigues (vrodrig@us.ibm.com), DB2 pureXML Technical Enablement, IBM
2006年 12月 07日 DB2® V8 XML Extender は、他のデータベースと同じく、XML のストレージとアクセスのための 2 つのモデルを用意しています。つまり XML 文書に手を加えず構文解析されないテキストとして CLOB 列に格納することもでき、あるいは XML 文書を一連のリレーショナル表にマップし、シュレッドすることもできます。どちらのオプションにも、パフォーマンスの制約があることが知られています。DB2® 9 の新たな pureXML™ 技術は、こうした制約を、XML 固有の階層フォーマットで XML を格納し、クエリーを実行することで克服しようとしています。この記事では、pureXML によるパフォーマンスのメリットがある場合とない場合、また CLOB ストレージやシュレッドによるストレージとのパフォーマンスの違いを定量的に示す一連の測定結果について説明します。
はじめに
DB2® 9 の pureXML™技術は、XML データ管理を最高レベルのパフォーマンスで行えるように設計されています。この記事では、pureXML のパフォーマンスを、CLOB (character large object) およびシュレッドによる XML ストレージのパフォーマンスと比較します。多くのデータベース・システムでは、XML データを CLOB として、あるいはリレーショナル表に「シュレッド (shred) して」格納することができます。この 2 つのオプションは、DB2® V8 でも XML Extender によってサポートされています。DB2 9 でも後方互換性が維持されており、XML Extender を利用することができます。しかし pureXML の機能は、この 2 つのオプションを上回っています。
DB2 の XML Extender は、一連のストアード・プロシージャーと UDF (user-defined function)、UDT (user-defined data typ) などから構成されており、これらが DB2 のコア・エンジンの上に XML 機能を追加しています。XML Extender は、こうしたプロシージャーと UDF の中に XML パーサーと XML 専用ロジックを備えることによって、(従来の DB2 エンジンの機能がサポートする) XML の格納と取得の機能を実行します。XML Extender(US) は、XML Extender Column あるいは XML Extender Collection と共に使用することができます。
XML Extender Column を使用する場合は、XML 文書に手を加えず、構文解析されないプレーン・テキストとしてそのまま格納することができます。このプロセスは非常に単純ですが、XML 文書の内部構造を無視しています。基礎となるストレージを、CLOB 列に、あるいは VARCHAR 列に、あるいはファイルシステム内のファイルにすることもできます。VARCHAR 列の場合、XML Extender はサイズが 3KB までの文書しか格納できません。多くのアプリケーションでは、この制限を保証するのは困難です。理解の深い DBA (database administrator) であれば、この制限を 32k に変更できるかもしれませんが、この最大値でさえ保証は困難なことが多いものです。外部ファイル・ストレージは柔軟ですが、データベース管理による一貫性と保全性を確保できません。そのため、2GB までの 文書を保存できる CLOB が、XML Extender Column のための最も一般的な選択肢となっています。後ほど、XML Extender の CLOB 列のパフォーマンスを検証します。
XML Extender Collection を使用する場合には、XML データをリレーショナル・フォーマットに変換することができます。そのためには、データベース・スキーマの中に、想定される XML 構造からリレーショナル表への固定マッピングが必要です。ストアード・プロシージャーは、このマッピングに基づいて XML 文書からアトミックなデータ値を抽出し、それらの値を従来のリレーショナル行や列に挿入します。このプロセスは、「シュレッディング (shredding)」つまり分解として知られています。このプロセスには XML 構文解析が含まれており、1 つの論理 XML 文書挿入を一連の SQL 行挿入に変換します。現実のアプリケーションでは、数十のリレーショナル表を使うことで、オリジナルの XML 構造の中にある 1 対多の関係のすべてを簡単に表現することができます。いったんデータがリレーショナル・フォーマットになれば、単純な SQL を使ってデータにアクセスし、操作を行うことができます。しかし、オリジナルの XML 文書の再構成も非常にコストがかかります。多方向結合や、適切な XML タグ付けの生成が必要になります。タグ付けは標準化された SQL/XML 公開関数 (US) で定義でき、それによってオリジナルの文書、あるいは新規の文書や別の文書を再構成することができます。しかし XML Extender Collection は、オリジナルの XML 文書に関連付けられたデジタル署名を保存しません。
XML データをリレーショナル・フォーマットで利用できることは、相変わらず重要な要求事項です。その最も一般的な理由として、リレーショナル・データしか利用できないレガシーの SQL アプリケーションやパッケージ化されたビジネス・アプリケーション、BI (business intelligence) ツールなどにデータを提供する必要性があげられます。そのため DB2 9 は、新しい「分解」ソリューションを提供しています。このソリューションは「注釈付きスキーマ・シュレッド」あるいは「新シュレッド」としても知られており、XML Extender Collection のシュレッディングよりも 7 倍から 8 倍高速です。後ほど、この新しい高速シュレッダーのパフォーマンスを、IBM DB2 9 の IBM pureXML™ サポートと比較します。
DB2 9 での新たな pureXML 技術は、CLOB あるいはシュレッドによる XML ストレージとは大幅に異なっています。pureXML は文書をプレーン・テキストとして格納せず、また XML をリレーショナル表やオブジェクト・リレーショナル表にマップしません。XML を、XML のデータ・モデルと一致する XML 固有の階層構造フォーマットで格納するのです。すべての XML 文書は、明確に定義された要素と属性のツリーであり、また XML クエリーはツリーのトラバーサルとして表現されます。つまり、そうした XML の構造に対応した階層構造ストレージと処理フォーマットとすることで、効率的な XML データ管理が行えることが直感的にわかります。この主張を裏付けるために、DB2 9 のpureXML のパフォーマンスを、CLOB ベースの XML処理とシュレッドによる XML 処理と比較します。
テストの構成
表 1 は、この記事で行った比較の要約です。基本的に、CLOB ストレージとシュレッドによるストレージに対する重要な XML 操作を、それに対応する pureXML 操作と比較しています。
表 1. CLOB をシュレッドによる XML 処理と pureXML と比較する
| CLOB による XML 処理 | DB2 9 の pureXML |
|---|
|
XML を XML Extender の CLOB 列に挿入する
|
XML を XML 列に挿入する
| |
CLOB から完全な文書を取得する
|
XML 列から完全な文書を取得する
| |
XML Extender の「抽出」関数を使って CLOB の XML をクエリーする (クエリー時に XML 構文解析を行う)
|
XML 列に対する XQuery
| | | | XML をリレーショナル表にシュレッドする | DB2 9 の pureXML |
|---|
|
DB2 9 の新しいシュレッドを使って XML をリレーショナル表にシュレッドする
|
XML 列に XML を挿入する
| |
SQL/XML 公開関数を使ってリレーショナル・データ (それまでにシュレッドされた XML など) から XML 文書を作成する
|
XML 列に対する XQuery
|
すべてのテストは、下記のデータと設定で行われました。
- IBM® AIX® 5.2 (64bit) を搭載した 4-CPU の pSeries システムと、1 つの DB2 9 インスタンス
- 記事「DB2 9 の XML パフォーマンス特性」の金融シナリオで使用した、1,000 から 100,000 件の間の CustAcc 文書 (サイズは 4kb から 20kb)
- 32kb のページ・サイズを持つ DMS (database managed) 表スペース
- すべての表スペースは、(一部の CLOB ストレージ・テストのように) 特に断りがない限り、no file system caching オプションを使って定義されています。
- すべての表スペースは 10 台以上の物理ディスクに分散され、またデータベース・ログは別ストライプのボリュームに置かれます。
- 公平で有効な比較を行うために、すべてのテストにおいてデータベースの構成と調整は同じにしてあります。
CLOB 列を pureXML 列と比較する
現在、あるカテゴリーの XML アプリケーションでは、XML ストレージとして CLOB 列が一般的に使われているため、この比較は興味深いものと言えます。DB2 9 が登場するまでは、それ以上の選択肢がありませんでした。CLOB ストレージと pureXML 処理との基本的な違いは、XML 構文解析と、構文解析が挿入やクエリーのパフォーマンスに与える大きな影響にあります。
CLOB 列に XML 文書が挿入される場合、これらの文書は構文解析されないテキスト・オブジェクトとして挿入されます。挿入時に構文解析を行わないようにすることで、特に CPU にバインドされるシステムでは、パフォーマンスの面でメリットがあります。しかし XML 構文解析を行わないとなると、XML 文書の構造は完全に無視されてしまいます。そのためデータベースは、格納されたテキスト・オブジェクトに対してインテリジェントで効率的な検索や抽出操作を行うことができません。唯一の対策として、クエリー実行時に XML パーサーを呼び出し、検索条件が評価されるように XML 文書を「調査」するしかありません。XML 構文解析は CPU 負荷が非常に高いため、検索や抽出のパフォーマンスは低くなりがちです。CLOB 列から XML 文書を素早く読むためには、盲目的に文書全体を取得する方法しかありませんが、この方法でも XML の内部構造は無視されます。
DB2 9 の pureXML 技術では、XML 文書を挿入時に構文解析し、クエリー時には構文解析しません。XML 文書は、構文解析されたフォーマット (DB2 9 では、新しいデータ型である「XML」を使って表現されます) で格納され、クエリーを実行されます。この構文解析されたフォーマットはノードのツリーの構造であり、XML 文書をテキスト表現したものとは異なっています。検索操作と抽出操作には XML 構文解析が行われません。XML 構文解析のオーバーヘッドは挿入時にしか生じないため、これはパフォーマンスの面で非常にメリットがあります。同様に、XML 列から文書を取得するにはシリアライズが必要です。つまり、構文解析された XML フォーマットを元のテキスト表現に戻す変換が必要です。このオーバーヘッドは、XML が既にテキスト形式で保存されている CLOB から完全な XML 文書を読み取る際には生じません。
要約すると、CLOB ストレージは挿入や完全な文書取得には適切なパフォーマンスを示しますが、その代わり検索と抽出のパフォーマンスは貧弱なことが普通です。DB2 9 の XML データ型は、挿入と取得のパフォーマンスをいくらか犠牲にすることで、検索と抽出に非常に高いパフォーマンスを得ています。ビジネス・データの場合、挿入よりも検索、分析されることの方が多いため、これは妥当なトレードオフです。つまり 1 つの挿入に対して複数の検索、というのが一般的な比率なのです。また、XML 列は潜在的にオーバーヘッドが高いのですが、多くの場合、その欠点よりも XML 列がバッファー・プールにバッファーされる (CLOB 列はバッファーされないが) 利点の方が大きいと言うことができます。
次のセクションでは、こうしたトレードオフを定量化するために行われたパフォーマンス測定の結果について調べます。
CLOB 挿入を XML 挿入と比較する
最初のテストでは、索引を付けた場合と付けない場合とで、100,000 件の文書を連続的に挿入しました。この場合、多くの OLTP アプリケーションと同じように、1 つの文書を挿入する毎に必ずコミットしています。図 1 の結果は、XML 列挿入と CLOB 列挿入との間での相対的な経過時間を示しています (低い方が優れています)。XML 挿入の経過時間を比較のベースライン (100%) とすると、6 つの XML 索引を維持しても、ほんのわずかのオーバーヘッドしか生じません (このシナリオでは 5%)。
図 1: シングル・ユーザーの場合の XML 列と CLOB 列の挿入パフォーマンスの比較
同じ XML データを CLOB 列に挿入する場合には、約半分の時間しかかかりません (53%)。これは、XML 構文解析と、XML データに対する詳細な処理が回避されているためです。大まかに言えば、CLOB 列にとって XML Extender の「サイド・テーブル」は、XML 列に対する本物の XML 索引に対応します。挿入時にサイド・テーブルを維持するためには、XML 構文解析と追加のリレーショナル挿入が必要です (選択された XML 要素と属性の値は別々に抽出され、格納されるため)。その結果、挿入の経過時間は、少なくとも pureXML 挿入の時間と同じになります。このシナリオでは 23% 高くなっています。
図 1 の実験は、DB2 の表スペースに no file system caching オプションを使っています。もしDMS 表スペース・コンテナーにファイル・システム・キャッシングを許すと (図 2)、XML 挿入のパフォーマンスはわずかに高まる一方、CLOB 挿入のパフォーマンスは低くなります。CLOB 挿入は直接書き込みを使うため、ファイル・システム・キャッシュは必要なく、純然たるオーバーヘッドでしかありません。しかし、もし XML 構文解析を行わないのであれば、ファイル・システム・キャッシングは CLOB 列に対する読み取り操作には効果的です。
図 2. XML 列挿入と CLOB 列挿入に対するファイルシステム・キャッシングの影響 (索引、サイド・テーブルなし)
シングル・ユーザーのデータベース・アプリケーションは非常に稀です。そのため、並行ワークロードに対するパフォーマンス特性に注目することが重要です。この挿入テストは、別々にデータベースに接続される 10 本の並行スレッドを使うように変更されています。それぞれの接続は、10,000 件の文書を (考える時間なしに) 挿入します。図 3 は、ワークロードが大きく増加することによって CLOB パフォーマンスが劇的に悪化することを示しています。CLOB 挿入は、シングル・ユーザーのテストでは XML 挿入の約 2 倍高速でしたが (図 1)、このマルチ・ユーザー・テストでは 2 倍以上低速です (207%)。これは、CLOB 挿入が XML 列挿入ほど並行動作の恩恵を受けないためです。並行動作の数が増加するにつれ、XML 列でのバッファー型挿入は、CLOB での並行直接書き込みよりもはるかにスケーラブルになります。
図 3: マルチ・ユーザーでの挿入パフォーマンスを XML 列と CLOB 列とで比較する
図4 を見ると、並行動作による高速化が、CLOB 列よりも XML 列でかなり顕著なことがわかります。シングル・ユーザーでの XML 挿入を 100% のベースラインとすると、私達のシステムと構成では、10 の並行挿入ストリームによって、同じ 100,000 の文書を 18% の時間で挿入することができました。これは 5 倍以上速いことになります。CLOB 挿入は XML 挿入ほどには並行動作の恩恵を受けず、まだベースラインの 37% を必要としています。これは非並行型の CLOB 挿入よりも 1.4 倍速いだけです。
図 4: 並行動作によって XML 列挿入と CLOB 列挿入が高速化される
こうした挿入テストのすべてを、1000、5000、10,000、50,000 件の文書に対しても行いました。想像したとおり、CLOB 列の場合も XML 列の場合も、挿入に要した時間は挿入される文書の件数に従って、ほとんど直線的に増加しました。そのため、これを示す図は簡単のため省略してあります。
XML クエリーを CLOB 列と XML 列とで比較する
XML 列と CLOB 列との間でのクエリー・パフォーマンスの違いを評価するために、一般的な検索と取得を網羅する、下記のような 5 つのクエリーを設計しました。
- すべての文書を完全な文書として取得する (述部なし)
- ある基準に一致する 1 つの文書を完全な文書として取得する (述部が 1 つ)
- ある基準に一致する複数の文書を完全な文書として取得する (述部が複数)
- すべての文書を部分的に取得する
- ある基準に一致するすべての文書を部分的に取得する
これら 5 つのクエリーでは、下記の操作が実装されています。
Q1 (Select*): すべての XML 文書を選択します (<table> から * を選択します)
Q2 (1Pred1Doc): 与えられた口座番号に対する Customer 文書を返します。
Q3 (5PredSome): 主たる住所をカリフォルニア州に持ち、米ドルでの口座を持ち、顧客ステータスがまだプレミアムにはなっていない、すべての女性顧客に対する Customer 文書を返します。
Q4 (PartialAll): それぞれの Customer に対して、その顧客の名前と、その顧客の全口座の残高の合計を返します。
Q5 (PartialSome): 口座の中に IBM の株を持つ顧客全員が主として使用している E メール・アドレスを取得します。
CLOB の場合、こうしたクエリーは、XML Extender の抽出関数を使って SQL で表現されます。XML 列の場合は XQuery で表現されます。このテストでは、XQuery が SQL に埋め込まれているか、あるいは単独で実行されるかによって、パフォーマンス上の差はありませんでした。すべてのクエリーと一部のサンプル・データは、pureXMLvsCLOBvsShredded.zip として「ダウンロード」セクションから入手することができます。
図 5 は、pureXML を使った場合と CLOB を使った場合の両方に関して、5 つのテスト・クエリーすべてのパフォーマンス (経過時間) を示しています。これを見ると、pureXML クエリーは、CLOB 列の XML に対するクエリーよりも、優に 20 倍から 30 倍、あるいは 40 倍も速くなりうることがわかります。これらの結果は、表スペースに対してファイルシステム・キャッシングを行わない、私達のデフォルト設定に対する結果です。図 6 は、ファイルシステム・キャッシングを行った場合の結果を示しています。ファイルシステム・キャッシングが大きな影響を持つのは、述部評価を行わずにすべての文書を取得する、クエリー Q1 の場合のみです。ファイルシステム・キャッシングを行わない場合、Q1 のパフォーマンスはXML 列に対しても CLOB 列に対しても同程度であり、バッファー・プールでバッファーしない CLOB 列でわずかに (10%) 不利なだけです。ファイルシステム・キャッシングによって CLOB の取得パフォーマンスは大幅に改善され (図 6)、クエリー Q1 は XML 列に対して 2 倍以上速くなります。これは、XML 列からの読み取りにシリアライズ (つまり構文解析された XML をテキスト・フォーマットに戻す変換) が必要なためです。ファイルシステム・キャッシングを行わない場合、XML 列は DB2 のバッファー・プールでバッファーされる一方 CLOB 列はバッファーされないため、シリアライズのオーバーヘッドは軽減されます。
図 5: クエリー・パフォーマンス (索引なし、ファイルシステム・キャシングなしの場合)
クエリー 2 から 5 までに対しては、ファイルシステム・キャッシングが大きな役割を果たすことはありません。これらのクエリーは、述部を評価し文書フラグメントを抽出するために、必ず副文書レベルでのアクセスを必要とします。ここで pureXML の本領が発揮されます。つまり XML は構文解析されたフォーマットで格納されるため、クエリー実行時には構文解析が必要ありません。私達のテストでは、これによってパフォーマンスは 7 倍から 44 倍向上しています。
図 6: クエリー・パフォーマンス (索引なし、ファイルシステム・キャシングあり)
重要な点として、XML 列と CLOB 列との間でのクエリー・レスポンス時間の差が、構文解析 (CLOB の場合) あるいはトラバース (pureXML の場合) を必要とするデータの量と共に劇的に増加することに注目してください。図 7 は、表の中にある文書の数の関数としてのクエリー・レスポンス時間を示しています (文書の件数の範囲は 1,000 から 100,000 で、索引あるいはサイド・テーブルを使わない場合)。
図 7: データ量の関数としての Query 2 のパフォーマンス
XML Extender には、述部評価のための XML 構文解析を避けて XML 文書の検索を高速化するために、サイド・テーブルの概念が用意されています。挿入時には、特定の要素と属性がリレーショナル表の中に抽出されます。これによって CLOB 挿入に大きなオーバーヘッドが追加されることは既にわかっていると思いますが、サイド・テーブルは効率的に検索され、CLOB を含むメイン・テーブルと結合されます。私達の行った 5 つのテスト・クエリーのうちの 3 つ (q2、q3、q5) は、サイド・テーブル参照の恩恵を受けるフィルター述部を含んでいます。サイド・テーブルによって、CLOB に対する XML 構文解析の大部分を回避することができ、それによって多くの場合、CLOB クエリーが 100 倍以上高速になります。
これを、サイド・テーブルと同じ効果のある、本物の XML 索引を持った pureXML と比較したものが図 8 です。図 8 の 6 本の棒が示す経過時間は、どれも約 1 秒、あるいは 1 秒未満です。それでも、索引を持つ pureXML は、サイド・テーブルを持つ CLOB 列よりも 6 倍から 35 倍高速です。これにはいくつかの理由があります。pureXML の索引は、対応する文書の行を直接指します。サイド・テーブルの場合は、DB2 は最初にサイド・テーブルに対して索引参照を行った後、対応する行を、CLOB を含むメイン・テーブルと結合します。クエリー Q3 (5PredSome) は複数の述部を持ち、メイン・テーブルの他に 3 つのサイド・テーブルを使っているため、4 方向結合を計算する必要があります。クエリー Q5 は述部に対してサイド・テーブルを使っていますが、顧客の E メール・アドレスを取得するために、(XML 構文解析を行う) 抽出関数を必要とします。
図 8: 索引 (pureXML の場合) とサイド・テーブル (CLOB の場合) による述部評価
図 8 から明確にわかるように、サイド・テーブルは構文解析が必要な CLOB の数を減らす上で有効ですが、DB2 9 の XML 索引もサイド・テーブルと同じように、述部評価にトラバースが必要な文書の数を減らす上で有効です。従って、索引とサイド・テーブルを使用することで、XML の場合も CLOB の場合も一般的には絶対的な経過時間は減少しますが、XML 列の方が CLOB 列よりも大幅にパフォーマンス上優れているという相対的な差が解消されることはありません。
マルチ・ユーザーのクエリー・テストは、CLOB 列と XML 列の両方に対して 10 ユーザーで行われました。ただし、CLOB ストレージと pureXML ストレージの間での相対的なパフォーマンス差は上記のシングル・ユーザーの場合と同様であったため、結果は省略します。
シュレッドによるストレージを XML 列に対して比較する
XML データをリレーショナル表にシュレッドできることは、相変わらず一般的な要求です。その典型的な理由として、既存のアプリケーションはまだ XML を理解できず、リレーショナル・フォーマットを要求するかもしれないという点があげられます。こうしたアプリケーションには、レガシーの SQL アプリケーションやパッケージ化されたビジネス・アプリケーション、また BI ツールやレポート・ツールなどがあります。DB2 9 の注釈付き XML Schema 分解 (「新シュレッド」) は、古い XML Extender シュレッディングの持つ、機能上、パフォーマンス上の制約を解決しています。以下のセクションでは、DB2 9 の新しいシュレッディング・パフォーマンスと DB2 9 の pureXML 技術とを比較検証します。
これらのテストに使われた Customer データは、先ほどと同じです。さまざまな繰り返し要素があるため、従来のリレーショナル・スキーマで XML データを表現するためには、合計で 12 の表に 87 の列が必要でした。このスキーマを図 9 に示します。この図は、100,000 件の顧客文書をシュレッドした後の、各表の列の数と行の数を示しています。合計すると、これらの表には 100,000 件の XML 文書を表現する 350 万以上のリレーショナル行が含まれています。図 9 の矢印は、1 対多の関係を示しています。12 の表の間での結合を効率的に行えるよう、すべての主キー列と外部キー列に索引が定義されています。
図 9: シュレッドされた XML データを保持するためのリレーショナル・スキーマ
リレーショナル表にシュレッドする場合と pureXML 挿入との比較
このリレーショナル・スキーマの 100,000 件の文書を、DB2 9 の新しい注釈付きスキーマ・シュレッドでシュレッドすると、同じ XML 文書群を XML 列に挿入するよりも約 1.75 倍遅くなります (図 10)。これは、OLTP アプリケーションで通常行われるように、どの文書を挿入した後にも必ずコミットした場合の結果です。
図 10: pureXML 挿入を DB2 9 のシュレッディングと比較する (文書挿入後に必ずコミットした場合)
コミットの頻度を下げれば、XML 列のパフォーマンスはシュレッディングよりも一層良くなります。コミットする文書を 1 つおきにすると、XML 挿入はシュレッディングよりも 2.56 倍速くなります (私達のシナリオと構成の場合)。バルク挿入やインポート操作の場合には、50 あるいは 100 件の文書ごとにコミットするだけなので、XML 列挿入は シュレッディングよりも 4 倍から 5 倍速くなります (図 11)。コミットの間隔を広げると、1 回のログ I/O リクエストあたりのログ・ページの数が大きくなるため、その効果は XML 列挿入の方がシュレッディングよりも顕著に表れます。
図 11: pureXML 挿入を DB2 9 のシュレッディングと比較する (コミット間隔を変化させた場合)
図 12 は、コミット間隔が 50 の場合について、DB2 9 の新しい注釈付きスキーマ・シュレッドを、V8 の XML Extender シュレッドと pureXML 挿入と比較しています。私達のテストでは、新シュレッドは XML Extender シュレッドよりも 7 倍速く、さらに pureXML 挿入では、V8 のシュレッディングの 30 倍にもなります。
図 12: DB2 V8 の XML Extender シュレッディングを DB2 9 の技術と比較する (コミット間隔 = 50)
シュレッドされたデータに対する XML クエリーを pureXML 列と比較する
ここで例えば、XML フォーマットでのクエリーの結果を必要とする XML 指向のアプリケーション、あるいは Web サービスを提供することを考えてください。もし XML データがリレーショナル表にシュレッドされていると、リレーショナル・クエリーの結果を XML に戻す変換が必要です。そのためには、SQL クエリーの SELECT 節に SQL/XML 公開関数を使用して、結果セットに対して必要な XML タグ付けを作成します。
図 9 のリレーショナル・スキーマに対して、5 つの SQL クエリーが定義されていました。これらは、XML 列に対する 5 つの XQuery と論理的に等価です。これらの SQL クエリーは従来のリレーショナル述部を使い、一部の、あるいはすべての表を結合し、そして SQL/XML 公開関数を使って XQuery と同じ XML の結果を返します。この相対的なパフォーマンスの結果を示したものが図 13 です。
クエリー Q2 (1Pred1Doc) は、口座番号を参照した結果に基づいて、1 つの文書のみを返します。(pureXML と SQL/XML 公開関数の) どちらの場合も、このクエリーのパフォーマンスを高めるために口座番号に索引が付けられています。SQL/XML クエリーは非常に高速ですが、それでも XML 列に対しては XQuery よりも 75 倍も低速です。この理由は、XQuery は索引を使って文書を発見し、それをシリアライズすればよいだけですが、SQL/XML 公開関数は 12 のリレーショナル表すべてを結合して XML 文書を作成しなければならないためです。
クエリー Q1 (Select*) と Q3 (5PredSome) は多くの文書を返します。そのため、リレーショナル・データから SQL/XML 文書を作成するコストも文書の数に従って大幅に増加します。クエリー Q4 (PartialAll) は各 XML 文書からいくつかの値を読み取り、それらを元に、まったく新しい文書を作成します。pureXML ストレージに対する XQuery の場合、値は XML 列から読み取られ、文書の作成方法は XQuery で表現されます。シュレッドされたデータに対する SQL/XML 公開関数の場合、値はリレーショナル列から読み取られ、文書の作成方法は SQL/XML で表現されます。どちらの場合も、文書の作成がボトルネックになるため、Q4 ではほとんど同じパフォーマンスを示しています。
図 13: シュレッドされたデータに対して pureXML XQuery を SQL/XML 公開関数と比較する
図 13: シュレッドされたデータに対して pureXML XQuery を SQL/XML 公開関数と比較する
Q5 (PartialSome) は複数の述部を使い、1 つの要素のみを持つ、ほんのわずかの XML 文書しか返しません。この場合は、SQL/XML のコストはそれほど高くありません。その理由は、1 つの結果行あたり 1 つの要素しか作成せず、しかも 12 の表のうちの 3 つしか結合しないためです。リレーショナル・データに対する検索は XML データに対する検索よりも多少速いため、このクエリーのパフォーマンスはシュレッドされたデータに対する場合の方が高くなっています (私達の設定では XQuery よりも 20 倍高速でした)。
まとめ
シングル・ユーザーのワークロードでは、CLOB 挿入は pureXML 挿入よりも高速ですが、通常のビジネス・シナリオでは並行挿入の影響があるため、CLOB 挿入は XML 列への挿入よりも 2 倍から 2.5 倍も低速になることがあります。各文書の挿入ごとにコミットが行われる場合、pureXML 挿入は DB2 9 の新しいシュレッディング・ソリューションよりも約 60% から 70% 高速です。コミット頻度が低いバルク挿入、あるいはインポートの場合には、pureXML はシュレッディングの 4 倍から 5 倍もの XML データを取り込むことができます。しかもこれらのテストでは、V8 での XML Extender シュレッディングよりも 7 倍から 8 倍高速な、DB2 9 の新しいシュレッディング・ソリューションが使われているのです。
XML 型の列の XML データに対する XQuery は、それに対応する、CLOB 列に対するクエリー (クエリー時に XML 構文解析が必要です) よりも 40 倍も高速です。「pureXML クエリー」と「CLOB クエリー」との間の絶対的なパフォーマンス差は、クエリー対象となるデータの量と共に (直線的に) 増加します。
シュレッドされたデータに対する pureXML の XQueries と SQL/XML 公開関数との間の相対的なパフォーマンスの差は、XML としてのタグ付けが必要なリレーショナル・データの量に大きく依存しますが、必要な結合の数にも依存します。複雑なデータの取得が必要な場合には、XQuery のパフォーマンスは明らかに公開関数によるクエリーを上回ります。私達が行ったいくつかのテストでは、DB2 の pureXML ストレージから XML データを取得する方が、リレーショナル表から XML データを作成するよりも 50 倍から 100 倍高速でした。しかし、複雑な結合がなく、返される結果に XML タグがほとんど、あるいはまったくない単純な検索クエリーでは、SQL の方がずっと高速です。とはいえ、アプリケーションでは常に、クエリー・パフォーマンスと挿入パフォーマンスの比較を行い、両者の兼ね合いを検討する必要があります。XML 挿入のパフォーマンスを要約したものが図 14 です。
図 14: XML 挿入のパフォーマンスの要約 (commitcount =1)
この記事で示したすべてのパフォーマンスの結果は、特定のハードウェア、操作、データベースという構成による、隔離された研究室環境で得られたものであることに注意してください。この記事とは異なる環境で異なるテストを行った場合には、この記事で示した結果よりもパフォーマンスの差が大きくなる、あるいは小さくなる可能性があります。
私達が行ったすべての測定では DB2 のみを使用しましたが、CLOB およびシュレッドによる XML ストレージのパフォーマンスに関する問題の多くは、それぞれ XML をテキストとして保存する、あるいはリレーショナル・データ・モデルに変換する、という一般的な概念に固有のものです。従って、こうした概念をサポートする他の DBMS 環境でも、似たようなパフォーマンス特性が得られる可能性があります。そうした点に関心のある読者は、読者自身の環境でそうした問題を探ってみてください。その際には、この記事で取りあげた資料がテストを行うにあたっての基礎として利用できるはずです。
謝辞
この記事に関して助言をくださった Henrik Loeser と Cindy Saracco、Nikolaj Richers の各氏に感謝いたします。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| Sample scripts for this article | pureXMLvsCLOBvsShredded.zip | 14KB | HTTP |
|---|
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | 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 でコンピューター・サイエンスの博士号を取得しています。 |
| 
| | Vitor Rodrigues は IBM Silicon Valley Lab のソフトウェア開発者です。コンピューター・サイエンスとシステム・エンジニアリングの専攻でポルトガルの University of Minho を卒業しています。2005年、DB2 Everyplace と DB2 9 pureXML 担当のインターンとして IBM に参加し、pureXML の DB2 9 QA チームの一員として DB2 9 の XML 機能に関する深い知識を身につけました。彼はインターンシップの後、正規社員となり、現在は DB2 9 XML Enablement チームに所属しています。 |
記事の評価
| 
