3

JCR または RDBMSについて調査し、他の投稿を読んだ後、ドキュメント管理システムに JPA ではなく JCR を使用するかどうかまだ確信が持てません。ユーザー。

私が JCR を検討する主な理由は、ドキュメントがコンテンツのように見えるためです。また、仕様は、それに付随するいくつかの問題にすでに対処しています。主に、ストレージとバージョン管理に関心があります。また、ドキュメントを JCR 実装内にカプセル化し、アプリケーション固有の他のすべてに JPA を使用したいと考えています。

多分誰かが私の残りの質問で私を助けることができます:

  • JCR の読み取り/クエリのパフォーマンスは JPA とどのように関連していますか (実装によって大きく異なることはわかっていますが、いくつかの経験則があるかもしれません)。
  • いくつかの特定の JCR 実装を使用した同様のユースケースで、実際の経験を持っている人はいますか? もしそうなら、それをリレーショナル データベース (JPA) と混ぜましたか?
  • ファイルストレージとバージョン管理の利点を考慮して、JCR を導入するオーバーヘッドに見合う価値はありますか? (私は独自のカスタム使用アクセス制御 (JPA) に行く可能性が高く、実行時に新しいノード プロパティを導入するための特別な柔軟性は必要ありません)
  • データの整合性とバックアップ ソリューションについて経験のある人はいますか?

更新: この質問は詳細に回答されていますが、誰かがより実用的な観点からその使用についてより批判的な見方をしている可能性があります。個人的には、次の技術的に関係のない問題についてますます懸念を抱いています。

  1. ドキュメンテーション: Jackrabbit のドキュメンテーションは貧弱です。OCM のガイドには最初の段落にデッド リンクが含まれています。いくつかの検索クエリの例では、不明な理由で例外がスローされます。非常に基本的なチュートリアルにTODOがあり、スタンドアロン サーバーが JDK8 内で適切に動作していません。はまったく文書化されていません。
  2. 成熟度: Jackrabbit Oak はまだ進行中のようであり、他のソリューションは放棄されているか、最先端にあるように見えます。
  3. コミュニティ: JPA とは対照的に、JCR の調査を行うと、ヒット数が大幅に減少します。これは、テクノロジーに不慣れなプロジェクト チームが (些細な) 問題に行き詰った場合に、実際の問題になる可能性があります。
4

1 に答える 1

5

短いバージョン: ドキュメントは構造化または半構造化されたコンテンツです。これは、階層的に編成されたデータ ストレージのユース ケースです。すべての基本的な dms/cms を自分で実装したくない場合は、JCR を使用する必要があります (これを考慮してください。おそらく、彼らが常に実行している間に、初めて実行することになります)。

詳細バージョン: JCR は、バージョン管理、ロック、ライフサイクル管理、参照整合性など、ドキュメントまたはコンテンツ管理システムの基本的なユース ケースの多くを仕様別にカバーしています。さらに、スキーマを変更せずにデータを拡張できます (もちろん、モデルでノード タイプを定義できますが、そうする必要はありません)。ほとんどの JCR 実装 (Jackrabbit など) は、バックエンドでデータベースを使用して、リレーショナル バックエンド上の抽象化レイヤーよりも "少し" 大きくします。大規模なデータを処理するには、データベースに構造化データ (ノードとプロパティ) を保存しながら、ファイルシステム ストレージ (すべてのバイナリ データをデータベースに保存するよりもはるかに高速) を使用できます。

JPA を使用する場合、この dms/cms のすべてを自分で処理する必要があります。もちろん、それを行うこともできますが、JCR 実装で既に行われているのは、はるかに低レベルのプログラミングです。すべてのモデルの変更にはスキーマの変更が必要であり、テーブルのレイアウトはそれほど簡単ではありません (すべてのプロパティが列であるドキュメント用の大きなテーブルが必要ですか? ドキュメント クラスごとに個別のテーブルが必要ですか? どのようにライフサイクルをモデル化しますか? バージョン管理をどのようにモデル化しますか?)

JCR での最初のホップについては、David のモデルをお勧めします。アプリケーションのすべてをコンテンツと見なしてください。私は、JCR と JPA の組み合わせに反対することを決定したプロジェクトで働いていたので、ストレージ用のさまざまな API を扱う必要はありませんでした。

そして、少なくともいくつかの JCR 実装があります。

  • Jackrabbit 2 (参照実装、読み取り操作用に最適化、現在メンテナンス モード)
  • Jackrabbit OAK (読み取り/書き込みパフォーマンスのバランスがとれた、スケーラブルなコンテンツ リポジトリを目指しています。Jackrabbit と同じコア チームによるものです)
  • Jackrabbit FileVault (純粋にファイルシステム上のバックエンド)
  • Modeshape (代替実装、高速でスケーラブル、REST API を使用、非常に優れたドキュメント)

ところで。JCR API と実装は、ほとんど RESTful アーキテクチャーを念頭に置いて行われています。したがって、REST API を検討すると、マッピングもかなり単純になります。さらに、消費者は JCR API を介してコンテンツを直接探索できるため、コンテンツを他のアプリケーション (つまり読み取り専用) に簡単に統合できますが、JPA を使用してデータベースの内部設計を明らかにする必要があり、消費者の契約が破られる可能性が高くなります。変更について。

残りの質問について:

  • 比較チャートはありません。いつものように、データ構造とインデックス、およびクエリの設計に依存します。JCR 実装にはキャッシュが組み込まれており、通常は結果セットを反復処理しています。したがって、高速/低速に関する一般的な声明はありません。すべてはユースケースに依存します。
  • 私も同様のことを行い、Jackrabbit の実装には満足していましたが、JDK7 を使用していました。リポジトリにはすべてのデータ (ユーザー設定、アプリケーション設定などを含む) があり、JPA の永続性はまったくありませんでした。必要に応じて、オブジェクト コンテンツ マッピングも利用できます。
  • はい、紹介する価値があります。Jackrabbit には独自のユーザー管理機能があり、自分で実装する必要はありません。また、JCR API および JAAS を介してアクセス制御を利用できます。ただし、JCA ResourceAdapter は Jackrabbit API を公開しないため、ユーザー管理とアクセス制御の管理に JCA ResourceAdapter を使用しないことをお勧めします。
  • データの整合性とバックアップに関する問題は、JCR や JPA にとって特別なものではありません。どちらも、あるレベルで整合性を保証し (データベースの整合性、JCR は参照整合性を実行します)、両方をバックアップできます (db バックアップ、fs バックアップ)。どちらも標準化されたデータ アクセス方法であるため、独自のバックアップ ロジックを実行することもできます。
于 2015-06-15T19:31:10.667 に答える