SQLデータベース間でのデータの共有
一度は作成しなかった問題を解決しようとしています。
私は、さまざまなサーバー上のさまざまなデータベースに支えられた多くのWebアプリがある環境で作業しています。
各データベースは、設計とアプリケーションがかなりユニークですが、抽象化したい共通のデータがまだ残っています。たとえば、各データベースには、ベンダーテーブル、ユーザーテーブルなどがあります。
この共通データを単一のデータベースに抽象化したいが、他のデータベースにこれらのテーブルを結合させ、制約を適用するためのキーさえ持たせたい... MsSql環境にいる。
利用可能なオプションは何ですか？私の見方では、次のオプションがあります。
- リンクサーバー
- ビューへのアクセスを許可するログインのみを読み取ります
他に考慮すべきことはありますか？
この問題に対処する方法はたくさんあります。ビジネスニーズに応じて、ソリューション1、2、または3を強くお勧めします。
トランザクションレプリケーション ：共通データベースがアカウントのレコードであり、データの読み取り専用バージョンを別のアプリケーションに提供したい場合は、コアテーブルを複製できます。テーブル、各個別のサーバーに。このアプローチの利点の1つは、必要な数のサブスクライバーデータベースに複製できることです。これは、サブスクライバーが使用できるテーブルとフィールドをニーズに基づいてカスタマイズできることも意味します。したがって、1つのアプリケーションがベンダーテーブルではなくユーザーテーブルを必要とする場合、ユーザーテーブルのみをサブスクライブします。別のベンダーがユーザーテーブルではなくベンダーテーブルのみを必要とする場合は、ベンダーテーブルのみをサブスクライブできます。もう1つの利点は、レプリケーション自体が同期されたままであり、問題が発生した場合はいつでもサブスクリプションを再初期化できることです。
トランザクションレプリケーションを使用して、データウェアハウスから100以上のテーブルをプッシュし、複数のシステムからの集約データへのアクセスを必要とするダウンストリームアプリケーションを分離しました。データウェアハウスは、ミラーおよびログ配布のデータソースから1時間ごとに更新されるため、本番アプリケーションには、毎時20〜80分のスライディングウィンドウ内に多数のシステムからのデータがありました。
ピアツーピアトランザクションレプリケーション パブリケーションタイプは、指定したユースケースに適している場合があります。これは、ノードごとにスキーマまたはレプリケーションの変更をロールアウトする場合に非常に役立ちます。標準のトランザクションレプリケーションには、この領域でいくつかの制限があります。
スナップショットレプリケーションのパブリケーションタイプは、トランザクションパブリケーションよりも待機時間が長くなりますが、ある程度の待機時間が許容できる場合は、それを検討する必要があります。
Microsoft SQL Serverショップであるとおっしゃっていましたが、他のRDBMにも同様のテクノロジーがあることに注意してください。 MS SQL Serverについて具体的に説明しているため、トランザクションレプリケーションではOracleデータベースへのレプリケーションも可能です。したがって、組織内にこれらがいくつかある場合でも、このソリューションは機能します。
トランザクションレプリケーションを使用することのマイナス面は、中央サーバーがダウンした場合、レプリケートされたオブジェクトのダウンストリームコピーのデータで遅延が発生し始める可能性があることです。レプリケートされたオブジェクト（記事）が本当に大きく、テーブルを再初期化する必要がある場合も、実行に非常に長い時間がかかる可能性があります。
Mirrors ：ダウンストリームサーバーのデータベースにほぼリアルタイムでアクセスできるようにする場合は、最大2つの非同期ミラーを設定できます。この方法でデータをCRMアプリケーションに統合しました。すべての読み取りは、結合からミラーへのものです。すべての書き込みはメッセージキューにプッシュされ、中央の運用サーバーに変更が適用されました。このアプローチの欠点は、2つを超える非同期ミラーを作成できないことです。災害復旧にもミラーを使用する予定がない限り、この目的で同期ミラーを使用することは望ましくありません。
メッセージングシステム ：単一の中央データベースからのデータを必要とする多数の個別のアプリケーションがあることが予想される場合は、IBM Web Sphere、Microsoft BizTalk、Vitria、TIBCOなどのエンタープライズメッセージングシステムを検討することをお勧めします。これらのアプリケーションは、この問題に対処するために特別に構築されています。これらは、実装と保守が高価で扱いにくい傾向がありますが、グローバルに分散されたシステムや、すべてがある程度データを共有する必要がある数十の個別のアプリケーションがある場合は、スケールアップできます。
リンクサーバー ：これはもうお気に召したようですね。リンクサーバーを介してデータを公開できます。これは良い解決策だとは思いません。本当にこのルートを使用したい場合は、中央データベースから別のサーバーへの非同期ミラーをセットアップしてから、ミラーへのリンクサーバー接続をセットアップすることを検討してください。これにより、少なくともWebアプリケーションからのクエリが中央の本番データベースでブロッキングまたはパフォーマンスの問題を引き起こすリスクが軽減されます。
IMO、リンクサーバーは、アプリケーションのデータを共有するための危険な方法である傾向があります。このアプローチでも、データはデータベースで二級市民として扱われます。特に開発者がさまざまな接続方法のさまざまな言語のさまざまなサーバーで作業している可能性があるため、かなり悪いコーディング習慣につながります。誰かがあなたのコアデータに対して本当におかしなクエリを書くかどうかはわかりません。共有データの完全なコピーを非コアサーバーにプッシュする必要がある標準を設定した場合、開発者が不正なコードを作成するかどうかを心配する必要はありません。少なくとも、その貧弱なコードが他の適切に記述されたシステムのパフォーマンスを危険にさらすことはないという観点からです。
リンクサーバーの使用がこのコンテキストで不適切である理由を説明するリソースは数多くあります。 （a） リンクサーバーに使用するアカウントにはDBCC SHOW STATISTICS権限が必要です。そうでない場合、クエリは既存の統計を利用できません 、（b）クエリOPENQUERYとして送信されない限り、ヒントは使用できません。（c）OPENQUERYと一緒に使用するとパラメーターを渡すことができません。（d）サーバーにリンクサーバーに関する十分な統計がないため、かなりひどいクエリプランが作成されます。 （e）ネットワーク接続の問題が原因で障害が発生する可能性があります、（f） これら5つのパフォーマンスの問題のいずれか 、および（g） Windows Active Directory資格情報を認証しようとしたときの恐ろしいSSPIコンテキストエラーダブルホップシナリオ 。リンクサーバーは特定のシナリオで役立つ場合がありますが、技術的には可能ですが、この機能を中心に中央データベースへのアクセスを構築することはお勧めしません。
バルクETLプロセス：Webアプリケーションで高度なレイテンシが許容できる場合、SQL Serverエージェントによって実行される SSIS（このStackOverflowの質問にある多数の適切なリンク） を使用してバルクETLプロセスを記述できます。サーバー間でデータを移動するジョブ。 Informatica、Pentahoなどの他の代替ETLツールもあるので、最適な方法を使用してください。
待ち時間を短くする必要がある場合、これは適切なソリューションではありません。高レイテンシを許容できるフィールド用にサードパーティがホストするCRMソリューションに同期するときに、このソリューションを使用しました。高レイテンシ（基本的なアカウント作成データ）を許容できないフィールドについては、アカウント生成の時点でWebサービス呼び出しを介してCRMに重複レコードを作成することに依存していました。
毎晩のバックアップと復元：データが高度なレイテンシ（最大1日）と使用不可の期間を許容できる場合、環境全体でデータベースをバックアップおよび復元できます。これは、100％の稼働時間を必要とするWebアプリケーションには適したソリューションではありません。アイデアは、ベースラインバックアップを取り、それを別の復元名に復元し、新しいデータベースが使用可能になったらすぐに元のデータベースと新しいデータベースの名前を変更することです。一部の内部Webサイトアプリケーションでこれが行われるのを見てきましたが、通常、この方法はお勧めしません。これは、本番環境ではなく、開発環境が低い場合に適しています。
ログ配布セカンダリ ：プライマリと任意の数のセカンダリ間のログ配布を設定できます。これは、データベースをより頻繁に更新できることを除いて、毎晩のバックアップおよび復元プロセスに似ています。 1つの例では、このソリューションを使用して、2つのログ配布受信者を切り替えることにより、ダウンストリームユーザー向けに主要なコアシステムの1つからデータを公開しました。 2つのデータベースをポイントし、新しいデータベースが利用可能になるたびにそれらを切り替える別のサーバーがありました。私はこのソリューションが本当に嫌いですが、この実装を見たときにビジネスのニーズを満たしました。
また、一般的なデータストアとアプリDB間の組み込みSQL Serverレプリケーションの使用を検討することもできます。私の経験から、それは双方向のデータ転送に最適であり、外部キーの使用を可能にする各dbのテーブルのインスタンスがあります（リンクサーバーを介してFKが可能ではないと思います）。
他のオプションもあるかもしれませんが、リンクされたサーバーとビューを組み合わせた最良のオプションの正しい道だと思います。これは、新しいデータベースを作成し、2つのリンクサーバーを追加し、権限を設定して、必要なビューを作成するのと同じくらい簡単です。
あなたの目標がabstract out this common data to a single database but still let the other databases join on these tables, even have keys to enforce constraintsその後、このソリューションは正常に機能します。
欠点としては、リンクサーバーでパフォーマンスの問題が発生する可能性があるため、データベースに大量のトラフィックが発生することが予想される場合は、Dougまたはmwebberが提案する方法を使用して実際にデータを移動することを検討する必要があります。
リンクサーバールートを使用する場合は、OPENQUERYに reading up をお勧めします。 OPENQUERYと4つのパーツ識別子 here に関する良い記事があります。
Microsoft Sync Framework をご覧ください。同期アプリを作成する必要がありますが、必要な柔軟性が得られる場合があります。
多くの回答が述べているように、特に高TPS環境で、または多くのテーブルでこれが必要な場合は、レプリケーションをよく見る必要があると思います。ただし、リンクサーバー、類義語、およびチェック制約を使用して、いくつかのシステムで指定された目標を達成する方法について、いくつかのコードを提供します。
この一般的なデータを単一のデータベースに抽象化したいが、他のデータベースにこれらのテーブルを結合させ、制約を強制するためのキーさえ持たせたい
データベース内のビューまたは synonym をリンクサーバー（または他のローカルDB）の共通テーブルに設定できます。ビューがちょうどselect * from tableとにかく。
権限がある場合、テーブルシノニムを使用すると、リモートアイテムでDMLを実行できます。
ただし、この時点では、ビューまたはシノニムへの外部キーを持つことはできませんが、チェック制約を使用して同様のことを実現できます。
いくつかのコードを見てみましょう：
create synonym MyCentralTable for MyLinkedServer.MyCentralDB.dbo.MyCentralTable
go
create function dbo.MyLocalTableFkConstraint (
@PK int
)
returns bit
as begin
declare @retVal bit
select @retVal = case when exists (
select null from MyCentralTable where PK = @PK
) then 1 else 0 end
return @retVal
end
go
create table MyLocalTable (
FK int check (dbo.MyLocalTableFKConstraint(FK) = 1)
)
go
-- Will fail: -1 not in MyLinkedServer.MyRemoteDatabase.dbo.MyCentralTable
insert into MyLocalTable select -1
-- Will succeed: RI on a remote table w/o triggers
insert into MyLocalTable select FK from MyCentralTable
もちろん、中央のテーブルで参照されているレコードを削除してもエラーにならないことに注意することが重要です。