mb_language("uni"); mb_internal_encoding("utf-8"); mb_http_input("auto"); mb_http_output("utf-8"); ?>
XMLデータベース(XML DB)製品が誕生したのは今から約10年前であり、当初から多くのエンジニアに注目されていました。誕生から現在までの間に様々なXML DB製品が開発され、リリースされては消えていくことを繰り返して現在にいたっています。
業務システムへのXMLの適用が定着した現在、その誕生以来再びXML DB製品に多くのエンジニアの注目が集まっています。今回XML DB製品を紹介するにあたって、表1のDBMS(データベース管理システム)製品の役割を評価する観点から解説していきます。
複数の利用者が行う処理を確実に実行
処理の高速化
アプリケーションのインターフェースの簡素化
アクセスの標準化
物理的な格納制約に影響されないインターフェースの確保
▲表1:DBMS製品の機能
リレーショナルデータベース(RDB)/階層型データベース/オブジェクトデータベースなどを分類することはシステムにデータベースを適用する業務領域と一致しています。従って適用領域が決まれば、システム構築に採用するDBMSを容易に決めることができるでしょう。
RDBは万能のデータベースとして様々な方面で利用されていますが、XML DBは一般的なRDBと利用される場面が異なります。つまりXML適用の考え方により、従来のDBMSとして異なる性格(分類)を持つデータベースとなり得るのです。
XMLはデータベースのアーキテクチャを決めるものではなく、そこで扱われる言葉と表現ルールを決めているだけです。XMLの特長は文書表現からデータ表現まで幅広く適用できることですので、XML DBにはアーキテクチャの異なる製品が存在しています。
RDBをはじめとするXML DB登場以前の製品はアーキテクチャを決めている型がそれぞれ一致しています。一方XML DBには型が複数あり、リレーショナル型/オブジェクト型/ファイル型/独自型などに分類できます。
▲図1:XML DBの種類
XMLの業務への適用領域に得意・不得意があるとすると、それは採用する型の違いに起因しています。しかし最近のトレンドとして、XMLの構造を素直に受け入れる型を特長としている製品が目立ってきました(これらはネイティブなXML DBを特長にしている製品です。それが目指す最終形は万能なものですが、実際のところまだ得意・不得意が存在しているようです)。
ネイティブなXML DBは比較的知名度があるものだけでも全世界で40以上あり、その中でオープンソースXML DBは2~3割を占めています。XML DBに対応しているリレーショナル製品も含むとその数は50以上となり、XML DBをさらに広義に定義すれば100を超えているかも知れません。
国内で代表的なXML DB製品には10製品程度が存在します(表2)。
Exterra
Luxeon
NeoCore
Oracle
SQL Server
Tamino
TX1
▲表2:国内の代表的なXML DB製品
冒頭の説明の通り、今回は製品の良し悪しを比較するという視点ではなく、ユーザがXML DBを選択するときの判断ポイントを解説していきます。XML DB各製品はそれぞれ特長を持っており、それをいかす形で使えばよいのです。そういったことから、単純に機能面だけを比較して製品の良し悪しを決められないのです。
XML DBを導入するする際、導入目的/システムの制約/今後のシステムの拡張を考慮する必要があります。そして万能を求めず、欲張らずにあまり現状にとらわれない製品選択をしましょう。
▲図2:XML DBを選定する際のフロー
また選択する際には詳細な方式に着目するのではなく、まず外部機能からその特長を把握して判断することが大切です。このようにデータベースのスペックや内部処理を検討する前に、搭載する側の業務要件をデータベースの観点から整理することも重要です。そして、適用要件を明確にしたら製品選択へと進みます。さらに必要に応じ、製品のパフォーマンスが十分なのかをベンダーもしくはSIerに確認するとよいでしょう。
XML DB製品選択のポイントは外部のインターフェースと内部エンジンの2つに大きくわけられます。外部のインターフェースとは、XML DB製品を使う時に直接アプリケーションや利用者に影響を与えるXML文書/構造制約/クエリーを指します。
▲図3:XML DBの製品選択のポイント
それに対して内部エンジンとは、DBMSのパフォーマンスや正当性確保のための高速性/完全性(排他制御)/柔軟性(スキーマの変更)に関するものです。
XML DBには高速化の対策を特長としている製品が多く存在します。XML文書自体でもXSLTやXqueryを扱えるので、データベースとしての特長として、まず高速化など差別化しやすい部分を特長にしているのです。
各製品は特長となる技術を向上させるために独自技術を投入していますが、注目すべきポイントとしてスループット/レスポンス/参照性能/更新性能に注目すればいいでしょう。
筆者はXML DB製品とデータベースを使わないXML文書を性能比較したことがありますが、単体の性能はデータベースを利用しないXML文書の方が処理が速いという結果となりました。しかしこれはあくまでテスト環境での話であって、実際の利用では様々な条件が加わるために結果が同じとは限りません。
例えば更新と参照が同時に実走した時、更新の範囲や階層構造の箇所など性能に関する評価を単純にすることはできません。性能評価を話題にする時に製品のどの特長が活かされ、欠点がシステムの構築全体に影響しないかということを明確にしないと思わぬ落とし穴に出くわします。
膨大なXML文書を検索し、目的のデータ(ドキュメント)を抽出する処理を基本とするなら、データの抽出時間をどこまで高速化できるかがレスポンスおよびリードタイムを短縮するための課題です。検索には表3の2つの方法があります。
格納順など決まった順序やXML構造に則した検索をするシーケンス検索
条件により検索の順序が変わり、予想できないランダムな検索
▲表3:検索の方法
シーケンス検索を行う際には、表4の方法で検索速度を向上させます。できるだけ大きなサイズで入出力を行います。
あらかじめキャッシュ(メモリ)などの高速な媒体上での検索を行う
XMLSchemaやDTDを用いて、あらかじめXML構造をデータベースに保有して検索する
▲表4:決まった順序やXML構造に則した検索
ランダムな参照処理の高速化には、スキーマ構造とXML文書もしくはXML文書自身から構造情報と値の関係を構築する必要があります。また全件検索相当の細かな粒度の検索辞書を生成する方法でも可能であり、これら方式の違いは性能に関する特長としてあらわれます(表5)。
文書構造の処理は得意だが、ランダムな検索が苦手
ランダム検索に優れているが、あまり複雑なXMLの構造になると苦手
XMLの構造にそった処理は得意だが、その他の処理が苦手
▲表5:XML DBにあらわれる検索についての特長
また検索性能をあげるための工夫は、更新処理の性能にも影響を与えます(表6)。
参照性能はゆっくりしているが、更新処理は速い
参照処理は高速だが、更新処理が大変遅くなる
スキーマにそった更新処理は問題ないが、階層の深い部分の一部を変更すると更新量の割には処理時間がかかる
▲表6:XML DBにあらわれる更新処理についての特長
更新スピードを決めるのはXMLのデータ自身の更新スピードのほか、高速な参照処理のために必要なデータ更新スピードです。
更新処理のレスポンス時間を左右するのはコミットという更新データを確定する処理時間です。データ更新とアプリケーションが同期を行うのか、キャッシュ上でプレコミットが行われて非同期にパーマネントな更新が行われるかで性能差がでてきます。そのほか、階層の深さも処理能力に影響します。
大規模・高性能のシステムを構築する際、利用するXML DBのスループットの性能は大変重要視されます。スループットの性能を決めるのは排他制御のロックの範囲と処理ソフトウェアです。
ロックの範囲を狭めるとドキュメントとしての完全さ(一貫性)を保持することが難しくなりますが、他の処理へ影響は少なくなります。しかし階層構造の深いドキュメントは構造上、ロックの範囲を狭めることは難しいのです。
特に更新の参照が混在する処理や日々XML文書に変更が伴う利用では、他の処理は更新処理に影響されてしまい参照処理で処理待ちになる場合があります。例えば参照処理の速さを特長にしている製品でも、更新処理の影響を確認する必要があります。
XMLのデータの精度はXML構造の保持とデータの値に対しての保証となります。XML DB内のデータの完全保証は一般のデータベースと同じく排他制御により行われますが、その排他制御の範囲は製品により異なります。
XMLはデータ処理とドキュメント処理により単位の粒度が異なります。データ処理は独立した多数の同一タイプのデータの集合で成り立っていますから、XML文書のサイズも細分化できます。細分化により排他制御の範囲を極小化できれば排他制御の影響を受けづらくなりますので、性能上は優位になります。
XML文書は章や節の単位で細分化していますが、文書全体が基本単位となるために何らかの方法で文書全体の完全性を保証しなければならない場合があります。
階層構造の深い部分の更新はその上位の階層に他の処理で変更を加えると文書全体の整合性が失われますから、上位階層から該当箇所までをロックする必要が出てきます。従って構造上複雑なものに対応していたとしても、XML DB製品の性能差がでてきます。
操作性のよさはXML文書の特長ですが、XML DBでは操作性をさらに向上させているものが多く、ほとんどのXML DB製品は国際標準のインターフェースを使って汎用性を重要視しています。
またXML文書自身がスキーマ情報を持ちますので、データベースの構造設計に新たな構造設定をなくすためXMLのスキーマをそのまま使う方法や、XML文書を格納すればデータベースとして成り立たせる方法をとります。
XML DBの操作はできるだけ国際標準に準拠した対応が取れていることが一般的に望ましいのですが、多くのXML DB製品はさらにXpathとXqueryに対応しています。なぜならば、XML DBが汎用性を追う時に採用する技術は「基礎の標準化」であり、XpathとXqueryは汎用化すべき基礎だからです。
ただXML DBの中には適用対象を限定し、特定業務に特化したインターフェースを用意している製品もあります。この場合、XMLの構造にこだわるほどクエリの標準化は重要ではありません。
今後XML DBのアプリケーション面での充実はWebサービスやSOAに対応する機能であると予想されていますが、クエリを隠蔽化する必要があります。XML DBがどのアプリケーションレベルのインターフェースを用意するのかがXML DBの特長となるでしょう。
XML DBはアプリケーションに対応することでXMLのメリットがより引き立ちます。原理主義的DBの定義は「アプリケーションからの独立しているもの」です。この定義から考えると、XML DBを採用しているDBMSはデータベースから逸脱したものといえるでしょう。
しかしWebサービスやSOAという考えかたが常識となっている現在、「WebサービスやSOAを取り込んで業務色の強いアプリケーションから独立しているもの」としてデータベースを定義してもよいのではないかと思っています。
この領域のデータベースは限られた領域を設定し、その中で汎用性を追います。XMLの中にはアプリケーション色の強い標準があり、「取り込み用のXML DB」とすることができます。WebサービスやebXMLなどではUDDI、リポジトリという広義のデータベースとして定義されてます。
セマンティックWebやトピックマップもデータベースの仕様に相当するものが存在します。さらに、CMS/KMS/LMSなどの様々なマネジメントシステムのインターフェースも操作(クエリ)の統一化がなされたデータベースシステムといえます。それらを取り入れてより実践的な機能を持たせたXML DBはXpathとXqueryを利用者に使わせる必要は少なく、また使わせるとシステム的な整合性が取りにくくなってきます。
CMS/KMS/SOAなどに対応するXML DBはより高度でコンプレックスなクエリを持ったデータベースといえます。XMLの標準化のさらなる応用分野を取り込んだXML DBはますます発展・進化するでしょう。
整形式XMLのサポートしているXML DBはXML DBの持つもっとも大きな特長をはっきり全面に打ち出しているといえます。「スキーマの対応」「整形型XMLの対応」のどちらか、もしくは両方をサポートしているのがXML DBの大きな特長だからです。
スキーマ対応のXML DBはXML文書の形式を厳格に保証するためにあります。整形型XML文書が正しければ、通常のデータベース設計をDBMSに対して行う必要のない柔軟なデータベース構築が可能になります。
また利用側には「確定したXML文書のスキーマが動作する方法」「XML文書だけで動作させて柔軟な登録が行える方法」の使い分けが必要です。
XMLスキーマ、DTDなどへの対応の有無はXML DB製品の大きな特長の1つです。そのスキーマをデータベースのマネジメントで使うのはドキュメント品質の保持に大変有効な機能です。
しかしスキーマの変更が多い処理の場合、そのつどスキーマ変更をXML DBに反映させる処理が必要となり、結果的にXML DBの柔軟性を失う場合があるので注意が必要です。
XML文書だけの部分修正でもXML文書の構造変化がともなえばスキーマの変更も必要となり、中にはXML DBの構造の大掛かりな作業が必要となるXML製品もあります。スキーマ対応の評価は「確定したXML構造の処理」「常に構造変化をともなう処理」などの有無でわかれます。
XMLの特長は様々なシステムやデータベースと繋げられることです。多くのXML DBは様々なデータベース製品との連動機能を必須機能として持っています。適用するシステムがシステム間の連動を想定しているのなら、その機能は必須でしょう。ちなみに、WebサービスやSOAとの連結を特長にしているXML DB製品にも筆者は注目しています。
最後に切磋琢磨しあって市場で発展しているXML DB製品の特長を表7に解説してまとめます。表の○印は製品ごとの特に際立っている2つの特長をあらわしているものです。
▼表7:市場で発展しているXML DB製品の特長
EsTerra | Cyber Luxeon |
NeoCore | Oracle9i Database Release 2 |
SQL Server 2000以降 |
Tamino | TX1 | |
---|---|---|---|---|---|---|---|
高速検索 | ○ | ○ | ○ | ||||
大容量 | ○ | ○ | ○ | ○ | |||
柔軟性 | ○ | ||||||
操作性・運用性 | ○ | ○ | |||||
相互接続性 (連動性) |
○ | ○ | ○ | ||||
万能性 | ○ |
EsTerraは高速化とノード単位の細やかな性能チューニングが可能であり、膨大なXML文書の格納と高速検索で様々なデータを柔軟に管理できる。
Luxeonは実績あるDOMオブジェクトを利用した柔軟性が特長であり、レスポンスを向上させる高性能なキャッシュ処理も備えている。
NeoCoreはデータ量・構造に影響されない高速検索が可能であり、スキーマ定義やインデックス定義が不要で柔軟なシステム(データベース)構築が可能である。
Oracleは実績あるRDBMSにXML機能を付加したものである。RDBの利点とXML技術の利点をあわせたRDBと連動したシステムおよびデータベースの拡張性が特長である。
SQL ServerはRDBMS上でXMLデータ型を用意してXMLフラグメントまたはXML文書を保管してXMLデータ処理に対応している。Webサービスとの対応など「相互接続性」「相互運用性」を確保しているのが特長である。
TaminoはXML文書の持つ意味情報をストレートに理解して大容量で複雑なデータ管理し、ミッションクリティカルな処理や画像・ファイルなどの格納に強いXML DBである。また既存のシステムやデータベースの情報をXMLに統合することも可能である。
TX1はテラバイト級のデータ容量でも高速検索が可能であり、標準に準拠したインターフェースで、効率的なアプリケーション開発が可能である。更新と参照の並列化で「高速化」「トランザクション一貫性」「リカバリ機能などの信頼性」が特長である。
▲このページのTOPへ