NeverBlockおよび非ブロッキングデータベースアダプター

作者 Mirko Stocker, 翻訳者 編集部 投稿日 2008年9月10日 午前6時23分

コミュニティ

Ruby

トピック

Ruby on Rails,

データアクセス

タグ

データベース,

Parallel Programming,

MySQL,

Ruby1.9,

SQLite,

Oracle

NeverBlock(リンク)はライブラリであり、Ruby 1.9ファイバーを使用し、非ブロッキングコードの記述を可能にする。NeverBlockから得られる最初のデータベースは、Postgresであった(FibersおよびNeverBlockのInfoQ掲載記事参照)(参考記事・英語)。数日経過した今、NeverBlockは、新たなMySQLPlusドライバーを使用しMySQLに対するサポートについても追加した。MySQLPlusは元のRuby MySQLドライバーの上部にビルドする。しかし非同期のクエリー処理サポートやスレッデッドアクセスサポートを追加する。

また、Asymy(リンク)と呼ばれるRubyのMySQL接続へ非同期操作をもたらすことを目指している、他のプロジェクトもある。InfoQは、 MySQLPlusに関わったRoger Pack氏に話を聞いた。われわれはMySQLPlusおよびAsymy間の相違と、新たにアダプターを作成した理由に特に関心があった。

 

 

 

 

 

 

 

まずは、これまでの経緯についてです。かつての最先端技術はC MySQL libであり、あらゆるクエリーをブロックしました。両者とも、その点を克服しようとしています。

まずは、これまでの経緯についてです。かつての最先端技術はC MySQL libであり、あらゆるクエリーをブロックしました。両者とも、その点を克服しようとしています。

Asymyは、純粋なRuby非同期MySQLアダプターです。Rubyで記述されているので、構文解析はかなり遅く(約10分の1の速度)、また比較的新しい製品なので、まだバグが潜んでいます。

両者の相違は、Asymyはイベント駆動「専用」である一方、MySQLPlusはスレッドやイベント駆動で動作すると言ってもよいでしょう。クエリーが 読み出されている間IOをいつ待機すべきかを実際に検出することができないため、そのイベント駆動の側面は多少制限されています。ですからまだ完璧ではあ りません。しかし正しい方向への一歩でしょう。

実際、われわれはAsymyを開始し、Muhammed(Ali氏、NeverBlockを支えている人の1人)(リンク)が、ちょっとした修正のみで標準C MySql libがマルチスレッドとほぼ同等の生産をすることを見出したので、それに切り替えました。MySQLPlusライブラリは、Tomita Masahiro氏のライブラリ(リンク)に対する多少の変更です。

ですから、そこにはある種の重複があると考えます。大抵はC対Rubyの疑問のようなもので、われわれはCを記述しなかったので、重複はありませんでした。

NeverBlockが現在MySQLPlusで動作するように、それもEvent Machineで動作するのか?

 

 

基本的にNeverBlockは、Fibers、EventMachineおよびPostgresまたはMySQLPlus driversが組み合わさったものです。それにパッチを当てる場合(リンク)、その答えはイエスです。 EventMachineスタイルの段階的なプログラミングをする場合、1.8.xでさえも動作します。

1.8.x MySQLドライバーの代わりにスレッドフレンドリードロップとして、すでにMySQLPlusは機能していることに、注意してください。また、たまたまNeverBlockおよび1.9と動作していますが、それは元々の目標でした。

そのプロジェクトの今後の計画についてはどうか?その他のデータベースについても採用する予定があるのか?

 

 

Muhammed氏は、 その可能性を述べました。これまでにかなり取り上げてきたので、その予定はありません。

今後の計画は、rails 2.2をNeverBlockやMySQLPlusと動作させることであり、願わくは良いパフォーマンス結果が得られると良いと思います。

またMySQLPlusは、MySQLPlusの共著者の1人であるAman Gupta氏の手により開発された、完全に非同期なEvent Machine MySQLクライアント(リンク)で使用される。

当然ながら、PostgresおよびMySQLはRubyで使用される唯一のデータベースではない。そこでruby-oci8の著者であるKUBO Takehiro氏に話を聞いた。ruby-oci8(リンク)はOracleデータベースのインターフェイスである。NeverBlockに対する意見およびruby-oci8との統合は容易かどうかについて尋ねた。

 

 

 

わたしの意見では、簡単ではないと思います。Neverblock-pgはPGconn#send_queryを使用してクエリーを発行し、クエリーが完 了するまでファイバーを一時停止します。しかし、ruby-oci8の非ブロッキングモードは異なります。クエリーが実行されると、非ブロッキングモード のruby-oci8は結果を待機しますが、他のスレッドをブロックしない。ruby-oci8外には、ファイバーをサスペンドするためにコードを追加す る場所はありません。しかし、ruby-oci8を修正して NeverBlockを導入しようとは考えていません。なぜなら、NeverBlockファイバープールを使用せずに、ユーザが非ブロッキング操作を明快に使用することができるからです。

また、非ブロッキング操作にNeverBlockが 必須なのかどうか分かりません。rb_thread_blocking_region() (ruby 1.9の新機能)によって、ruby-pgがブロッキング操作をラップする場合、他のスレッドはブロックしません(The Futures of Ruby Threadingを参照)(参考記事・英語)。

わたしがこれまで述べてきたことにもかかわらず、ActiveRecordアダプターへ接続プール機能を追加しようとする取り組みは、ありがたく思います。まさにわたしが望んでいるものです。

非同期のインターフェイスをSQLiteへ実装することは筋が通っているかどうか、sqlite3-rubyアダプター(リンク)の責任者であるJamis Buckis氏にも話を聞いた。

 

 

正直に言うと、それほどでもありません。SQLiteは組み込みデータベースであり、MySQLやPostgreSQLのようなクライアント/サーバモデ ルではありません。SQLiteへの非同期クエリーをサポートするためには、アプリケーションとは別のプロセスで実行できるように、まずそれをサーバへ変 換する必要があり、それが完了するまでにはもはやsqliteを使用する理由がまったくないと思うことでしょう。

稼動Web環境においてSQLiteを使用しないことを強く勧めたいと思います。テストや開発にとって、大変すばらしいです。また組み込みアプリケーションでもうまく動作します。しかし、Web環境ではクライアント/サーバモデルとほぼ同様に動作しません。

どう思うか?より良いパフォーマンスには、非ブロッキングデータベースアクセスは必要なのか?

原文はこちらです：http://www.infoq.com/news/2008/09/non-blocking-database-adapters

• 次へ >