2

SQL Azureアプリケーションを計画するときに留意すべきパフォーマンスの考慮事項はどれですか？Azure Storage、およびワーカーとWebの役割は非常にスケーラブルに見えますが、最終的に1つのデータベースを使用している場合は、ボトルネックのように見えます。

私はについての数字を見つけようとしていました：

  1. SQL Azureはいくつの同時接続をサポートしていますか？
  2. 帯域幅はどれですか？

しかし、運はありません。

たとえば、非常に高レベルの挿入を使用する計画とアプリケーションを計画していますが、毎回集計関数の結果を返す必要があるため（たとえば、列に同じキーを持つすべてのレコードの合計）、できません。テーブルストレージと一緒に行きます。

バッチ処理はオプションですが、時間応答も重要であるため、データベースが多くの接続で肥大化するのではないかと心配しています。

シャーディングは別のオプションですが、挿入の量が多い場合でも、データの量は非常に少なく、1つのPKでFKがない4〜6列です。したがって、1Gb DBでさえ、パーティションにとって過剰な（そして過剰な支払い：D）ことになります。

この種のアプリケーションに直面したときに覚えておくべきパフォーマンスキーはどれですか？

乾杯。

4

2 に答える 2

3

なんらかの形でリソースの競合が発生した場合、SQL Azure は接続を調整します (これには高負荷が含まれますが、データベースが物理的に移動された場合にも発生する可能性があります)。スロットリングは非決定論的です。つまり、これが発生するかどうか、いつ発生するかを予測することはできません。調整すると、SQL Azure は接続を切断し、再試行を実行する必要があります。サポートされる接続数と帯域幅は、基盤となるインフラストラクチャの柔軟性が高いため、「設計上」公開されていません。そうは言っても、セットアップは高スループットではなく、高可用性向けに最適化されています。

バーストが既知の時間に発生する場合は、それらのバースト中だけシャーディングし、バーストが発生した後にデータを統合することを検討できます。これを処理する別の方法は、スロットリングが発生した場合にのみ、書き込みのキューイング/バッチ処理を開始することです。そのための Azure キューと、ワーカー ロールを使用して、後でキューを空にすることができます。この「オーバーフロー メカニズム」には、スロットリングが発生した場合に自動的に係合するという利点があります。

別の方法として、Azure Table Storage を使用して、データの集計を実行してすべてのレコードの必要な合計を返す代わりに、レポートできる実行中の合計の別のテーブルを保持することができます (これは、ロックがないため注意が必要な場合があります)。ただし、テーブル）。

明白なことを述べて申し訳ありませんが、最初のステップは、シナリオでスロットリングが発生するかどうかをテストすることです。オーバーフローソリューションを試してみます。

于 2011-04-22T15:15:14.247 に答える
3

スケーラビリティとパフォーマンスの両方を実現することは、クラウドであっても非常に難しい場合があります。あなたの質問は主にスケーラビリティに関するものだったので、たとえばキューを使用して、データが「最終的に」一貫性を持つようにアプリケーションを設計することをお勧めします。Worker ロールは、受信挿入要求をリッスンし、挿入を非同期的に実行します。

データベースへのラウンドトリップ数を最小限に抑え、接続プールを最適化するには、挿入も必ずバッチ処理してください。つまり、1 回のショットで 100 個のインサートを送信できます。また、SQL Azure が MARS (複数のアクティブなレコードセット) をサポートするようになったことにも注意してください。これにより、1 つのバッチで複数の SELECT を呼び出し元のコードに返すことができます。バッチ処理と MARS を使用すると、データベース接続の数を最小限に抑えることができます。

シャーディングは通常、読み取り操作に役立ちます。挿入についてはそれほどではありません（ただし、挿入をシャーディングでベンチマークしたことはありません）。したがって、シャーディングが要件に対してそれほど役立つかどうかはわかりません。

Azure オファリングは、データベースが同じサーバー上の他のユーザーと共有されるマルチテナンシー環境でのスケーラビリティと妥当なパフォーマンスを第一に設計されていることに注意してください。したがって、応答時間が保証された強力なパフォーマンスが必要な場合は、ホスティングの選択を再評価するか、tijmenvdk によって提案されているように、ニーズに合わせて Azure のパフォーマンス境界を実際にテストする必要があります。

于 2011-04-25T19:48:07.343 に答える