複数サイトからのデータの統合 (クライアント)
多くの企業では、データを収集して処理する支社や事業所があり、データを中央に送信する必要があります。以下に例を示します。
在庫データを、地方の倉庫にある多数のサーバーから、本社にある中央のサーバーに集約します。
企業内の独立ビジネス部門の情報を、中央のサーバーに送信します。
分散した場所からの注文処理情報を集約します。
場合によっては、中央サイトからリモート サイトにデータを送ることもあります。一般にこのデータは、中央サイトだけで更新する製品在庫テーブルなどのように、リモート サイトでは読み取り専用になります。
次の図は、中央サイトとリモート サイトとの間で双方向のデータ フローが発生する一般的なシナリオを示しています。
.gif "支社へのデータのレプリケーション")
この図で、データはまずハブに送られ、その後ハブがサービスを提供している支社に送られます。組織に中間層がない場合は、中央サイトと支社の間で直接データがやり取りされることもあります。
Adventure Works Cycles の例
Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。詳細については、「AdventureWorks2008R2 サンプル データベース」を参照してください。
Adventure Works Cycles には、世界中に多数の営業所があります。各営業所では、その地域の営業担当者から得たデータを収集します。このデータは支社のハブに送信され、各営業日の最後に中央サイトに送信されます。営業所が価格と販売促進に関する最新の情報を得られるように、データも中央サイトからハブを介して各営業所に送られます。
このシナリオの一般的な要件
支社のアプリケーションには一般的に以下のような特性があり、適切なレプリケーション ソリューションで対処する必要があります。
データは、中央サイトとリモート サイトで入力および更新されます。
リモート ユーザーは、中央サイトに接続することなく独立して更新できることが必要です。
複数のユーザーが同じデータを別々に更新する可能性があるため、データの競合の問題に対処する必要があります。
製品の価格テーブルのデータなど、一部のデータは中央サイトでのみ更新されます。
ユーザーは、要求時またはスケジュールされた時刻にデータを同期する必要があります。
アプリケーションは、リモート サイトが非同期のままでいられる期間を制御する必要があります。
各ユーザーが 1 つ以上のテーブルに対して異なるデータを受信できるように、一部のテーブルではフィルタ選択が必要です。たとえば、支社では、その支社の区域内の顧客についてのみ連絡先情報を受け取ります。
一部のデータは、サイト間で転送される際に 1 つの単位として扱う必要があります。たとえば、リモート ユーザーから中央サイトに注文を送信する際には、注文のヘッダーを注文の詳細より先にコミットする必要があります。
データが同期された時点で実行されるカスタム ビジネス ロジックが必要な場合があります。
専用接続ではなくインターネットを経由したデータの同期が必要になる場合があります。
このトピックで説明した図のように、中央サイトとリモート サイトとの間で 1 つ以上の中間層を経由してデータを受け渡すように業務を編成する場合があります。
次の図は、このシナリオに関連するフィルタ選択を示しています。
.gif "支社のアプリケーションのフィルター選択")
このシナリオで使用するレプリケーションの種類
Microsoft SQL Server では、出版業界にたとえてレプリケーション システムのコンポーネントを表しています。コンポーネントには、パブリッシャ (出版社)、サブスクライバ (購読者)、パブリケーション (出版物) とアーティクル (記事)、およびサブスクリプション (定期購読物) があります。上記の図では、中央サイトがパブリッシャです。中央サイトのデータはパブリケーションで、各データ テーブルはアーティクルです (アーティクルはストアド プロシージャなどの他のデータベース オブジェクトの場合もあります)。各ハブはパブリケーションのサブスクライバで、サブスクリプションとしてスキーマとデータを受信します。次にハブはデータを再パブリッシュし、支社がこのデータをサブスクライブします。システムのコンポーネントの詳細については、「レプリケーションのパブリッシング モデルの概要」を参照してください。
SQL Server では、さまざまなアプリケーション要件に対して各種のレプリケーション (スナップショット レプリケーション、トランザクション レプリケーション、およびマージ レプリケーション) を用意しています。このシナリオはマージ レプリケーションによる実装が最適で、前のセクションで概説した要件によく適合します。マージ レプリケーションの詳細については、「マージ レプリケーションの概要」および「マージ レプリケーションの動作方法」を参照してください。
.gif "重要な注意事項") 重要 |
|---|
このシナリオは 2 つの方法で実装することが可能です。本社をパブリッシャとし、支社をサブスクライバとする方法と、本社をサブスクライバとし、支社をパブリッシャとする方法です。マージ レプリケーションでは、中央にサブスクライバがあるようなトポロジはサポートされません。すべての変更がリモート サイトで起きる場合でも、本社をパブリッシャ、リモート サイトをサブスクライバとする必要があります。同様のシナリオを、中央にサブスクライバがあるトポロジを使用して、トランザクション レプリケーションで実装することもできます。各リモート サイトに一意のデータセットを提供する競合解決またはフィルタ選択がアプリケーションに不要な場合には、トランザクション レプリケーションの使用を検討してください。詳細については、「複数サイトからのデータの統合 (サーバー)」を参照してください。 |
このシナリオに関連するマージ レプリケーションのオプション
マージ レプリケーションでは、このトピックで先に説明した要件に対応するための、いくつかのオプションが用意されています。以下に、各要件とそれに対応するマージ レプリケーション オプションの一覧を示します。
データは、中央サイトとリモート サイトで入力および更新されます。
マージ レプリケーションでは、別のオプションを指定する必要はありません。
リモート ユーザーは、中央サイトに接続することなく独立して更新できることが必要です。
マージ レプリケーションでは、別のオプションを指定する必要はありません。
複数のユーザーが同じデータを別々に更新する可能性があるため、データの競合の問題に対処する必要があります。
マージ レプリケーションは、データの競合が予測される場合には競合の検出と解決策を提供します。競合が発生しないようにアプリケーションを設計するのが理想的ですが、それが不可能な場合は、既定の競合解決メカニズム (最初のデータを優先) やカスタムの競合解決を使用できます。詳細については、「マージ レプリケーションの競合の検出と解決」を参照してください。
製品の価格テーブルのデータなど、一部のデータは中央サイトでのみ更新されます。
マージ レプリケーションでは、パブリッシャでのみ更新されるテーブルのダウンロード専用アーティクルが提供されます。詳細については、「ダウンロード専用アーティクルを使用したマージ レプリケーションのパフォーマンス最適化」を参照してください。
ユーザーは、要求時およびスケジュールされた時刻にデータを同期する必要があります。
レプリケーションでは、プッシュ サブスクリプションとプル サブスクリプションの 2 種類のサブスクリプションを使用できます。要求時の同期処理には、プル サブスクリプションの方が適しています。サブスクリプションの種類および同期処理のスケジュールの詳細については、「パブリケーションのサブスクライブ」および「データの同期」を参照してください。
アプリケーションは、リモート サイトが非同期のままでいられる期間を制御する必要があります。
マージ レプリケーションでは、すべてのサブスクライバが特定の期間内に同期されるように、サブスクリプションの有効期限を設定できます。詳細については、「サブスクリプションの有効期限と非アクティブ化」を参照してください。
各ユーザーが 1 つ以上のテーブルに対して異なるデータを受信できるように、一部のテーブルではフィルタ選択が必要です。たとえば、各営業担当者は、自分が担当している顧客に関する連絡先情報だけを受け取ります。
マージ レプリケーションでは、列と行をフィルタ選択することができます。行フィルタには、静的なものと、パラメータ化されたものがあります。静的フィルタは、パブリケーションの作成時にのみ適用されます。1 つのデータセットが生成されます。パラメータ化されたフィルタは、サブスクライバが同期されるたびに適用されます。各サブスクライバごとに別々のデータセットが生成されます。支社のアプリケーションでは、多くの場合にパラメータ化されたフィルタが使用されますが、静的フィルタも使用できます。詳細については、「マージ レプリケーション用にパブリッシュされたデータのフィルター選択」を参照してください。
一部のデータは、サイト間で転送される際に 1 つの単位として扱う必要があります。たとえば、リモート ユーザーから中央サイトに注文を送信する際には、注文のヘッダーを注文の詳細より先にコミットする必要があります。
マージ レプリケーションでは、関連するテーブルのセットを 1 つの単位として処理するように指定できます。この単位を論理レコードと呼びます。詳細については、「論理レコードによる関連行への変更のグループ化」を参照してください。
データが同期された時点で実行されるカスタム ビジネス ロジックが必要な場合があります。
マージ レプリケーションでは、同期時に実行するコードを指定することができます。このコードはさまざまなイベントに対応し、同期対象のデータにアクセスできます。詳細については、「マージ同期中のビジネス ロジックの実行」を参照してください。
専用接続ではなくインターネットを経由したデータの同期が必要になる場合があります。
(SQL Server Compact 3.5 SP2) を使用する場合、データは HTTP 接続または HTTPS 接続を経由して同期されます。SQL Server の他のエディションでは、Web 同期が利用できます。この場合は HTTPS が必要です。詳細については、「マージ レプリケーションの Web 同期」を参照してください。
中央サイトとリモート サイトとの間で 1 つ以上の中間層を経由してデータを受け渡すように業務を編成する場合があります。
マージ レプリケーションでは、再パブリッシュを利用してこの要件に対応できます。この方法では、中央のパブリッシャが 1 つ以上のサブスクライバにデータをパブリッシュし、さらにサブスクライバが他のサブスクライバにデータをパブリッシュします。詳細については、「データの再パブリッシュ」を参照してください。
このシナリオの実装手順
このシナリオを実装するには、最初にパブリケーションとサブスクリプションを作成してから、各サブスクリプションを初期化してください。各手順の詳細については、以下のリンクをクリックしてください。
サブスクリプションの初期化が終わり、パブリッシャとサブスクライバの間でデータ フローが発生したら、共通の管理および監視作業の詳細について、必要に応じて以下のトピックを参照してください。