db4oとweb application

db4oをC# 3.5sp1環境のweb applicationで使用するに当たって、学んだことは、以下のとおりです。

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のファイルサイズ制限もありますし。)

db4o c#

http://vexxxx.com(ve以後はダミーです)

就職した会社の最初のプロジェクトがリリースを迎えました。

asp.net 3.5でdb4oをdbに使っています。db4oのバージョンは、7.8です。

技術的に面白い構造としては、db4oにオブジェクトをぶち込むスレッドを常時回しておき、
保存処理が呼ばれるとそのスレッドの処理キューに加える事で、リクエスト完了時間を早めました。

サイト内のすべてのデータは、サーバメモリにキャッシュされており、キャッシュの中身は編集等があった際に即座に書き換えられるので、db4oの非同期の影響による不整合は発生しないと見ています。

ようするにメモリー内キャッシュしたオブジェクトをHDDにバックアップするための手段としてdb4oを利用しているといったところです。

DED製作

DEDというブラウザゲームを作り始めて2ヶ月が過ぎました。

新しい仕事が忙しくなってきて、一日40分も時間を取るが精一杯になってきましたが＾＾；

特徴的なのは、フルキャッシュで稼動させており、データはdb4oというOODBで丸ごとバックアップさせるという荒業を使っています。

やってることは簡単で、ゲームサーバオブジェクトをOODBから取得し、それをGlobal.aspxに静的プロパティに代入する。すべてのページからゲームサーバオブジェクトにアクセスして、芋づるで取得してきた他のゲームオブジェクトにアクセスする。

正常にサーバが落ちてくれれば、コネクションを閉じる時に保存してくれるのですが、万が一サーバが終了処理を実行できない落ち方をした場合のために、db4oのバックアップメソッドを周期的に呼んでおきます。

金銭的な部分が絡んだ場合は、万が一のロストも許されませんが、このゲームにおいては、これで十分そうです。それよりパフォーマンスが上がれば、それだけ多くのユーザーに楽しんでもらえるので。

当然ながら、サーバのリソースはかなり食いますが、処理速度のパフォーマンスと開発効率は最高に良いです。いずれレポートを記載します。