シャーディング
クラウド内のアプリケーションのスケーリングの問題は非常に一般的です。 クラウドテクノロジーの概念には、オンデマンドでのアプリケーションのスケーリングが含まれます。 自尊心のあるクラウドプロバイダーは、対応する機能をサポートしています。
なぜ水平スケーリングが必要なのですか？ アプリケーションのパフォーマンスを改善するという疑問が生じた場合、いくつかのオプションがあります。 ご存知のように、サーバー用の新しいハードウェアを購入したり、RAMの量を追加したりできます。この原則は、垂直スケーリングと呼ばれます。 ただし、この方法は非常に高価で長く、制限があります。 確かにトップエンドのハードウェアを購入することはできますが、アプリケーションのすべての要件を満たせるとは限りません。
水平スケーリングと呼ばれる2番目の方法では、アプリケーションがホストされているPaaSの場合、サーバーまたはアプリケーションのインスタンスの数を増やすことにより、アプリケーションで使用可能なコンピューティングリソースを拡張します。 つまり、以前にアプリケーションが1つのサーバーに配置されていて、ある時点で負荷の「引き込み」が停止した場合、まったく同じ2番目のサーバーを購入できます。 アプリケーションをその上に置くと、アプリケーションへの要求の一部は最初のサーバーに、一部は2番目のサーバーに送られます。
この原則は、「クラウド」にあるアプリケーションの水平スケーリングに置かれていますが、実際の物理サーバーの代わりに、仮想マシンの概念もあります。 1つの仮想マシンのインスタンスがアプリケーションに十分でない場合は、インスタンスを増やして、複数の仮想マシンに負荷を分散できます。
Microsoftのクラウドプラットフォームの機能を考慮すると、それらは非常に幅広いものです。 自動スケーリング、オンデマンドスケーリングがあり、UIとSDK、REST API、およびPowerShellの両方を使用して利用できます。
ただし、アプリケーション（PaaS）または仮想マシン（IaaS）のスケーリングが非常に簡単な場合、必要なインスタンスの数を指定すると、非常に多くのインスタンスが存在することになり、アプリケーションでMS SQLデータベースを使用する場合、いくつかの疑問が生じます。 もちろん、最初に頭に浮かぶのは、SQL Server仮想マシンのクラスターを編成することです。 ソリューションは非常にシンプルで、誰もが使い慣れています。 しかし、アプリケーションがデータベースをサービス（SaaS）として使用する場合はどうでしょうか？ SQL Serverクラスターを構成しない場合はどうなりますか？
もちろん、Windows Azureについて話している場合は、SQL AzureがSQLデータベースとして使用されます。 このデータベースは、SQL Azure Federationsと呼ばれる水平スケーリング（シャーディング）のテクノロジーをサポートしています。 操作の原理は非常に単純です。1つのテーブルの各行が論理的に独立しており、異なるデータベースに格納されます。 最も簡単な例：
これは、データが異なるデータベースインスタンス（シャード）に格納されている同じテーブルです。 つまり、識別子1のアカウントデータは最初のデータベースに保存され、識別子2のアカウントデータは2番目のデータベースに保存されます。
Azure SQLの制限
それで、これは何を私たちに与えますか まず、データを互いに分離します。 あるアカウントのデータは、別のアカウントのデータとはまったく関係ありません。 したがって、シャーディングテクノロジーを使用して、データベースの水平スケーリングだけでなく、マルチテナントシナリオも実装できます。
特定のシャードに格納されているデータのサイズはデータベースの総量よりも桁違いに小さいため、データベースからのデータサンプリングの速度が向上します。
ただし、どの技術にも欠点があります。 シャーディングも例外ではありません。 上記のサンプルデータベースを使用してシャーディングテクノロジーを使用する場合に発生する可能性があるデメリットについて考えてみましょう。
ご存じのように、 Azure SQLアーキテクチャを思い出すと、サービスは同時に複数のデータベースからデータを取得することをサポートしていません。 つまり、1つのデータベース-1つの接続。 そして、破片も例外ではありません。 つまり、データベース内のクライアント数を返す最も単純なリクエストを許可する場合、各シャードを個別に実行する必要があります。
元のリクエスト：
SELECT Count(*) FROM Account
特定のシャードのリクエストの例：
USE FEDERATION Accounts(AccountId = 4) WITH RESET, FILTERING = OFF
GO
SELECT Count(*) FROM Account
このリクエストによって返された値を合計するロジックは、アプリケーションに配置する必要があります。 つまり、データベースレベルでは通常のSQL Serverの一部の機能が制限されているため、フェデレーションを使用すると、コードの一部がアプリケーションに「移動」します。
まえがき
もちろん、SQL Azure Federationsは万能薬ではなく、水平方向のデータベーススケーリングの原則を実装できます。 マルチテナントアプローチも、データベースの一種の水平スケーリングであるとしましょう。 あるユーザーのデータは別のユーザーのデータから「論理的に」分離されるだけでなく、「物理的に」も分離されるためです。
新しいユーザーを追加する必要がある場合は、そのユーザー用に別のデータベースを構成します。 問題は、アプリケーションロジックに「ルーティング」メカニズムが必要であることです。 つまり、アプリケーションは、現在作業しているデータベースを知る必要があります。
しかし、Azure Federations SQLに戻って...
マイクロソフトのアイデアそのものは称賛に値します。 データベースを簡単に自慰できるツールを手に入れるといいでしょう。 そして、特定のクエリの結果に基づいて自動スケーリングを行うには（まあ、これはすでに素晴らしいです）...
ただし、原則として、SQL Azureフェデレーションの使用に切り替える最終決定を行う前に、既存のデータベースを慎重に分析する（および、原則として、既存のデータベースを転送する）か、アプリケーションが使用するデータベースアーキテクチャとロジック自体を細かく検討する必要がありますこのデータベースを操作するためのアプリケーション。
彼らはある種の理論を整理しました。 ただし、実際には、実際に踏むことができるかなり多数のレーキがあります。 したがって、最初からSQL Azureフェデレーションの使用を開始するのがいかに簡単かを示すのではなく、既存のAzure SQLデータベースを移行してフェデレーションを使用するようにします。 DBAが実行する必要がある手順、および移行フェーズ中に発生する可能性がある問題を考慮してください。
一般に、切り替えないでください！ 週の作業を始めましょう！