JSR-347はデータグリッドの仕様だ。このJSRの誕生には、JSR-107のJCacheと比較して、どのように使うのかについて論争があり混乱が伴っていた。InfoQはManik Surtani氏に、JSR 347とJSR 107について話を聞いた。また、キャッシングやNoSQL、データグリッド、Infinispanや関連する話題にも話が及んだ。
氏はJSR-347の仕様策定を主導しており、JBoss CacheとJBoss Infinispanのコミッタとメンテナを長い間務めている。JBoss CacheとJBoss Infinispanはそれぞれ、代表的なオープンソースのキャッシュシステムでありデータグリッドだ。Infinispanデータグリッドプロジェクトが発表されたのは2009年の4月だ。氏はこの発表の少なくとも4ヶ月前からデータグリッドのプロトタイプを作っていた。InfinispanはJSR 347に着想を与え、現在のJSR 347に提案された特徴の多くはInfinispanから得ている。
InfoQ:JSR 347の目的は何ですか。JSR 107との違いは何ですか。
JSR 347はJavaプラットフォーム向けのデータグリッドとしても知られていますが、APIとプログラミングモデル、そしてフォルトトレラントなインメモリの分散キーバリューストアの振る舞いについて標準化するために提案されたものです。JSR 107 (Javaプラットフォーム向け一時キャッシュ)との違いはたくさんあります。
- データの永続性。JSR 347はレコードの保存機構であり、本質的な分散の仕組みによって耐久性を提供します。一方、JSR 107は一時的で揮発性の高いデータを保存する前提の仕様です。
- 分散。JSR 107の実装は分散化されていてもかまいません。一方、JSR 347の実装は分散化されていなければなりません。従って、JSR 347の方がデータストアの使い勝手を向上させるためにより機能豊富なAPIを提供します。例えば、グリッド上のデータの保存場所を制御するAPIや非同期のノンブロッキングAPI、実装の一貫性をサポートするAPIは、実装が分散化されているということを知っていなければ意味がありません。
- Map/Reduceと分散コード実行。データがグリッド上に分散/パーティションされている場合、コードの実行をデータ側に移動させた方が他の方法よりも合理的な場合があります。JSR 347はこのようなことを実現するAPIも提供する予定です。
InfoQ:JSR 347を実装することを約束したベンダを教えてください。GemfireとCoherenceがJSR-347にまだ関わっていないのはなぜですか。
これまで、専門部会にはRed Hat、Gigaspaces、GridGainが参加していました。OracleとIBMとは正式に契約する前で法務上の確認をしているところです。すでに両社とも興味を示しています。
氏はOracle CoherenceチームがJSR 347に関わってくれることを希望していると話した。彼らは興味を示しており、正式に契約する前の内部の手続きを待っているところだ。また氏はJSR 347チームはGemfireを連絡しているが、まだ返信をもらえていないと話した。
InfoQ:JBoss Cacheはどのように発展してきましたか。JBoss CacheがInfinispanへと発展した経緯を教えてください。
JBoss CacheはJBoss Application Serverで利用するクラスタリングの仕組みです。HTTPとEJBのセッションのクラスタリングとトランザクションがあるHibernate/JPAの第二レベルのキャッシュに利用できます。
氏は開発者がJBoss Cacheを永続化するデータを保管するデータグリッドとして使い始めたことを説明した。しかし、JBoss Cacheはデータグリッド用に設計されていない。そこでInfinispanを作ったのだ。Infinispanはクラスタリングの仕組みとしてJBoss Cacheを置き換え、より強力なデータグリッド機構を提供する。
InfoQ:JBossのユーザがまずはセッションのレプリケーションのような機能のためInfinispanを使うと考えた場合、どのくらいのJBossユーザがそこから進んでInfinispanのデータグリッド機能を使うようになると思いますか。JSRで定義されたキャッシュや分散キャッシュ用の標準的なインターフェイスが(まだ)ないことを考えた場合、どのくらいのJBossユーザがInfinispanの分散キャッシュやデータグリッドの機能を使うと思いますか。
難しい質問ですね。JBossアプリケーションサーバもInfinispanもオープンソースプロジェクトであり、コミュニティの内部でなにが行われているのか、Infinispanとどのように関わっているのか正確には分かりません。ユーザフォーラムやIRCの情報を元に考えると、大多数の人がJBossに配置したウェブアプリケーションやEJBからInfinispanへ直接アクセスするためのAPIについて質問しています。質問をする人だけでそのくらいいるのです。
InfoQ:データグリッドソリューションの定義するのはとのような特徴でしょうか。クエリ、トランザクション、リードスルーキャッシュ、ライトビハインドキャッシュ、データシャーディング、データレプリケーション、Map/Reduceなど様々な特徴があります。データグリッドがサポートしなければならない機能はなんですか。
これは私の主観的な考えですが、データグリッドには、トランザクション、リードスルー、ライトスルー、ライトビハインド、そして何らかのパーティショニングやシャーディング、そしてリスナが必要だと思います。クエリとMap/Reduceはもっと先進的な機能ですが、早晩誰もがデータグリッドの機能として期待するものになるでしょう。なので、このふたつも必要なものだと思います。
InfoQ:InfinispanのMap/Reduceはどのようなものになりますか。これがJava開発者にとって重要なのはなぜですか。
Map/reduceはたくさんのサーバデータを分散して処理する場合、重要なコンセプトになります。この方法はネットワークトラフィックを最小にしながら、多くのCPUを利用できるのです。
InfinispanのMap/ReduceのコンセプトはGoogleの研究を取り入れていますが、実装は流れるようなインターフェースや人間が読める、直感的に理解できるインターフェイスのような設計原則、そして、現代のJavaの一般的なベストプラクティスに従います。HadoopのようなJavaの他のMap/Reduceの実装とは違い、Infinispanの実装は遥かに直感的で開発者に優しいと思います。
InfoQ:InfinispanはJSR 347のリファレンス実装になるのですか。
いいえ。リファレンス実装はApacheライセンスにしなければなりませんが、InfinispanはLGPLライセンスです。
InfoQ:InfinispanはMemcached Text Wireプロトコルをサポートしていますが、なぜですか。
非Java環境でも受け入れられるようにするためMemcached Text Wireプロトコルをサポートしました。Memcachedにはたくさんのプロトコルがあり、ほとんどのプラットフォームに対応しています。Memcached Text Wireプロトコルをサポートをサポートしたので、どんなプラットフォームでもInfinispanが使えるようになりました。
その後、Memcached Wireプロトコルの代替として、Hot Rodも実装しました。そして、Javaの"参照"クライアントを実装した後、コミュニティがPythonとRubyのHot Rodクライアントを実装したことを知りました。
氏は続けて、Memcachedのプロトコルはデータグリッドソリューションにはシンプルすぎる、リクエスト/レスポンススタイルのクライアント/サーバそのものだからだ、と言う。逆に、Hot Rodを使えば、サーバはクライアントに接続してクライアントへバックエンドのトポロジ変化をプッシュする。この仕組みは柔軟性を確保するために重要だ。そして、こっそりとグリッドの新しいノードを追加することもできる。氏が言うにはHot Rodの将来のバージョンではイベントの仕組みがあり、この仕組みが新しいチャンスを作るという。分散キャッシュ向けのMemcachedワイヤプロトコルもあるが、Hot Rodがデファクトのデータグリッド向けの標準的なワイヤプロトコルになりそうだ。
InfoQ:JSR 347やInfinispanをOracle Coherence、Enterprise EhCacheやVMWare Gemfireと比べるとどうですか。
あなたの挙げた製品にはJSR 347で計画されている特徴がすべて盛り込まれています。最も大きな違いはAPIです。もちろん、他の製品がすべてを包摂しているわけではありません。Map/Reduceのように実装されていない機能もあります。しかし、どの製品も足りない機能を追加できるように構成しているはずです。
InfoQ:JSR 347やInfinispanはNoSQLソリューションの仕様やNoSQLソリューションそのものなのでしょうか。NoSQLソリューションでないとするならどのような機能が足りていないのでしょうか。
JSR 347は標準です。しかし、NoSQLではなくデータグリッドの標準です。一方、InfinispanはJSR 347の実装であり、従って、データグリッドです。しかし、NoSQLのような機能を追加しようとしています。NoSQLとデータグリッドの違いは徐々に小さくなっていくと思います。
氏の説明によれば、JSR-347はJavaに特化しない本格的なNoSQLの仕様の前身だという。
大きな違いはプラットフォームに対する独立性です。JSR-347はJavaの仕様ですが、多くのNoSQLデータベースはJava以外でも利用できます。
InfoQ:クエリはJSR-347の一部ですか。
これは専門部会で決定するべき事案です。
InfoQ:データグリッドやNoSQL、オブジェクトキャッシュをどのように捉えていますか。
オブジェクトキャッシュは一時的なインメモリのオブジェクト保存場所で、検索するには高コストで計算も難しい。一方、データグリッドは柔軟で分散化されているという特徴のおかげで、ある程度の耐久性を提供しオブジェクトキャッシュよりも一歩進んだ機能を提供します。NoSQLのアプローチは違います。少なくとも分散NoSQLエンジンの場合は、ディスクをプライマリのストレージエンジンとして使用しながら、柔軟性と拡張性を提供します。
InfoQ:NoSQLの実装で最も重要な特徴はなんですか。
私は柔軟な拡張性が最重要だと思います。柔軟な拡張性がないのなら、RDBMSを使い、遥かに慣れ親しんだセットアップや利用方法の利点を享受したほうがいいでしょう。
InfoQ:Inifinispanと(Coherence、Enterprise、EhCache、GemFire)との設計上の違いは何でしょうか。
プロプライエタリな製品の内部設計はどうなっているかわかりません。
InfoQ:Inifinispanの設計思想を教えてください。
接続可能性と拡張性が鍵です。私たちが事前に提示した使い方に従うだけではなく、ユーザ自身がInfinispanを使ってどんなことでもできるようにしたいと思っています。インタセプタやコマンド、振る舞いの追加でき、オープンソースで、コードと設計の透過性がInfinispanの拡張に役に立てばいいと思います。
氏はInfinispanとJSR 347についてさらに詳しく知る方法を教えてくれた。来週にはInfinispan 5.1.0のベータ版がリリースされるそうだ。JSR 347 WikiはJSR 347がどこへ向かっているのかを知ることができるサイトだ。Inifinispan とCDI統合についての動画もある。これを見れば仕様に何が含まれるのか分かるかもしれない。また、Infinispan Mavenアーキタイプを使えば、一気にプロジェクトを開始してJSR 347に何が含まれるか探ることもできる。