nhibernate - 持続性無知はスケーリングできますか?

Question

NHibernate と Linq2Sql について簡単に説明しました。また、Entity Framework をのぞいてみるつもりです。

私がこれらの ORM について話すときに提起される質問は、「彼らはスケーリングできない」ということです。Google からは、うまくスケーリングできるという印象を受けますが、最終的には、支払うべき代償があるに違いないと思います。

Answer 1

これは良い質問です。IMHO はカスタム DAL と同じようにスケーリングできます。私は nHibernate しか使用していないので、nHibernate と、システムのスケーリングに役立つ機能のみに焦点を当てます。

• 遅延読み込み - 遅延読み込みをサポートしているため、不要なアイテムの読み込みを避けることができます。もちろん、Select n+1 の問題に注意する必要がありますが、システムにはこれを防ぐための機能があります。
• Eager Fetching - SQL への余分なトリップを回避するために必要なオブジェクトを熱心にフェッチするには、さまざまな方法があります。
• セカンド レベル キャッシュ - nHibernate は、DB へのトリップを減らしてスケーラビリティを高めるために使用できるセカンド レベル キャッシュをサポートしています。ある程度の柔軟性を提供するさまざまなバッキング プロバイダーが利用可能です。
• 独自の SQL を作成する - nHibernate では、ストアド プロシージャを呼び出すか、エンティティを返す SQL クエリをインラインで提供できます。これにより、生成された SQL がうまくいかない場合に、独自の SQL を使用できるようになります。たとえば、再帰クエリを使用して自己結合ツリーを熱心にロードします。

そうは言っても、カスタム DAL レイヤーを最初に微調整する方が簡単だと思います。なぜなら、あなたはその構造に精通しており、微調整できるからです。ただし、優れた ORM は、かなりの最適化を可能にする多くのフックを提供します。あなたはそれを学ぶのに少し時間を費やす必要があります.

また、コードのパフォーマンスが重要な領域があり、要件内で ORM を動作させることができない場合は、アプリケーションのその小さな領域に対して、独自の DAL レイヤーをカスタム構築できると思います。ファクトリによって作成されたリポジトリなどの適切な設計パターンを使用している場合は、リポジトリの実装を交換するだけです。

Answer 2

ORM で構築されたアプリがうまくスケーリングしないというのは、まったく正しくありません。不注意または怠惰な開発者が、恐ろしく非効率な SQL を生成するコードを記述して ORM を悪用する前に、確かにそれは起こりました。パフォーマンスの高いアプリを構築するということは、すばらしい抽象化が内部で実際に何をしているのかを理解することを意味します。ただし、このトラップから抜け出すのにそれほど時間はかかりません。ORM を使用しても、SQL プロファイラーまたはNHibernate Profilerをまったく開かないという意味ではありません。

また、SP の方がはるかに高速であるという主張については、こちらとこちらをお読みください。さらに、ORM (少なくとも NHibernate) を使用すると、必要に応じて SP を簡単に使用できます。