MongoDB に Java ORM を使用する場合のオーバーヘッドはどれくらいですか? または、基本的なドライバー レベルで読み取りまたは書き込みを行ったほうがよいでしょうか?
要件の 1 つとして Mongo DB を追加します。
java
-morphia
-spring-data
-その他の Java ORM マッピング ツールがいくつかあります。
Morphia の最新バージョンは 1 年以上前にリリースされました
が、Spring のデータは積極的に維持されています。これから始めるならどれを使えばいいのか、
ORM を使用するとパフォーマンスは低下しますが、開発はスピードアップします。ここにはトレードオフがあります。
ORM ツールでは Morphia が最も安定しています。ここでは、Morphia と Basic Mongo Driver のパフォーマンスの比較を確認できます。
Morphia は、最も多くの機能を備え、活発なコミュニティを持っているため、最も適していると思われます。比較については、このリンクを参照してください: MongoDB の Morphia、Mongo4j、Spring データの比較は?
ここでは、一般的に言及すべきことがかなりあります。MongoDB のセットアップもテストせずにパフォーマンスを実際にテストすることはできないため、そのためのベンチマークを考え出すことは非常に困難です。したがって、必要な結果を提供するために、環境を微調整して調整することができます。
さらに、読み取りと書き込みのパフォーマンスを区別する必要があります。特に書き込みはWriteConcern中古の影響を大きく受けます。したがって、WriteConcern.NONEシナリオで 50% のオーバーヘッドになる可能性があるものは、WriteConcern.SAFE.
DBObjectはい、Object <->マッピングは通常、リフレクションを介してオブジェクトの get 値と set 値を検査する必要があるため、ODM 実装には確実にオーバーヘッドがあります。したがって、重要な点は、パフォーマンスが重要なオブジェクトに提供する必要があるカスタムの手動でコーディングされたコンバーターをプラグインする機能です。Spring Dataの場合、デフォルトのカスタムにリフレクション マジックを実行させるのEntityInstantiatorではなく、実行するカスタムを登録するだけで、パフォーマンスが大幅に向上します。new Person(…)
Spring Data チームは、さまざまな に対する書き込み、プレーン ドライバー、およびリポジトリの抽象化による読み取りのために、OTS MongoDB インスタンスのパフォーマンスを重み付けするビルドをセットアップしました。数値は、リポジトリがテンプレートよりも速くデータを読み取ることを示す場合があるため、数字は慎重に検討する必要があります。これは、インフラストラクチャによって影響を受ける必要があります。キャッシングを追加します。WriteConcernMongoTemplate