SQL Serverアプリケーションをスケールアウトしてワークロードを向上させるオプション

投稿日: 2017年8月21日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

大量の処理負荷を満たすためにデータべースをスケールアウトすることは難しいことです。SQL Serverのスケーラビリティメソッドの詳細は、ここをクリックしてください。

SQL Serverの管理者にとって大きな課題の1つは、より重いデータ処理作業負荷に対応するために、常にデータベースを拡張することでした。問題を複雑にするMicrosoftには、さまざまなSQL Serverのスケーラビリティオプションが用意されていますが、すべての状況に対応できるわけではありません。

まず、SQL Serverアーキテクチャをスケールアウトするかどうかの基本的な質問があります。前者は、より多くのプロセッサ、メモリ、およびデータストレージを備えたより大きなサーバにデータベースを移動することです。後者はSQL Serverアプリケーションを複数のサーバに拡張し、データ処理の負荷を分散し潜在的なデータの冗長性と可用性の利点を提供します。

ここでは、SQL Serverをスケールアウトするさまざまな方法に焦点を当てます。どのスケーラビリティ・メソッドを使用するかを決定する前に、データベース管理者は、データ更新の頻度、異なるデータベース間でデータをパーティション化できるかどうか、SQL Server上で実行されるアプリケーションを変更できるかどうかなどの要素を考慮する必要があります。その答えを手に入れて、彼らは特定のニーズを満たすスケールアウト計画を立てることができます。

これらの回答を見つけるために、一般的に使用されているSQL Serverスケールアウトアプローチの基本的な詳細をMicrosoftが投稿した技術情報から集約しています。

スケーラブルな共用データベース
データベースはデータベースサーバー上に物理的に配置する必要はありません。ストレージエリアネットワーク(SAN)に配置する代わりに、異なるサーバー上で実行されている複数のSQL Serverインスタンスによって同時にデータにアクセスできます。本質的に、SANに接続されている各インスタンスは、同じデータベースコピーから動作します。

このスケーラビリティメソッドは通常、SQL Serverアプリケーションを変更することなく使用できます。しかし、大きな欠点は、静的な日付のワークロードにのみ適していることです。スケーラブルな共有データベースは、複雑なクエリ(データウェアハウスなど)を伴う読み取り集中型アプリケーションでは非常によく機能します。

ただし、スケーラブルな共用データベースは、読み書き操作が混在するアプリケーションには適していません。データを書き込こむときにSQL Serverデータベースにロックが設定されます。データを共有データベースに書き込む場合は、書き込み操作が完了するまで、1つを除くすべてのSQL Serverインスタンスが一時的にデータからデータを取得します。その結果、書き込み操作はデータベースのパフォーマンスに悪影響を及ぼします。

分散パーティションビュー
スケーラブルな共有データベースとは異なり、SQL Serverのワークロードをスケールアウトするこの手法は、頻繁に更新されるデータに対してうまく機能し、オンライントランザクション処理（OLTP）アプリケーションに適しています。欠点を挙げるとすれば、データを分割する必要があることです。 また、データベースアプリケーションでは、すべてのパーティションで処理操作を同期させるための変更が必要になる可能性があります。

分散パーティションビューアプローチの背後にあるコンセプトはシンプルさです。大規模データベースのデータは、いくつかの小さな分散データベースに分類されます。たとえば、請求書を含むデータベースを年ごとに分割することができます.2016年の請求書をあるデータベースに配置し、2017年の請求書を別のデータベースに入れることができます。 関連するデータが含まれているデータベースに対して、更新と照会を実行することができます。

データ依存型ルーティング
これは基本的に、大量のOLTPアプリケーション用に設計された分散パーティションビューのバリエーションです。データベースも同様に一連の小さなデータベースに分類されます。 違いは、クエリを正しいデータベースにルーティングするプロセスがどのように管理されるかです。分散パーティションビューでは、SQL Server自体がデータパーティション構造を認識し、要求されたデータにアクセスする場所を決定します。これに対して、データ依存型ルーティングの場合、SQL Serverアプリケーションまたはミドルウェアサービスは、必要なデータがどこにあるかを決定します。

リンクサーバー
SQL Serverは、ローカルデータベースのようにリモートデータベースにアクセスできます。そのため、スケールアウトされたデータベースのコレクションを単一の大きなデータベースのように扱うようにソフトウェアを構成することが可能です。リンクされたサーバーは、既存のSQL Serverアプリケーションを簡単に変更して別のスケールアウト手法をサポートできない場合に実行可能な代替手段を提供します。

ただし、SQL Serverは一連の独立したデータベースに接続するため、SQL Server間の正式な結合はできません。ローカルテーブルとリモートテーブル間の参照整合性の欠如など、SQL Server内のいくつかの制限に加えて、リモートデータベースへのアクセスにはかなりの処理オーバーヘッドがあります。リンクサーバーを必要とするSQLサーバーアーキテクチャーは、特にローカルリモートテーブル間のジョインを介して、リモートデータにアクセスする必要性を最小限に抑えるように設計する必要があります。

ピアツーピアレプリケーション
SQL Serverアプリケーションをスケールアウトするもう1つのメカニズムは、異なるサーバー間でデータをレプリケーションすることです。ピア・ツー・ピアレプリケーションは、本質的に、スケーラブルな共有データベース・メソッドの逆です。複数のデータベースサーバーがデータベースの1つのコピーを共有するのではなく、それぞれ独自のコピーが含まれています。データに動きがあると、その変更はすべてのコピーにレプリケーションされます。

ピア・ツー・ピア・レプリケーションは、比較的大きい数のデータベース書き込みを処理できますが、比較的静的なデータに用いるのが最適です。しかし、レプリケーションプロセスに伴うレイテンシのため、非常に時間に敏感なデータには適していません。また、書き込みよりも多くの読み込みを処理する場合に汎用性が高いのは、スケーラビリティオプションです。

関連したトピックス

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。