いくつかの新しい機能を搭載したRavenDB 2.0がリリースされた。InfoQはRavenDBの創設者でありプロジェクトリードであるOren Eini氏 (Ayende Rahien)に独占インタビューを行い、プロジェクトの背後で下されたさまざまな意思決定の根拠や今後の計画について話を聞いた。
2009年にRavenDBプロジェクトが始まったとき、Erlang上に構築するという選択肢があった。しかし、最終的にチームは既存の経験が生かせ、多くのライブラリが利用でき、企業分野での普及している.NET上で実装することにした。
私たちは.NETがまだ1.0のアルファ版だったころから使っていました。慣れ親しんだ環境で使いやすく、データベースを実装するのに必要な性能や信頼性、安定性、開発しやすさが手に入れられる環境です。
また、既存のエコシステムと簡単かつしっかりと統合できるものが欲しかったのです。つまり、すでにしっかりと確立された基盤の上に構築できることです。こうすることで私たちはクライアントサイドには優れた.NET統合を提供し、サーバサイドは簡単に拡張し監視しカスタマイズできるようにしました。
Erlangのライブラリの種類は限られています。またある種の作業を行うのは難しいです。とりわけ、CLRの豊かな環境と比べてしまうとErlangは不毛の地です。簡単には結論を出せませんでした。結論を出す前にCouchDBのコードベース全体を調べ、どうなっているか把握しようとしました(そして、その時点はCouchDBはナチュラルなErlangの使い方をしていないと気づきました)。
たとえば、RavenDBはLuceneや空間ライブラリのような既にCLR向けに存在しているライブラリを利用できます。同じようなライブラリが存在していたとしても、Erlangで同ことをするのは難しいです。
しかし、最終的には専門知識の問題でした。私たちはCLRを手なずけ、転がし、死んだふりを暴く方法を知っています。
.NETを選択したのはよかったようだ。RavenDBは今やOhlohですべてのプロジェクトチームの上位2%内に位置している。
RavenDBの利点のひとつは、ほかのいくつかのNoSQLとは違いACIDを保証することだ。
多くのNoSQLは今、70年代にDB屋にとって明らかになったことを学んでいると思います。つまり、トランザクションなしではつらいということです。トランザクションに依存することができないと、自分のコードでトランザクションを管理しようとしなければならず、データが汚染されたり複雑な部分が大量にが生まれたりします。
確かに、トランザクションはシンプルではありません。正確にかつ高性能になるように記述しなければなりません。しかし、ほかに良い方法はありません。ビジネスソフトウエアの開発者が(頭を悩ませるほかの問題に加えて)トランザクションを保証するように実装するのは荷が重過ぎます。
私自身、時々アプリケーション開発者として働きますが、トランザクションを手放すつもりはありません。したがってRavenDBはトランザクションを保証することをひとつの主要な約束事にしています。完全にACIDを保証します。
RavenDBはバンドルベースアーキテクチャを採用している。小さなコア部分が開発者によって拡張できるようになっている。Oren氏の説明では、RavenDBチームがリリースしている多くの機能も最初は利用するかどうか選択できる機能パックとしてリリースされた。こうすることで大きな新機能を混乱することなく簡単に提供することができる。また、開発者は独自の拡張を作ることもできる。拡張方法も簡単で、ある拡張ポイントを継承して、コードをコンパイルし、生成されたDLLをプラグインフォルダに配置するだけだ。
来年はどのような計画を立てているのだろうか。
WinRTからAndroid、iPhone、JVMまでクライアントの数を増やしたいです。また、RavenDBノードの大規模なクラスタを管理するシステムについても計画中です。RavenDBから直接レポート出力するというアイディアも検討しています。しかし、これは実験的で最終的な成果は生まれないかもしれません。私たちが取り組もうとしているもっとも重要なことは索引管理とクエリオプティマイザの改善であり、実運用向けのRavenDBの自動チューニング方法の改善です。
RavenDBはデュアルライセンスポリシーを採用している。非OSS(商用)プロジェクトの場合はサブスクリプションで提供される。また、RavenHQやCloudBirdのようなプロバイダはRavenDBをサービスとして提供している。