blubird

Blubirdとは

概要

　コンプリートゲノムの解析においてはその性質上全塩基配列とアノテーションをRAMに取り込んで作業することが不可欠となる。しかし、RAMの容量は常に限られたものであり、総容量１GBを超えるヒトゲノムのような巨大なゲノムの解析において、そして比較ゲノム解析においては全てをRAMに取り込むことは現実的ではない。一方、version 1 の new G() における"long sequence"オプションのように仮想メモリを使い段階的に使用する領域だけRAMに取り込む手法はその為に既存のプログラムの書き換えを必要とし、G-language GAEではOdysseyの百を超えるメソッドを利用できないという問題に直面する。

　RAMは容量の限界だけでなくその永続性もゲノム解析ではボトルネックとなる。通常あるゲノムの解析を行う時、解析のためのプログラムは幾度となく現象に合わせて修正・拡張されてゆき、多くの場合一つの解析を行うために一つのプログラムではなく複数のプログラムを要する。こういった場合、修正や拡張の度に何度もゲノムデータベースは読み込まれ同じ解析が繰り返し行われることになる。当然ながら待ち時間が生じるだけでなく、大量の計算資源が無駄に使われる。さらに、複数のプログラム間でのデータの受け渡しもRAMには永続性がなく一つのプログラムが終われば消えてしまうので、ファイルなどを介すことが必須となる。

　また、version 1では、G-language Projectの三つの目的：

• 現在個別に開発されている解析ソフトウェアの統合開発環境を構築
• 既存の解析ソフトウェア・手法・結果を再利用可能な方法で蓄積
• 重複する解析の為の汎用解析システムの構築 のうち、２の結果の蓄積に関しては具体的解決案を提唱できなかった。そこで、version 2ではBluebird DBMSという、リレーショナルデータベース連動による大規模キャッシングシステムを実装する。

　通常Gの構造体はポインタの階層構造から出来ており、最下層のポインタはメモリ（RAM）上の値を指し、値を参照することができる。Bluebirdではこの最下層のポインタがRAM上のデータを指さずに、リレーショナルデータベース内部のデータの位置を差す。こうすることによって、リレーショナルデータベースのデータ保護機能、速度、ビュー作成機能などのメリットを使いながら、永続的で大容量な作業記憶を実現する。リレーショナルデータベースのデータは長期記憶装置であるハードディスクに保存されるので、RAMの容量やコストから考えればほぼ容量の制限はない、といえるだろう。このように、若干の速度とひきかえにBluebirdを用いると永続的でほぼ無限容量のRAMを持つかのように計算することができる。プログラムの動作の仕方は同じなので、"long sequence"オプション使用時のような問題も生じず、どんなに大きなゲノムでもOdysseyの全解析メソッドが適用できる。当然ながらRAMも同時に使えるので、Bluebirdでデータベースなど容量が膨大なものについてはリレーショナルデータベースを使い、計算の為には速度を重視してRAMを使う、といった用法が望ましい。

　リレーショナルデータベースはネットワーク上でデータベースサーバとなることが可能であり、インターネット経由でTCP/IPによる接続が出来る。これを利用すると、一つのリレーショナルデータベースをもととした、Bluebirdを介すGのプログラムは全て同一のRAMを持てる。これはデータグリッドなど分散コンピューティング環境において絶大な力を発揮する。そしてそのリレーショナルデータベース内部ではGプログラム利用者によって次々に結果が蓄積され、それがキャッシュとして使えるだけでなく、許可されているものに関しては利用及び改変することが可能で、またすぐにInspireと連動させてWeb上でデータを公開することもできる。

エキスパート向け説明

　Bluebird実装において鍵となるのがPerlのtie関数及びCPANのDBI, DBDモジュールである。DBIはPerlからデータベースやSQL構文に依存しない方法でデータベースにアクセスするインタフェースであり、使用するデータベースに対応するドライバ、DBDを入れ替えるだけで様々なリレーショナルデータベースを利用することができる。現在Bluebirdは速度を重視してmysqlをメインに使用している。そして、tie関数は参照や代入などといった変数に対する処理を明示的に決定できる仕組みを用意している。これにより単なる代入がデータベースへのアクセスになる、ということが実装可能になる。通常tie関数は構造体には適用できないが、Bluebirdでは最下層のポインタにその上層部のポインタを合わせて持たせた上で純粋にポインタだけからなる構造体を作ることで実現している。

　しかし、あまり大きくない構造体もしくは変数の場合、毎回リレーショナルデータベースへ問い合わせるのはかえって遅くなってしまう場合がある。そのような場合には永続性だけを利用し、リレーショナルデータベースから直にRAMにロードすることも可能である。この場合パースする必要がないのでフラットファイルから読み込むよりは速くロードできる。