1. 巨大クラスを作ってはならない。
普通のOO Programmingでも普通に作らない方がもちろん良いのですが、db4oを使用する場合、クラスごとの保存となるため、クラスが巨大であるほどパフォーマンスが落ちているように感じました。
小刻みにクラスを作って、Store(object obj, int storelv)の保存階層で調整するのがよさそうです。
2. GenericのListを継承しない
バージョン7.4以後、GenericのListを継承したオブジェクトを保存するとdbを開ける度に、indexoutofrangeが発生するようになりました＾＾； これには相当悩まされました。。。(回避方法があったらどなたか教えてください)
3. Storeをキュー化する
iobjectcontainerのstoreメソッドのパフォーマンスに難を私は感じました。階層指定して、最適化してあげてもです。(これには、まだ私の勉強不足があるかもしれません)
db4oは、キャッシュオブジェクトのバックアップとして使っていたので、前回の書き込みにあったように、storeメソッドを別スレッドのキューに入れて、溜め込ませることでユーザーへのリスポンス速度を得ました。
最もこれは、RDBMSでも出来るでしょうが、キャッシュオブジェクトとマッピングする手間が省ける事が利点です。
この仕様の問題点は、サーバ起動時またはページが必要とするデータをコールする際に、データをメモリーにロードする時間が発生する事です。
郵便番号のデータクラスを260000件をGeneric List型にロードするのに、40秒ほどかかってしまいます。(IEnumerableのまま、実装は、IQueryable型？）であれば、数秒でロードしますが、検索の時間がGeneric List型の方が圧倒的に早いので、260000件のToList()に時間がかかります。
一度IQueryableでロードしてから、別threadでListに変換し、変換が完了次第、IQueryableを消していくなどの方法をとると、とりあえず起動も快適にできそうではあります。
結論として、db4oによるwebアプリケーション開発は、データ構造は複雑だけども、データ量そのものは少ないというアプリケーションに向いてそうです。(iisのメモリー制限やdb4oのファイルサイズ制限もありますし。)
