XML データベースによるデータの扱い方を比較する

pureXML とネイティブ XML データベースとの類似点と相違点は何か

XML が使用される機会が増えるにつれ、構造が可変のデータを無理に不適切なデータ構造に変換せずに保管できるシステムが要求されるようになってきています。そうした要求には、ネイティブ XML データベースも、XML サポートを統合したリレーショナル・データベースも応えることができます。そこで疑問となるのは、どういう理由で XML に対応した従来のデータベース、またはネイティブ XML データベースのいずれかを選択するのか、という点です。この記事では、eXist、Mark Logic、そして IBM® DB2® Express-C などを含め、いくつかの異なるソリューションによるデータの扱い方を比較します。そしてそれらの違いを実際の長所短所として説明します。

Adriaan de Jonge, Software Professional, Freelance

author photoAdriaan de Jonge はソフトウェアの専門家として、現在はオランダ政府の業務に携わっており、いくつかのプロジェクトで随時いくつかの役割を果たしています。彼は IBM developerWorks と Amazon に XML 関係の記事を執筆しています。連絡先は adriaandejonge@gmail.com です。



2008年 12月 16日

XML データベースが登場したての頃は、いわゆるネイティブ XML データベース (NXD) と XML 対応の通常の RDBMS (relational database management system) との違いは大きなものでした。NXD は XML で記述された文書の保管に最適化されていましたが、旧来の RDBMS は通常の BLOB (binary large object) に構文糖を多少追加しただけで、たまたまその BLOB が XML を含むというものでした。

頻繁に使用する頭字語

  • API: Application programming interface
  • HTTP: Hypertext Transfer Protocol
  • IT: Information technology
  • XML: Extensible Markup Language

最近では、NXD は相変わらず NXD ですが、より進歩しています。同時に、成熟した RDBMS を提供するベンダー達も XML 文書の保管技術を進化させています。今や XML フラグメントが BLOB の中に保管されることはありません。XML フラグメントはツリーのような構造で保管され、典型的な XML 文書の基本的性質であるツリー風の文書を含められるように最適化されています。

初期の実装の頃から今日の成熟したソリューションに至るまでの間に、XML 文書に対するクエリー言語の標準化に関する根本的な発展があり、その最も顕著なものが XPath (XML Path Language) 2.0 をサポートする XQuery 1.0 です。XQuery の概念は長年にわたって開発されていたもので、最終的な結果は初期のバージョンと似ていますが、より成熟したものになっています。SQL (Structured Query Language) と同様、XQuery によってベンダーへの依存がなくなり、再利用が促進されます。

なぜ XML データベースが必要なのか

通常のデータベースは、高度に構造化されたデータも、構造化されていない文書も保管することができます。どちらの場合も、データ構造があまり頻繁に変更されないことが重要です。しかし構造が可変の文書を保管する場合には、リレーショナル・データベースの弱点が表面化します。構造化されたデータとは異なり、構造が可変の文書は文書要素の順序や要素同士のネスト構造に関して多くの自由度を持っています。また構造化されていない文書とも異なり、個々の要素を説明的なラベルを使って分類することができます。そして要素の粒度が細かいという傾向があります。

構造が可変のデータをリレーショナル構造の中に保管することはできるのでしょうか?もちろんできますが、そうすると、頻繁に変更される特定のデータ構造、つまりラベルでは記述しにくい一般化されたデータ構造を持つことになったり、あるいはコンテンツ管理システムで使用されるような (実際にはメタデータであるはずのものとデータとが混在する) 抽象モデルを持つ羽目になったりする可能性が高くなります。

一方 XML フォーマットは、構造が可変の性質を持つデータの記述に適しています。またデータ・モデルを容易に維持することができます。新しい要素名を追加してもデータ構造が変わることはなく、データ構造は常にツリー構造のままです。新しい要素名を追加する場合には、その要素名がツリー構造の中でどのように使われ、どのように関係するかを記述する XML スキーマを変更すればよいだけです。

職歴書、製品説明書、顧客からの注文書といった文書の場合には XML 文書が適切なフォーマットかもしれません。また XML は同時に、構造化されたデータも構造化されていないデータも記述することができます。


では、それでもリレーショナル・データベースは必要なのか

新しいソフトウェア・ソリューションを作成する場合であれば、答えは「ノー」かもしれません。構造が可変のデータを保管できるソリューションがある場合には、構造化されたデータも構造化されていないデータも、そのソリューションを使って保管することができます。1 つのストレージ・ソリューションにすべてのデータを保管し、しかも場合によってはクエリーの相互接続や作成を行って 1 つのパスですべてをカバーできる方が、複数のストレージ・ソースからデータを統合するよりもずっと容易です。

無理をせず、この質問に対して正直に「ノー」と答えるためには、データとして保管されているものの大部分は、構造が可変の性質を持つ文書のようなものでなければなりません。しかしデータの大部分が、高度に構造化されたエンティティー・リレーションシップ・モデルによく合致し、あまり文書風ではなく複雑に入り組んでいる場合には、NXD を選択しても状況は改善されないかもしれません。

では、データの性質をどう判断すればよいのでしょう。また、構造化されたデータと、構造が可変のデータ、そして構造化されていないデータの量がだいたい同じ場合にはどうすればよいのでしょう。判断が難しい場合、最近では都合の良いことに、従来からのデータベースが XML 文書や XML 文書の断片をうまく含められるようになっています。そうした XML 断片にアクセスする方法はデータベースによって異なります。ただしそれらの実装での 1 つの共通点として、それらは XQuery 1.0 の構成体を使っています。


ソリューション

市場に出ているいくつかの製品では、何らかの形で XML データベースが実装されています (例えば Xindice、Tamino、X-Hive、Oracle、Microsoft® SQL Server など)。しかしこの記事では、これらの製品についての説明はしません。長々と詳細に製品を比較することは現実的ではなく、またこの記事は XML データベース・ソリューションのベンダーのサイトで公開されていることを考えれば、そうした比較をしても信用されないでしょう。著者がフリーランスであるからといって、この中立性の問題が十分に解決されるわけではないのです。

ここでは pureXML フィーチャーを持つ IBM DB2 Express-C について説明し、従来の NXD による手法とデータの扱い方を比較します。この比較をするために、私は eXist-DB というオープンソースのプロジェクトを選びました。eXist と DB2 Express-C はどちらも無料で入手することができ、使いやすい機能を豊富に提供しています。

非常に大量のデータを保管したい場合には、DB2 の商用版を購入することをお勧めします。最初は DB2 は重たいソリューションに思えるかもしれませんが、デスクトップ PC やラップトップ PC に DB2 Express-C をインストールして pureXML フィーチャーを評価することは比較的容易なのです。eXist には商用版はありませんので、eXist を超えるパフォーマンスやスケーラビリティーを要求する場合には、eXist に代わる候補として Mark Logic が適切です。Mark Logic を評価するためには 30 日間の試用ライセンスを使うか、あるいはストレージの容量が 100MB に制限されたコミュニティー版を使います。

似た製品同士 (例えば DB2 と Oracle など) で製品比較をしたいという要求があることは承知しています。この 2 つの製品に関しては、少し以前のものですが、オンラインで行われた議論が見つかるはずです。ここではもっと根本的な議論として、DB2 Express-C の pureXML フィーチャーは eXist-DB と比べてどうなのか、あるいは同様に、DB2 は Mark Logic と比べてどうなのか、といった比較を行います。


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

大部分の製品カテゴリーの名前と同様、ネイティブ XML データベースという言葉は少し誤解を招きがちです。ネイティブ XML データベースという言葉を聞くと、データベースとは何か、ネイティブ XML とは何か、DB2 は NXD なのか、といった疑問が湧いてきます。

ウィキペディアによれば、「コンピューター・データベースとは、レコードを集めて構造化したもの、またはコンピューター・システムに保管されたデータ」です。ネイティブ XML とは、XML に関連する技術を XML 以外の技術と混合せずに使用することです。これはつまり、SQL をまったく使うことなく XQuery と XPath を使えるということです。IBM は、「DB2 の機能を pureXML と呼ぶということは DB2 がネイティブ XML だということなのか」という質問を想定しています。この定義に関しては次のセクションで取り上げます。

NXD を XML 対応の RDBMS と比較する場合、典型的な NXD は文書リポジトリーとして分類することもできると思います。しかし文書リポジトリーという言葉は Alfresco や Magnolia などの製品で使われています。これらの製品は既存のデータベースの上に階層化されており、eXist や Mark Logic が提供する基盤 (特に、XQuery を効率的に実行する機能) がありません。Alfresco や Magnolia などの製品は、ワークフローや使いやすいインターフェースなど、上位レベルの機能に焦点を絞っているのです。一方、NXD ではそうした機能はユーザーの自由に任されています。NXD は下位レベルの文書リポジトリー API のみを提供します (例えば WebDAV (Web-based Distributed Authoring) やカスタムの RESTful コネクターなど)。

つまり典型的な NXD は XML 文書を効率的に保管することができます。NXD は XQuery 技術を提供し、また文書リポジトリー機能のための薄いレイヤーを提供します。

また NXD にはリソース指向の傾向があります。これは要するに、リポジトリーに保管されるコンテンツの個々の部分を URI (Uniform Resource Identifier) を使って特定できるということです。HTTP または WebDAV を使うことで同じ URI によってデータにアクセスできるため、接続性の問題がありません。

データを 1 つのリソースとして扱うことには欠点もあります。文書同士は分離されているため、複数の文書にわたって分割されているデータの間の関係を作成しにくくなります。1 つの文書が権限データを含み、それを他の文書群が参照している場合には、参照整合性を維持することが難しくなります。そこで、大規模な XML データベースのベンダーは、複数の文書にまたがるデータを制限するオプションを提供しています。ただし、その方法は他の XML 技術にようには標準化されていません。


pureXML

IBM はネイティブ XML データベースという言葉を避ける選択をしましたが、それでも IBM のソリューションが純粋に XML の性質を持つということを伝えようとしています。DB2 Express-C は NXD としては典型的なものではありませんが、NXD としての特性を実際にいくつか持っています。ある観点から見ると、DB2 は XML 対応の列を持つ通常の RDBMS のように見えます。XML 技術を気にせずにリレーショナル・データベースを使いたい場合には、単純に XML 対応の列を無視することができます。しかし XML 機能が実際に必要な場合には、XML 対応の列という微妙な表現を、XML 機能がないかのように勘違いしてはいけません。

pureXML という名前は、次の 2 つの点から妥当な名前であると言えます。

  • XML データはネイティブ・ツリー・フォーマットで保管され、リレーショナル・データとは分離されています。
  • すべてのデータ (つまりリレーショナル・データと XML データの両方) に対して 1 つの XML インターフェースを使ってアクセスすることができます。

XQuery 1.0 は XML 文書に対してクエリーを実行するためだけのものではありません。IBM は XQuery 関数を提供しており、これらの関数を使うとリレーショナル・データに対してクエリーを実行することができ、またその結果を XML 対応の列の XML と自在に組み合わせることができます。そしてデータを組み合わせた結果は XML フォーマットで返されます。

DB2 は純粋なデータベース・インフラストラクチャーです。DB2 では、多くの NXD で提供されている文書リポジトリー機能の薄いレイヤーは提供されていません。これは DB2 を使って (薄い、または厚い) 文書リポジトリーを実装することはできないという意味ではありません。現状では、Alfresco など大部分の文書リポジトリーは XML 対応ではない RDBMS の上に実装されており、NXD の上に実装されているわけではありません。そうしたリポジトリーのベースとして DB2 を使用すれば、少なくとも現在そうしたリポジトリーによって提供されているものと同じ結果を得ることができます。しかも XML ストレージ機能を使ってデータ・モデルをもっと柔軟にできるというメリットを得られる可能性が高くなります。

Alfresco などの製品に pureXML のような機能が追加されるまでには、しばらく時間がかかるかもしれません。なぜなら、Alfresco などの製品は 1 つのデータベース製品に結びつけられることを嫌うからです。XQuery 1.0 仕様はありますが、データベース製品の中での XQuery 言語の使い方は標準化されていません。そうした製品に対しては、XML データベースの新しい機能を使用するのを遅らせ、XQuery や接続プロトコルの使い方が統一されるまで待ち、当面は WebDAV やリレーショナル・データベース・コネクターのように実装が統一されている標準のみに従う方が安全なのです。


DB2 の pureXML 機能をどこで使用するのか

答えは非常に単純です。世界中の IT ソリューションの圧倒的大多数はリレーショナル・データベースに大きな投資をしてきました。ある 1 つのソリューションに必要な柔軟性がリレーショナル・データベースに欠けている場合であっても、リレーショナル・データベースは相変わらず他の手段よりも成熟しており、また厳しい要求に適しています。

次のステップに進んで XML 技術を採用したいと望む会社が、長年にわたる開発の成果を捨て去り、それを NXD で置き換える可能性は低いと言えます。そうした会社はリレーショナル・データベース以外に NXD も使用するかもしれませんが、そうすると複数ソースにまたがって分割されたデータを統合するという新たな課題が生じます。トランザクションの処理や参照整合性を考えてみてください。そうした懸念事項の解決は不可能ではありませんが、1 つの統合ソリューションでそれらに対応できれば多くのメリットがあります。

pureXML の中ではリレーショナル・データと XML データとを組み合わせることができるため、XML への移行が容易になり、あるいはもっと現実的な可能性として、部分的に XML 技術に移行できるようになります。


まとめ

XML 文書は構造化されたデータを記述することができますが、XML 文書を数多く含む NXD は、複数の文書にまたがって分割された構造化データの関係を記述したり参照整合性を維持したりするためには最善のソリューションではないかもしれません。NXD でそうした関係を管理することが (例えば XPointer を使って) 既に可能な場合にも、そういう使い方は標準化されていません。

最も適切な助言としては、適切なツールを適切な作業に使うということです。しかし NXD と RDBMS とが共存すると、それらをどのように統合するのかという問題が発生します。DB2 の pureXML 機能は両方の世界の最も優れた部分を併せ持ち、また構造化されたデータも、構造が可変のデータも保管することができます。構造化されていないデータの保管に関しては、NXD と RDBMS のどちらも同じ程度に適しています。

実際に求めるものがデータベースではなく文書リポジトリーの場合には、別の質問をする必要があります。その要件は文書リポジトリーのフロントエンド機能に焦点があるのでしょうか、それともバックエンドに焦点があるのでしょうか。管理インターフェースやワークフロー、視覚化といったエンドユーザー機能が大量に必要な場合には、市場にある多くの製品 (Alfresco など) がそうした機能をサポートしています。XQuery や全文検索といった強力なクエリー・メカニズムや、構造が可変の文書を効率的に保管することに関心がある場合には、eXist や Mark Logic などの NXD が検討に値するかもしれません。

データベース・ソリューションの世界は少数の大きなベンダーで占められており、IBM はそうしたベンダーの 1 つです。NXD は相変わらずニッチなマーケットです。問題は、NXD の小さなプレーヤーが競争に生き残れるかどうか、大企業に買収されるかどうか (例えば X-Hive は EMC に買収されました)、あるいはハイブリッド・ソリューションにマーケット・シェアを奪われるかどうか、ということです。明確な傾向として、RDBMS ベンダーは NXD に市場シェアを奪われまいとして、適切に統合された独自かつ完全機能の XML ソリューションを提供することで顧客の要求に応えようとしています。

参考文献

学ぶために

  • XQuery 1.0 について学んでください。XQuery はXML クエリーのための強力な標準であり、すべての有力な XML データベースで使われています。
  • developerWorks の XML ゾーンは XML の技術ライブラリーとして、広範な話題を網羅した技術記事やヒント、チュートリアル、技術標準、IBM Redbooks などを用意しています。
  • developerWorks technical events and webcasts で最新情報を入手してください。
  • developerWorks podcasts ではソフトウェア開発者のための興味深いインタビューや議論を聞くことができます。
  • technology bookstore には、この記事や他の技術的な話題に関する本が豊富に取り揃えられています。

製品や技術を入手するために

  • DB2 pureXML のページを訪れ、完全な DB2 プラットフォームの機能について pureXML 機能を含めて学んでください。
  • 無料のコミュニティー版、DB2 Express-C を使って pureXML 技術を評価してください。
  • オープンソースの NXD、eXist-DB をダウンロードしてください。eXist-DB は MySQL にとって徐々に NXD による競合となりつつあります。
  • パフォーマンスとスケーラビリティーの要件が eXist の機能を上回る場合には、eXist に代わる候補として Mark Logic が適切です。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Information Management
ArticleID=366809
ArticleTitle=XML データベースによるデータの扱い方を比較する
publish-date=12162008