Hibernate ValidatorやHibernate Searchなどの開発者であるEmmanuel Bernard氏は、Hibernate OGMの誕生を発表した。新しいフレームワークの目的はNoSQLデータストアにJPAを利用した共通のインターフェースを提供することである。OGMは、Object Grid Mappingの略である。
InfoQはEmmanuel Bernard氏と情報交換を行い、Hibernate OGMに関して、および、どのNoSQLデータストアをサポートする予定なのかを尋ねた。Emmanuel氏は、すでにチームが協力可能な状態にあることからInfinispanから取りかかるが、他も対応予定であると答えた。InfinispanとHibernate OGMはともにJBossが主導している。Infinispanはとっかかりとしてはよい選択である。なぜなら、Infinispanのトランザクションモデルはリレーショナルデータベースと似通っており、すぐにJPAに橋渡しできるからだ。
Hibernate OGMは誕生したばかりだが、すでに他のNoSQL実装をサポートする予定がある。たとえば、EhCacheチームは、Hibernate OGMプロバイダになる計画があり、必要に応じてHibernate OGMチームとともにHibernate OGMに機能拡張や抽象化を提供することになっている。MongoDBやCouchDB、Redis対応への貢献に興味がよせられているとEmmanuel氏は語った。氏は、これらのサポートがすぐに動き始めてくれることを願っている。氏は、他のプロジェクトや個人がキーバリューストアやドキュメント指向データベース、列指向データベース、グラフ指向データベースなどのサポートに殺到してくれるよう望んでいる。
InfinispanやCassandra、Voldemortのように、Apache Luceneのインデックスをデータストアに格納できるようにしよう。Hibernate OGM JP-QLエンジンの実装は、LuceneとHibernate Searchに依存しており、そうするとHibernate OGMの初期の適用はまた自然と思えてくる。これをサポートしていないNoSQLのサポートには問合せの実装に異なる戦略を利用する必要がある。
InfoQ: JPAとMySQLに詳しい開発者がHibernateOGMとInfinispanを利用するのはどれぐらい難しいものなのでしょうか。学習曲線はどのようになるでしょうか。
とても簡単ですよ！それが私たちの目的なのです。
プログラムモデルやその意味はそっくりそのままです。私たちはJPAのようなAPIに関して話をしているのではないのです。Hibernate OGMは完全なJPAエンジンです。私たちは既に、CRUD操作のマッピングのほとんどを既にサポートしています(エンティティ階層やアソシエーションなどを含めてです)。Hibernate Coreを利用してJAPアプリケーションをHibernate OGMを使ったものに変換する必要があるのであれば、次の手順を実行すればよいのです。
- アプリケーションにHibernate OGM jarと依存するjarを追加する
- persistence.xmlを編集し、プロバイダをHibernate OGMに変更してJDBC関連のプロパティを削除し(JDBCドライバや、スキーマ生成の方言など)、Infinispan設定ファイルへのポインタを追加する
- アプリケーションを実行する
persistence.xmlの変更前/変更後の例を参照してみてください。
たったこれだけです。今日の制限事項はJP-QLです。Alpha 2にはまだJP-QLサポートが含まれていません。次のバージョン(alpha3と呼んでいます)には、単純なJP-QL問合せのサポートが含まれるでしょう。しかしながらHibernate Searchに慣れ親しんでいるのであれば、すでに全文検索が利用可能なのです(まったく同じです)。
プロジェクトのすばらしいところは、JPAのCRUDサポートでHibernate Coreのほとんどの部分を再利用していることです。このことにより、エンジンがものすごく成熟したものになりました。JPA関連のバグが発生しない、もしくはHibernate Coreと同程度しか発生しないこととなるのです。
InfoQ: どのような場面でJPA/RDBMSを使うべきで、どのような場面でJPA/NoSQLを使うべきなのでしょうか。片方より他方を使うべき指針や、一連のユースケースのようなはあるのでしょうか。
私は答えをしっているふりをするつもりはありません。正直に言うと、業界全体として答えを探しているところなのです。そうはいっても、挑戦してみて恥をかいてみましょう。まず最初に、リレーショナルデータベースで、プロジェクトが満足しているのであれば、なんとしてもリレーショナルデータベースに固執するべきでしょう。NoSQLは、現在のリレーショナルデータベースエンジンが機能的に足りないような状況をカバーする全く異なった一連のツールなのです。グラフ指向DBは、グラフが関連するあらゆる問合せで力を発揮します(パリにすんでいる友達の友達の友達を調べる)。たとえば、データグリッドは、低レイテンシやトランザクションが重要であり、データのサイズが莫大でないときに使われます。BigTableのクローンはデータサイズが重要な際に適します(たとえば、大量のエントリと大量のデータなど)。
Emmanuel氏は、NoSQLソリューションの利用とJPAプログラムモデルの利用は直交(独立)していると付け加えた。JPAは、すべてのNoSQLユースケースに含まれているわけではない。ドメインモデルを利用するアプリケーションは、Hibernate OGMとの組み合わせがうまく機能するだろう。JPA/NoSQLの明確なユースケースは、リレーショナルデータベースの負荷を取り除くことだ。Hibernate OGMが開発者にNoSQLソリューションをためして、深く知るきっかけになれば、Hibernate OGMは成功したといえるだろう。
InfoQ: 近い将来にサポートされる予定の単純な問合せとはどういうものでしょうか。リレーショナルデータベースと大半のNoSQLストアの間で不一致な点があるなかで、JPAのどれぐらいの部分をサポートするのでしょうか。
旧来のリレーショナルデータベースとNoSQLストアの違いは、次の大きな2つのエリアに現れると私は考えます。
- トランザクションとリカバリモデルにおいて
- 関連するデータの格納(およびその後のアクセス)方法において
トランザクションの違いについていえば、Hibernate OGMはこれらの違いに取り組んで隠蔽をするべきではないと考えます。それよりも、根底にあるトランザクションモデルを受け入れて、ユーザがそれを意識するようにすべきだと思います。そうしないと、それぞれのNoSQLソリューションのよいところを損なってしまうことになりかねません。
永続化されるエンティティと関連はおそらく、対象となるデータストアごとに異なってくるだろうと氏は語った。氏は、JPAの関連モデルは多くのNoSQLデータストアに自然にフィットするだろうと考えている。質問の中にでてきた避けるべき不一致というのは、JPAでは真の問題とはならない。なぜならJPAは２つの関連するエンティティを異なるライフサイクルで管理することができ、ドキュメント指向モデルのような埋め込みオブジェクトや埋め込みオブジェクトのコレクションさえも扱うことができるからだ。Hibernate OGMでは、スキーマはドメインモデルにより管理されており、実際のオブジェクト構成とは無関係にし、スキーマレスのデータストアに適合させることができる。
InfoQ: Google App EngineのJPAサポートに対する共通の不満として、RDBMSシステムのJPAと比べて少し強制されていると感じるというものがあります。これはNoSQLに対するJPAに対しても同様でしょう。Hibernate OGMは、JPAとRDBMSに慣れ親しんでいる開発者にどれぐらい自然と感じてもらえるものでしょうか。また。開発者がGoogle App EngineのJPAサポートに対して抱く不満を目にされたことはありますか?
Google App EngineのJPAに対する不満は、BigTableストレージの制限とクエリエンジンの制限、GAE/Jチームの時間的制約が組み合わさったものだと考えています。GAE/Jチームはとても優秀で、彼らがやり遂げたことと比べてとても小さなチームです。すべてのことを優先して行うことはできないのです。
Hibernate OGMでは(現時点では)、サポートされない機能よりも、パフォーマンス上の制限（特定の状況での過度のキールックアップなど）の方が大きいです。もちろん、私たちの初期のJPA-QLサポートは完全とはほど遠いもので、しばらくの間は我慢していただく必要があります。私たちのゴールは、JPA開発者にとって自然なものになることです。そうはいっても、下層のNoSQLエンジンの機能や強みと反対の方向に進めることはできません。
InfoQ: Hibernate OGMは、SQLFireと比較してどういう特徴があるでしょうか。
その製品は詳細に知りませんので、詳細に立ち入らないことにしますが、もしポイントを述べないといけないのであれば次のような点でしょう。
- SQLFireはGemFireのためのもので、NoSQLに対して(もしくはデータグリッドのなかでさえも)汎用的なものではありません
- SQLFireはオープンソースではありません(ただそれだけです ;) )
Hibernate OGMとInfinispanに取り組んでいて、JDBCも同様にサポートするという考えも検討しました。これは、将来取り組むことになるでしょうが、JPAと、より面白いレベルの抽象化(関連エンティティと埋め込み可能なオブジェクトなど)を私は優先しています。Hibernate OGMを重複するデータの一貫性をたもつ非正規化エンジンとみることもできます。これは、調整役にとっての大きな成功であり、データアクセスパターンを最適化してれます。これは、リレーショナル層では自然に達成できないことです。
多くの開発者がHibernateとJPAを利用しているので、NoSQLサポートのHibernateフレームワークへの追加は自然に思える。Hibernate OGMはNoSQL実装へのインターフェースを統一することによって、NoSQLの採用をさらに推進していくことだろう。しかし、どのようにしてオブジェクトマッピングとJPA-QLを多様なNoSQL実装に対応させていくのだろうかという疑問は残っている。