SQL Databaseのスケーリングおよび開発機能

これは、SQLデータベースの仕組みに関するシリーズの第2部です。 最初の部分では、SQLデータベースのアーキテクチャについて説明しました。2番目の部分では、SQLデータベースのスケーリングといくつかの開発機能に焦点を当ててこのレビューを続けます。

SQLデータベースのスケーラビリティ

SQL Databaseでデータベースをホストすることの最も重要な利点の1つは、組み込みのスケーラビリティ機能です。 必要に応じて、データベースを追加できます。 2つのSQLデータベースコンポーネントは、各ノードのワークロードを絶えず監視することにより、スケーラビリティを提供します。 最初のコンポーネントはエンジンスロットル（カーネルスロットル）で、サーバーを過負荷から保護します。 2番目のコンポーネントはロードバランサー （ロードバランサー）です。これにより、サーバーが高パフォーマンスモードで継続的に動作しないことが保証されます。

性能規制

データセンターの各SQL Serverサーバーは、複数のクライアントによって同時に使用されます。 サブスクライバアプリケーションがサーバーの過負荷を引き起こし、SQL Serverインスタンス全体を混乱させる可能性があります。 たとえば、完全復旧モードでは、大量の行、特に大きなオブジェクトを含む行を挿入する操作により、トランザクションログと、ジャーナルが配置されているディスク全体がいっぱいになる可能性があります。 さらに、SQL Serverの各インスタンスは、リソースを奪うことができない他の重要なシステムプロセスとコンピューターを共有します。 これらの中で最も重要なのは、システムの状態を監視し、SQLデータベース環境へのアクセスを提供する構造サポートプロセスです。



コンピューターのパフォーマンスを混乱させる過度の負荷からデータセンターのリソースを保護するために、各コンピューターの負荷はエンジンスロットルコンポーネント（カーネルロードスロットル）によって監視されます。 さらに、データベースの各レプリカが追跡されます。 これにより、値が指定された制限内になければならない統計インジケータを制御できます。ログサイズ、ロギング操作の期間、プロセッサ使用率、物理データベースのサイズとユーザーデータベースSQLデータベースのサイズの実際の制限。 制限値を超えた場合、SQLデータベースは10秒間連続して読み取りおよび書き込み要求を拒否できます。 リソースの制限を超えると、SQLデータベースがすべての読み取りおよび書き込み要求を拒否する場合があります（リソースの種類によって異なります）。

負荷分散

現時点では、可用性の保証にもかかわらず、SQLデータベース環境のパフォーマンスを保証することはできません。 その理由の1つは、マルチテナントアクセスをサポートする問題です。SQLデータベースを持つ多くのクライアントは、SQL Serverの同じインスタンスと同じコンピューターを共有します。 各サブスクライバーの接続に必要なワークロードのレベルを予測することはできません。 それでも、SQLデータベースインフラストラクチャを開発する際に考慮された重要な側面は、高いパフォーマンスを確保することです。 SQL Databaseの負荷分散サービスは、データセンター内の各コンピューターの負荷を評価します。



新しいSQLデータベースをクラスターに追加するとき、ロードバランサーはコンピューターの現在のワークロードレベルを考慮して、新しいレプリカ（プライマリおよびセカンダリ）の配置を決定します。



コンピューターの1つが過負荷になった場合、ロードバランサーは負荷の少ないコンピューターにプライマリレプリカを移動できます。 最も簡単な方法は、パフォーマンスが低下するSQLデータベースのプライマリレプリカとセカンダリレプリカを切り替えることです。 このスイッチは、すべての読み取りおよび書き込み操作がメインレプリカで実行されるため、パフォーマンスを即座に向上させることができます。

データベース連携

フェデレーションを使用すると、中間層またはフロントエンドのスケーリング原則と同じ方法でデータベース層をスケーリングできます。 単純な場合、特定の原則に従って、フェデレーションは1つの大きなベースをいくつかの小さなベースに分割します。 通常、この原則は、小さなベースを相互に独立させる（相互参照を最小限に抑える）ように選択されます。 実際のフェデレーションでは次のことができます。

1. SQL Databaseの単一データベースのサイズに関する150 GBの制限を克服します。
2. フェデレーションの各メンバーが通常は異なる物理サーバーに配置されるようにすることで、システム全体のパフォーマンスを改善します。
3. マルチテナント （ SaaSアプリケーション用のマルチテナントアーキテクチャ）を実装します 。

フェデレーションとシャーディングの技術的な詳細はこの記事の範囲外です（これは別の大きなトピックなので）が、美しい（フェデレーション）に参加したい人のために、記事の最後にSQLデータベースのフェデレーションアーキテクチャのトピックに関するロシア語の投稿へのリンクを示します。

安全性

SQLデータベースのセキュリティ問題のほとんどは、レベルで対処されています。 ローカルデータベースへのアクセスと同様に、ユーザーはSQLデータベースに接続するためのアカウントとパスワードを持っている必要があります。 SQL Databaseは、標準のセキュリティ機能のみをサポートしています。 したがって、各アカウントは明示的に作成する必要があります。



各SQLデータベースサーバーで、指定したIPアドレスからのトラフィックのみを許可するようにファイアウォールを構成できます。 デフォルトでは、許可されたIPアドレスのリストは空です。 これにより、サービス拒否（DoS）攻撃のリスクが軽減されます。 クライアントとSQLデータベース間で転送されるすべてのデータは、SSLを使用して暗号化する必要があります。 クライアントは、Encrypt = Trueパラメーターを使用して接続する必要があります。これにより、「悪意のある中間者」攻撃の脅威が排除されます。 DoS攻撃のリスクをさらに減らすために、DoSGuardサービスを使用して、同じIPアドレスからのログインエラーを一定期間監視し、これらのIPアドレスからすべてのリソースへのアクセスをブロックできます。

SQLデータベースの開発者向けガイドライン

SQL Database用のSQL Serverアプリケーションの開発は、SQL Serverのローカルインスタンス用のアプリケーションの開発と非常に似ていますが、いくつかの重要な違いがあります。

接続と切断

SQLデータベースを含むクラウドデータベースを使用する場合、プログラムコードでのそのような状況の処理を含む、予期しない切断を処理する準備をする必要があります。 切断を処理する最善の方法は、接続を再確立し、失敗したコマンドまたはクエリを実行することです。これが再試行ロジックの原則です。



ネットワークの問題が原因で接続が中断された場合、SQL Databaseはセッションを終了する前に意味のあるエラーメッセージをアプリケーションに返すことができません。 この接続を再利用しようとすると（SQL Serverへの接続プールの作成と同様）、トランスポートレイヤープロトコルエラーメッセージが表示されます。



他のデータベースと同様に、SQLデータベース環境は、エラー、システムリソースの不足、およびその他の一時的な問題により、時々中断します。 これらの状況では、アクティブな要求がクライアント接続から送信された場合、SQLデータベース環境は常に特定のエラーメッセージを返そうとします。 ただし、保留中の要求がない場合、クライアントアプリケーションにエラーを常に通知できるとは限りません。 たとえば、SQL Server Management Studioを使用してデータベースを操作しているときに30分以内にアクティブなクエリが送信されなかった場合、セッションはタイムアウトします。 アクティブなクエリがないため、SQLデータベース環境はエラーメッセージを返すことができません。

クラスターインデックスの要件

SQL Serverとは異なり、各SQLデータベーステーブルにはクラスター化インデックスが必要です。 テーブルの主キーを宣言すると、デフォルトで、主キーの列（またはキーのタイプに応じて複数の列）にクラスター化インデックスが作成されます。 主キークラスタインデックスは、クラスタ化インデックスを作成する唯一の方法ではありません。 これが最善の解決策ではない場合があります。 クラスター化インデックスは、キー値に基づいてテーブル内のデータ行を並べ替えて格納します。 データ行自体は1つの順序でのみソートできるため、各テーブルに存在できるクラスター化インデックスは1つだけです。 各テーブルのクラスター化インデックスの存在を制御する必要があります。



SQL Databaseは、HEAPテーブルの作成をサポートしていません。 HEAPテーブルは、クラスター化インデックスを持たないテーブルです。 このルールは、SQLデータベースにのみ適用されます。 一時テーブルは、データセンターのSQL Serverのサービスインスタンスの一部であるtempdbデータベースにあります。 これらのテーブルは、HEAPテーブルにすることができます。



クラスターインデックスを持つテーブルに追加の非クラスター化インデックスを作成する場合、これらの追加のインデックスはクラスターキーを使用してテーブルデータを参照します。 SQL Serverでは、非クラスター化HEAPデータインデックスはその物理アドレスを使用してこのデータを参照します。 複数のSQL Databaseデータベースを同じSQL Serverデータベースに保存できます。 したがって、物理ストレージアドレスへのリンクを使用すると、SQLデータベースシステムの柔軟性が大幅に低下します。



SQL ServerおよびSQL Databaseのすべてのインデックスは、バランスの取れたツリーとして保存されます。 SQL Databaseの高可用性とレプリケーションのコアテクノロジーは、バランスの取れたツリーシーケンスのレプリケーションに基づいています。 この構造により、コンピューターを互いに独立して保守できます。 システムは、HEAPテーブルを操作するときに提供できない最適化されたI / Oを利用します。

トランザクション管理

SQL Databaseは、通常のTransact-SQLコマンドを使用したローカルトランザクションをサポートします。これは、同様のSQL Serverコマンドと完全に一貫しています。



SQLデータベース設定は、スナップショットを分離します。 READ_COMMITTED_SNAPSHOTおよびALLOW_SNAPSHOT_ISOLATIONパラメーターはオンです。 デフォルトでは、SQL ServerおよびSQL DatabaseにはREAD COMMITTED分離レベルが設定されています。 READ_COMMITTED_SNAPSHOTデータベースパラメータも使用されるため、SQLデータベース環境のトランザクションはオプティミスティック同時実行モードで実行されます。 SQLデータベースの設定を変更できません。 ただし、トランザクションを開始する前にSET TRANSACTION ISOLATION LEVELコマンドを発行することにより、分離レベルを制御できます。 ユーザーは、オプティミスティックな同時実行を使用する場合はデフォルト値（READ COMMITTED）を変更できず、ペシミスティックな同時実行を使用する場合はSQL Serverのデフォルト値（READ COMMITTED）を設定できません。 SQL Serverでデフォルトの作業メカニズムを実装する唯一の方法は、各トランザクションの各テーブルで作業するときに、WITH特殊ロック技術（READCOMMITTEDLOCK）を使用することです。

トラブルシューティング

ユーザーは、リソースの物理的な割り当てや、使用するコンピューターとデータベースファイルの構成を制御できません。 したがって、システムにはトラブルシューティングの最小要件があります。 クエリ処理のパフォーマンスの低下や並列処理の問題（ブロッキングなど）が見つかった場合は、トラブルシューティングが必要になる場合があります。 デフォルトのSQLデータベース分離レベルは、READ COMMITTED SNAPSHOTに設定されています。 したがって、ユーザーは深刻なブロッキングの問題を解決する必要はありません。



ロックまたは最適でない実行計画のトラブルシューティング手法は、SQLデータベースとSQL Serverでほぼ同じです。 SQL Serverと同様に、基本的なトラブルシューティングツールの一部は、動的管理ビュー（DMV）として利用できます。 ただし、SQL Databaseは、SQL Serverが提供する動的管理ビューの一部のみをサポートし、利用可能な動的管理ビューの一部には異なるメカニズムがあります。 たとえば、SQL Serverでは、多くのビューのコンテンツを表示するにはVIEW SERVER STATE権限が必要であり、SQL DatabaseのVIEW DATABASE STATE権限はユーザーに必要です。 SQL Serverでは、sys.dm_tran_locks、sys.dm_exec_requests、およびsys.dm_exec_query_statsビューに、サーバーインスタンス全体のプロシージャとクエリの詳細が表示されます。 SQLデータベース環境では、これらのビューはSQLデータベースに関する情報のみを返します。 サポートされている動的管理ビューの詳細については、「メタデータ」セクションを参照してください。

合計

全体として、SQL Databaseは、スケーリング、フォールトトレランス、およびワンクリック使用（またはワンクリックの隣）向けに設計された、特別に設計されたクラウドベースのリレーショナルデータベースであることがわかります。 SQL DatabaseとSQL Serverを比較すると、SQL DatabaseはSQL Serverの正確なコピーではありませんが、SQL Serverの最も興味深い機能が次第にSQL Databaseで利用可能になります（ クラウドベースのSQL Reportingなど ）。



PS。 シャーディングとフェデレーションのリソース：

1. SQLデータベースを使用したシャーディング-このドキュメントは、シャーディングと呼ばれる水平データパーティションを持つアプリケーションを構築するためのガイドです。 その中のデータは、いくつかの物理データベースに分散されます。これにより、アプリケーションまたはサービスが成長し、データの量が増えるにつれて、アプリケーションまたはサービスのスケーラビリティが確保されます。
2. SQLデータベースフェデレーションの最初の知り合い -この記事では、SQLデータベースのフェデレーションとは何か、なぜフェデレーションが必要なのかという質問に答えます。
3. SQLデータベースのフェデレーション-SQLデータベースのフェデレーション実装の詳細な説明。