ここから本文です

CMS Watch : 巨大な格差「ザ・グレート・デバイド」 /データベースは20世紀の代物

2006年4月 1日 掲載

デイブ・ケロッグ

情報テクノロジーには、巨大な格差「ザ・グレート・デバイド」が存在している。我々が話題にしてはならないとされている格差、存在しないかのようなふりをしつつ、でも実際には、年々広がっている格差……。それは、データとコンテンツの間の格差だ。

データは、ITの世界の一級市民だ。立派な家も持っている。コントロール、一貫性、セキュリティ、バックアップとリカバリー、インデックス、そしてクエリメカニズムを持ったデータベースの中に住んでいる。

一方、ほとんどのコンテンツは、ホームレスとして、ファイルシステムに追放されている。運が良ければ、コンテンツをインデックス化する検索エンジンを使って、特定の言葉やフレーズを含んだファイルを探せるようにはなっているだろう。あるいは、何かしらの追加設定があって、XML タグがあるならそのいくつかはインデックス化して、分野検索ができるかもしれない。しかし、ほとんどのコンテンツにとって、パワフルで高度なクエリや一貫性のある処理、瞬時に取り出せる機能といった、データベースに住むことの恩恵は、単に手の届かないものでしかない。

結果として、我々のコンテンツに対する理解はかなり貧しいものとなり、コンテンツを使ってできることについての期待も薄れてしまった。コンテンツは、データと同じツールやアプローチで管理できるし、またそうすべきだという神話が広まっている。

ECM とはコンテンツのためのものではなかったのか？

貧しい国にも裕福な住人がいるように、コンテンツのなかにも、データベースに住める上流階級がいる（企業のウェブコンテンツ、航空機の修理マニュアル、新薬の申請書など）。一般に、これは ECM （エンタープライズコンテンツマネジメント）システムを通じて実現されている。ECM とは、コンテンツをリレーショナルデータベースの杓子定規なテーブルにフィットするよう一口サイズに分解し、それらについてのメタデータ（作成者、バージョン、登録ステータス、承認要件など）を追跡するシステムだ。

こうして、上流階級のコンテンツは、データベースでの暮らしを満喫することになるが、ここに大きな皮肉がある。ECM の根底部分にあるデータベースシステムの限界ゆえに、ECM は通常、コンテンツ自体を曖昧なものとして扱う、という点だ。つまり、ECM は、コンテンツにまつわるたくさんの情報を追跡して管理してくれるが、コンテンツの中身に入り込むという点では、あまり助けてくれない。「コンテンツ」がミドルネームになっているにもかかわらず、今日の ECM は、本当のところ、コンテンツのためのものではい。メタデータのためのものなのだ。

例えて言うなら、ECM システムは、レポート機能はあるのにクエリ機能がないデータベースのようなものだ。レポートなら、あれこれ閲覧できる。ボブが作ったレポート、サリーが作ったレポート。こっちはバージョン2で、あっちはバージョン３。はたまた、正式公開にあたってジョーの承認が必要なレポート、などなど。なのに、より詳細なレベルで入り込んで、独自のクエリを実行したり、レポートに手を加えて別のかたちの別のデータにまとめる機能がない。なぜなら、ECM のレポジトリでは、通常、コンテンツとは曖昧なもので、システムは、それに関係した情報を単に追跡しているにすぎないからだ。

もちろん、システムによっては、コンテンツを自動的に分解したり、塊に砕いたりして、より詳細な断片、とはいえやっぱり曖昧な断片にする機能を持ったものもある。しかし、これらのアプローチを可能にするには、コンテンツが絶対的にスキーマ（データベースの構造）に則っていなければならず（実際にはほとんどあり得ないことだ）、それを外れると、修復不可能な問題を引き起こす。ひとたび分解したコンテンツを再構築することは、はたして可能だろうか？　その答えは、たいていの場合、ノーだ。本来の状態と切り裂かれた状態の間を行ったり来たりするなかで、情報が失われてしまう。さらに、塊に砕く方法を選ぶとしても、そのような状態のコンテンツを使った場合の作業速度を考えると、ほとんどのユーザが、結局は相当に「粗挽き」の塊を選ぶことになるだろう。ほとんどのシステムでは、「細挽き」レベルのコンテンツで作業しようとしても、単に遅すぎるし、厄介すぎるからだ。

BLOB の帰還

世界中にある情報の80％は非構造化情報で、その圧倒的多数がデータベースには保存されていない情報だという事実を、リレーショナルデータベースの輩たちは決して忘れてはいない。彼らは、もう何十年にもわたって、自ら「非構造化データ問題」と名付けた状態を解決しようとしてきた。最初に彼らが提供したのは、まったく曖昧な「バイナリ・ラージオブジェクト（BLOB）」だった（これがいったい何を指していたかと言うと、そう、あのファイルシステムだ）。そして次に、「キャラクタ・ラージオブジェクト（CLOB）」が登場して、これに基本的なテキスト検索能力が盛り込まれていた。

1997年、ニューヨークのラジオシティ・ミュージックホールで Oracle 8が発表された時、私はその会場にいて、ラリー・エリソンがファイルの死亡宣言を出すのを聞いた。しかし、ファイルは不屈にも生きつづけた。

また、Microsoft がこの問題を解決しようとして取り組んでいる WinFS についても、私はかなりの資料を読んできた。DBMS とOSをどちらも手中にする Microsoft は、この問題に違ったアプローチを取った。より良い DBMS を作ろうとするのではなく、より良い XML ベースのファイルシステムを作ればいいじゃないか、というものだ。WinFS は、もともとは Cairo で導入される予定だったが、今では Vista の予定とされている。これを待っているのは、まるで「ゴドーを待ちながら」（サミュエル・ベケットの戯曲）の物語のようなものだ。なぜかって？　遅れている理由のひとつは、間違いなく、あまりにも有名な Microsoft の開発プロセスの滞りにある。しかし、一部には、WinFS が SQL Server に実装されるべきだという事業判断上の制約が影響しているに違いない。リレーショナルデータベースというのは、階層構造のモデル化という点では、きわめて能力が低い。階層構造になったファイルシステム、しかもそれぞれのファイルに内部的なノードの階層構造が複雑に含まれているようなファイルシステムをモデル化するなど、リレーショナルデータベースにとっては、まったく最悪のアプリケーションと言うしかない。

ザ・グレート・デバイドを解消する最新の試みとしては、リレーショナルデータベースに追加された XML タイプがある。このアプローチは、アブストラクトのデータタイプにまでさかのぼる。これはもともと、Postgres で導入され、Ingres で初めて商用化され、後に Illustra によってデータブレードという名前を与えられ、その後、Informix に売られて、1990年代半ばに誇大宣伝された“ユニバーサル”データベースに使われた。

考え方は単純だ。あるタイプのデータがデータベースにフィットせず、しかも問題の原因がリレーショナルモデルにあるのではないと思うのであれば、問題は、実装における限界、とりわけデータタイプの不足にあるに違いない。つまり、コラムに対するタイプが無限に提供されているかぎり、テーブルやコラムはどんなものでも完ぺきにモデル化できる、という考え方だ。メッセージがあるのなら、メッセージのタイプを作ること。空間座標があるのなら、空間座標のタイプを作ること。

実際のところ、アブストラクトのデータタイプを使った顧客はほとんどいなかったが、それでも RDBMS のベンダーたちは、非構造化データ問題の最新ソリューションとして、厭わずこれを前面に押し出した。大手の RDBMS ベンダーはすべて、XML をタイプとして追加する作業の真っ最中にある。こうすれば、INTEGER のコラム「DOC-ID」と XML のコラム「DOCUMENT」を持ったテーブル「DOCUMENTS」を作成できるようになる。

コンテンツはデータよりも先にありき

しかし、この最新の試みがザ・グレート・デバイドを解消するとは、私は思っていない。RDBMS ベンダーは、またしても間違った問いかけを出発点としてしまったからだ（これで4回目になる）。それは、「どうすれば既存のデータベースに非構造化コンテンツを入れられるのか」だ。しかし、本来問いかけるべきは、「コンテンツはデータとどう異なるのか、コンテンツが一級市民になれるデータストアはどうやったら作れるのか」だ。

この問いかけに、私自身がお答えしよう。

• 第一に、コンテンツがデータの特殊ケースだという考え方を捨てなければならない。真実はその逆で、データがコンテンツの特殊ケースなのだ。データとは、たまたま非常に規則的な構造を持ったコンテンツなのだ。
• 第二に、コンテンツ、なかでも特に XML コンテンツは、構造上きわめて階層的であることを認識しなければならない。このため、これを実現する技術は、階層構造をうまくモデル化できるものでなければならない。
• 第三に、コンテンツは、そのままの状態で受け入れられなければならない。さもなければ、コンテンツの登録はまったく不可能になってしまうだろう。これは、検索エンジンにとって格好の練習材料となる。検索エンジンは、データベースというレンズを通して見ると数多くの限界があるが、ひとつすばらしい長所を挙げるならば、コンテンツをそのままの状態で受け入れるという点だ。コンテンツは、あまりにも多くのソースから来ていて、そもそもあまりにも量が多いため、コンテンツ登録の前段階としての準備や変更を求めるなど、純粋に不可能なのだ。
• 第四に、DBMS には、十分な機能を備えた検索エンジンを搭載する必要があるだろう。ユーザが実行したいクエリは、構造化フィールドと非構造化フィールドの両方を組み合わせたものとなるからだ（例えば、「ボブが書いたドキュメントで『腱鞘炎』という言葉が含まれているものをすべて探して、その第1段落目を返してほしい」など）。そうなれば、従来ながらのB- Tree 構造のインデックスでは十分でないし、独立テキストと XML のインデックスでも用は足りない。
• 第五に、シンプルなデータの世界には存在しないが、コンテンツにはつきものの、数多くの曖昧さに対応できるシステムを構築する必要があるだろう。これには例えば、語形変化（「デイブ」と「デイビッド」）、類義語（「砕く」と「壊す」）、分類法（「果物」と「りんご」）、そして原語（英語の「アップル」とフランス語の「ポム」）などがある。

次世代のデータベースシステムを設計するにあたって、コンテンツを一級市民として扱って初めて、我々は、ザ・グレート・デバイドを解消できるだろう。そして、来たるべき世代のコンテンツアプリケーションを可能にし、構造化データとして示せる20％だけでなく、持っているすべての情報から、価値を手にすることができるだろう。iTunes を聴いている今どきの若者たちが「レコードって何？」と聞いてくるように、コンテンツベースにクエリを打ち込んでいる若者たちが「データベースって何？」と言う日が来るだろう。

「お父さん、それって、数字や短いテキストフィールドしか処理できないコンテンツベースがあったってこと？　使えねぇなぁ」。だから、データベースは20世紀の代物なのだ。

デイブ・ケロッグは、XML コンテンツサーバの MarkLogic Server を手がける MarkLogic の社長兼最高経営責任者（CEO）。ソフトウエアおよびアプリケーション業界で30年のキャリアを持ち、過去には、Business Objects、Versant Object （オブジェクトデータベース管理システムのプロバイダ）でマーケティング責任者を務めた。さらに前職では、RDBMS ベンダーの Ingres Croporation で技術およびマーケティング業務を担当している。

この記事の原文「 Databases Are So 20th Century 」は、2006年1月2日、「cmswatch.com」に掲載された。

トラックバック

このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/378

このページへのトラックバック一覧

» marklogic 語る from 内部用：マーケティング関連倉庫 [2006年06月07日 17:19]
    http://www.designit.jp/archives/2006/04... [続きを読む]