BlogKLabは、多くのスマートフォン向けゲームを開発・提供しています。スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。1日目の記事になります)今年もアドベントカレンダーの季節がやって来ました。お祭り騒ぎと年末進行の勢いで、普段は書かないような変なネタも含めてKLabエンジニア陣が多彩なエントリーをお届けします。最初は昨年に引き続きKLabアドベントカレンダーの旗振り役をさせていただいてますoho-sからです。古今東西、人々は伝説に宗教にそして現実にそれを追い求めて来ました。そもそも「生きている」ってどういうことなのでしょう。現代の生物学においても、その定義は非常に曖昧です。急進的な主張としては、一個体の生物を構成する物理化学生物的な現象を全て完全に正確に模倣したら、それは生きているということではないか、というものです。方法としてよく見られるのが、脳のコンピュータへのアップロードです。これは、人間の脳を構成するあらゆる情報をデータ化したうえで、ものすごい性能のコンピュータにシミュレーションさせることで、人間がコンピュータ上で生きていけるのではないか、という考え方です。人間の神経細胞は140億個以上あるといわれ、それら同士の結合はさらに大変な数になります。現在の最高性能のコンピュータをもってしても、シミュレーションは不可能です。神経細胞同士の接続の性質も完全にわかっているとはいいがたい状況です。一方で、「その人」を維持するに足る正確さで各神経細胞や、その相互の接続の情報を取得することができるのでしょうか?生物学の世界では、生物の全遺伝情報、いわゆるゲノムがデータ化できた現在、次のターゲットは、脳の神経細胞とその全結合情報のデータ化となっています。電子顕微鏡やその他の観測手段を用いてデータ化していくのです。一個体の全神経細胞とその全接続の情報のことを「コネクトーム」と呼び、一部の生物のコネクトームはインターネットで公開さえされているのです。自分自身のコネクトームを作成し、それをシミュレーションできたら不老不死になれそうです。SFの登場人物たちはきっとこうやって、いとも簡単に脳をコンピュータにアップロードし、コピーし転送しバックアップしアップグレードし、そして進化しているのでしょう。RDBMSのバックアップさえ一仕事なのに、一貫性や同一性やその他諸々は本当に大丈夫なのか。どんなデータ構造なのか。気になるところはいくらでも出て来ます。そこで、GraphDBです。「電気線虫はアンドロイドの夢を見るか?」まずはコネクトームとはどのようなデータになるのかを具体的にお話ししましょう。)のコネクトームがあります。線虫は体長1mmほど、全細胞数およそ1000個、神経細胞は300個くらいです。コネクトームの実態は、神経細胞をノード、それらの接続をエッジとしたグラフデータです。このようなデータを永続化したり神経活動をシミュレーションしたりなどの様々な処理をするには、グラフデータを扱うのに適したデータ管理システム、そう、GraphDBがあればいいということになります。GraphDBとは、その名の通りグラフデータ構造を格納して処理するためのDBMSです。有名なものとしては、Neo4jなどがあります。ノードとエッジからなるネットワークのようなデータ構造を、テーブルからなるデータ構造を管理するRDBMSのように、管理するものです。RDBMSでグラフ構造を扱ったことのある人は、その煩雑さと低性能に悩まされたことがあるかもしれません。RDBMSでグラフ構造を扱うのは非常に難しいと言われています。GraphDBは最初からグラフデータ構造を扱うために設計されているために、はるかに速く安全にグラフ構造を管理できるのです。GraphDBや、グラフデータを扱う仕組みは、例えばSNSのユーザー間の関係性であったり、検索対象ドキュメントの間の関係性であったりと、様々な対象が現実にあり、近年利用が進んでいる分野です。いうことで、本稿では、Go言語でグラフデータを格納し永続化できる簡単な仕組みを実際に作成し、そこに線虫のコネクトームを格納して、その線虫を不老不死にしてみましょう。B」まずはバックエンドのデータストアを決めます。ここでグラフに向いた独自データストアを作り始めてもいいのですが、今回はLevelDBを使います。GoでLevelDBを使うに当たっては、公式ドキュメントと、こちらを参考にしました。LevelDBはいわゆるKVSなので、グラフデータに適したキーを設計しなければいけません。今回は、以下のようなキーの構造にしました。始点IDと方向とタイプと終点IDでの検索ができます。一方で、このキー構造だと、終点から始点への検索ができないので、エッジを格納するときは、始点から終点までの前向きエッジと終点から始点までの後ろ向きエッジを同時に格納することで解決しました。こちらが、実際に作ってみたリポジトリです。以下にノードとエッジのコードを提示します。node.goedge.goまた、DBのOpenや検索等のためのコードが以下になります。graphdb.go公開されている多くのGraphDBには、ロックやトランザクションや各種制約、クエリ言語やサーバーとして動かすための仕組みなどがありますが、今回はLevelDBにグラフ構造を永続化して、簡単なノードの検索とエッジの検索ができるようになったということで、ここまでにしておきます。線虫のコネクトームデータはこちらのものを利用しました。10.1126/science.1221762.を参照してください。dot形式のデータで取得してテキストエディタ等で置換とマクロでTSV形式の単純なデータに変換しました。実際のデータはこのようなものです。dataこれを作成したGraphDBに読み込みます。読み込みは以下のようなコードを書きました。id}そして、まずは永続化した線虫のコネクトームをDOT形式で書き出し、データの確認をします。db.PrintGraph2DOT()}以下が出力したdot形式ファイルをGraphVizで書き出したものです。次に、ノードに接続するエッジを検索してみましょう。コードはこんな感じになります。}}さらに、こうすると、Hop数を変えてノードを羅列できます。これで僕のPC上で線虫が不老不死となりました。今回はあくまでも実生物の神経ネットワークを使いやすい形で静的に永続化したにすぎず、生物のダイナミックな「生きている」という性質は、シミュレーションを動かしたりしなければ得られません。不老不死ははるか遠い。今回、なぜこのような題材を選んだかということを最後に説明しないと意味不明になりそうなので、説明しておきます。GraphDBに興味があったこと、特に、今あるものを利用するのではなく、どう実現されているのかに興味があったので実際に作ってみようと考えました。既存のGraphDBはサーバーを立てて使うものが多いのですが、プログラム組み込みで使うものが欲しかったというのもあります。言っているところで、EliasDBというものを見つけました。今回は、それRDBMSでもいいじゃんというレベルしか実装できませんでしたが、GraphDBはとても面白いので、今後も勉強していきたいと思います。GraphDBを使った題材を考えていて、コネクトームというものを知り、これだ!と思ったわけです。コネクトームに関しては、ロボットに線虫のコネクトームを元にしたシミュレーションシステムを接続し、電子線虫サイボーグを作る研究など、とてつもなく未来な研究が実際に行われています。興味のある方は調べてみると面白いと思います。それでは、引き続きこの後のKLabアドベントカレンダーをお楽しみください。