問題を解決するための戦略/生産におけるNHibernateアプリケーションの調整

Question

まず、私はDBAではありませんが、DBAが本番データベースを時々変更したり変更したりする環境で働いていますアプリケーションの再構築/再デプロイの必要性。通常、これらの変更は、索引の修正、procsの変更、および場合によっては小さな構造の変更（通常はprocsを介してアプリから抽象化されます）で構成されます。

明らかに、チームは、NHProf、SQLプロファイラ、および負荷テストなどのものを使用して生産に入る前に、NHibernateのパフォーマンスの問題をキャッチするように努めるべきです。つまり、コードが作成されて本番環境で実行されたら、ある程度の微調整を可能にするために使用できる特定の戦略がありますか？ストアドプロシージャを使用すると、100％の時間はDBAの柔軟性を最大限に引き出すように思えますが、NHibernateの効率性を犠牲にすることは明らかです。私が読んだことから、更新可能なビュー（SQL Server）は実際にはNHibernateでもうまく動作しません（これは真実ではないかもしれません）。

私はNHibernateについてかなり読んだことがあり、何年も前から実験してきましたが、実稼働環境でこれを実践したことはありません。一度配備すれば最大限の調整を可能にするための一連の「ベストプラクティス」にはまだ触れていません。

NHibernateのユーザとして、あなたとあなたのチームは、生産中に発生する場合、の問題をどのように扱いますか？？私のプロダクション環境はASP.NETアプリケーションとSQLサーバーで構成されていますが、回答をそのプラットフォームに限定する必要はありません。

Answer 1

は私が同様の位置にいて、幸せな私たちのDBAを保つために、私は次のようでした：

1. はのいくつかを書きましたHQLでのクエリ、SQLでの他のクエリ（特にperf-sensitive）
2. これらのクエリをファイルごとにクエリごとに1つずつ外部化しました。
3. アプリケーションでこれらのクエリを実行する必要がある場合は、適切なファイルを読み込み、必要に応じてプリプロセッサを実行して実行します。

この方法では、DBAは理論的にはのファイルを変更するだけで調整できます。これはストアドプロシージャを使用する場合と非常によく似ています。

実際では、それは（...あなたが私のドリフトをキャッチした場合）あなたが本当にそれらのファイルへのDBAアクセスをあげるかどうかを判断するのはあなた次第です

DBAはただDBMSのプロファイリングを使用する必要がありますIMHO彼女の所見を開発者に報告します（「20回/秒で実行され、10回のジョインを実行するこのクエリがあります。それは本当に必要ですか？それはキャッシュすることができますか？それらのすべての結合が本当に必要ですか？

Answer 2

私はまだ展開段階ではありませんが、私の現在のプロジェクトでは、私はこれをすでに克服してきました。私の解決策は現在、私のクエリをストアドプロシージャで置き換えることでした。 DBから戻って来るデータの形が変わらない限り、それは大きな問題ではありません。あなたは開発中に楽しんだ敏捷性のいくつかを失ってしまいますが、最初は聞こえるほど悪くないとは思いません。最初にコースの変更を行ったときにコードプッシュがあり、そのポイントからはprocの変更だけです。

Answer 3

NHProfのようなプロファイラを使用すると、実行されたSQL問合せを見ることができます。そのため、DBAに表示できます。このツールは、n + 1選択のような問題を検出することもできます。キャッシュの第二のレベルを使用して

が役立つことができます：http://web.archive.org/web/20110514214657/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/11/09/first-and-second-level-caching-in-nhibernate.aspx