Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

 


XML & Web Servicesインタビュー


個性派DB「Caché」、RDBの牙城を崩せるか

米国での急成長を受け、昨年から本格的に日本市場開拓に乗り出したインターシステムズ。その主力製品となるオブジェクト型データベース「Caché」は、XMLネイティブではないものの、非RDBを検討中の開発者には気になる存在だろう。Cachéのソフトウエア開発ディレクター、兼日本担当シニアマネージャのロバート・ネーグル氏に、製品開発の経緯、XML/Webサービスとの接点、今後の戦略などについてインタビューした。


@IT編集局
上島 康夫
2004/3/24
インターシステムズ本社 ソフトウエア開発ディレクター ロバート・ネーグル(Robert Nagle)氏

OODBで1人勝ちの真相

 ほんの短期間だけ注目され、すぐに消えていったテクノロジは数多い。オブジェクト型データベース(以下、OODB)も、その典型の1つだろう。1990年代後半にJava言語が登場し、オブジェクト指向開発とOODBは、次世代を担うテクノロジの両輪と期待された。Javaは目覚ましい普及を遂げたものの、相棒のOODBはパフォーマンスの低さ、スケーラビリティの不足といった重大な欠点を克服する以前に、システム開発の主流から転げ落ちてしまった。

Q:この経緯を知る者にとって、CachéというOODBがRDB全盛の今日まで生き残り、しかもここ数年で売り上げを大きく伸ばしているとは、にわかに信じがたい。どうしてこのOODB製品だけが、パフォーマンスの問題を乗り越えられたのだろうか。

ネーグル:Cachéは非常にユニークなパーシステンスモデルを持っている。われわれは、この構造を「Sparse Multidimensional Array」と呼んでいる。オブジェクトを格納する際に、クラスの階層は分解され、それぞれのクラスインスタンスはさらに複数の多次元配列に分割格納されるのがCachéの特徴だ。もしオブジェクトがプロパティを持たなければ、ストレージにアロケートされない。この多次元配列は高度に圧縮されたフォーマットなのでデータサイズを非常に小さくできる。このためCachéのコンカレンシー・エンジンはこれらの配列を高速に処理できるのだ。

編集部注:sparseとは「希薄な、まばらな、散在する」の意(リーダーズ英和辞典第2版)。あえて日本語に訳せば「散在する(まばらな)多次元配列」くらいか。

 ネーグル氏は格納されるデータが「sparse(スパース)」であることを特に強調した。Cachéでは1つのオブジェクトをいくつかの要素に分割し、それらをアクセスしやすい配列構造で保存しているようだ。オブジェクトのインスタンスごとにこれらの構造に割り当てるデータ量には違いがあるが、このまばらの構造のおかげで冗長なデータ領域を確保する必要がない。RDBではテーブルの正規化とインデックス作成はコストのかかる作業で、自動化できるプロセスではないが、Cachéではオブジェクトの格納時に自動的にインデックスを作成するという。

図 Sparse Multidimensional Arrayの概念図


Q:ほかのOODB製品は、なぜ十分なパフォーマンスを得られなかったのか。

ネーグル:多くのOODB製品、特に初期のものは、オブジェクト単位の粒度で物理的なストレージに格納することにこだわっていた。つまり、オブジェクトレベルとページレベルでの一致(コンカレンシー)を固持していたのだ。これに対して、Cachéのコンカレンシー・モデルは、(前述の多次元配列のおかげで)よりフレキシブルな構造を持っていた。この結果、われわれは高いパフォーマンスとスケーラビリティを得られた。

Cachéの開発コンセプト

Q:なぜ、インターシステムズはOODBを追求し続けるのか。

ネーグル:われわれがCachéという製品を立ち上げようとした当時(1995〜1996年ごろ、製品出荷は1997年)、ほとんどの新しいアプリケーションはオブジェクト指向でプログラミングされていた。ユーザープレゼンテーション層やビジネスロジック層ではオブジェクト指向のフレームワークを使いつつも、最後はO-Rマッピングになる。そこに大きな問題があると認識した。O-Rマッピングはアプリケーションのパフォーマンスに大きな影響を与えると同時に、開発工期にもマイナス要因となる。なぜなら、O-Rマッピングは非常に難しい、時間のかかる作業だから。「オラクル・テクニカルジャーナル」では、O-Rマッピングは開発時間の40%を占めると述べている。プレゼンテーション層、ビジネスロジック層、データストア層までをオブジェクトで統一できるのが正しいソリューションだと考えた。

Q:それは、古くて新しい議論だ。OODBのコンセプトには誰もが賛成するが、それは現在でも達成されていない。

ネーグル:初期のOODBは、2つの大きな問題を抱えていた。1つはスケーラビリティ。シングルユーザーや数人までのマルチユーザーのレベルでは対応できていたが、多くのユーザーによる多くのトランザクションがかかると、性能が著しく劣化した。2つ目は、データ・アクセスの手段が非常に貧弱だった。ほとんどの開発者は標準化されたSQLによるアクセスを望んでいたのに、初期のOODBはSQLアクセス機能が十分ではなかった。Cachéを立ち上げるときにわれわれが目指したのは、OODBであること、ただしスケーラビリティを備えていること、そして手軽にデータ・アクセスできるようSQLに対応することだった。

編集部注:CachéのSQLアクセスに関しては、開発者は特別な工数を必要とせず、SQLインターフェイスは自動的に生成される。このインターフェイスはSQL92をサポートしたうえに、オラクル拡張やSQL Server拡張の一部までサポートしているという。

ネーグル:Cachéで目指したのは、ノートPCで動く個人用のアプリケーションをアプリケーションの構造を変更することなく、16CPUマシンで動かすような5000人のマルチユーザーアプリケーションに拡張できることだった。

ビジネス成功の理由

Q:OODBの技術的な問題を解決できたとしても、それは必ずしもビジネスに直結するわけではない。Cachéのビジネスでの成功は、オブジェクト指向開発の浸透によってもたらされたのか。

ネーグル:当社の成長は多くの要因によるが、多くのパートナー企業を通して、エンドユーザーに届ける間接販売モデルに特化している。パートナー企業はアプリケーションを開発しCachéとともに販売するのだが、彼らの販売するアプリケーションが非常に大きな成功を収めた。それがCachéの成功につながったと認識している。

Q:なぜCachéを使ったアプリケーションは成功したのか。

ネーグル:市場に一番乗りできたから。つまりCachéによって開発期間を非常に短縮できた。ユーザーの新しい要望に素早く対応できたのだ。しかし、市場に一番乗りするだけでは成功できない。さらにアプリケーションを早く変更できることも大事だ。ここはOODBのRDBに対するアドバンテージである。パートナー企業がよいアプリケーションをより早く開発できること、それにCachéの機能が貢献しているのが、成長の秘けつだと思う。

ニーズが高まっているWebサービス、XMLについて

Q:Cachéのインターフェイスは非常に多様(SQL、.NET、Java、XML、Webサービス)だが、現在どのインターフェイスが多く使われているのか。

ネーグル:開発のトレンドは2〜3年ごとに変わっている。3年前は.NETで開発する例はほとんどなかったが、いまでは半数の開発者が.NETだ。同じように、4年前には誰もWebサービスなどという言葉は聞いたこともなかったが、過去2年でWebサービスの開発が増加している。CachéはWebサービスとしてデータを公開するために、シンプルなモデルを用意している。具体的には(既存のデータベース・インスタンスを)2つのキーワードを加えて再コンパイルすればよいだけだ。われわれはアプリケーション開発の新しい手法に、常に対応することを目指して製品を開発している。

Q:非RDBのもう1つの選択肢であるXMLネイティブデータベース(NXDB)には、どのような見解を持っているか。

ネーグル:われわれの意見では、XMLはトランスポートのためのデータフォーマットであって、ストレージに適したフォーマットではない。データ交換のためのフォーマットだ。われわれが重視しているのは、XML形式のデータに簡単に変換できること。XMLのストリームデータを新たなCachéクラスにマップしたり、Cachéから取り出したデータを簡単にXMLに変換するといった機能を持たせることが重要で、ストレージフォーマットをXMLにすることは考えなかった。Cachéのストレージエンジンは、XMLの格納、マニピュレイト、階層構造などに親和性を持っている。XMLのクエリを使いたいという要望はまだ例外的だが、サポート範囲の拡大は続けていく。

新製品「Ensemble(アンサンブル)」の意味するところ

Q:RDBのメジャー製品であるOracle、DB2、SQL Serverなどは、開発ツールやWebサーバ・プラットフォームとの統合化に進んでいるが、Cachéの今後の製品開発はどの方向に進むのか。

ネーグル:Cachéはすでに開発ツールやWebアプリケーションサーバを持っているが、ツールベンダになるつもりはない。ただ、アプリケーションサーバとデータベースサーバとの統合は進めていくつもりだ。ここ数年、新しいアプリケーション開発の流れが生まれている。それはEAIをターゲットとしている製品群だ。これからのアプリケーションは、社内外に散在するアプリケーションの統合を目的に開発されていくことが多くなるだろう。エンタープライズシステム、レガシーシステム、Webポータルなどを統合していく流れだ。われわれもこの分野に参入する。ビジネスプロセスモデリングやビジネスアクティビティモニタリングといった機能を持つEAI製品を今年後半には発表できるだろう。製品名は「Ensemble(アンサンブル)」だ。webMethod、Tibcoなどが競合となる。

Q:今年度の日本市場での取り組みは。

ネーグル:本格的に日本に参入した昨年は移行の年だったととらえている。今年は、新たなパートナー企業との契約を進めていくなど、本格的に活動するつもりだ。とりわけ、医療分野のアプリケーション開発にフォーカスする。医療分野データモデルの要求は、財務や通信分野と比べてもはるかに複雑なので、Cachéの性能をアピールできると考えている。

終わりに

 Cachéの成功が、開発工期の短縮であったことは興味深かった。いまひとつ伸び悩み気味のNXDBでも、スケーラビリティとパフォーマンスが改善されれば、十分RDBに対抗できることの証明といえよう。また、インターシステムズがEAI製品にフォーカスしていることは、今後を占う意味で重要だ。Webサービスの主戦場はアプリケーション統合ソリューションに絞られてくるのは間違いない。

個性派DB「Caché」、RDBの牙城を崩せるか


XML & SOA フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

HTML5+UX 記事ランキング

本日月間