Heap or Disk? キャッシュはいかが？

本日B+Treeとjava.lang.ref.SoftReferenceを活用した、開発を容易にするオブジェクトのキャッシュのランダム追加テストが成功しました。これは非常に面白い可能性を持っているので、ちょっと紹介させてください。

db4oは「オブジェクト指向」の斬新なアイデアでは世界の最先端を言っているといっても過言ではないでしょう。そのアイデアは世界中のエキスパートを惹きつけて止みません。またそのシンプルさは、誰もが軽く触ってみようと思うほどです。

ところがシンプルなオブジェクトはともかく、少し複雑なオブジェクトになると途端に難しくなってしまいます。またその革新性が、ユーザーの敷居を高くしてしまっているのも実情です。

db4oは「オブジェクト」の永続化ツールです。ところがこの「オブジェクト」は諸刃の剣なんです。それはこういうことです。

「オブジェクト」は、メモリ上のヒープで産声を上げます。それは一通りの仕事をした後、休憩をすることになります。実際には、ガーベッジコレクタが、メモリ上に休憩度合いに応じてエリアを作り、オブジェクトの状態を見ながらそのエリアに移動させるわけです。そしてとうとうお休みをもらうことになります。そうです。田舎に帰ってしまったわけです。もう呼び出せません。

しかしdb4oによって永続化されたオブジェクトは、田舎から呼び戻すことができます。そうして田舎から呼び戻すことができるオブジェクトがたくさん出来て、大変便利になります。ところがそこから、実は問題が発生します。

呼び戻す（メモリ内）か、田舎で休む（ディスク）かを、全員に指示しなくてはいけないことです。例えば田舎から必要に応じて呼び出していたら、500人も集まってしまった。中には全然仕事していないオブジェクトもいます。どういうことだ！？なんで仕事が無いのに田舎に帰らないんだ？

Javaは強い参照を持つ、つまりクラス内のフィールドで他のオブジェクトを参照していると、参照されているオブジェクトはコレクトされない、つまり田舎に帰らないわけです。そのためdb4oではactivate(呼び出し)とdeactivate(暇をやる)メソッドが用意されているわけですが、先ほどのように全部管理するとなると途方に暮れるわけです。

そこで考えるわけです。暇になったオブジェクトを自宅待機にしておいて必要なときにすぐ呼び出せたり、あんまり仕事がなかったら田舎に返しておいて必要になったらすぐに呼び戻せないものか・・・と。

つづく

さて、実際にハリケーンの名前を使ったランダム追加テストを今日行ったわけですが、パフォーマンスもなかなかです。ホットスポットのルーチンではなるべくヒープを避けて、スタックの効率利用を考えているんですが、まだまだ改善の余地はありそうです。なんとか月内に一通り形にします。検索は完全一致と範囲検索についてなら、明日にでも一通り実装できると思うので、あとは少し厄介な削除をここ数日中に実装しようと考えています。

db4o Japanese Community
http://www.db4o.com/japan/
japan@db4o.com