これまでにSpring Dataを使用したことはありませんが、MySQLベースのアプリケーションでHibernate ORMを何度も使用しました。 MongoDBベースのアプリケーションでどちらのフレームワークを選択すればよいのか理解できません。
答えを探してみましたが、実稼働環境で2つを比較する答えが見つかりません。 MongoDBでこれらの2つのフレームワークを操作するときに問題が見つかりましたか?
免責事項:私はSpring Dataプロジェクトのリーダーであるため、ここでは主にSpring Data側について説明します。
2つのプロジェクトの主な違いは、Hibernate OGMチームがJPAを中心に作業を集中することを選択したのに対し、Spring Dataチームは明示的にそうしなかったと思います。その理由は次のとおりです。
したがって、Spring Dataでは、サポートされているストアに一貫したprogramming modelを提供することを選択しましたが、すべてを単一の過度に抽象化したAPIに強制しようとしないでください。よく知られたテンプレート実装を取得すると、リポジトリの抽象化。すべてのストアで同じように機能しますが、ストア固有の機能と概念を活用しましょう。
免責事項:私はHibernate OGM開発者の1人なので、その背後にある理由のいくつかを提供しようと思います。
Hibernate OGMは、NoSQLソリューションにJava Persistence(JPA)サポートを提供します。HibernateORMのエンジンを再利用しますが、リレーショナルデータベースではなくNoSQLデータストアにエンティティを永続化します。特定のデータストア機能へのアクセスを提供することも目的としていますJPAがうまく適合しない場合。
このアプローチは、いくつかの理由で興味深いものです。
既知のセマンティックとAPI。 Java開発者はすでにJPAに慣れているため、低レベルのAPIを学ぶ必要はありません。また、HQLとネイティブバックエンドクエリの両方をサポートしています。
後期バックエンドの選択。適切なNoSQLデータストアを選択することは簡単ではありません。 Hibernate OGMを使用すると、特定のNoSQLソリューションにコミットする必要がなくなり、さまざまなバックエンドを簡単に切り替えてテストできます。
既存のツールとライブラリ。 JPAとHibernate ORMはしばらく使用されており、それらを使用するライブラリーとツールを再利用することができます。
ほとんどのJPA論理モデルが適合します。適切な適合の例は、@Embedded
、@EmbeddedCollection
および@Entity
(選択したデータストアに基づくノード、ドキュメント、またはキャッシュにすることができます)です。確かに、@Table
と@Column
も処理する必要があるため、注釈名は奇妙なものになる可能性があります。
JPAは永続性をオブジェクトレベルで抽象化し、多くのトリックと最適化の余地を残します。ポリグロットの永続化など、いくつかのアイデアが計画されています。複数のデータストアにデータを格納し、特定の読み取りジョブに最適なものを使用します。
主な欠点は、JPAの一部の概念(たとえばトランザクション)をNoSQLの世界に簡単にマッピングできないことです。トランザクションの境界設定メソッドにアクセスできますが、トランザクションをネイティブでサポートしていないデータストア(この場合、トランザクションは、操作をグループ化し、呼び出しの数を最適化するために使用されます)をロールバックすることはできませんdb)。
また、データセットが本質的に非ドメインモデル中心である場合、Hibernate OGMは適していません。
SpringDataを使用することができます。 Spring ORMでも、エンティティ、トランザクションなどのJPAのいくつかを使用していて、JPAおよびHibernate APIからの最適な組み合わせを提供していることを思い出してください。 JPAがNoSQLに対してさらに成熟した場合、Springコミュニティは将来のバージョンで対応する予定です。それが主な理由ではありませんが。ほとんどの理由は、@ Oliver Drotbohmによって説明されています。 SprinDataの詳細なドキュメントを読み、データモデル、データストアの継続性/成長のスケーラビリティをさらに分析し、ソリューションに最適なものを見つけ、@ Davideからの提案を検討してください。多くの場合、SpringDataは、MongoDBと統合しながら、JPAよりも成功率が高くなっています。