大規模なエンタープライズWebアプリケーションが使用され始めています。最近私は、ユーザーのアクセス許可、アクセス、プロファイル情報の一般的なビットなど、多くのデータベース呼び出しを行っていることに気づいた。大規模なアプリケーション - データアクセスの処理方法
私はAzureで見ることができますが、1時間あたり平均50,000のdbクエリを見ています。
私たちはDevExpress XPO ORM経由でLinqを使用してクエリを実行しています。今はこれらのうちのいくつかは結合ですが、大半は単純な1つのテーブルクエリです。
この種の情報にアクセスするには、常にデータベースに最も適した方法ですか？この情報の一部が決して変更されないため、データベース作業をオフロードする方法はありますか？
ありがとうございます。
これを視点に入れてみましょう。 1時間に3600秒で、1秒あたり20回以下の操作が可能です。どんな測定でも慎重に低い。
つまり、たとえば30秒または1分と言うユーザーのアクセス許可をキャッシュすることには何も問題はありません。
通常、コードにはキャッシュしないでくださいが、前にはASP.NET出力キャッシュとドーナツキャッシュはほとんど無視されますが、最も効率的です。
http://www.dotnettricks.com/learn/mvc/donut-caching-and-donut-hole-caching-with-aspnet-mvc-4
より多くの情報を持っています。その後、大量の数値をすべて無視してプロファイラを実行します。実際のヘビーユーザーはどのページで使用されているかのようにアクセス許可の周りにある可能性があります。これをサブシステムに入れ、キャッシュします。 asp.netサブシステムのユーザーIDオブジェクトにプリロードすることができれば、asp.netの一部のフィルターでキャッシュが分離されるため、コードはページ内のデータベースにヒットしません。
対策。あなたのSQLはスマートであることを確認してください - EFとLINQは人々が怠け者であるため、非常にばかげたSQLにつながります。完全なオブジェクトをインスタンス化しないで投げ捨てるだけで、必要なフィールドだけを尋ねることができます。あなたの指標が効率的であることを確認してください。本当の問題（測定）が始まると元に戻ります。
しかし、古い規則は次のとおりです。cache early。そして、LINQの最適化はかなり後ろにあります。
質問にLINQと結合を記載すると、既にORMに問題があることが示唆されます構成。また、「オプティミスティックな並行処理が厄介だと思ってトランザクションを使用しないでください」と「リクエストごとにトランザクションを忘れて、データベーストランザクションを意味するのではない」と追加します。これらの2つは、誤って書かれたORMコードの振る舞いがVB6やADOコードよりも悪くなるようにするのに十分です。 –
実際にトランザクションを使用しているわけではありません。私は間違った言葉を使用しました:) – bExplosion
おかげでトム、私はプロファイリングと一緒にこれを調べます。 – bExplosion
プロファイル、アクセスなどのようなユーザー固有の情報をデータベースから取得する場合は、リクエストごとにフェッチするのではなく、ログイン時に一度情報を取得してセッションを維持する方がよいでしょう。これはデータベースとの取引を減らすはずです
あなたの質問は、広範かつ非特定のものです。私たちはあなたの設定を知ることができないので、改善を提案することはできません。あなたがそれらを提供したとしても、数十の最適化の機会があるので、この質問は広すぎました。さらに、「頻繁に使用される」と「たくさんのdbコール」と考えるのは関連性があります。特に、Linq *やストアドプロシージャではありませんが、追加することもできます。どちらも、どちらも違いはありません、彼らはあなたがそれらをどのように使用しているかに完全に依存しています。 – HimBromBeere
おかげで、申し訳ありませんが質問はあいまいでした。私はそれがより明確であることをうまくいけばそれを改めた。 – bExplosion
1時間あたり50,000クエリが大きくありません。標準ガイダンスが適用されます。データベースが遅いと想定しないでください。常にあなたのコードです。適切なスキーマ、索引を使用します。あなたが望まないものをロードしないでください。レポートにORMを使用しないでください。オプティミスティックな並行性を使用します。誰かが「リクエストごとのトランザクション」の意味を誤解しているため、トランザクションを使用しないでください。 –