3

データウェアハウスと相互作用し、分析を行うためにデータを取得するアプリケーションを開発しています。

この場合、データウェアハウスへの書き込みが非常に少なくなるため、Hibernateはパフォーマンスのオーバーヘッドになりますか。

意図は、ビジネス層とデータ層の間の結合を緩めることです。

この要件については、Spring JDBCはORMを使用するよりも理想的ですか？

4

4 に答える 4

2

さらに読み取るために、私は2番目にキャッシュ付きのSpringJDBCを使用します。最初にデータベースレベルでキャッシュを試してみますが、パフォーマンスが十分でない場合は、アプリケーションレベルのキャッシュに移行します。

于 2012-08-08T11:37:13.573 に答える
1

Hibernateは微調整されたSpringJDBCほど効率的ではないかもしれませんが、はるかに使いやすく、したがって生産性が向上します。さらに、それはおそらくあなたのアプリケーションのボトルネックにはならないでしょう！

セットアップはとても簡単なので、試してみて、時間を節約してください。これは、代わりにJDBCを使用して節約できる数ミリ秒よりもおそらく価値があります...

于 2012-08-08T07:43:49.470 に答える
1

ORMは、結果をオブジェクトとして実際に使用することを計画している場合にのみ役立ちます。パフォーマンスは、適切なキャッシュ（ehcache）の背後に配置すれば、JDBCと同等である必要があります。

于 2012-08-08T13:59:10.250 に答える
1

Hibernateは、ほとんどが読み取りアプリケーションの場合にパフォーマンスが向上します。次の理由でパフォーマンスの問題が発生する可能性があることに注意してください
。A。オブジェクトプロキシ
の多用B.SQL生成は適切かもしれませんが、最適化されていません-構成でshow_sql=trueプロパティをオンにすることを強くお勧めします休止状態のソリューションを使用する場合は、いくつかのベンチマークでSQL呼び出しを注意深く監視します。


Bを克服するには、Hibernateを介してストアドプロシージャを呼び出し、結果をオブジェクトにマッピングすることを検討してください（SQL生成ではなく、オブジェクトマッピングにHibernateを使用してください）。その意味で、Hibernateは動作においてSpring-JDBCに近づきます。
さらに、パフォーマンスを向上させるためにHibernateのキャッシングステートを使用することを検討してください-これがあなたのケースで可能かどうかはわかりません-a。クエリキャッシュ
b。第1レベルのキャッシュ（セッションスコープ）
c。第2レベルのキャッシュ-application-wisdeスコープ
では、適切な設計を行い、DALを可能な限り緩く結合することをお勧めします。これにより、Hibernateのパフォーマンスが低下した場合に、次のような他の代替手段に簡単に切り替えることができます。 Springとして-JDBC

于 2012-08-10T18:32:13.443 に答える