2

.NET Web アプリケーションを Azure に移行する可能性を検討しています。Web サーバーの側面を処理するためのマルチロール設定は、十分に機能しているようです。

Azure データベースのパフォーマンスと、ニーズに合った適切なスケールアウト戦略の採用に関して、私は留保しています。120 個のテーブルで構成される単一のデータベースを使用し、トランザクションの 80% は 10 個のテーブルで実行されます。残りは、さまざまなアカウント レベルの設定とグローバル参照に使用されます。最大のテーブルは 500 万行で構成され、残りの 9 つの大きなテーブルで一連のトリガーを使用して操作されます。各テーブルは、50 万行から 25 万行の間で保持されます。

私の当初の考えは次のとおりでした。

  1. 最大のテーブルを独自のデータベース インスタンスに移動し、SYNONYM を使用して参照します。Azure DB がデータベース インスタンス間で SYNONYMS をサポートしていないように見えることに気付きました。

  2. フェデレーションを使用して、ワークロードをより多くの Azure DB インスタンスに分散させます。私たちの DB は 5GB しかないので、これは時期尚早のオプションでしょうか?

  3. データベースにサービスを提供するには、SQL を備えたより高いスペックの仮想マシンを使用します。

ここには多くの不明な点があることを認識しており、決定的な答えは期待していません。Stackoverflow コミュニティがどのような体験を提供できるかを知りたいだけです。

追加情報

  • 現在のセットアップ: 12 GB の RAM を備えたまともな仕様のマルチコア サーバー上で実行されている、120 個のテーブルからなる単一のデータベースを備えた単一の SQL Server 2008 R2 インスタンス。
  • 現在のパフォーマンスは非常に優れており、スケーラビリティと交換できる程度です。
  • データベースは毎月 10% ずつ増加しており、リレーショナル データ、トリガー、複雑なストアド プロシージャに大きく依存しているため、代替として Azure テーブルを使用することは困難です。
4

3 に答える 3

2

あなたは一度に2つの問題を解決しようとしていますが、これは最善のアプローチではないかもしれません。まず、既存のアプリケーションを移行します。次に、スケールアウトアーキテクチャを開発しようとしています。これらの両方を同時に実行しようとすると、アーキテクチャ上の問題が発生します。スケールアウトについてあまり気にせずに、最初にアプリケーションを移行することをお勧めします。アプリケーションを実行すると、よりスケーラブルなアーキテクチャを開発できます。スケーラブル、SQL、および低コストを組み合わせたソリューションはほとんどありません。そのため、SQLへの依存度が非常に高い、思いついた「スケーラブルな」ソリューションには、いくつかの苦痛な妥協点があります。

よりスケーラブルなものを構築するには、既存のアーキテクチャを詳しく調べて、大規模なやり直しを計画する必要があります。アプリケーションを個別のワークロードに分割し、T-SQL、トリガー、複雑なストアドプロシージャなどへの依存度を高めます。これが価値があるかどうかの必要性/ビジネスケースは、アプリケーションのロードマップによって異なります。

Windows Azureに移行する長期的な正当な理由があると仮定すると（既存のアプリの安価なものはその1つではありません）、現在、移行戦略の最初のステップに着手しています。この最初のステップでは、変更をできるだけ少なくして、単に「機能させる」ことをお勧めします。その場合、SQLをVMに配置するのが最も理にかなっているかもしれません—他に何もないとしても、より多くの制御と余裕を与えることです。すべてが実行されたら（移行のステップ1）、移行のさらなるフェーズを確認できます。手順2からnは、アプリケーションアーキテクチャが劇的に変化し、テーブルストレージをより多く使用し、SQLをより少なく使用することを意味します。したがって、ステップn - mまでに、SQLのパフォーマンスやスケーラビリティは問題になりません。

クラウドアプリケーションのデータモデルはより複雑であり、慎重に検討する必要があります。これは、 CALMのデータモデルで詳しく書いたものです。

パニックにならない。

アプリケーションにありふれた未来がある場合は、co-loでホストされるソリューションが最適である可能性があります。ここでは、ニーズを満たすデータベースサーバーを具体的に構成できます。アプリケーションに対する高い野心がある場合は、時間の経過とともに、Azureで適切に実行されるはるかにスケーラブルでクラウドに適したアーキテクチャにアプリケーションを移行できます。

于 2013-03-07T20:12:38.713 に答える
0

VM オプションは、特にアプリに変更を加えることができない場合に最も簡単な方法です。

SQL フェデレーションでは、アプリを変更する必要があります (USE FEDERATION のこと)。

さらに、SQL Azure の場合、一時的な障害の処理/スロットリングを考慮する必要があります。さらに、SQL Server で使用しているすべての既存の機能が完全にサポートされていることを確認する必要があります (たとえば、部分的にサポートされている TSQL、CLR サポートなど)。

于 2013-03-07T15:16:32.357 に答える
0

オプション＃3を使用します。SQL Azure は、特に大量のデータに対してパフォーマンスが重要なクエリを処理する場合に、そのパフォーマンスがやや予測不可能になる可能性があります。

于 2013-03-07T15:07:45.033 に答える