Db2 での XML パフォーマンスのベスト・プラクティス

XML 文書の細分度の慎重な選択

XML アプリケーション、特に XML 文書の構造を設計する場合、1 つの XML 文書にまとめて保持するビジネス・データを選択できる場合があります。

例えば、サンプルの部門データの各 XML 文書には、1 つの部門の情報が含まれています。

CREATE TABLE DEPT(UNITID CHAR(8), DEPTDOC XML);

<dept deptID="PR27">
   <employee id="901">
      <name>Jim Qu</name>
      <phone>408 555 1212</phone>
   </employee>
   <employee id="902">
      <name>Peter Pan</name>
      <office>216</office>
   </employee>
</dept>

<dept deptID="V15">
   <employee id="673">
      <name>Matt Foreman</name>
      <phone>416 891 7301</phone>
      <office>216</office>
   </employee>
   <description>This dept supports sales world wide</description>
</dept>

この中間的な細分度を選択することは、アプリケーションによるデータのアクセスおよび処理の細分度が、ほとんど部門単位である場合に適切です。 また、複合的な部門 (1 つの組織単位に複数の部門が所属する場合など) を 1 つの XML 文書に結合するように決める場合もあります。ただし、アプリケーションが通常、一度に1つの部門のみを処理する場合は、この粗い粒度は最適ではありません。

各従業員に「部門」属性を加えてその従業員が所属する部門を示し、従業員別に 1 つの XML 文書にすることも 選択できます。 このような精細な細分度は、従業員が重要なビジネス目標を使用し、その目標を同じ部門内の他の従業員が自由にアクセスおよび処理する頻度が高い場合、非常に適切な選択になります。 ただし、アプリケーションが、通常 1 つの部門の全従業員を処理する場合は、部門ごとに 1 つの XML 文書にするのが、より適切な選択になります。

XML での属性と要素の適切な使用方法

XML 文書の設計でよくある質問は、 どのような場合に要素の代わりに属性を使用するのか、またその選択がパフォーマンスにどのように影響するかです。

これは、パフォーマンスより、データのモデリングに非常に強く関わる質問です。 ただし、原則として、XML 要素は繰り返しとネストが可能なため、属性より柔軟性があります。

例えば、 前述の例の部門文書では、要素「phone」を使用することによって、複数の電話番号を持つ 1 人の従業員について、複数の「phone」のオカレンスが可能になります。 この設計は、後で電話番号を、例えば国別コード、市外局番、内線などの子要素に小さく分割することが必要になった場合にも、拡張が可能です。

対照的に「phone」を要素でなく従業員要素の属性にすると、 1 人の従業員に付加できるのは 1 つだけで、子要素は追加できません。 このような制約によって、将来スキーマを展開できなくなる場合があります。

多くの場合、すべてのデータは属性を使用しなくても モデル化できますが、1 つの要素に対して繰り返しがなく、サブフィールドもないことがわかっているデータ項目に対して属性を使用することは、非常にわかりやすい選択です。 要素には開始タグと終了タグの両方がありますが、それに対して属性は 1 対の名前と値だけで 済むため、XML データのサイズを若干縮小することができます。

Db2では、エレメントと同じように、照会、述部および索引定義の属性を使用することができます。 属性はエレメントよりも拡張性が低いため、Db2は特定のストレージを適用し、最適化にアクセスできます。 ただし、これらの利点は、パフォーマンスのために要素を属性に変換することを促すものではなく、データ・モデリングを検討すると要素が必要になる場合は特に、パフォーマンス向上という予期せぬメリットとみなすべきものです。

XML スキーマ検証のオーバーヘッドの認識

XML スキーマ検証は、 XML 構文解析でオプションのアクティビティーです。 パフォーマンスの検討を行った結果、スキーマ検証を使用可能にすると、 一般的に XML 構文解析時にはスキーマ検証の未使用時よりも CPU を著しく集中的に使用することが示されています。

このオーバーヘッドは、 XML 文書の構造とサイズ、特に使用する XML スキーマのサイズと複雑さによって大幅に変動します。 例えば、中程度に複雑なスキーマでスキーマ検証すると、CPU 使用量が 50% 増加する場合もあります。 XML の挿入が入出力に大きく制約されていない限り、通常 CPU 使用量が増加することによって 挿入のスループットは減少します。

XMLスキーマは、XML文書のセットで許可される構造、エレメントおよび属性、データ・タイプおよび値の範囲を定義します。Db2では、XML スキーマに対してXML文書を検証できます。 文書の検証を選択すると、検証は通常挿入時に行われます。検証により、データベースに挿入されたデータがスキーマ定義に準拠していることが確認されます。つまり、表に入力するデータの整合性が向上します。

XML 照会と XML スキーマの準拠を確認するための型検査をさらに厳密に行うことがアプリケーションで必要かどうかを判断する場合、パフォーマンスへの影響を考慮してください。 例えば、XML文書がデータベースに保管される前に、XML文書を受信、検証および処理するアプリケーション・サーバーを使用している場合、おそらくDb2で文書を再度検証する必要はありません。 その時点で、文書が有効なことは既に認識されているからです。 同様に、データベースが、信頼できるアプリケーション、例えばユーザーが制御するアプリケーションから XML 文書を受け取り、その XML データは常に有効なことがわかっている場合、スキーマ検証を回避して、挿入のパフォーマンス向上という効果を得ることができます。 ただし、Db2データベースが信頼されていないソースからXMLデータを受信し、Db2レベルでスキーマの準拠性を確保する必要がある場合、それに対して余分なCPUサイクルを費やす必要があります。

可能な場合はXPath式の絶対パスを指定します

要素が XML 文書の構造のどこにあるかわかっている場合、パスを完全に指定したフォームで情報を提供し、不要なオーバーヘッドを回避します。

次の SQL ステートメントによって作成された表を検討してください。

CREATE TABLE customer(info XML);

次の図に、情報列のサンプル・データを示します。

<customerinfo Cid="1004">
    <name>Matt Foreman</name>
    <addr country="Canada">
          <street>1596 Baseline</street>
          <city>Toronto</city>
          <state/>Ontario
          <pcode>M3Z-5H9</pcode>
    </addr>
    <phone type="work">905-555-4789</phone>
    <phone type="home">416-555-3376</phone>
</customerinfo>

顧客の電話番号または所在する市を検索する場合、 データを取得するために使用できるパス式は複数あり、その中から選択できます。

/customerinfo/phone および //phone のいずれでも電話番号を取得できます。 同様に、/customerinfo/addr/city および /customerinfo/*/city のいずれも市を戻します。 最良のパフォーマンスを得るためには、*または//のいずれかを使用して、完全に指定されたパスを使用することをお勧めします。これは、完全に指定されたパスによって、Db2が直接エレメントにナビゲートできるため、文書の関連部分以外の部分をスキップします。 //phoneを/customerinfo/phoneの代わりに要求すると、文書内の任意の場所に電話エレメントを要求することになります。 これには、Db2文書の「addr」サブツリーに移動して、文書の任意のレベルで電話エレメントを探す必要があります。

* および // を使用すると、予期しない照会結果になる場合があります (例えば、次の図に示すように、「customerinfo」文書の中に「assistant」情報も含む文書がある場合)。 パス //phone では、顧客の電話番号とアシスタントの電話番号が、区別されずに戻されます。 照会結果から、アシスタントの電話番号を顧客の電話番号として誤って処理するおそれがあります。

<customerinfo Cid="1004">
    <name>Matt Foreman</name>
    <addr country="Canada">
          <street>1596 Baseline</street>
          <city>Toronto</city>
          <state/>Ontario
          <pcode>M3Z-5H9</pcode>
    </addr>
    <phone type="work">905-555-4789</phone>
    <phone type="home">416-555-3376</phone>
    <assistant>
          <name>Peter Smith</name>
          <phone type="home">416-555-3426</phone>
     </assistant>
</customerinfo>

XML データに対する無駄のない索引定義による余分なオーバーヘッドの回避

"customerinfo" XML 文書を顧客名で検索する照会が多いと想定します。 次のステートメントに示すように、顧客名要素に索引があれば、 このような照会のパフォーマンスを大幅に改善できます。

CREATE TABLE CUSTOMER (info XML);

CREATE INDEX custname1 ON customer(info) 
GENERATE KEY USING XMLPATTERN '/customerinfo/name' as sql varchar(20);

CREATE INDEX custname2 ON customer(info) 
GENERATE KEY USING XMLPATTERN '//name' as sql varchar(20);

SELECT * FROM customer
WHERE XMLEXISTS('$i/customerinfo[name = "Matt Foreman"]' passing info as $i);

上に定義された索引は両方とも、顧客名で XMLEXISTS 述部を評価する場合の対象になります。 ただし、custname2 索引は顧客名の索引エントリーだけでなく、アシスタント名の索引エントリーも含むため、 custname1 索引より大幅に大きくなる可能性があります。 これは、XML パターン //name は、文書内のどこでも 名前要素に一致するからです。 ただし、アシスタント名で検索することがまったくなければ、 その名前に索引を付ける必要はありません。

読み取り操作の場合、custname1 索引のほうが小さく、したがって早く実行できる可能性があります。 挿入、更新および削除操作の場合、 custname1 索引は顧客名についてのみ保守のオーバーヘッドがかかりますが、 custname2 索引は顧客名とアシスタント名について索引の保守が必要です。 挿入、更新、および削除のパフォーマンスを最大にする必要があり、アシスタント名に基づいて索引によるアクセスは必要ない場合に、余計なコストをかけたくないことは明らかです。

文書レベルでフィルター操作する 述部用 XMLEXISTS の使用

次の表とサンプル・データを検討します。

CREATE TABLE customer(info XML);

<customerinfo>
    <name>Matt Foreman</name>
    <phone>905-555-4789</phone>
</customerinfo>

<customerinfo>
    <name>Peter Jones</name>
    <phone>905-123-9065</phone>
</customerinfo>

<customerinfo>
    <name>Mary Clark</name>
    <phone>905-890-0763</phone>
</customerinfo>

例えば、電話番号が "905-555-4789" の顧客名を戻したいとします。 多くの場合、次のような照会を作成してしまいます。

SELECT XMLQUERY('$i/customerinfo[phone = "905-555-4789"]/name' passing info as "i") 
FROM customer;

しかしながら、次のようにいくつかの理由で、この照会ではお客様が求める結果は得られません。

• 次のように、表に含まれる行と同数の行の結果セットが戻されます。 これは、SQL ステートメントに WHERE 文節がなく、したがって 行を全く除去できないことによります。 結果を次の図に示します。

  <name>Matt Foreman</name>
  
  3 record(s) selected

• 述部と一致しない表内の各行に対して、空の XML シーケンスを含む行が戻されます。 これは、XMLQUERY 関数の XQuery 式が一度に 1 つの行、または文書に適用され、 行が結果セットから除去されることがなく、その値のみ変更されることによります。 その XQuery によって作成される値は、述部が真の場合は顧客名要素、そうでない場合は空のシーケンスです。 これらの空の行は、SQL/XML 規格に従えば意味論として正しく、示されているように照会を作成すれば必ず戻されます。
• 照会のパフォーマンスが低下します。 まず、 この照会は行の除去ができないため、/customerinfo/phone に索引が作成されていても使用できません。 次に、この照会は多数の空の行を戻すため、無用な時間がかかります。

パフォーマンスの問題を解決して必要な出力を取得するには、SELECT 文節で XMLQUERY 関数を使用して顧客名のみを抽出し、行を除去する検索条件を WHERE 文節の XMLEXISTS 述部に移動します。 このようにすると、索引の使用と 行のフィルター操作が可能になり、さらに空の結果行によるオーバーヘッドを回避できます。 この照会は次に示すようになります。

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i") 
FROM customer
WHERE XMLEXISTS('$i/customerinfo[phone = "905-555-4789"]' passing info as "i")

大括弧使用による XMLEXISTS のブール述部の回避

次の照会に示すように、XMLEXISTS 関数で前記の照会を、誤って大括弧を使用しないで 作成することがよくあります。

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i") 
FROM customer
WHERE XMLEXISTS('$i/customerinfo/phone = "905-555-4789"' passing info as "i")

このように照会を作成すると、 結果は次に示すようになります。

<name>Matt Foreman</name>
<name>Peter Jones</name>
<name>Mary Clark</name>

3 record(s) selected

XMLEXISTS 述部の式は、XMLEXISTS が常に真と評価するように作成されています。 このため、 除去される行はありません。 ある行に対して、XMLEXISTS 述部は 内部の XQuery 式が空のシーケンスを戻した場合のみ、偽と評価します。 ただし、大括弧がなければ XQuery 式はブール式になって常にブール値を戻し、空のシーケンスを戻すことはありません。 注意が必要なのは、 XMLEXISTS は値の存在を正しく確認し、値がブール値の「偽」であっても、値が存在すれば真と評価することです。 これは、ユーザーの意図ではないにしても、SQL/XML 規格に従った正しい動作です。

繰り返しますが影響は、除去される行がないため電話の索引を使用できず、 実際に必要な行よりはるかに多数の行を受け取ることです。 また複数の述部を使用する場合も、次の照会に示すように同じ誤りをおかさないように注意してください。

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i") 
FROM customer
WHERE XMLEXISTS('$i/customerinfo[phone = "905-555-4789"] and 
		 $i/customerinfo[name = "Matt Foreman"]' 
      passing info as "i")

ここでも XQuery 式は "exp1 and exp2" のフォームになっていることから、ブール式です。 行をフィルター操作し、索引の使用を可能にするように作成した照会は、 次に示すようになります。

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i") 
from customer
WHERE XMLEXISTS('$i/customerinfo[phone = "905-555-4789" and name = "Matt Foreman"]' 
      passing info as "i")

RUNSTATS の使用による XML データおよび索引に関する統計の収集

XML表および索引に関する統計を収集するためにRUNSTATSユーティリティーが拡張され、Db2オプティマイザーは、これらの統計を使用して、 XML照会のための効率的な実行プランを生成します。 したがって RUNSTATS を、リレーショナル・データで使用するように XML 表と索引でも継続して使用してください。 XML 表の統計を取得するには、XML 表スペース名を明示的に指定するか、 LISTDEF を使用して ALL または XML オブジェクトを組み込む必要があります。

SQL/XML パブリッシング・ビューの使用によるリレーショナル・データの XML としての公開

リレーショナル列は SQL/XML パブリッシング・ビューに組み込むことができ、 ビューの照会時には、どの述部も、構成された XML に対してでなく、このリレーショナル列に対して表現してください。

SQL/XML パブリッシング関数を使用すると、リレーショナル・データを XML フォーマットに変換できます。 SQL/XML パブリッシング関数をビュー定義に隠すとよい結果になる場合があります。 アプリケーションまたは他の照会は、パブリッシング関数自体を扱うのでなく、単に構成された XML 文書をビューから選択できます。 次のステートメントによって、隠された SQL/XML パブリッシング関数を含むビューが作成されます。

CREATE TABLE unit( unitID char(8), name char(20), manager varchar(20));

CREATE VIEW UnitView(unitID, name, unitdoc) as
   SELECT unitID, name, 
          XMLELEMENT(NAME "Unit",
             XMLELEMENT(NAME "ID", u,unitID),
             XMLELEMENT(NAME "UnitName", u.name),
             XMLELEMENT(NAME "Mgr", u.manager)
                  )
   FROM unit u;

ビュー定義にリレーショナル列が含まれていることに注意してください。 これは、単にビューであり、マテリアライズされたビューでないため、物理的な冗長性が作成されることはありません。 リレーショナル列を公開することは、このビューを効率よく照会するために役立ちます。

次の照会はリレーショナル述部を使用して、 "WWPR" に対する XML 文書のみ確実に構成されるため、ランタイムが短縮され、特に大きなデータ・セットで顕著な結果になります。

SELECT unitdoc
FROM UnitView
WHERE unitID = "WWPR";

XMLTABLE ビューの使用によるリレーショナル・フォーマットでの XML データの公開

ビューを使用して XML データをリレーショナル・フォーマットで公開することが必要な場合もあります。 前述の注意と同様の注意が必要ですが、 逆のやり方になります。 次の例の SQL/XML 関数 XMLTABLE は、XML 文書から値を表形式で戻します。

CREATE TABLE customer(info XML);

CREATE VIEW myview(CustomerID, Name, Zip, Info) AS 
SELECT T.*, info 
FROM customer, XMLTABLE ('$c/customerinfo' passing info as "c" 
   COLUMNS 
   "CID"     INTEGER      PATH './@Cid',
   "Name"    VARCHAR(30)  PATH './name',
   "Zip"     CHAR(12)     PATH './addr/pcode' ) as T;

ビュー定義には、ビューを効率よく照会できるように XML 列「info」が含まれています。 指定した ZIP コードの顧客 ID と名前を表形式のリストにして取得したいとします。 これは、次の照会のいずれでもできますが、多くの場合 2 番目の照会のほうが最初の照会より実行が速くなります。

最初の照会で述部のフィルター操作は、 XMLTABLE 関数によって生成された CHAR 列の「Zip」で表されています。 ただし、リレーショナル述部のすべてが、内在する XML 列または索引に適用できるわけではありません。 したがって照会は、ビューがすべての顧客に対する行を生成することを求め、その後で Zip コード 「95141」に対応する行を選び出します。

SELECT CustomerID, Name 
FROM myview
WHERE Zip = '95141';

2 番目の照会は XML 述部を使用して、 確実に「95141」に対応する行のみを生成するため、ランタイムが短縮され、特に大きなデータ・セットで顕著な結果になります。

SELECT CustomerID, Name
FROM myView
WHERE xmlexists('$i/customerinfo[addr/pcode = "95141"]' passing info as "i");

パラメーター・マーカー付き SQL および XML ステートメントを使用した短い照会と OLTP アプリケーション

SQL/XML 関数の XMLQUERY、XMLTABLE および XMLEXISTS は、外部パラメーターをサポートします。

非常に 短いデータベース照会はきわめて短時間で実行される場合が多いため、そのコンパイルと最適化の時間が全応答時間の中の大きな割合を占めます。 そのため、 コンパイル、すなわち「準備」は一度だけにして、各実行では述部のリテラル値を渡すだけにすることが考えられます。 これは、短く、また繰り返しのある照会を含むアプリケーションに対して推奨する手法です。 次の照会は、前述の例の結果を得るためにパラメーター・マーカーを使用する方法を示します。

SELECT info 
FROM customer
WHERE xmlexists('$i/customerinfo[phone = $p]' 
                passing info as "i", cast(? as varchar(12)) as "p")

XML 挿入とリトリーブ時のコード・ページ変換の回避

XMLは、内部および外部でエンコードできるため、Db2内の他のタイプのデータとは異なります。 内部エンコードとは、XML データのエンコードをデータ自体から派生させることが可能ということです。 外部エンコードは、エンコードが外部の情報から派生するということです。

Db2とXMLデータを交換するために使用するアプリケーション変数のデータ・タイプによって、エンコード方式がどのように派生するかが決まります。 アプリケーションが XML に文字タイプの変数を使用していれば、 外部エンコードです。 バイナリーのアプリケーション・データ・タイプを使用している場合は、 XML データは内部エンコードとされます。

内部エンコード方式は、エンコードが以下のように、ユニコード・バイト・オーダー・マーク(BOM)またはXML文書自体のエンコード宣言のいずれかによって判別されることを意味します <?xml version="1.0" encoding="UTF-8" ?>

コード・ページ変換は余分な CPU サイクルを消費するため、パフォーマンスの観点から考えると、コード・ページ変換を可能な限り避けてください。 内部エンコードは不要なコード・ページ変換を防止するので、外部エンコードのデータより内部エンコードの XML データのほうが適切です。

このことから、 アプリケーションでは文字タイプよりバイナリー・データ・タイプを優先的に使用すべきです。 例えば、ODBC で SQLBindParameter() を使用して パラメーター・マーカーを入力データ・バッファーにバインドする場合は、 SQL_C_CHAR、SQL_C_DBCHAR、または SQL_C_WCHAR でなく、SQL_C_BINARY データ・バッファーを使用する必要があります。 ホスト・アプリケーションでは、XML AS BLOB をホスト変数タイプとして使用します。

Java™アプリケーションからXMLデータを挿入する時に、XMLデータをバイナリー・ストリームとして読み取ること(setBinaryStream)は、ストリング(setString)よりも優れています。 同様に、JavaアプリケーションがDb2からXMLを受け取り、それをファイルに書き込む場合、XMLが非バイナリー・データとして書き込まれると、コード・ページ変換が発生することがあります。

XMLデータをDb2からアプリケーションに取得すると、それがシリアライズされます。 シリアライゼーションは、XML 構文解析と逆の操作です。 これは、Db2が内部XMLフォーマットを変換するために使用するプロセスです。内部XML形式は、構文解析されたツリー状の表現であり、アプリケーションが理解できるテキスト形式のXML形式に変換されます。 ほとんどの場合、Db2に暗黙的な直列化を実行させるのが最善です。 これは、以下の例に示すように、SQL/XMLステートメントは、単にXMLタイプの値を選択するだけで、Db2はできるだけ効率的にアプリケーション変数に直列化を実行することを意味します。

CREATE TABLE customer(info XML);

SELECT info FROM customer WHERE...;

SELECT XMLQUERY('$i/customerinfo/name' passing info as "i")
FROM customer
WHERE...;

アプリケーションが非常に大きな XML 文書を扱うときは、 データ・リトリーブに LOB ロケーターを使用することが適切な場合があります。 この場合、 CLOB などの文字タイプへの明示的なシリアライゼーションは、エンコードの問題および不要なコード・ページ変換が生じるおそれがあるため、LOB タイプ、できれば BLOB への明示的なシリアライゼーションが必要です。 明示的シリアライゼーションは、次の照会に示すように XMLSERIALIZE 関数を使用します。

SELECT XMLSERIALIZE(info as BLOB(1M)) FROM customer WHERE...;

XMLMODIFY ステートメントを使用した XML 文書の部分的更新

XML 文書の一部のみを変更する必要がある場合、XMLMODIFY 関数を使用することで、XML 文書全体を置き換える場合よりも効率的に XML データを変更できます (特に大規模な XML 文書の場合)。 小さいXML文書の場合、単一レコード内に収まる文書については、XMLMODIFYステートメントによってパフォーマンス上の利点は提供されません。

アプリケーションが XML 列の更新に XMLMODIFY ステートメントを使用しない場合、XML 列の XML 文書全体が削除され、新規 XML 文書で置き換えられます。XMLMODIFYを使用してXML列を更新する場合は、XMLMODIFY関数によって変更されたXML表スペース内の行のみを削除または置換する必要があります。

構文解析されたXML文書の入力データに拡張可能動的バイナリー XML Db2 クライアント/サーバー・バイナリー XML 形式を使用します

XML データの解析は、XML データの INSERT、LOAD、および UPDATE 操作中のパフォーマンスに影響する、最も重要な要因の 1 つです。 データの挿入、更新またはロードを行う時に拡張可能動的バイナリー XML Db2 クライアント/サーバー・バイナリー XML 形式を使用すると、CPUオーバーヘッドが削減されます。 Db2DRDAzIIPリダイレクトはバイナリーXMLによる影響を受けませんが、構文解析は不要であるため、z/OSXMLシステム・サービスzIIPおよびzAAPはバイナリーXMLによって影響を受けます。

拡張可能動的バイナリー XML Db2 クライアント/サーバー・バイナリー XML 形式データをクライアント上のJavaアプリケーションから送信すると、Db2サーバーで必要とされるCPU時間が削減されます。 ただし、XMLデータをバイナリー形式に構文解析することは、クライアント上で実行されるIBM® Data Server Driver for JDBC and SQLJによって処理されます。 テキスト XML を送信する場合と比べて、クライアントでクラス 1 経過時間が増加することがあります。 経過時間の増加がご使用の環境に影響しない場合は、バイナリーXMLを使用してDb2サーバーのCPU時間を削減します。

XPath または XQuery を使用するタイミングを決定する場合のパフォーマンスの考慮

通常、XQuery および XPath を使用する類似した操作を実行する場合は、似たようなパフォーマンスが得られるはずです。 ただし、場合によっては、XPath によってパフォーマンスが向上することがあります。

FETCH WITH CONTINUE を使用した XML データへの高速アクセス

FETCH WITH CONTINUE ステートメントを使用して、最大長が不明または非常に大きい XML 列を参照する照会のパフォーマンスを向上させることができます。