私のアプリケーションは、Windows azure と SQL Database(Azure) を使用しています。近い将来、SQL データベースのトラフィックは毎分 50,000 トランザクション近くになるでしょう。5GB の Web データベースを使用しています。
現在、SQL データベースでは、パーティションあたり 400 の同時操作の制限があります:参照
この制限を克服するために可能な方法は何ですか? 現時点で私が考えることができる最善の解決策はフェデレーションです。他の方法はどれですか？そして、どれが最高ですか？
EDIT :トランザクションは書き込み専用です。クライアント システムから 5 秒ごとにパフォーマンス データを収集しています。これは最終的に SQL データベースにデータを挿入する REST API に送信されます。したがって、UI とキャッシュは問題外です。
Windows Azure SQL データベースでフェデレーションを使用することは、1 つのオプションです。しかし、Table Storage、Blob、または Queue などの別のデータ ストアに重い作業をオフロードすることを好みます。それらは重い負荷を処理するように構築されており、パーティション分割がはるかに簡単だからです。これを適切なキャッシングと組み合わせると、この制限を簡単に克服できます。
サイトのホームページにトップ 10 の製品リストがあり、1 日あたり 100,000 人の訪問者がいるとします。1 つのオプションは、毎回 SQL Azure にクエリを実行することですが、これは SQL Azure に大きな負荷がかかる可能性があります。ただし、たとえば 24 時間ごとにワーカー プロセスを実行し、その時点で上位 10 個の製品を計算し、それらを Table Storage に保存することができます (国ごと、カテゴリごと、. ..)。これは、事前に生成されたビューとして見ることができます。上位 10 個の製品を表示するたびに、Table Storage (テーブル内の特定のパーティション) からアイテムをクエリすると、スケーリングが大幅に向上します。そこに ASP.NET キャッシュを追加すると、非常に信頼性の高いシステムが得られます。
データの読み取りは以上でした。しかし、ユーザーが注文を作成したり、メッセージを送信したりできるユーザー入力も期待していると思います...また、重い負荷が予想される場合、SQL Azure は直接対話するための最良のオプションではない可能性があります（制限を見た）。フロントエンドとバックエンドの間でキューを使用することは、より良い解決策かもしれません。
ユーザーが注文すると、キュー (ストレージ キューまたはサービス バス キュー) にメッセージを書き込むことができます。作業者はこのメッセージを受け取り、その注文のテーブルに、時間、製品数、さらにはユーザーの注文画面に表示されるステータス (処理中など) を含むレコードを作成します。これが完了したら、注文を完了するために必要なすべての時間があり、完了したら、最終結果を SQL Azure に保存します (さらに、テーブル ストレージの注文レコードを更新します)。最終結果を SQL Azure に保存しても、レポートなどを使用できるようになります...
これは、アプリケーションに大きな影響を与えます。別の解決策として、仮想マシンで SQL Server をホストすることもできますが、これはまだ CTP にあることに注意してください: Windows Azure での SQL Server 仮想マシンのプロビジョニング
フェデレーションは、シェアード ナッシング インフラストラクチャであるため、もちろんオプションです。ただし、最初に、なぜそんなに大量のトランザクションが必要なのかを考えてみてください。トランザクションは主に読み取りまたは書き込み操作になりますか? 中間層はありますか? 使用可能な手法は、書き込み操作と読み取り操作で異なります。中間層が配置されている場合に、SQL Database インスタンスで 1 秒あたりのトランザクション数を最小限に抑えるために使用できるいくつかの手法を次に示します。
読み取りシナリオ (または非正規化) で、システムがコンシューマーにデータを提供しようとしている場合、キャッシュは重要です。データの鮮度やノード間の同期の問題など、考慮すべき深刻な長所と短所があると言う以外に、キャッシングについては詳しく説明しません。以下の他の 2 つの手法は書き込み用です。
セットベースのトランザクションは、データベース システムでは非常に重要です。たとえば、システムが毎秒大量のレコードを挿入する場合、たとえば、挿入リクエストをキューに配置し、別のスレッドでキューを処理してから、10 または 20 のリクエストを単一のデータベース呼び出しにプールします。これには、データベースでの非同期処理とセット ベースの操作が必要です。しかし、結局のところ、処理のためにレコードをグループ化することは、SQL Database で成功するための鍵の 1 つです。同様のパターンを実装しなければ、1 秒あたり 500 トランザクションをはるかに超えるシステムを現在設計しています。
結果整合性はもう 1 つの重要な概念であり、以前にセットベースのアプローチで言及しました。結果整合性とは、現時点ではデータベースにすべてのレコードが含まれていない可能性があり、すべてのレコードが利用可能になるまでに時間がかかる可能性があることを意味します。しかし、最終的には、レコードがそれを達成します。上記の (キューを使用した) 例では、セットベースの操作と結果整合性パターンの両方を実装しています。