JDBC/Hibernate Fetchサイズとメモリの問題

Question

私は作業中のアプリケーションがデフォルトのフェッチサイズを使用していることに気づきました。問題は、大部分の場合、ユーザーが大量のデータ（数千から数十万に及ぶ）をフェッチし、デフォルトの10が実際には大きなボトルネックになっていることです。

したがって、ここでの明白な結論は、フェッチサイズを大きくすることです。最初は、デフォルト値を100に設定し、いくつかのクエリで1000に設定することを考えていました。しかし、ネット上では、メモリの問題を防ぐためにデフォルト値が小さすぎる（つまり、JVMヒープがそれほど多くのデータを処理できない場合）、私はそれについて心配すべきでしょうか？

これ以上の説明はありません。結果セットをフェッチしている間にフェッチサイズが大きくなるとオーバーヘッドが増えることを意味しますか？あるいは、デフォルトでは10レコードをフェッチしてGCをGCして別の10などをフェッチすることができます（一方で10000を一度にフェッチするとOutOfMemory例外が発生します）。このような場合は、とにかくメモリ内のすべてのレコードが必要なので、私は本当に気にしません。前者の場合（結果セットが大きければメモリのオーバーヘッドが大きくなります）、まずテストをロードする必要があります。

Answer 1

フェッチサイズも大きく設定すると、はとなり、OutOfMemoryErrorになります。

これらのすべてが必要な事実は、とにかくのレコードはおそらく正当ではありません。より多くの機会にエンティティが返されました。ResultSet s ...フェッチサイズを10000に設定すると、JDBCクラスで表される10000レコードがヒープされます。もちろん、あなたはこれらをあなたのアプリケーションを通して渡すことはありません。最初にそれらをお気に入りのビジネスロジックエンティティに変換し、ビジネスロジック実行者に渡します。この方法では、JDBCが次のフェッチ・バルクをフェッチするとすぐに、最初のフェッチ・バルクからのレコードをGCで使用できます。

通常、この変換は前述のメモリの脅威のため、一度に少しずつ実行されます。あなたは絶対的に正しい

一つのことは、しかし：あなたべき明確に定義された要件を微調整する前にとパフォーマンスのためテスト。

Answer 2

ここで明らかな結論は、フェッチサイズを大きくすることです。

おそらく、「ユーザーが戻すオブジェクトの数を減らすことができるかどうかを見てみましょう。 Googleが結果を返すとき、あなたは25〜50のバッチでそれを行い、あなたが有用であると考えられる最大の可能性でソートします。ユーザーが何千ものオブジェクトを戻している場合は、おそらくそれを減らす方法を考える必要があります。データベースはより多くの作業を行うことができますか？それらのオブジェクトのいくつかを削除するために書き込むことができる他の操作がありますか？オブジェクト自体がよりスマートになりますか？