オブジェクト指向データベースの復権（前編）

CachéとObjectStore、脱RDBMSの真価を探る　Page 1

2004/9/2
山田祥寛

データベースといえばRDBMSという固定観念は、オブジェクト指向開発の普及により、ゆるやかに崩れつつある。本記事では、オブジェクトとして定義された複雑なデータ構造をシームレスに格納できるデータベースとして、オブジェクト指向データベース（OODB：Object Oriented DataBase）の可能性を探ってみる。（編集局）

■オブジェクト指向データベースの置かれた状況

主な内容 --Page 1-- オブジェクト指向データベースの置かれた状況 オブジェクトモデルをそのまま格納できるメリット --Page 2-- Caché―多次元データモデルが効率的なデータ管理を実現 Cachéの機能進化の歴史 --Page 3-- ObjectStore―CFAがパフォーマンスと拡張性を支える ObjectStoreの機能進化の歴史 --Page 4-- 個性的な進化を遂げたOODB

　今日のシステム開発においてデータベースといえば、リレーショナルデータベース（以降、RDB）が主流だ。RDBは「テーブルと呼ばれる2次元の表にすべてのデータが格納されるため、直感的で分かりやすい」「フィールド間にリレーションシップを設定することで複雑なデータ構造も表現できる」というメリットにより、パーソナル用途からエンタープライズシステムまで広範なユーザー層に支持を得て、爆発的に普及した。しかし、Java、C++、C#をはじめとしたオブジェクト指向技術が台頭するにつれて、RDBが必ずしも最適解とはいえない状況が発生しつつある。

　その要因の1つは、ITの役割がますますビジネス密着型の傾向を強め、データの複雑さの度合いが増しているという点が挙げられる。現実世界の状態や現象は、必ずしも単純な2次元表に収められるものばかりではない。現実のデータをRDBに格納するために、多大な労力と苦労を強いられている技術者は少なくない。複雑なデータを正規化した結果、1つの問い合わせに対して、何重ものJOIN（結合）が必要になる可能性がある。結合は多くの場合、高負荷な処理であり、パフォーマンス上のボトルネックとなる最大の原因だ。

　もう1つに、開発生産性の観点から見た問題が挙げられる。JavaなどでRDB連携を行ったことがある方ならば、容易に想像がつくだろう。例えば、SELECT命令によって取り出した結果セットは、いちいちオブジェクトのプロパティ値に割り当てる必要がある。また、INSERT／UPDATE時には逆にオブジェクトのプロパティから値を取り出して、SQL命令を動的に組み立てる必要がある。これは単調であると同時に煩雑でもあり、開発生産性を低下させる一因となっている（これをインピーダンス・ミスマッチという）。一説によれば、オブジェクトとRDB間のマッピングに要する工数が全体のコーディングに占める割合は、実に3〜7割にも上るというから驚きだ（システムの特性によって、この割合は一概にはいえないが）。こうした単調なコーディングが、思わぬバグを引き起こす原因となることも、大きな課題といえるだろう。

　このようなマッピング作業の負荷を軽減するための手法として、O/Rマッピング（Object/Relational Mapping）が注目されている。O/Rマッピングの主な実装として、HibernateやTorque、Castor、Cayenneなどが挙げられる。しかし、これらのツールはコーディングを簡素化するものではあって、先述したパフォーマンス上の問題を解決するものではない。O/Rマッピングの実装によってはメモリを大量に消費するため、扱うレコード数（データサイズ）によってはパフォーマンス上のボトルネックとなるケースも少なくない。

■オブジェクトモデルをそのまま格納できるメリット

　それならば、ビジネス・エンティティであるオブジェクトそのものをデータベースに格納すればよいではないか、という発想から生まれたのが、オブジェクト指向データベース（OODB：Object Oriented DataBase）だ。そもそも設計から実装モデルまでオブジェクト指向で進められてきた開発が、データベースに格納するためだけにまったく異なる2次元表形式に変換しなければならないこと自体、不自然である。OODBを導入することで、RDBでは避けられなかったインピーダンス・ミスマッチを回避できる。

図1　開発工程で生じるRDBとOODBの違い

　OODBによる開発では、O/Rマッピングのように、ただ単にオブジェクトと2次元表のミスマッチを疑似的にラッピングしているわけではないから、単にマッピングコードの記述が回避できるだけではない。オブジェクトの分解／再構築にかかるオーバーヘッドが根本的になくなるので、パフォーマンスの大幅な改善が期待できる。

　本稿では、OODBの代表的な製品である「Caché」「ObjectStore」の2製品について、それぞれの概要を見ていくことにしよう。OODBと一口にいっても、標準的なアーキテクチャが必ずしも確立されていない分野だ。両製品ともに、高いパフォーマンス、信頼性を打ち出すために、それぞれに異なるアプローチを採っているのが面白い。（次ページへ続く）

1/4

Index
連載：オブジェクト指向データベースの復権（前編） CachéとObjectStore、脱RDBMSの真価を探る
	Page 1 ・オブジェクト指向データベースの置かれた状況 ・オブジェクトモデルをそのまま格納できるメリット
	Page 2 ・Caché―多次元データモデルが効率的なデータ管理を実現 ・Cachéの機能進化の歴史
	Page 3 ・ObjectStore―CFAがパフォーマンスと拡張性を支える ・ObjectStoreの機能進化の歴史
	Page 4 ・個性的な進化を遂げたOODB

オブジェクト指向データベースの復権

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）