OODBの弱点とdb4o

db4o dbms

コンパクトで速くて簡単に使えるのでとても気に入っているdb4oだが、決して万能ではなく、使っているとOODBであるが故の弱点も見えてくる。

一つは散々既出だろうがなんといってもデータベース操作の方法が標準化されていない(オープンになっていないという意味ではない)ことだろう。よくOODBの謳い文句として「XXXXではJDBCやSQLを使用する必要がありません。」というのがあるが、これは必ずしも長所ともいえないのである。
db4oではSODAというオープンソースのAPIを使っているがこれは全てのOODBで使える程普及しているものではない。標準化団体であるODMGのODLなんてものもあるが普及しているとは言い難いし、SQLとは比べものにならない。SQLを使えるOODB(Caché等)もあるが(db4oもJDBC+SQLを使うプロジェクトもある)、元々2次元の表にアクセスするための言語であり、借り物感は拭えない。

もう一つは(特に組込用途を前面に押出しているdb4oは)耐障害性を高める仕組みがRDBに比べて豊富ではないことだろう。
例えばdb4oはACIDトランザクションを提供しておりコミット中に起こったクラッシュからリカバリする方法を持っている(※1)し、dRS(db4o Replication System)と呼ばれるレプリケーションの仕組みもあるが(※2)、ハードウェアの恒久的な障害等が発生した際に、ある時点のバックアップからのデータベースの復旧はできない。PostgresのWrite Ahead Logging（WAL）のようなロールフォワードリカバリができるトランザクションロギングの仕組み(※3)が是非欲しいところなのだ。

WALのような仕組みに関してはその気になれば自作することもできるが、信頼性やテストの手間を考えると膨大な工数がかかるのでDBMSとして最初から装備されていると有難いのだが。
まあ無いものねだりをしても仕方が無い。これらの弱点を埋めるためのいろいろな事を考えてみたいと思っている。


※1 Db4o Product Design » db4o Core » Transactions
※2 db4o Replication System (dRS)
※3 ログ先行書き込みプロトコルに基づくロギング――Write-Ahead Logging (WAL) - PostgreSQL 7.3.4 管理者用ガイド