空間インデックスと第3のイメージキャッシュ
db4oの上にインデックスプロジェクトを考えている中でちょっとひらめいたことがあります。
ちょうど空間インデックスについて考えていたんですが、空間インデックスって、例えばGISやCADのアプリケーションで使われるわけです。その場合にどんな機能を提供すべきかって考えていました。ちょっと分かりやすくするために、ある空間のイメージを表示するまでの一般的なプロセスをちょっと挙げてみます。
- 画像のレイヤを重ねてユーザーデータを合体させた完全なイメージ
- （ユーザーデータ）
- 各レイヤのイメージ（Java2DでいうBefferedImageやVolatileImageなど）
- 複合空間オブジェクト（Java2DでいうGeneralPathなど）
- 空間オブジェクト（Java2DでいうPoint2DやPolygonなど）
- 生データ（x, y, 緯度, 経度, 縮尺など）
下から上へプロセスは進みます。Java Advanced Imaging(JAI) APIという拡張APIではJava2Dにない様々な機能がJNIと連動して提供されていますが、そこではイメージをタイルのように小さな塊の集合体として取り扱っています。これはなぜかというと、上記の３であるイメージをオブジェクトから書き出す（Rendering）コストが非常に大きいため、効率的にイメージをメモリにキャッシュすることがパフォーマンスの鍵だからです。
そしてこのキャッシュは、Java2Dでいうと、RAM上のBufferedImageとVRAM上のVolatileImageに分けることができます。このようにキャッシュはメモリ上に展開されるわけですが、従って容量の小さいメモリ上にいかに効率よくキャッシュを展開するかが非常に重要な課題になってきます。
それではこのようなアプリケーションでデータベースの果たす役割は？
既存のデータベースでは、せいぜい６の生データを返すだけです。もちろん６より上はプラットフォームに依存するからなんですが、そこで、ひょっとしたらdb4oがかなりいい仕事ができないかと思ったわけです。上記３のタイルイメージの第3のキャッシュ場所として。キーポイントは以下のようなポイントになります。
- BufferedImageやVolatileImage等の超早い格納と取得
- 内部byte[]を圧縮・解凍する効率的な方法
- 空間インデックス
これはBufferedImageまたはVolatileImageを再作成するよりも速いスピードでないと意味がありません。その差が大きければ大きいほど、メリットが大きくなります。しかしひょっとしたらdb4oのI/O性能の範疇を超えるレベルかもしれません。ただもしうまくいけば、非常に面白いソリューションになるのではと思います。
db4o Japanese Community
http://www.db4o.com/japan/
japan@db4o.com
