私は問題を解決しようとしていますが、それは私が作成したものではありません。
私は、さまざまなサーバー上のさまざまなデータベースに支えられた多くの Web アプリがある環境で働いています。
各データベースは、その設計とアプリケーションがかなりユニークですが、抽出したい共通のデータがそれぞれに残っています。たとえば、各データベースには、vendors テーブル、users テーブルなどがあります。
この共通データを単一のデータベースに抽象化したいと思いますが、他のデータベースをこれらのテーブルに参加させたり、制約を適用するためのキーを持ったりすることもできます... 私は Msql 環境にいます。
利用可能なオプションは何ですか? 私の見方では、次のオプションがあります。
他に考慮すべきことはありますか？
この問題に取り組む方法はたくさんあります。ビジネス ニーズに応じて、ソリューション 1、2、または 3 のいずれかを強くお勧めします。
トランザクション レプリケーション: 共通データベースがアカウントの記録であり、データの読み取り専用バージョンを個別のアプリケーションに提供する場合は、コア テーブル (場合によってはテーブルのコア列だけでも) を個別のサーバーごとにレプリケートできます。このアプローチの利点の 1 つは、必要な数のサブスクライバー データベースにレプリケートできることです。これは、サブスクライバーのニーズに基づいて、サブスクライバーが使用できるテーブルとフィールドをカスタマイズできることも意味します。したがって、あるアプリケーションがベンダー テーブルではなくユーザー テーブルを必要とする場合は、ユーザー テーブルのみをサブスクライブします。ユーザー テーブルではなく、ベンダー テーブルのみが必要な場合は、ベンダー テーブルのみをサブスクライブできます。もう 1 つの利点は、レプリケーション自体が同期を維持し、問題が発生した場合にいつでもサブスクリプションを再初期化できることです。
私はトランザクション レプリケーションを使用して、データ ウェアハウスから 100 を超えるテーブルをプッシュし、複数のシステムから集約されたデータにアクセスする必要があるダウンストリーム アプリケーションを分離しました。当社のデータ ウェアハウスは、ミラーおよびログ配布データ ソースから 1 時間ごとにスケジュールされて更新されていたため、運用アプリケーションには、1 時間あたり 20 ～ 80 分のスライディング ウィンドウ内に多数のシステムからのデータがありました。
パブリケーション タイプとしてのピア ツー ピア トランザクション レプリケーションは、提供されたユース ケースにより適している可能性があります。これは、スキーマまたはレプリケーションの変更をノードごとにロールアウトする場合に非常に役立ちます。標準のトランザクション レプリケーションには、この領域でいくつかの制限があります。
スナップショット レプリケーション パブリケーションの種類は、トランザクション パブリケーションよりも待ち時間が長くなりますが、ある程度の待ち時間が許容できる場合は、それを考慮する必要があります。
あなたは Microsoft SQL Server ショップだとおっしゃいましたが、他の RDBM にも同様の技術があることを覚えておいてください。特にMS SQL Serverについて話しているので、トランザクションレプリケーションではOracleデータベースにもレプリケートできることに注意してください。したがって、組織内にこれらがいくつかある場合でも、このソリューションは引き続き機能します。
トランザクション レプリケーションを使用することの欠点は、中央サーバーがダウンした場合に、レプリケートされたオブジェクトのダウンストリーム コピーのデータで遅延が発生し始める可能性があることです。レプリケートされたオブジェクト (アーティクル) が非常に大きく、テーブルを再初期化する必要がある場合、それにも非常に長い時間がかかる可能性があります。
ミラー: ダウンストリーム サーバーでほぼリアルタイムでデータベースにアクセスできるようにする場合は、最大 2 つの非同期ミラーをセットアップできます。この方法で CRM アプリケーションとデータを統合しました。すべての読み取りは、ミラーへの結合から行われました。すべての書き込みはメッセージ キューにプッシュされ、中央の運用サーバーに変更が適用されました。このアプローチの欠点は、2 つ以上の非同期ミラーを作成できないことです。障害復旧にもミラーを使用する予定がない限り、この目的で同期ミラーを使用することは望ましくありません。
メッセージング システム: 単一の中央データベースからのデータを必要とする個別のアプリケーションが多数あることが予想される場合は、IBM Web Sphere、Microsoft BizTalk、Vitria、TIBCO などのエンタープライズ メッセージング システムを検討することをお勧めします。これらのアプリケーションは、この問題。それらは、実装と保守が高価で面倒になる傾向がありますが、グローバルに分散されたシステムや、ある程度データを共有する必要がある数十の個別のアプリケーションがある場合は、スケールアップできます。
Linked Servers : あなたはすでにこれを考えているようですね。リンクされたサーバーを介してデータを公開できます。これが良い解決策だとは思いません。本当にこの方法を使用したい場合は、中央データベースから別のサーバーへの非同期ミラーをセットアップしてから、ミラーへのリンク サーバー接続をセットアップすることを検討してください。これにより、Web アプリケーションからのクエリが中央の運用データベースでブロックやパフォーマンスの問題を引き起こすリスクが少なくとも軽減されます。
IMO、リンクされたサーバーは、アプリケーションのデータを共有するための危険な方法になる傾向があります. このアプローチでも、データはデータベース内の二流市民として扱われます。特に、開発者がさまざまな接続方法でさまざまな言語のさまざまなサーバーで作業している可能性があるため、かなり悪いコーディング習慣につながります. 誰かがあなたのコア データに対して真に厄介なクエリを作成するかどうかはわかりません。共有データの完全なコピーを非コア サーバーにプッシュすることを要求する標準を設定すると、開発者が不適切なコードを作成するかどうかを心配する必要がなくなります。少なくとも、彼らの貧弱なコードが他のよく書かれたシステムのパフォーマンスを危険にさらすことはないという観点からは.
このコンテキストでリンク サーバーを使用することがなぜ悪いのかを説明する、非常に多くのリソースがあります。(a)リンク サーバーに使用されるアカウントに DBCC SHOW STATISTICS アクセス許可が必要である、またはクエリが既存の統計を利用できない、(b) 次の場合を除き、クエリ ヒントを使用できない。 (c) OPENQUERY で使用するとパラメーターを渡すことができない、(d) サーバーにはリンク サーバーに関する十分な統計がないため、かなりひどいクエリ プランが作成される、(e) ネットワーク接続の問題が発生する可能性がある(f)これら 5 つのパフォーマンスの問題のいずれか、および (g)ダブルホップ シナリオで Windows Active Directory 資格情報を認証しようとすると、恐ろしい SSPI コンテキスト エラーが発生する. リンク サーバーは特定のシナリオで役立つ場合がありますが、この機能を中心に中央データベースへのアクセスを構築することは、技術的には可能ですが、お勧めできません。
一括 ETL プロセス: Web アプリケーションで高度な待機時間が許容される場合は、SQL Server エージェント ジョブによって実行されてサーバー間でデータを移動するSSIS を使用して一括 ETL プロセスを作成できます (この StackOverflow の質問には多くの適切なリンクがあります) 。Informatica、Pentaho などの他の代替 ETL ツールもありますので、最適なものを使用してください。
レイテンシを低く抑える必要がある場合、これは適切なソリューションではありません。私はこのソリューションを、サード パーティがホストする CRM ソリューションと同期するときに使用して、長い待ち時間を許容できるフィールドに使用しました。高い待ち時間を許容できないフィールド (基本的なアカウント作成データ) については、アカウント生成の時点で Web サービス呼び出しを介して CRM に重複レコードを作成することに依存していました。
毎晩のバックアップと復元: データが高度な待機時間 (最大 1 日) と使用できない期間を許容できる場合は、環境全体でデータベースをバックアップおよび復元できます。これは、100% の稼働時間を必要とする Web アプリケーションには適したソリューションではありません。ベースライン バックアップを取得し、それを別の復元名に復元し、新しいデータベースが使用可能になったらすぐに、元のデータベースと新しいデータベースの名前を変更するという考え方です。一部の内部 Web サイト アプリケーションでこれが行われているのを見てきましたが、一般的にこのアプローチはお勧めしません。これは、運用環境ではなく、下位の開発環境に適しています。
ログ配布のセカンダリ: プライマリと任意の数のセカンダリの間でログ配布をセットアップできます。これは、データベースをより頻繁に更新できることを除いて、夜間のバックアップと復元のプロセスに似ています。ある例では、このソリューションを使用して、2 つのログ配布受信者を切り替えることにより、主要なコア システムの 1 つからダウンストリーム ユーザーにデータを公開しました。2 つのデータベースを指し、新しいデータベースが利用可能になるたびに切り替える別のサーバーがありました。私はこのソリューションが大嫌いですが、この実装を見たときは、ビジネスのニーズを満たしていました。
他のオプションがあるかもしれませんが、リンク サーバーとビューの組み合わせを使用する最適なオプションを選択するのに適していると考えてください。これは、新しいデータベースを作成し、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ます。OPENQUERYvs 4 part identifiers hereに関する良い記事があります。
Microsoft Sync Frameworkをご覧ください。同期アプリを作成する必要がありますが、必要な柔軟性が得られる場合があります。