XMLは主役から名脇役に
数年前には、XMLはIT業界注目のキーワードだった。しかし、ここ最近はあまり耳にしない。とはいえ、XMLが消えてなくなったわけではない。むしろXMLはほとんどのシステムで、何らかの形で活用されつつある。複数のシステムがあれば、その連携にはXML形式でデータのやりとりがなされ、さらに業界ごとにXMLの国際標準化も進みつつある。
アプリケーション開発においても、エラーログなどを単なるテキスト形式で出力するのではなく、XML形式で出力することも増えてきた。XMLデータにしておけば、後からそれを様々な形式に変更し表示したり、別のシステムに取り込んだりという作業が極めて容易になるのだ。いまやXMLは主役ではないが、名脇役としてあちこちで活躍している。
XMLをデータベースで効率よく扱うには
ところで、リレーショナルデータベースで大量なXML形式のデータを扱うには、大きく2つの方法がある。1つは、XMLデータを丸ごとCLOB(Character Large Objects)カラムに格納する方法だ。この方法では、そのままデータを挿入するだけなので、データ格納時に何ら手間がかからず高速に処理できる。そのため、XML形式データを単純に蓄積する用途には向いている。
ただし、特定の値を検索し取り出すには、XML構造をいちいち解析しなければならず、速度はそのぶん遅くなる。さらに、格納されているXMLデータの一部を更新する用途にも、まったく向いていない。 もう1つの方法が、XMLデータを分解しリレーショナルデータのテーブルに展開し格納する方法だ。
この方法なら格納された後は、通常のリレーショナルデータベースのデータとまったく同じなので、自由に検索もできデータ更新も容易だ。とはいえ、格納時にはその都度XMLデータをリレーショナル形式に展開する手間が増え、そのぶん余計に時間がかかることになる。
さらに、この展開する方法ではXMLの優位性である柔軟性を大きく損なうことになる。XMLは、タグとそれに囲まれた値という極めてシンプルな構造だ。タグを増やせば簡単に項目を増やせるし、タグの中にさらにタグを記述するといったように階層的なデータ構造も容易に表現できる。このシンプルさでデータ構造の変化にも柔軟に対応できるのが、XMLの最大の特長と言っても過言ではない（図１、2）。
たとえば、価格比較サイトのようなシステムでデータを扱う場合、決まりきった商品だけを扱うのであれば、リレーショナルデータベースのテーブルにデータを格納しても問題ない。インデックスなどを用いれば、検索も高速に行えるだろう。とはいえ、実際の価格比較サイトでは、頻繁に新しいタイプの商品が追加されるはずだ。商品が追加されれば、カテゴリ追加もありスペックなどを表現するデータ項目も増やすことになる。
これをリレーショナルデータベースで構築していたのでは、商品種類が増えるたびにテーブル構造を変更しなければならない。テーブル構造変更も大きな手間だが、さらに、それにアクセスするプログラムにも手を入れる必要もあるかもしれない。これでは、手間とコストが大きくかかり、柔軟で使いやすい価格比較サイトをスピーディーに実現するのは極めて難しい。
リレーショナルとXMLをネイティブに扱えるDB2 pureXML
多くのリレーショナルデータベースではXMLが扱えるとはいえ、上記のような状況のためXMLの特長を最大限に活用しているとは言い難い。活用するにはXML形式のデータをそのまま管理できる、XMLデータベースを利用することになる。
これならば、項目の追加やデータ構造の修正も容易に行え、さらにプログラム変更も最小限でその変更をシステムに反映させることも可能だろう。逆にXML専用データベースは、トランザクションデータの扱いは不得意。そのため、システムでXMLの柔軟性を確保したければ、現実的にはリレーショナルデータベースとXMLデータベースの2つを連携させて利用することになるのが普通だ。
これはこれで、異なるシステムを運用し、連携させるという大きな手間がかかることになりかねない。 このような状況は、XMLが扱える機能を持つデータベースであるOracleでもSQL Serverでも同様だ。それに対し、従来のリレーショナルデータベースで無理矢理XMLデータを扱えるようにするものではなく、ネイティブにXMLを扱えるようにしたのがIBM DB2のpureXMLという機能だ（図3）。
通常のリレーショナルデータベースのエンジンに加え、XMLを扱うための専用のエンジンとデータ格納領域を、DB2という1つのデータベースに統合してしまったのだ。 当たり前だが、リレーショナルデータベースでのXMLデータベースもどきの機能よりも、XMLデータを扱う性能は高くXMLの柔軟性を十分に発揮できる。そして、これまでのSQL技術者はSQLで、新しいタイプのXMLベースの開発者はXqueryなどを用いXMLデータをネイティブに扱うことができる。
成熟度が上がったいまだからこそ、製品選択に真剣に取り組むべき
かつては、システムを新たに構築する際には、どのデータベースを選ぶかはかなり重要だった。大規模なシステムであれば、様々な比較資料を作り、さらに実データ、実機を用い大がかりなベンチマークテストを行うことも多々あった。多くのリソースと手間をかけ、データベースを選んでいたのだ。
ところがここ最近は、データベースを選ぶ際に大がかりなベンチマークテストを行い比較評価したといった話を、ほとんど聞かなくなった。システム事例の取材などで話を聞いても、紙の資料では比較したがベンチマークまでは行っていないことも多い。
多くの場合、これまでOracleを使ってきたから次もOracle。シェアが高いから、あるいはプラットホームがWindowsだからSQL Serverを選ぶというように、あまり積極的な理由で製品選択の作業が行われていない。これは、どのデータベース製品もそれなりに成熟し、製品としての完成度も上がってきたためとも考えられる。
たしかに基本的な機能、性能の部分には、いまや大きな差がなくなりつつあるのがデータベース製品の状況なのかもしれない。 とはいえ、もう少しじっくりと各製品を眺めてみれば、それぞれの特長というものがあらためて浮かび上がってくるはずだ。Oracleの良さ、SQL Serverの良さ、そしてDB2の良さというものを今一度見つめ直してみると、自分たちが実現しようとしているシステムにベストフィットの機能や性能が見えてくるかもしれない。
製品としての成熟度が上がってきたいまだからこそ、今一度きっちりと製品比較をする。そして、自分たちの要求に本当に合った製品を選ぶことができれば、中長期的なTCO削減につながる選択になるのかもしれない。
