目次


ネイティブ XML データベースを最適化するための 6 つのヒント

ネイティブ XML データベースで XQuery を使うための常識的なガイドライン

Comments

XQuery とネイティブ XML データベース

データベースを利用する場合、XQuery (XML データの集合に対してクエリーを実行するために設計された関数型言語) をネイティブ XML データベース・システムと併せて使用すると極めて重宝することがあります。例えば複雑なクエリーをいくつも作成して実行する場合、クエリーのほとんどがデータを取得するだけのものであれば、標準的なリレーショナル・データベースと比較すると、ネイティブ XML データベースを使用している場合の方がクエリーの作成にかかる時間も実行時間も短くてすみます。また XQuery には、今日得られる中で最も単純で最も強力なデータ変換システムが組み込まれているため、全文索引付けシステムを別途設計したり、あるいはユーザー用に大量のデータを組み立てたりする必要がなく、開発時間を短縮することができます。

ネイティブ XML データベースは、データの挿入や更新などの操作には時間がかかる代わりに、データの取得に関しては何も手を加えないデフォルトの状態でも非常に高速に処理が行われます。これはネイティブ XML データベースが、概してデータを正規化せずに保持し、デフォルトで索引を提供し、利用可能な RAM を極めて有効に活用するためです。一方、非常に大規模なデータ・セットを扱う場合には、以下に挙げる一般的で常識的ないくつかのガイドラインに従うことで、ネイティブ XML データベースからデータを取得するのにかかる時間をさらに短くすることができます。

  • 正規化を避ける
  • 一意の要素名を使う
  • 事前に値を計算する
  • クエリーを使ってデータを変換する
  • XQuery コードをプロファイリングする
  • 最適化のリストを保持する

これらのガイドラインは一般的なものであり、IBM DB2® Express-C、Mark Logic Server、eXist、さらには Oracle Berkeley DB XML といった、今日入手可能なネイティブ XML データベースの多くに適用することができます (「参考文献」のリンクを参照)。では、データの取得を最適化するためのガイドラインを詳しく見て行きましょう。

正規化を避ける

ネイティブ XML データベースのスキーマを設計する際に最も重要なことは、リレーショナル・データベースを設計する場合と同じ方法でデータを正規化しようとしないことです。

ネイティブ XML データベースのデータを正規化するためには、複数の XML 文書型を設計し、リレーショナル・モデルのテーブル同士を関連付ける場合と同じような方法で文書型同士を関連付ける必要があります。しかしほとんどの場合、ネイティブ XML データベースではデータの正規化は必要ありません。リレーショナル・モデルのテーブルに格納するには何十ものテーブルが必要となるデータが、1 つの XML 文書型に収まってしまうことはよくあることです。

今日存在している大部分の XQuery 実装は至って効率の悪い方法で結合を実行するため、たとえ単純なクエリーであっても、数千件ものレコードが関係すると、その処理時間は耐えがたいほど長くかかる場合があります。これはデータを単純に正規化してもよいかどうかを判断するための基準になります。

つまり「サポートされる」クエリーのなかに、レコードを選択して取得するために結合操作を行う必要があるようなクエリーが存在すると考えられる場合には、データを正規化してはなりません。

「サポートされる」クエリーというのは、ユーザーによって実行されることが十分に想定されるクエリーのことを言います。例えばビデオテープを販売するアプリケーションを作成する場合、ユーザーが実行する可能性があるクエリーとして、ビデオのタイトルに含まれるキーワードと監督の名前を指定して、一致するビデオをすべて検索するといったものがあります。このようなクエリーを実行できるようにするため、ビデオについて説明する XML 文書には必ずタイトルと監督の名前を含める必要があります。一方、このアプリケーションでサポートする必要がないクエリーとしては、タイトルに特定のキーワードが含まれ、なおかつニューヨーク生まれの監督によって作成されたビデオをすべて検索するといったものがあるかもしれません。つまりこのビデオ・アプリケーションの例では、監督についての (監督の名前以外の) 詳細情報がある場合には、その情報を別の XML 文書に保持することを検討してもよいのです。

互いに関連付けられた 2 つの文書型 video-recdirector-rec を持つデータベースを想像してみてください。video-rec にはビデオに関する詳細情報が含まれ、director-rec 識別子も含まれています。director-rec には、さまざまな監督に関する詳細情報が含まれています。あるキーワードがタイトルに含まれていて、しかもニューヨーク生まれの監督によって作成されたビデオのレコードを検索するクエリーでは、レコードを選択して取得するために結合操作を行わなければなりません。しかし先ほど触れたように、このような種類のクエリーはサポートしなくてもよいかもしれません。これはむしろデータ・マイニングのクエリーであり、オンライン・ビデオ・ストアのサイトを閲覧するユーザーのほとんどは、このような種類のクエリーを実行することはまずないからです。一方で、監督の詳細情報を別の文書型に保持する明確な理由がなければ、その情報を video-rec 文書の中に保持するようにしても構いません。

ネイティブ XML データベースでは、レコードを選択して取得するために結合操作を行うのは決して効率の良いものではありませんが、検索結果のデータを操作する際に複数の XML 文書型からデータを取得するのはまったく問題ない場合がほとんどです。ここで説明しているビデオ・ストアでは、検索を行った後、監督の出身地を取得するために、最初の検索では対象としなかった文書からデータを取得する必要があるとしても、その出身地を含めた結果を表示するための作業は容易で効率の良いものになります。このようにして結果を組み立てる操作で対象とするレコードは、既にアプリケーションによって選択され、表示されようとしている数件のレコードに限られます。しかしそのために必要な計算量やメモリー量は、一般的な検索クエリーで複数の文書型を結合する場合に比べれば無視できる程度です。

一意の要素名を使う

一意の要素というのは、その要素を指定すると必ず XML 文書の中の同じ要素を指す場合を言います。一意でない要素というのは、XML 文書の任意の場所で使われ、前にパスを付けないとどの要素を指しているのかが明確にならない場合を言います。例えば、ある XML 文書にまったく異なる 10 種類のノード型が含まれ、それぞれの型に date 要素が子孫として含まれている場合、その date 要素は一意でない要素名です。一意でない要素名を使用すると、XQuery や XPath などを評価あるいはプロファイリングしてデータを見つけることができません。例えば、一意でない要素名を使用すると、ほとんど索引参照を行わないコードを適切に評価することはできません。また、一意でない要素名を使用すると、最近サポートされるようになってきたファセット検索を行う上で障害になる可能性があります。

以下のセクションでは何種類かの最適化の例を紹介しながら、リスト 1 に示す文書の設計を変更し、互いに異なる要素名を使う形にします。

リスト 1. ベースとなる、一意でない要素名を使用する文書
#+BEGIN_SRC nxml-mode
<class-info>
  <school>Lusher Elementary School</school>
  <grade>10</grade>
  <teachers>
    <teacher>
      <name>
        <first>Carol</first>
        <last>Osborne</last>
      </name>
    </teacher>
    <teacher>
      <name>
        <first>Dan</first>
        <last>Silver</last>
      </name>
    </teacher>
  </teachers>
  <students>
    <student>
      <name>
        <first>Barrie</first>
        <last>Stoff</last>
      </name>
    </student>
    <student>
      <name>
        <first>Andrew</first>
        <last>Silver</last>
      </name>
    </student>
    <student>
      <name>
        <first>Larry</first>
        <last>Cracchiolo</last>
      </name>
    </student>
    <student>
      <name>
        <first>Richard</first>
        <last>Hughes</last>
      </name>
    </student>
    <student>
      <name>
        <first>Bruce</first>
        <last>Silver</last>
      </name>
    </student>
    .
    .
    .
  </students>
</class-info>
#+END_SRC

索引参照の実行回数を減らす

Silver という苗字の学生の下の名前を取得するためには、リスト 2 のような XPath 式を使うことができます。

リスト 2. Silver という苗字の下の名前を検索するための XPath 式
: /class-info/students/student/name[last = "Silver"]/first

検索対象をリスト 1 の文書の中で見つかるデータのみに制限したとすると、リスト 2 の XPath 式を評価すれば必ず正しい結果が返されます (リスト 3)。

リスト 3. XPath 式による結果
<first>Andrew</first>
<first>Bruce</first>

データに索引が付けられていない場合には、リスト 2 の方法を使うことで最も迅速に結果を得ることができます。XPath 式によって、対象の要素を見つけるためにデータベースが検索するブランチの数が制限されるからです。

一方でデータに索引が付けられている場合には、どのようなデータベース実装を使用するかによりますが、非常に大規模なデータ・セットがあるようであれば、リスト 4 のような式の方が確実に早く結果を得られるかもしれません。

リスト 4. データに索引が付けられている場合に使用する XPath 式
: //name[last = "Silver"]/first

なぜ速度が改善される可能性があるかというと、システムの検索対象となる索引付けされた要素が少ないからです。しかしリスト 1 の文書は一意でない要素名を使う設計であるため、リスト 4 の XPath 式では誤った結果が返され、教師の名前である Dan が結果の中に含まれてしまいます。この設計では、索引の使用を減らすようにクエリーのプロファイルを設定することができません。より適切な設計をするためには、リスト 1 の一意でない要素名を一意の要素名で置き換える必要があります。これを示したものがリスト 5 です。

リスト 5. リスト 1 の一意でない要素名を一意の要素名で置き換える
   //teacher/name => //teacher/teacher-name
   //teacher/name/first => //teacher/teacher-name/teacher-first
   //teacher/name/last => //teach/teacher-name/teacher-last
   //student/name => //student/student-name
   //student/name/first => //student/student-name/student-first
   //student/name/last => //student/student-name/student-last

ファセット検索をサポートする

ファセット検索の目標は、ユーザーがさまざまな軸に従って検索結果を素早く直感的に狭められるようなリンクを表示することです。このアプリケーションがファセット検索をサポートする場合、データベースの中にあるすべての教師をリストアップするクエリーによって、ユーザー・インターフェースには以下のような情報が返されます (リスト 6)。

リスト 6. ファセット検索
•Tabor, Gavin
•Nance, Jamey
•Haas, Carlene
•Davies, Yesenia
•Singer, Lupe

Narrow your search:

•School

   •Lusher Elementary School (35)
   •Academy of the Sacred Heart (34)
   •Isidore Newman School (32)
   •Audubon Charter School (28)
   •Benjamin Franklin Elementary Math-Science Magnet (25)

•Grades

    •9 (5)
    •10 (6)
    •11 (6)
    •12 (6)

リスト 6 には、School (学校) と Grades (学年) という 2 つのファセットがあります。各ファセットには 4 つまたは 5 つの値が含まれており、それらの値からは最新の検索結果を絞り込むための検索へとリンクが張られています。各ファセット値の隣には括弧に入った数字があり、この数字はリンクをクリックすると表示される教師の合計人数を示しています。ファセット検索の結果には、通常、各ファセットの取り得る値として、数個の値のみが表示されます。Grades ファセットの場合のように、ファセットが取り得る値の種類が少ない場合には、アプリケーションは通常、ファセットの取り得るすべての値を最も意味のある並び方で表示します。しかしファセットが取り得る値の種類が多い場合には、アプリケーションは通常、最も多くの結果を返すいくつかの値のみを、その結果の数の降順で表示します。

一部のネイティブ XML データベースはファセット検索をサポートしていますが、そうしたデータベースが最高のパフォーマンスを発揮するためには特別な索引を必要とします。データベース内のレコード数や、ファセットが取り得る値の種類が増加すると、ファセットの表示値を取得するための標準的な XQuery アルゴリズムが途端にボトルネックとなります。何千もの値を持つファセットを含む大規模なデータベースの場合には、そうしたアルゴリズムは使い物になりません。ファセット検索の強力さを活用するためには、ネイティブ XML エンジンはデータベースの中で要素が取り得る値から辞書を作成できなければなりません。これらの辞書は特別な索引から実装することができますが、そのためには結局のところ一意の要素名が必要になります。

ネイティブ XML データベースの規模が比較的小さく、ファセット検索をサポートしていない場合に、ファセット検索用に独自のコードを作成するには、要素名が一意であることが不可欠となります。それは、ファセット検索をサポートするコードが高度なデータベースに既に存在している場合に、要素名が一意であることが不可欠であるのとまったく同様です。

事前に値を計算する

XML 文書に冗長データを追加するという考え方は、経験豊富なリレーショナル・データベース管理者にとってまったく馴染みがないものかもしれません。しかしパフォーマンスが最大の関心事項である場合 (例えば何千万件ものレコードに対してクエリーを実行したときにファセット検索の結果を返さなければならない場合)、XML 文書の中にあるデータに基づいて一部の値を事前に計算し、その計算結果を XML 文書に追加しておくと、応答時間を大幅に改善することができます。ネイティブ XML データベースは、ストレージを犠牲にするのと引き換えに冗長性を許容することで、いかに優れたパフォーマンスを得られるかがすべてなのです。

例えば、画像のメタデータの XML 文書が大量にあるとします。これらの XML 文書のそれぞれには、cameradevicescanner という要素が 1 つ以上含まれ、それらのすべての要素が、画像を作成した機器に関する情報を保持しています。device 要素は複合ノードを表し、このノードにはその機器の名前を示す要素と、その他の情報を持ついくつかの要素が含まれています。この例では、すべての device 要素はアプリケーションの他の部分で必要になるため、device 要素を破棄することはできません。このアプリケーションではファセット検索を実装しており、画像を作成した機器の名前を表示する scanning device という名前のファセットを使用します。

同様に、画像のメタデータの XML 文書には、画像の高さと幅に関する height 要素と width 要素がありますが、アプリケーションでは size というファセットを使用します。このファセットは、height 要素と width 要素から容易に結果を得ることができます。

リスト 7 は最初に挙げた例を示しています。

リスト 7. 画像のメタデータの文書の最初の例
<image>
  <id>123456789</id>
  <date>2009-11-16T03:14:42</date>
  <description>Eiffel Tower</description>
  <device>
    <device-name>Scanmelter 2000</device-name>
    <device-resolution>300dpi</device-resolution>
    <device-manufacturer>Scanners Inc.</device-manufacturer>
    <service-tag>ASDFQWER</service-tag>
  </device>
  <width>1200</width>
  <height>1024</height>
</image>

リスト 8 は 2 番目に挙げた例を示しています。

リスト 8. 画像のメタデータの文書の 2 番目の例
<image>
  <id>123456788</id>
  <date>2009-11-16T03:14:42</date>
  <description>Empire State Building</description>
  <scanner>Pixel Maker LS</scanner>
  <width>800</width>
  <height>600</height>
</image>

今度は、このようなレコードを大量に持つデータベースを考え、2009年 11月 16日に撮影された画像に対してクエリーを実行すると 5,000 枚の画像が返されるとします。これらの画像のうち、アプリケーションは 30 枚を表示します。検索結果のビューには、scanning devicesize などを始めとするさまざまなファセットが表示され、各ファセットはその値の簡単なリストを提供します。scanning device というファセットの値には Scanmelter 2000 (1202)Pixel Maker LS (207) が含まれています。size ファセットの値には 1200x1024 (2302)800x600 (113) が含まれています。

これらの要件を満たすコードを作成する場合を考えてみてください。このコードはかなり簡単に作成できますが、あまりスケーラブルではありません。というのも、このコードでは各ファセット値を使って作成されるクエリーを実行したときに得られるレコードの数をカウントしますが、それに要する作業の量が問題となるからです。ファセットの値は何百もあるかもしれません。コードは、それらの各値に対する検索結果の数を計算し、そのファセットに対してどの 5 つのファセット値をリストに表示するのかを判断する必要があります。この状況は、データベースの中にあるレコードの数や、アプリケーションで表示されるファセットの数、そして各ファセットが取り得るファセット値の種類が増えるにつれ、急速に悪化します。アプリケーションが 50 個のファセットを表示し、何百万件ものレコードを扱う場合には、ファセット値を事前に計算し、それらの値をレコードの中に含めておくしか方法はありません。

リスト 7リスト 8 の XML 文書には、それぞれ、scanner-namesize という 2 つの新しい要素を含めるように変更することができます。こうした簡単な変更をするだけで、はるかにスケーラブルな実装にすることができます。

クエリーを使ってデータを変換する

XQuery の最大の強みは、呼び出し側が必要とするとおりのデータを提供できることです。しかしこの強みは、ほとんど活かされていないようです。多くの場合、アーキテクトはネイティブ XML データベースをバックエンドの XML Web データベースとして扱おうとします。つまりネイティブ XML データベースは単に XML 文書を返し、それらの XML 文書をフロントエンドが必要に応じて変換と描画を行うものとして扱いがちです。

企業で既に XQuery を使用してネイティブ XML データベースからデータを取得している場合、彼らは必ず即座にあらゆる理由を挙げ、データを XML フォーマットで返してから (例えば) XSLT を使用してフロントエンドでデータを変換するのだと主張します。以下に挙げたのは、それらの理由のなかでもより一般的なものです。

  • 同じデータを別の目的に使用する、他の製品を開発する計画があるから。
  • XSLT、Perl、PHP、JavaScript、Java™ 言語の使い方を既に知っているフロントエンド担当者達がいるから。
  • サービス指向アーキテクチャーが必要だから。
  • 誰も XQuery についての知識がなく、可能な限り XQuery を使わずにすませたいから。
  • データ・パイプラインが用意できているから。
  • XQuery は複雑そうに思えるから。
  • XQuery では xxxx ができないから。

ここでは、これらの 1 つ 1 つに反論することはしませんが、以下のポイントを頭に入れておいてください。

  • ブラウザーで表示する準備の整ったデータは、データベースに格納されている元のデータよりも大幅に小さいことが多いものです。
  • どのような基準で考えても、XQuery は XSLT よりも容易で強力、そして簡潔です。
  • 出力する際にデータを変換した方が、後で XSLT (あるいは何か他のもの) を使って変換するよりも、はるかに高速です。
  • クライアントが多様なフォーマットでデータを要求できるように XQuery を作成することができます。
  • データを変換するコードとデータを検出するコードが近くにあり、どちらも同じ言語で作成されていると、アプリケーション全体の複雑さが大幅に減少します。

これらのポイントの 1 番目、つまり描画されるデータのサイズと変換前の元データのサイズに関して、さらにもう少し考えておく必要があります。特に、大規模な XML レコードを扱う場合には注意が必要であり、大規模なレコードをフロントエンドに送信してフロントエンドで変換するという方法は避けなければなりません。ネットワーク上に送信するデータ・チャンクを可能な限り小さくすることで、アプリケーションの応答性とスケーラビリティーを目に見えて改善できることがよくあります。そして皆さんは多くの場合、まさにそのようにしているはずです。つまりデータベースからデータを取り出すときにデータの変換を行う場合、ネットワークに送信するデータ・チャンクを小さくしているはずです。

ビジネスが XQuery の強力さを最大限に活かしていない本当の理由は、未知のものに対する不安です。それは十分に理解できますが、既にネイティブ XML データベースを使用している場合には、その力を最大限に活かさずして、最終的に良い結果を生み出せるはずはありません。

XQuery コードをプロファイリングする

一般的に、コードのプロファイリングを行うということは、コードの各部分の処理にコンピューターがどれほど時間を費やすかを判断するということです。プロファイリングの目的は、最適化の効果が最も高いコード部分を識別することです。実行時間が最も長い部分が最も最適化の効果が高いとは限りません。場合によると、既に非常に効率の高いコード片に最大の焦点を当てる必要があるかもしれません。例えば、10 秒間で実行するコード片を、1 秒未満で実行するように最適化するのが比較的容易な場合でも、そのコードが 1 日に 1 回しか実行されないのであれば、1 日に百万回実行される関数を (ほんの少しでも) 高速化するために努力した方が適切かもしれません。

大部分のネイティブ XML データベースには、コードのベンチマーク測定、つまりプロファイリングのためのツールがあるので、そうしたツールを活用するようにしてください。場合によると、これらのツールでは、ある特定のコード片のパフォーマンスを、望んでいる方法で測定することはできないかもしれません。そうした場合には、プロセスのベンチマークを測定するために独自のコードを作成することをためらうべきではありません。時間のマーキングや測定のためのコードを XQuery モジュールの中に挿入してもまったく問題はありません。また、本番環境でベンチマーク用のコードを無効にできるのであれば、なおさら問題はありません。

また、XQuery は関数型プログラミング言語であるため、各関数は独立しています。ほとんどの場合、XQuery 関数の戻りシーケンスは、その関数を呼び出す際に使用されたパラメーターのみに依存します。従って、XQuery 関数を評価するためのユニット・テストやパフォーマンス・テストの作成は、Java、Python、Perl、C、PHP といった標準的な手続き型プログラミング言語で関数用のテストを作成する場合よりも簡単です。XQuery コードの中にある関数の実行時間は簡単なスクリプトなどの外部プロセスを使って容易に測定することができます。例えば、簡単で賢明な Emacs スクリプトを使うと、コードを強調表示して特定の組み合わせのキーを押すだけで、編集対象の XQuery コードを実行させたり時間測定をしたりすることができます。スクリプトによってサーバーにコードを送信し、そのコードをサーバーに評価させ、実行時間の結果を新しいバッファーに返すようにすればよいのです。

最適化のリストを保持する

プラットフォームに適用可能な最適化のリストを保持し、アプリケーションのパフォーマンスを改善する必要がある場合には必ず、そのリスト全体を十分に調べるようにします。この記事で既に説明した最適化の他に、私は以下の項目をリストに加えています。

可能な場合にはコードを事前にコンパイルする

一部のネイティブ XML データベースは XQuery コードを事前にコンパイルしたり構文解析したりすることができます。サーバー内で頻繁に実行されるコードの場合、サーバーがコードに遭遇するごとに構文解析やコンパイルを行う必要がないようにすれば、パフォーマンスは目に見えて改善されます。

索引を利用するコードを作成する

多くの場合、ネイティブ XML データベースは索引から直接 XQuery または XPath 式を評価してクエリーを解決することができるため、文書を取得する必要がありません。可能であれば、そうした動作をするクエリーを作成する必要があります。データベースのオプションや検索関数のオプションを探し、索引から直接検索結果を得られるようにし、検索結果の妥当性検証フィルタリングをすべて回避するようにするのです。

フィルタリングせずに索引から結果を取得する方法には欠点があります。それは、検索対象のノードが最上位レベルのノード (すなわちフラグメント・ルート) ではない場合に注意しなければならないことで、フィルタリングされた検索結果には含まれないノードが、検索結果の中に含まれている可能性があるということです。このことは理解しておく必要があります。

XQuery 拡張機能を検討する

大部分のネイティブ XML データベースには、高速に実行するために設計された XQuery 拡張機能が用意されています。厳密な XQuery から外れると、アプリケーションは特定の製品と結びつけられたものになってしまいます。しかし実際には、大量のデータを処理する本番環境では、パフォーマンスを高める拡張機能のメリットを検討する価値は十分にあります。その場合、移植性には犠牲を伴うことが多いものです。

フォレスト、スタンド、マージを理解する

一部のネイティブ XML データベースは、スタンド (木立を表す言葉で、ファイルのことを意味しています) を含むフォレスト (森を表す言葉で、ディレクトリーのことを意味しています) の中にバイナリー・フォーマットでデータを保持します。新しいレコードは多くの場合、新しいスタンドの中に配置されます。システム (つまり管理者) は、定期的にスタンドをマージしてパフォーマンスを高めます (フォレストの中にスタンドが少なければ、それだけクエリーに対する応答時間が短くなります)。しかしフォレストが大きくなりすぎてはいけません。システムを最適化する場合には、マージを開始する前に (あるいはマージを開始するようにシステムを構成する前に)、フォレストの最大最適サイズとスタンドの最大数を調べるようにします。

つまりデータがロードされるとマージがトリガーされます。そしてマージによって、スループット能力の限界近くで動作しているシステムがダウンしてしまう可能性があります。可能であれば、データのロードとマージはシステム負荷が最小のときに行われるようにスケジューリングする必要があります。パフォーマンスに与える影響としては、データのロードの方がデータのマージよりもはるかに小さいものです。データのロードが長時間実行される場合、ピーク負荷時にはマージのみ禁止することを検討してください。

まとめ

ネイティブ XML データベースは現在、何千万件ものレコードを持つデータベースに対して複雑な検索を行うサイトに活用されています。これらのデータベースを適切な条件の下で一部のアプリケーションに使用することにより、まだこれらのデータベースを使用していない組織よりも相当有利な立場に立つことができます。しかし他のすべてのデータベース技術と同じように、ネイティブ XML データベースの強力さを最大限に活かすためには、システムの効率と応答性を最適化する方法を十分に理解する必要があります。


ダウンロード可能なリソース


関連トピック

  • DB2 9 での XML クエリー・パフォーマンスを高める XML 索引を学ぶ」(Matthias Nicola 著、developerWorks、2006年11月)は、XML クエリーや XML の索引を一貫性のある方法で作成するための一連のガイドラインを解説しています。これらのガイドラインに従うことで、索引によって期待どおりクエリーを高速化することができます。
  • Query DB2 XML Data with SQL」(Cynthia Saracco 著、developerWorks、2006年3月) では、XML 列に格納されたデータに対して SQL や SQL/XML を使ってクエリーを実行する方法を学ぶことができます。
  • Query DB2 XML data with XQuery」(Don Chamberlain と Cynthia Saracco 著、developerWorks、2006年4月) では、DB2 での XQuery 言語の使い方について学ぶことができます。
  • XQuery入門」(Howard Katz 著、developerWorks、2006年1月) を読んでください。この記事では、XQuery 仕様の歴史的背景、ドキュメントへのロードマップ、そして現状のスナップショットについて解説しています。
  • XQueryの神話と誤解を暴く」(Frank Cohen 著、developerWorks、2005年5月) では、XQuery に関する作り話や誤解の多くを取り上げ、それらを詳細に解説しながら誤解を解いています。
  • XML Database Products では、XML データベース製品市場の最新情報を得ることができます。
  • XQuery 1.0 仕様に対する W3C 勧告を読み、この XML クエリー言語について、また多様な XML ソースから情報を取得して解釈する XQuery の機能について学んでください。
  • XQuery 1.0 と XPath 2.0 の関数および演算子に関する W3C 勧告には、XPath 2.0、XML Query 1.0、XSLT 2.0 に必要な関数と演算子のすべてが網羅されています。
  • W3C による XML クエリーの使用事例を読み、XQuery の使用シナリオについて学んでください。
  • What is XQuery」(Per Bothner 著、XML.com、2002年10月) を読み、XQuery の概要を理解してください。XQuery を深く理解する前に、または XQuery を使おうとする前に必要な中心的概念などが解説されています。
  • XML Schema Part 2: Datatypes Second Edition を読み、XML Schema 言語の仕様について学んでください。
  • XPath に関する勧告を読んでください。XPath は XML 文書の各部分を位置指定するための言語であり、XSLT と XPointer の両方に使われています。
  • パス・ベースの式言語、XPath が向かう方向について学んでください。
  • XML および関連技術において IBM 認定技術者になる方法については、IBM XML certification を参照してください。
  • developerWorks podcasts ではソフトウェア開発者のための興味深いインタビューや議論を聞くことができます。
  • Oracle Berkeley DB XML を入手してください。これはオープンソースで組み込み可能な XML データベースであり、コンテナーに格納され、また内容に応じて索引付けされた文書に XQuery ベースでアクセスすることができます。
  • Mark Logic Developer Network を訪れ、業界をリードする XML サーバー、MarkLogic サーバーを試してみてください。
  • IBM DB2 データベース・サーバーの無料版であり、画期的な pureXML 技術を含む、IBM DB2 Express-C 9.5 を入手してください。
  • XML 技術を使用して作成されたオープンソースのデータベース管理システムである、eXist-db を試してみてください。eXist は XML データ・モデルに従って XML データを格納し、また効率的に索引ベースで XQuery を処理することができます。
  • IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Information Management
ArticleID=464044
ArticleTitle=ネイティブ XML データベースを最適化するための 6 つのヒント
publish-date=12152009