hql と criteriaApi と QueryOver のパフォーマンスの違いは何ですか? 一方が他方より速い、または遅い状況はありますか?
編集: QueryOver と Linq で質問を拡張しました。
=============================================
さて、どの回答を回答としてマークするべきかわからないので、ほとんどの投稿に VoteUp をマークします。知らない。これは実際には、質問というよりも議論です。
hql と criteriaApi と QueryOver のパフォーマンスの違いは何ですか? 一方が他方より速い、または遅い状況はありますか?
編集: QueryOver と Linq で質問を拡張しました。
=============================================
さて、どの回答を回答としてマークするべきかわからないので、ほとんどの投稿に VoteUp をマークします。知らない。これは実際には、質問というよりも議論です。
ICriteria と HQL の間のパフォーマンス特性は、1 つの単純な理由で少し異なります (QueryOver については知りません)。
ICriteria クエリはデフォルトで、マッピングで定義されたフェッチ戦略を実装しようとしますが、HQL はデフォルトですべてを遅延と見なし、クエリ内の結合宣言に依存して何が熱心にフェッチされるかどうかを定義します。
さらに、ICriteria はパラメーターを渡すためのマッピングに依存しますが、HQL は明示的なパラメーターの型 (IQuery.SetInt32("fooParam", 5); など) を許可します。
本当に重要なのは、NH エンジンが ICriteria を解決し、最も有効な SQL を生成しようとする ICriteria クエリ (ICriteria.CreateCriteria().CreateCriteria() などを参照) のプラグ可能性です。
反対に、HQL クエリが一貫した結果を生成するかどうかを予測するのはおそらく簡単であり、そのため QueryCache の使用が容易になります。
どちらの方法でも、構成は ISessionFactory の作成とマッピングの定義で一度生成され、メモリ内にないものがあるため、パフォーマンスは良好です。
実際の SQL 生成は両者で異なっており、それが ICriteria -> HQL のユーティリティが存在しない理由です。
最終的に、私の経験から、2 つの間のパフォーマンスはおそらく同じギブまたは数ミリ秒であることがわかりました。
補足として、マッピングで可能な限り宣言すると、より簡潔な SQL 生成と NHibernate 操作が行われます。たとえばLength
、.hbm.xml で文字列プロパティをマッピングすると、NHibernate はデータベース。
QueryOver に関する限り、Criteria API の拡張機能として構築されているため、パフォーマンスは Criteria API と同じであると予想されます。したがって、2 つの API で同等のクエリを実行する場合、同じデータベース クエリが生成されることが期待されます。QueryOver インターフェースと Criteria インターフェースの唯一の相違点は、QueryOver インターフェースの方が「クリーン」で操作しやすいことです。
私の経験では、Criteria API は HQL インターフェイスよりも多くの「愛」を受けています。HQL インターフェイスで表現する同等の方法を見つけることができなかった基準インターフェイスで特定のクエリを表現できる場合に遭遇しました。
パフォーマンスに関しては、Criteria API と HQL と QueryOver の選択よりも、クエリが「要求される」方法の方がパフォーマンスに影響することがわかりました。あなたの考えに最も自然にフィットするインターフェイスを使用します。
QueryOverは、構文と型の安全性が向上しているため、ほとんどの点でCriteriaの非常に優れた代替品です。ただし、QueryOverでラムダ式を処理するとコストがかかる可能性があることに注意してください(LINQクエリにも同じことが当てはまると思います)。したがって、終了SQLクエリの実行には他のメソッド(ICriteria、HQL)よりも時間がかかりませんが、クエリオブジェクトを適切なSQLクエリに変換するのに時間がかかります。
例として、1秒間に数百のQueryOverクエリを実行するアプリケーションを開発しており(ADO.NETバッチサポートを使用)、クエリをICriteriaに変換すると、クエリを実行する能力がほぼ2倍になり、CPU使用率が半分になります。第2レベルのキャッシュとクエリキャッシングを使用すると、ラムダ式の処理に伴うオーバーヘッドを大幅に削減できると思います。しかし、これは私たちのアプリケーションには適していないため、私はこれを自分で行っていません。
どちらが速いかについてのあなたのより一般的な質問に関して:それは本当に依存します。確実に伝える唯一の方法は、プロファイリングツールを実行することです(NHProfは、このようなシナリオで驚異的に機能します)。ただし、一般的に、HQLはSQLに最も近いため、最も柔軟性があり、クエリを最適化するためのスコープが少し広がります。ただし、単純から中程度の複雑さのクエリの大部分では、ICriteriaとHQLの間にほとんどまたはまったく違いはありません。また、クエリが動的に構築されている場合、ICriteriaクエリの操作ははるかに簡単です。
私はまだ2つの違いを見つけていません。そうは言っても、hql には Criteria-API では利用できない機能があります。
前者を使用するか後者を使用するかは、ほとんどの場合、スタイルと個人的な好みの問題です。また、クエリから SQL への変換は、クエリに関してはあまり考慮されません。
私よりも詳しい人から: http://ayende.com/Blog/archive/2009/06/01/nhibernate-queries-ndash-should-i-use-hql-or-criteria.aspx