大量のデータとトラフィックが予想される Windows Azure で実行するシステムをセットアップしています。それを処理するために、Federated データベースを設計しています。必要に応じてアプリケーション自体を SPLIT (または DROP) フェデレーション データベースにすることに関心があります。これらの操作をトリガーする理由は 2 つあります。1) データベースのサイズが Windows Azure で許可されている制限に達している、2) サーバーのトラフィック量が多すぎる、SPLIT 操作によりパフォーマンスが向上する、応答時間を低く保ちます (高速に実行します)。(逆の操作は同様の推論に基づいています)。
私の質問は、これら 2 つの状態をプログラムで検出するにはどうすればよいですか?
Sql Azure 動的管理ビューを使用して、 Sql Azure データベースをプログラムで監視できます。フェデレーテッド・データベース全体を一度にモニターすることはできず、個々のメンバーをそれぞれモニターできることに注意してください。
動的管理ビューを使用して、サイズに関連する条件 1) を確認するのは簡単です。トラフィック/パフォーマンスに関連する条件番号 2) の検出は、意味のある正確なメトリックとそのしきい値を最初に特定する必要があるため、少し難しくなります。
SPLIT 操作と DROP 操作の動作が大きく異なることに注意してください。SPLIT は、パーティション メンバーを 2 つのデータベースに分割するオンライン操作 (停止時間はありません) です。データは 2 つの間で自動的に分割されます。この動作は、分割が実際に自動化されたスケーリング プロセスからトリガーされる可能性があることを意味します。
ただし、DROP はまったく異なります。フェデレーション メンバーを削除すると、Sql Azure はキー値の範囲を下位または上位の近隣フェデレーション メンバーに移動しますが、データ自体は単純に削除されます。この記事でより詳細な説明を得ることができます(記事内で「スケールダウン」を検索してください)。基本的に、ドロップされたデータベースからデータを手動でエクスポートし、それを宛先データベースに手動でマージする必要があります。技術的に言えば、Sql Azure Migration Wizard のコマンド ライン バージョンを使用してマージ操作を自動化できるかもしれませんが、それにはリスクがあります。製品化する前に、多くのテストが必要になります。
Microsoft は、フェデレーション メンバーのドロップ時に自動マージを実装することを計画していますが、それは将来のリリースで実装される予定です。現時点では、自動スケールダウンはお勧めできません。
アップデート
興味のある方は、フェデレーションされた SQL Azure データベースでの MERGE 操作にこちらから投票できます。