100以上のクライアントDBからのデータを一元化されたレポートデータベースに統合する方法に関するアドバイスを探す


10

私は小規模な(従業員数50人まで)SaaS企業のSQL開発者(DBAまたはアーキテクトではありません)です。私は次の方法を理解する必要があります。

  1. 100以上のOLTPデータベースから運用レポートをオフロード
  2. これらのレポートを複数のクライアントデータベースのデータに対して実行できるようにする
  3. 将来的に分析ベースのソリューションを提供するように当社を位置づける

トランザクションレプリケーション(特に多対1 /中央サブスクライバーモデル)、SQLサービスブローカー、ログ配布、変更追跡(CT)、および変更データキャプチャ(CDC)などのさまざまなテクノロジに関する記事をいくつか読んだことがあります。これは企業専用です)、どの経路が最適かはわかりません。

統合に関する専門知識をお持ちの方が、私たちと同様の設定に出会い、成功への道筋を示したり、役立つリソースに案内したりできることを願っています。

コストの制約により、このソリューションはSQL Server Standard Edition内で機能する必要があります。また、このソリューションは、小規模な組織内でサポート/維持するために合理的でなければなりません。

基本構成:

現在、100を超える個別のクライアントデータベースがあり、ほとんどがデータセンターのSQLサーバーに展開されていますが、一部はリモートアクセス可能なデータセンター内のクライアントサーバーに展開されています。これらはすべてSQL Server 2008 R2データベースですが、近日中にSQL 2016にアップグレードする予定です。

データベースプロジェクトとdacpacsを使用して、統合されるすべてのクライアントデータベースでスキーマが同じになるようにします。ただし、すべてのクライアントに同時に新しいバージョンへのアップグレードを強制するわけではないため、アップグレード間でスキーマが異なる場合があります。ソリューションは、クライアントAがソフトウェアバージョン1.0にあり、クライアントBがバージョン1.1にある場合に中断しないように十分に柔軟でなければなりません。

運用レポートは現在、各クライアントのOLTPデータベースから直接実行されます。これをオフロードしない場合、アプリケーションのパフォーマンスに与える影響を懸念しています。

高レベルの要件:

私たちのクライアントは、病院の無菌処理部門(SPD)で、これまでに処理したもの、在庫がある場所などに関する最新のレポートが必要です。SPDは、週末と休日を含め、24時間体制で在庫を処理します。この取り組みの主な目的の1つは運用レポートをより適切にサポートすることであるため、クライアントのニーズに対応し続けるために、データをできる限りリアルタイムに近づけることを望んでいます。

現在、実際には同じ病院システムの一部である個別のデータベースにいくつかのSPDがあります。これらのクライアントは、システム内のすべてのSPDに対してレポートを作成する機能を求めています。

戦略的に言えば、社内の分析イニシアチブをサポートするために、すべてのクライアントのデータを簡単に集約できる機能が必要です。収集した運用データをデータマート/倉庫のソースとして使用できることが期待されます。

これまでの考え:

トランザクションレプリケーションは、最も「リアルタイム」なソリューションを提供するようです。この応答が特に役立つことがわかりましたが、スキーマの違いが生じる可能性があるため、SQL Serverの多対1レプリケーションが機能しないことを懸念しています。

クエリがアクティブな間はログを復元できないので、ログ配布は理想的に聞こえません。ログを復元できるようにするには、全員を追い出す必要があります。そうしないと、データが古くなります。この方法が複数のデータベースからのデータを一元化するために使用できるかどうかは不明です。出荷される各ログは、それが由来する個々のデータベースに関するもののみであるためです。

SQLサービスブローカーを使用する場合、キューが処理するメッセージの数に対応できなかった場合、レイテンシは予測できない場合があります。

CTは、各テーブル行のバージョンのみを識別します。レイテンシは、データを取得して中央リポジトリに挿入するために、各データベースに対してSSISパッケージのようなものをどれだけ速く処理できるかに依存します。

各データベースを個別にレプリケートすることを検討する必要があり、その後、ある種のデータ仮想化手法を使用して、さまざまなレプリケートされたソースからのデータを組み合わせる必要があるでしょうか。

あなたが提供したいアドバイスや指示があれば、大歓迎です。


1
(ほぼ)リアルタイムの要件により、メッセージキューの実装(配信の保証)を伴うイベントベースの処理のみを取り上げます。これがお役に立てば幸い
グリマルディ2017年

1
HTAPをミックスに投入します。en.m.wikipedia.org/wiki/Hybrid_Transactional/… 共通ストアに入力するためのBIMLおよびSSIS。
マイケルグリーン

@ Grimaldi、SQLサービスブローカーを使用して、イベントベースの処理/メッセージキューまたはその他のメッセージングテクノロジーを実装することをお勧めしますか?
bperry 2017年

提案をありがとう、@ MichaelGreen。基本的に、HTAPでは、テーブルに非クラスター化列ストアインデックス(NCCI)を追加することで、OLTPとOLAPの両方に既存のデータベースを使用できるように見えます。レポートクエリはNCCIを使用するため、トランザクションオペレーションに干渉しません。SQL 2016には、Standard Edition(SE)のHTAPサポートが含まれていますが、列ストアキャッシュはSQLインスタンス全体で32GBに制限されているようです。同じインスタンスに数十のデータベースがあるため、これは問題になる可能性があります。microsoft.com/en-us/sql-server/sql-server-2016-editions
bperry 2017年

1
はい、列ストアですが、サーバーの仕様でアクセスできる場合はインメモリも使用できます。最近スニル・アガルワルがこれについて話しているのを聞いた。MSの経験則では、ゼロレイテンシレポートの利点のためにOLTPが約3%低下しました。残念ながら、無料のランチはありません。新しいインスタンスを作成してレポートDBを保持するか、新しいインスタンスを作成してHTAPをサポートするための十分なヘッドルームを確保できます。私はこのパターンを擁護していません。うまくいかないかもしれません。それが存在していることに気づかせたいだけでした。
マイケルグリーン

回答:


1

各データベースを個別にレプリケートすることを検討する必要があり、その後、ある種のデータ仮想化手法を使用して、さまざまなレプリケートされたソースからのデータを組み合わせる必要があるでしょうか。

はい。1つのインスタンスで複数のサブスクライバーデータベースをホストし、ビューを使用してそれらを照会したり、統合データベースにロードしたりできます。


これらのビューを設定するよりエレガントな方法はありますか?SELECT Field1、Field2、Field3 FROM [Database1]。[schema]。[TableName] UNION ALL SELECT Field1、Field2、Field3 FROM [Database2]。[schema ]。[TableName]
bperry 2017年

1

上記の説明に従って、以下のリンクはあなたと私が同じシナリオで作業するのに役立ちます。単一のサブスクライバーを持つ複数のパブリッシャー。

  1. server_idなどの列を1、2、3などのデフォルト値でさらに1つ追加し、それを複合主キーにします。

  2. パブリケーションを作成して記事を追加する場合、記事のプロパティのアクション[名前が使用されている場合]を[データを削除]に設定する必要があります。記事に行フィルターがある場合、フィルターに一致するデータのみを削除します。これは、新しいパブリケーションウィザードの[記事のプロパティ]ダイアログを使用するか、レプリケーションストアドプロシージャsp_addarticleを使用して、@ pre_creation_cmd引数に削除の値を指定することで設定できます。このように、中央サブスクライバーが複数のパブリケーションスナップショットから初期化または再初期化されると、フィルター句に一致するデータのみが削除されるため、以前に適用されたスナップショットデータが保持されます。

ここに画像の説明を入力してください

http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/


記事をありがとう。セントラルサブスクライバーモデルを使用して、パブリッシャーのスキーマの更新をどのように処理するか(たとえば、バージョンのアップグレードを使用して)解決しましたか?すべてのパブリッシャーデータベースを強制的に同時に更新しますか?私の環境では、常にこのオプションがあるわけではなく、それが中央サブスクライバーレプリケーションモデルを追求する上での主なためらいでした。この障壁を回避する方法がある場合、私は知りたいです!
bperry 2017

私は「パブリッシャーの更新」を使用していません。データベースを2つの部分に分割しました(2種類のレプリケーション)。 。集中管理されたサブスクライバーは、レポートサーバーとして機能するセカンダリレプリカのために、AlwaysOn可用性グループの一部でもあります。
Gulrez Khan 2017

私があなたの解決策を理解していることを確認させてください。たとえば、パブリッシャーAがバージョン1で、パブリッシャーBがバージョン2であるとします。1)両方のパブリッシャーでスキーマ変更のレプリケーションをオフにしました(セットアップ時にreplicate_ddl = 0を使用)。2)バージョン2には新しい列が含まれているため、中央サブスクライバーで手動で追加します。3)パブリッシャーB(アップグレード済み)で、新しい列を手動でレプリケーションに追加します(sp_articlecolumnを使用)。パブリッシャーAで変更は行われません。これにより、両方のパブリッシャーがレプリケーションを中断することなく中央サブスクライバーへのレプリケーションを続行できますか?
bperry 2017

以下のリンクを参照してください。dba.stackexchange.com/questions
142449

これも参照してください。.dba.stackexchange.com/questions
146070

1

1つの可能なアーキテクチャ:

レポートをデータウェアハウスベースのソリューションとして検討します。

通常、データウェアハウスは、ソースシステムの必要なサブセットを表すスキーマを持つDBです。AdventureWorksとAdventureworksDWは、そのモデリングを示しています。

次に、ETL:ソースからデータウェアハウスにデータを移動します。

ここで可能な実装は、変更の追跡を使用することです。

第一に、消費するものはバージョン固有であるが、返されるものは統一されているビューを実装できます。たとえば、Person.Genderがバージョン2には存在するがバージョン1には存在しない場合、バージョン1のPersonビューは、たとえばバージョン1の場合はnullを返すことができます。

ビューを読み取るだけの倉庫の消費者にとって、データは同じ形です(完全性は異なります)。

変更の追跡は、(比較的)軽量な方法で、更新のたびにどのデータを変更する必要があるかを判断します。

上記の実装はすべて手動で行うツールに依存しているため、SQLコーディングに自信を持ち、パフォーマンスシナリオをテストして、増分の実行速度を確認する必要があります。多くの場合、それらは1秒未満になる可能性がありますが、トランザクションテーブルの数が多いと、変更の処理で高い負荷が発生する可能性があります。(変更追跡は「比較的」軽量です...テストのみがそれを証明します)。

スキーマの違いがどのように現れるかを高度に制御でき、変更が追跡される場合、追跡がエンジンレベルで行われるため、正しく実装されたときに整合性の問題が発生する可能性はありません。

これが間違いなくあなたにとって正しいかどうか、言うのは難しいでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.