XMLデータベース開発方法論（6）　Page 5/5

変化に強いXMLデータベース設計とチューニング

川俣 晶
株式会社ピーデー
2005/11/19

■クエリの無駄を省く

　一般論として、クエリをより簡潔に記述できるようにデータベースの設計を整理することは、性能向上のための有効な手段の1つといえるだろう。XMLデータベースソフトの中には、クエリが複雑化することによって性能が著しく変わるものもあれば、複雑なクエリで性能が劣化しないことをセールスポイントにするものもあり、個別のソフトに対するチューニングとしては一概にはいえないが、1つのテクニックとして把握しておく価値はあるだろう。

　例えば、人物の情報を扱うために、以下のようなデータがあるとしよう。このデータに対しては、性別に対するクエリ、名前に対するクエリ、年齢に対するクエリの3種類があるとする。

<男性>   <名前>香月順一<名前>   <年齢>36</年齢> </男性> <女性>   <名前>香月陽子<名前>   <年齢>34</年齢> </女性>

　さて、「名前」要素や「年齢」要素はほかでも使われていて、親要素の種類を明示しなければならないとすれば、3つのクエリの具体的な内容は以下のようになる。

• 性別に対するクエリ
  「男性」要素の検索または「女性」要素の検索
• 名前に対するクエリ
  『「男性」要素または「女性」要素』の子要素である「名前」要素の検索
• 年齢に対するクエリ
  『「男性」要素または「女性」要素』の子要素である「年齢」要素の検索

　これを見ると、「男性」要素と「女性」要素の使い分けが意味を持つのは、最初のクエリだけであることが分かる。残りの2つのクエリでは性別を区別する意味がない。つまり、「または」の処理が無駄である。もし、この3種類のクエリが同程度の頻度で実行されるとすれば、無駄のあるクエリの方が多いことになる。

　ここで、男性と女性の区別は子要素で付けるとして以下のように直してみよう。

<人物>   <名前>香月順一<名前>   <年齢>36</年齢>   <性別>男性</性別> </人物> <人物>   <名前>香月陽子<名前>   <年齢>34</年齢>   <性別>女性</性別> </人物>

　このような書き換えによって、データ量は増えている。しかし、多くのXMLデータベースにおいて、データ量はクエリ性能を決定する主要な要因ではない。それよりも、クエリの複雑さや、クエリに重い処理が含まれるか否かが問題となる。この書き換えはクエリの内容を軽くすることが目的である。つまり、3種類のクエリは以下のような内容になる。

• 性別に対するクエリ
  「人物」要素の子要素である「性別」要素の検索
• 名前に対するクエリ
  「人物」要素の子要素である「名前」要素の検索
• 年齢に対するクエリ
  「人物」要素の子要素である「年齢」要素の検索

　上の場合と比較すると、クエリ内容がシンプルになったことが分かるだろう。

　ちなみに、Shunsakuのようなベタ検索を行うタイプのXMLデータベースの場合は、データ量を削減するチューニングがあり得る。その場合は上記の修正に逆行する修正によって性能が改善する可能性があることを付記しておく。

■クエリの効率アップ

　クエリの効率を上げるために、より積極的に情報を加えていく方法もある。例えば、以下のようなデータにおいて、成人であるか否かを意識するクエリの比率が高いとしよう。

<人物>   <名前>香月順一<名前>   <年齢>36</年齢> </人物> <人物>   <名前>香月陽子<名前>   <年齢>34</年齢> </人物> <人物>   <名前>香月舞<名前>   <年齢>11</年齢> </人物> <人物>   <名前>香月岬<名前>   <年齢>4</年齢> </人物>

　このようなクエリでは、年齢要素の内容を数値判定する処理が必要とされる。例えば以下のようなパス式を使うことになる（年齢が20歳以上の「人物」要素を得る）。

人物[年齢 >= 20]

　しかし、一般的に数値の範囲判定は、特定の値を持つ要素を探す処理と比較して、遅い処理になることが多い。このような決まり切った数値の判定が高い頻度で繰り返されているならば、この負担を軽減することで性能がアップし得る可能性がある。

　この場合であれば、年齢要素に、成人属性を付け、20歳以上であれば常に「True」の値を持つという設計にしてしまうのである。例えば、以下のようにする。

<人物>   <名前>香月順一<名前>   <年齢 成人="True">36</年齢> </人物> <人物>   <名前>香月陽子<名前>   <年齢 成人="True">34</年齢> </人物> <人物>   <名前>香月舞<名前>   <年齢>11</年齢> </人物> <人物>   <名前>香月岬<名前>   <年齢>4</年齢> </人物>

　このようにすると、上記のパス式に相当する処理は以下のように書き換えることができる。

人物[年齢/@成人 = 'True']

　大抵の場合、範囲判定よりも内容の一致判定の方が高速に処理できると思われるので、このような設計変更によってクエリ性能を向上させられる可能性がある。

　とはいえ、このような方法は冗長なデータ量が増えたり、常に年齢と「成人」属性を同期して修正する必要が生じるなどの問題点もある。もしも、クエリ性能が十分満足の行くレベルであれば、あえて採用する価値のない設計といえる。しかし、クエリ性能が不十分であれば、問題点を踏まえたうえでこのような設計変更を試みる価値はあるだろう。

■「標準」に魂を奪われるな！

　ここで説明したような設計技法は、「標準」に合致することを美徳とするXMLの常識に反している。例えば、W3C、OASIS、ISO、JISといった標準化団体はさまざまな言語を標準として定めているし、一般の企業などでも社内標準などが存在するだろう。そして、それらをきちんと順守して使うことは重要だといわれる。しかし、その常識は、XMLデータベースにおいては「必ずしも常識ではない」と見なすべきだと考えている。別のいい方をすれば、「絶対に守るべき」規範としてはいけない、といい直してもよい。XMLデータベースに要求されていることは、情報を蓄積し、検索することである。もし、標準を遵守することでその目的が損なわれることがあれば、標準を守るべきではない。

　このような断言は、なぜ「標準」が大切であるかという理由を問い直せば分かると思う。不特定多数の相手との通信を行う場合、通信の当事者が標準を守ることは重要である。勝手なプロトコルや言語を使っていては、通信が成立しないからである。また、標準に合致したデータは、それをサポートするさまざまなツールで処理できる可能性があり、独自言語のデータよりもずっと使い勝手がよい。一方、XMLデータベースは通常不特定多数の相手には公開されないので、標準を守っていなくても齟齬（そご）は生じない。また、現在存在するXML対応のさまざまなツール類は、XMLデータベースの内容をそのまま読み込むような設計にはなっていない。つまり、たとえXMLデータベースの内容を標準に合致させても、それを直接読み込ませることはできないのである。例えば、XMLデータベースに蓄積する文書をXHTMLに厳密に一致させたとしても、それをXHTML対応のHTMLエディタで直接開くことはできないのである。

　これに関して、あえて以下のように断言しておこう。

XMLの世界と、XMLデータベースの世界はまったくの別物であり、常識は必ずしも共有されない。

　しかし、標準をまったく無視することも得策ではない。XMLデータベースは、それだけ独立して世の中に存在するわけではないからだ。XMLデータベースの内容の一部を通信で交換することもあるし、便利なXML対応ツールで作成したデータをインポートすることもあるだろう。そのような状況を考えれば、XMLデータベース内部で標準を守らないとしても、いつでもデータを標準形式と変換できるような配慮を行うべきだろう。例えば、クエリ性能を上げるために設計変更を行うとしても、いつでも標準に合致する形に戻せるように必要な情報を保存する、といった配慮である。

　もちろん、あるがままに、外部で利用されるデータをそのままXMLデータベースに格納することが、最も使い勝手がよいことは間違いない。それが達成できるなら、効率のための設計変更などは行うべきではない。これらの説明は、あくまで性能が不足する場合の対応策であり、そのようなケースがしばしば発生するのではないかという私的な予測故に書かれたヒントである。

■連載の終わりに

　以上で連載は終わるが、もちろんここまでに書かれたことは、XMLデータベースを使うためのほんの入り口にすぎない。まだ実績も少ない世界なので、確実な結論はまだないが、選択肢の範囲は限定されている。100％の正解は示せなくても、大まかな方向は示すことができたといえるだろう。それだけでも、XMLデータベースを使ううえでのリスクを大幅に減らすことができるのではないかと思う。ぜひとも、皆さんもXMLデータベース、特にスキーマレスのXMLデータベースに興味を持ち、チャンスがあればそれに取り組んでみてほしいと思う。

　それはとても良いものであると同時に、乗り超える価値のある新しい目標となるだろう。（連載完）

5/5

Index
XMLデータベース開発方法論（6） 変化に強いXMLデータベース設計とチューニング
	Page 1 ・前回のおさらいと今回のテーマ ・ノイズまみれのシステム
	Page 2 ・変化に追従する柔軟なデータ構造 ・拡張のためのスタブ
	Page 3 ・YAGNI再び ・要素と属性の問題再び ・「ゼロ時間変換」を行うか否かの選択 ・データベースのリファクタリング
	Page 4 ・データ構造の最適化の必要性 ・準備段階 ・追加／削除の最適化
	Page 5 ・クエリの無駄を省く ・クエリの効率アップ ・「標準」に魂を奪われるな！ ・連載の終わりに

XMLデータベース開発論

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）