バッチ処理のオフロード
アプリケーションによっては、データに対して処理負担の大きなバッチ操作を実行する必要があります。多くの場合、これらのバッチ操作はオンライン トランザクション処理 (OLTP) サーバーでは実行できません。これは、処理のオーバーヘッドが、サーバー上の他の操作に干渉するためです。この場合、バッチ処理を独立したサーバー上で実行する必要があります。場合によっては、バッチ処理のオフロードが単純に軽減されます。その他の場合は、バッチ処理の結果をオンライン処理サーバーに反映させます。
次の図に、データがバッチ処理サーバーにレプリケートされる典型的なシナリオを示します。
.gif "バッチ処理データのレプリケーション")
Adventure Works Cycles の例
Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。 詳細については、「サンプル データとサンプル データベース」を参照してください。
Adventure Works Cycles では、バッチ処理を使用して Web サイトでのクレジット カード詐欺を調べています。Web サイトのトランザクションから収集されたデータは、Web サイトを提供する Microsoft SQL Server から、多数の Adventure Works Cycles アプリケーションが使用する独立した SQL Server にレプリケートされます。バッチ処理サーバーでは、クレジット カード詐欺のパターンに関してデータがチェックされます。詐欺検出の手順では少量のデータしか生成されませんが (アカウントが疑わしいアクティビティを示す場合、少数の列でデータが更新されます)、確認作業は高い計算能力を必要とし、大量のサーバー リソースを消費します。バッチ処理の実行後は、少量のデータが Web サイトの OLTP サーバーに返され、詐欺の疑いのあるアカウントが示されます。
このシナリオの一般的な要件
バッチ処理アプリケーションは、通常は次のような要件があり、適切なレプリケーション ソリューションで対処する必要があります。
- システムでトランザクションの一貫性を保つ必要があります。
- システムの待機時間を短くするため、オンライン処理サーバーでの更新をバッチ処理サーバーにすばやく伝える必要があります。
- 多数のトランザクションのレプリケーションを処理できる、高いスループットが必要です。
- オンライン処理サーバーに対するレプリケーション処理のオーバーヘッドをできるだけ少なくする必要があります。
- データの変更が双方向に送られ、バッチ処理の結果がオンライン処理サーバーに反映される可能性があります。
- バッチ処理サーバーで必要なデータは、オンライン処理サーバーで利用可能なデータのサブセットである可能性があります。
このシナリオで使用するレプリケーションの種類
SQL Server では、出版業界にたとえてレプリケーション システムのコンポーネントを表しています。コンポーネントには、パブリッシャ (出版社)、サブスクライバ (購読者)、パブリケーション (出版物) とアーティクル (記事)、およびサブスクリプション (定期購読物) があります。
- 上記の図では、オンライン処理サーバーがパブリッシャです。パブリケーションには、オンライン処理サーバーの一部またはすべてのデータが含まれます。各データ テーブルはアーティクルです (アーティクルはストアド プロシージャなどの他のデータベース オブジェクトの場合もあります)。バッチ処理サーバーはパブリケーションのサブスクライバで、サブスクリプションとしてスキーマとデータを受信します。
- 結果がオンライン処理サーバーに反映される場合、バッチ処理サーバーもパブリッシャです (通常はオンライン処理サーバーにあるものと同じパブリケーションです)。オンライン処理サーバーがパブリケーションをサブスクライブします。
システムのコンポーネントの詳細については、「レプリケーションのパブリッシング モデルの概要」を参照してください。
SQL Server では、さまざまなアプリケーション要件に対して各種のレプリケーション (スナップショット レプリケーション、トランザクション レプリケーション、およびマージ レプリケーション) を用意しています。このシナリオはトランザクション レプリケーションで最適に実装され、前のセクションで概説した要件によく適合します。トランザクション レプリケーションの詳細については、「トランザクション レプリケーションの概要」および「トランザクション レプリケーションの動作方法」を参照してください。
トランザクション レプリケーションは、以下に示すこのシナリオの主な要件に対応するように作られています。
- トランザクションの一貫性
- 短い待機時間
- 高いスループット
- 最小限のオーバーヘッド
このシナリオで考慮するオプションには、フィルタ選択、ピア ツー ピア トランザクション レプリケーション、および双方向トランザクション レプリケーションがあります。
- トランザクション レプリケーションでは、バッチ処理サーバーはアプリケーションに必要なデータのみ含まれるように、列および行をフィルタ選択することができます。詳細については、「パブリッシュされたデータのフィルタ選択」を参照してください。
- トランザクション レプリケーションでは、ピア ツー ピア レプリケーションまたは双方向オプションを利用して、複数方向で変更を反映させることができます。詳細については、「ピア ツー ピア トランザクション レプリケーション」および「双方向トランザクション レプリケーション」を参照してください。
このシナリオの実装手順
このシナリオを実装するには、最初にパブリケーションとサブスクリプションを作成してから、各サブスクリプションを初期化してください。各手順の詳細については、以下のリンクをクリックしてください。
- SQL Server Management Studio: ピア ツー ピア トランザクション レプリケーションを構成する方法 (SQL Server Management Studio)
- レプリケーション Transact-SQL プログラミング : ピア ツー ピア トランザクション レプリケーションを構成する方法 (レプリケーション Transact-SQL プログラミング)
- 双方向トランザクション レプリケーション
サブスクリプションの初期化が終わり、パブリッシャとサブスクライバ間でデータ フローが発生したら、共通の管理および監視作業の詳細について以下のトピックを参照してください。