2009年5月24日日曜日

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

2009年5月21日木曜日

db4o c#

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

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

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

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

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

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

2009年2月26日木曜日

DED製作

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

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

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

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

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

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

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

2008年11月23日日曜日

グリードコンピューティングとAI

擬似3D世界での学習と平行して、学習環境について考察してみた。

擬似3D世界でも現在のコンピューターの処理能力では、高精度のリアル体験学習は、相当性能の処理能力がないと難しいと言う事が分かってきた。

それでは、グリッドコンピューティング的に、学習プロセスを分散化させたらどうかという考えが浮かぶ。

サービスから学習レポジトリを受け取り、クライアントで学習した内容をサービスに送信させる事で、学習DBを構築していく。

学習処理は、一般ユーザーに実行してもらう事が考え付く、彼らに実行してもらうためには、鑑賞系ゲームとして配布し、エンターティメントを提供する代価として、学習処理内容を送信してもらう。

この方法は、一般のゲームでも応用できそうな気がしなくもない。

2008年11月6日木曜日

TravianのAI

フレに誘われてTravianというゲームを始めました。

GNO2のように、指示だけ与えれば、放置で活動してくれるゲームなので、プログラミングをしつつ、バックグランドでプレイしています。

規約的に自動化するのは違反になるので、ゲームデータと目標を設定する事で、目標達成最短の手数を教えてくれると役に立つなと思いました。

辛うじてAIの分野に入っていると思うのですが、エキスパートシステム的なシステムは、あまり興味がないので、多分作らないと思いますが。。。

2008年10月31日金曜日

飛行機のお隣さん

昔の高校を訪ねに飛行機で国内旅行をしました。
となりになった人が、System Biologyという本を持っていて、興味をそそられて話に。

なんで、人体の器官の働きをシミュレーションするアプリケーションを作っているとか。

心臓の一回の鼓動をシミュレートするのに一週間かかるそうで、心臓のセルの働きをタンパク質レベルで解析しているそうで。。。

つまりタンパク質が反応して、セルに動作を働きかけて、筋肉として心臓を動かしている・・・

億単位のオブジェクトを動かしてるんでしょうなぁ・・・

さすがに、AIが3D擬似環境から学ぶとした場合に、ここまでの精度は必要ないんだろうけども、精度を上げようとし過ぎると、リアルから学ぶより遅くなる可能性があると言う事が分かりました。。。

3D擬似環境を考えた場合、オブジェクトの最小単位をポリゴンではなく、極小の正方形を原子として捕らえるべきではないかと思いました。

ポリゴン3Dは、「見せる」事を重点に置いた場合には効率的ですが、物理判定や熱伝導をシミュレートするには、不向きなのかなぁ。

2008年10月28日火曜日

擬似世界から学ばせる

さて、前回の投稿で、学習形の汎用AIに興味があると書いた。

学習型と言っても、20qのように、言葉を教えて辞書を構築するだけでは、本当の知覚には繋がらない。
リンゴは、赤く丸い果物。赤は、RGBで、#FF0000。果物とは・・・

と教え込んでも、南国の人に雪を教えるような物で、知識として溜まるだけで、それが何で在るかは、深い理解をする事は出来ない。

究極的には、五感がセンサーとして必要になるわけだが、ハードウェアを製作するのは無理である。それは、大手の研究所に頑張っていただく。

では、ソフトウェアだけで何ができるかと考えると、人間と同じ五感を持ったAIが学習できる3Dの擬似世界を作る事である。物理の法則があり、温度があり、感触を擬似的に体験できる場である。逆に、その擬似世界は、私たち人間に取って、何も意味をしない。熱そうな物を見ても、私たちは、経験上熱そうと思うだけで、それを感じない。しかし、その世界の中のAIは、その熱を熱として感じる事が出来る。現実世界と逆である。

そして、擬似世界の中で、学んでから、現実世界にそのAIを配置する事で、コンロの上にあったフライパンは熱いという事を擬似的に理解している事になる。大金をかけて、ロボットを現実世界の中で、試行錯誤させる必要がないわけである。

ロボットが特定の用途で使用される場合も、この擬似世界は役に立つ。お掃除ロボットがあるとして、対応する段差を少し変えてみると、どうなるか?など、シミュレーションが容易に行えるからである。

次は、擬似世界で、どのようにAIが世界を「知覚」していくかを妄想してみる。