CouchDBの開発会社であるCloudant が CouchDB用の Java View Server をごく最近、リリースした。その意味は、Map-Reduce のジョブを書くのに、Erlang と Javascript やPythonのような インタープリタ言語 だけではなく、JVMベースの言語でも使える、ということである。そのアプローチは、今週の CouchDBコミュニティの会議で議論されるだろう。現在は、CloudantでホストされるBigCouchサービスだけで使われている。
彼らの言う一番の利点は、 Map、Reduceタスクに関連するあらゆる機能に使える、Javaの膨大なライブラリである。2番目の利点は、もっと信頼のできる静的な型チェックの面である（しかし、これは、証明が必要である）。
パフォーマンス比較も面白いだろうが、今までのところ、ベンチマークは、実行されていない。パフォーマンスは、ネイティブのErlang Viewよりも遅い、と思われる（Viewの中に Java とErlangは、混在できる）。 org.json ライブラリを使った JSONシリアライズとデシリアライズによるいくらかのオーバーヘッドがある。
Javaベースの Map Reduce を使うために、Viewは、 map, reduce そして rereduceに対するコールバックを提供する、単純な JavaView Interface を実装しているだけである。例えば、言葉を集める単純なviewは、configureされたJSONフィールドに何回その言葉が出てくるかを数える。
{
"_id":"_design/splittext",
"language":"java",
"views" : {
"title" : {"map":"{\"classname\":\"com.cloudant.javaviews.SplitText\",\"configure\":\"title\"}","reduce":"com.cloudant.javaviews.SplitText"},
}
}
InfoQは、 このプロジェクトの責任者で、CloudantのSearch部門のDirector である David Hardtke氏と話した。
InfoQ: Erlang上で走る CouchDBは、どのようにJVM コードとやりとりするのですか？実装で大変だったのは、何でしたか？
David: すべての CouchDB viewサーバ（ネイティブなErlangは、別にして）のように、 Java View Serverは、外部プロセスとして走ります。 CouchDB と viewサーバ間のコミュニケーションについては、よく定義されたプロトコル があります。通常、コミュニケーションは、標準IOを介して行われますが、我々は、実際のところ、パフォーマンスの理由で（マルチスレッドが使える）、OtpErlangのjava-erlang Libraryを使っています。
InfoQ: このコンテキストで使うことができるコード／ライブラリに、何か制限があるのですか？
David:一番大変なのは、セキュリティでした、システム レベルとユーザ データのレベルからの両方ですね。我々は、共有されるクラスタ上で、これを走らせています。ユーザ ライブラリをロードするのに、動的なクラス ローディングを使っています。クラス ローダは、悪意のある呼び出しを制限するために、相当厳重なセキュリティ マネージャを配置しています。
viewサーバーの現在のアーキテクチャは、非常に単純で、ErlangベースのCouchDB インスタンスからの呼び出しで動く、Javaスレッディングを使っているだけです。もしJavaサーバーがフェイルしたら、シャットダウンして、リスタートするだけです。そのようなサーバーに対する面白いアプローチは、ScalaベースのAkka framework や Jettyの ノン・ブロッキング リクエストを使うことでしょう。Java View Serverは、どのJVM上でも動きます。
すばらしい潜在力がJavaの次の言語には、あります。例えば、Clojure, Scala あるいは Groovy（また別の言語）をこのような開発に使えば、そのようなタスクを表現するのにJavaより、ずっと短く、そして強力です。David氏によると、Clojureベースのviewサーバは、他の組織によって開発中とのことである。
新しい Java View Serverを評価するために、Cloudantのサイトで無料のアカウントを使うことができる。詳しい手順が couchjava github レポジトリにある。