問題タブ [select-n-plus-1]

「N+1 選択の問題」は、オブジェクト リレーショナル マッピング (ORM) の議論では一般的に問題として述べられています。オブジェクト内で単純に見えるものに対して、多くのデータベース クエリを作成する必要があることと関係があることを理解しています。世界。

誰かが問題のより詳細な説明を持っていますか?

Foo にはタイトルがあります。
Bar は Foo を参照します。バーのコレクションがあります。
Foo.Title のコレクションが必要です。

コレクションに 10 本のバーがある場合、db を 10 回呼び出します。

bar.Select(x=>x.Foo.Title)

現時点では、これは (NHibernate Linq を使用していて、ドロップしたくありません) Bar コレクションを取得します。

私はこれについてアイエンデが言っていることを読みました。
別の関連する質問。
ちょっとしたドキュメンテーション。
また、関連する別のブログ投稿.
多分これは助けることができますか？これ
はどうですか？ 多分MultiQueryは私が必要とするものですか? :/

しかし、私はまだこれを適切な解決策で「コンパイル」できません。

n + 1を選択しないようにするには?

私はこのような実体と流暢なマッピングを持っています。

次に、このようなICriteriaクエリを実行します

NHProfを使用すると、このようなクエリが実行され、すべてのクライアントの詳細とアドレスが返されることがわかります。

期待どおりにすべてのレコードを返します

しかし、私がその後のようなコードを書く場合

それでも、各アドレスで選択を行うN+1の問題が発生します。どうすればこれを回避できますか？

ここに私が持っているものがあります:

また、A と別のエンティティ X の間で外部キーを使用せずに内部結合を行う必要があるため、createQuery ではなく createSqlQuery を使用する必要があります。（明らかに、データベースを変更することはできません）

だから、私ができたのは、素敵な 2N+1 選択だけです。(fetch=EAGER を使用しても、手動でも同じです)。

誰かが何か考えがありますか？

編集: @BatchSize を使用して、選択の数を A から B に減らしました。現在、N+2 の選択があります。

編集 2: データベースが古い DB2 であり、クラッシュするため、内部結合 (コンマを使用) を使用できません。

N+1 と悪い DB クエリの重大なパフォーマンスへの影響について同僚と話した後、 http: //guides.rubyonrails.org/active_record_querying.htmlにアクセスしました。

ActiveRecord (レール):

クライアントがアドレスを持っていて、クライアントをループしながらそれらにアクセスしようとしている場合、Rails はincludes先に進んでそれらをクエリに追加するように通知します。これにより、すぐに 9 つのクエリが不要になります。

ジャンゴ:

https://github.com/lilspikey/django-batch-selectは、バッチ クエリのサポートを提供します。上記のRailsが提供するものを達成するための他のライブラリやトリックを知っていますか? また、バッチ選択は同じ方法で懸念に対処しますか、それともこれら 2 つの異なることですか?

select_relatedところで、一見答えのように見えるかもしれませんが、私は について尋ねているわけではありません。addressへの外部キーがある状況について話していますclient。

Rails:includeで ActiveRecord のメソッドの 1 つを呼び出すときにハッシュ値を渡す例をいくつか見てきました。findただし、関係メソッドを介してこれが可能かどうかの例は見たことがありません。たとえば、次のものがあるとします。

私が見るすべての例は、次のようなコードを示しています。

しかし、関係の使用を示す例は見当たりません。代わりに、私がこのようなことをすることは可能でしょうか?

私はEntityFrameworkProfilerを使用してMVCプロジェクトのデータアクセスをテストしてきましたが、N + 1の問題のために、必要以上に多くのデータベースクエリを実行しているページに出くわしました。

これが私の問題を示す簡単な例です：

ビューはメンバーをループし、各メンバーのナビゲーションプロパティに従って、アドレスも表示します。各アドレス要求により、追加のデータベースクエリが生成されます。

これを解決する1つの方法は、Includeを使用して、必要な追加のテーブルが事前に照会されていることを確認することです。ただし、これは、コンテキストに直接接続されているクラブのObjectSetでのみ実行できるようです。この場合、ActiveClubプロパティは多くのコントローラーで共有されているため、メンバーとアドレステーブルを事前に照会する必要はありません。

次のようなものを使用できるようにしたいと思います。

ただし、MembersはEntityCollectionであり、Includeメソッドがありません。

メンバーEntityCollectionに強制的にロードし、EFにアドレスもロードするように依頼する方法はありますか？

または、この方法でエンティティのEntityCollectionナビゲーションプロパティを使用していますが、これは非常に悪い考えです。コンテキストから取得するときに、何をロードしているのかを知っておく必要がありますか？

私は、Entity Framework Profiler を使用した後に非常にばかげているように見えるデザイン パターンを使用してきました。

エンティティ クラスを拡張して、そのエンティティに関連付けられたコレクションのフィルター処理されたビューであるプロパティを持たせました。このような：

私は主にクラブを離れていないメンバーに関心があるので、このプロパティは非常に便利で、理にかなっているように思えました。

しかし、EF Profiler を実行した結果、これが N+1 の問題を引き起こすことが多いことがわかりました。メンバーをループし、そのアドレスも表示したい場合、アドレスに対する各リクエストは余分な db クエリになります。

この質問から、自分のプロパティを次のように変更できることを知りました。

これにより、この場合の N+1 問題は解消されますが、アドレス情報が常に必要なわけではなく、Member から別のナビゲーション プロパティをたどりたい場合があります。

理想的には、ActiveMembers などのフィルタリングされたプロパティの柔軟性を維持し、クエリに含めるプロパティを後で決定できるようにしたいと考えています。このような：

これは可能ですか、またはフィルタリングされたプロパティのアイデアを再構築する必要がありますか?

次のデータをフェッチするためのステートメントがあります: food-serving-name、food-name、food-brand-name、および food-category。4 つのフィールドはすべて別のテーブルにあります。私はこのようなステートメントを使用しています

以下は私のモデルです

上記のステートメントを実行すると、多くの SQL ステートメントが実行されていることがログに表示されます。明らかにこれは N+1 の問題です。find メソッドに間違った include パラメータを渡していると思います。誰かがこの呼び出しを最適化するのを手伝ってくれますか?

Hibernateは、N + 1クエリの問題を回避するための（少なくとも）2つのオプションを提供します。1つは、FetchModeをSubselectに設定することです。これにより、IN句を含むselectと、このIN句内のsubselectが生成されます。もう1つは、BatchSizeを指定することです。これにより、親のIDを含むIN句を使用してselectが生成されます。

どちらも機能しますが、親のクエリが複雑なため、[サブ選択]オプションでパフォーマンスの問題が発生することがよくあります。一方、BatchSizeが大きい場合（たとえば1000）、クエリの数とそれらのクエリの複雑さは非常に小さくなります。

したがって、私の質問は、BatchSizeではなくHibernateのSubselectFetchModeをいつ使用するのかということです。親エントリの数が非常に多い場合（数千）、副選択はおそらく意味がありますが、BatchSizeよりも副選択を使用したいシナリオは他にありますか？

編集：熱心な読み込みを処理するときに、2つの違いに気づきました。xToManyアソシエーションを熱心にロードし、サブセレクトを介してロードするように設定している場合、レイジーの場合と同じようにサブセレクトが生成されます。ただし、BatchSizeを指定すると、生成されたクエリは、個別のクエリではなく外部結合を使用します。熱心にロードするときにHibernateに個別のバッチクエリを使用させる方法はありますか？