Suchen Sie nach Ratschlägen zur Integration von Daten aus über 100 Client-DBs in eine zentralisierte Berichtsdatenbank

Ich bin ein SQL-Entwickler (nicht DBA oder Architekt) für ein kleines SaaS-Unternehmen (~ 50 Mitarbeiter). Ich habe die Aufgabe herauszufinden, wie man:

Laden Sie Betriebsberichte aus unseren über 100 OLTP-Datenbanken herunter
Lassen Sie diese Berichte für Daten aus mehreren Client-Datenbanken ausgeführt werden
Positionieren Sie unser Unternehmen, um in Zukunft mehr analytikbasierte Lösungen anzubieten

Ich habe eine Reihe von Artikeln über verschiedene Technologien wie Transaktionsreplikation (insbesondere das Viele-zu-Eins- / Zentralabonnentenmodell), SQL Service Broker, Protokollversand, Änderungsverfolgung (CT) und Änderungsdatenerfassung (CDC) gelesen Dies ist nur für Unternehmen), und ich bin mir nicht sicher, welchen Weg ich am besten einschlagen soll.

Ich hoffe, dass einige von Ihnen mit Integrationskenntnissen auf ein ähnliches Setup wie wir gestoßen sind und mich auf einen erfolgreichen Weg weisen oder mich auf einige Ressourcen verweisen können, die hilfreich wären.

Aus Kostengründen muss unsere Lösung in SQL Server Standard Edition funktionieren. Außerdem muss die Lösung angemessen sein, um sie in unserer kleinen Organisation zu unterstützen / zu warten.

Grundlegende Einstellung:

Derzeit verfügen wir über mehr als 100 einzelne Client-Datenbanken, von denen die meisten auf SQL-Servern in unserem Rechenzentrum bereitgestellt werden. Einige werden jedoch auf Client-Servern in ihrem Rechenzentrum bereitgestellt, in die wir remote zugreifen können. Dies sind alles SQL Server 2008 R2-Datenbanken, aber wir planen, bald ein Upgrade auf SQL 2016 durchzuführen.

Wir verwenden Datenbankprojekte und Dacpacs, um sicherzustellen, dass das Schema für alle zu integrierenden Client-Datenbanken gleich ist. Da wir jedoch nicht alle Clients zwingen, gleichzeitig auf neue Versionen zu aktualisieren, sind einige Schemaunterschiede zwischen den Upgrades möglich. Die Lösung muss flexibel genug sein, um nicht zu brechen, wenn sich Client A in Softwareversion 1.0 und Client B in Version 1.1 befindet.

Betriebsberichte werden derzeit direkt aus der OLTP-Datenbank jedes Clients ausgeführt. Wir sind besorgt über die Auswirkungen, die dies auf die Leistung der Anwendung haben wird, wenn wir sie nicht auslagern.

Hohe Anforderungen:

Unsere Kunden sind SPD-Abteilungen (Hospital Sterile Processing Departments), die aktuelle Berichte darüber wünschen, was sie bisher verarbeitet haben, wo sich das Inventar befindet usw. Das Prozessinventar der SPD ist rund um die Uhr verfügbar, einschließlich an Wochenenden und Feiertagen. Da einer der Hauptzwecke dieser Bemühungen darin besteht, die operative Berichterstattung besser zu unterstützen, möchten wir, dass die Daten so zeitnah wie möglich sind, um die Anforderungen der Kunden weiterhin zu erfüllen.

Derzeit haben wir einige SPDs in separaten Datenbanken, die tatsächlich Teil desselben Krankenhaussystems sind. Diese Clients möchten die Möglichkeit haben, Berichte über alle SPDs in ihrem System zu erstellen.

Strategisch gesehen möchten wir die Möglichkeit haben, Daten für alle unsere Kunden einfach zu aggregieren, um unsere internen Analyseinitiativen zu unterstützen. Wir gehen davon aus, dass wir die gesammelten Betriebsdaten als Quelle für Data Marts / Warehouse verwenden können.

Gedanken so weit:

Die Transaktionsreplikation scheint die "Echtzeit" -Lösung zu sein. Ich fand diese Antwort besonders hilfreich, befürchte jedoch, dass sie aufgrund des Potenzials für Schemaunterschiede bei uns nicht funktioniert: SQL Server Many-to-One-Replikation

Der Protokollversand klingt nicht ideal, da das Protokoll nicht wiederhergestellt werden kann, während Abfragen aktiv sind. Entweder muss ich alle rausschmeißen, damit das Protokoll wiederhergestellt werden kann, oder die Daten werden veraltet. Ich bin mir nicht sicher, ob diese Methode zur Zentralisierung von Daten aus mehreren Datenbanken verwendet werden kann, da jedes ausgelieferte Protokoll nur für die einzelne Datenbank bestimmt ist, aus der es stammt.

Bei Verwendung des SQL Service Brokers kann die Latenz unvorhersehbar sein, wenn eine Warteschlange nicht mit der Anzahl der zu verarbeitenden Nachrichten Schritt halten konnte.

CT identifiziert nur eine Version für jede Tabellenzeile. Die Latenz hängt davon ab, wie schnell wir so etwas wie ein SSIS-Paket für jede Datenbank verarbeiten können, um die Daten abzurufen und in ein zentrales Repository einzufügen.

Müssen wir in Betracht ziehen, jede Datenbank einzeln zu replizieren und dann möglicherweise eine Art Datenvirtualisierungstechnik zu verwenden, um Daten aus den verschiedenen replizierten Quellen zu kombinieren?

Jeder Rat oder jede Anweisung, die Sie bereit sind zu geben, wäre sehr dankbar.

— bperry
quelle

Aufgrund Ihrer (nahezu) Echtzeitanforderung würde ich mich nur mit der ereignisbasierten Verarbeitung mit einigen Implementierungen der Nachrichtenwarteschlange befassen (für Zustellungsgarantien). Hoffe das hilft

— Grimaldi

Ich würde HTAP in die Mischung werfen. en.m.wikipedia.org/wiki/Hybrid_Transactional/… BIML und SSIS zum Auffüllen des gemeinsamen Geschäfts.

— Michael Green

@Grimaldi, würden Sie empfehlen, SQL Service Broker zu verwenden, um die ereignisbasierten Verarbeitungs- / Nachrichtenwarteschlangen oder eine andere Messaging-Technologie zu implementieren?

— Bperry

Vielen Dank für den Vorschlag, @MichaelGreen. Grundsätzlich sieht es so aus, als würde HTAP es uns ermöglichen, unsere vorhandenen Datenbanken sowohl für OLTP als auch für OLAP zu verwenden, indem wir unseren Tabellen nicht geclusterte Columnstore-Indizes (NCCI) hinzufügen. Berichtsabfragen verwenden die NCCI, damit sie die Transaktionsvorgänge nicht beeinträchtigen. SQL 2016 bietet HTAP-Unterstützung in Standard Edition (SE), aber es sieht so aus, als ob der Columnstore-Cache für die gesamte SQL-Instanz auf 32 GB beschränkt ist. Dies könnte ein Problem für uns sein, da wir Dutzende von Datenbanken auf derselben Instanz haben. microsoft.com/en-us/sql-server/sql-server-2016-editions

— bperry

Ja, Spaltenspeicher, aber auch In-Memory, wenn Ihre Serverspezifikation es Ihnen erlaubt, dorthin zu gelangen. Ich habe Sunil Agarwal kürzlich darüber sprechen hören. Die Faustregel von MS war eine Verschlechterung des OLTP um etwa 3% zugunsten der Berichterstattung ohne Latenz. Leider gibt es keine kostenlosen Mittagessen; Sie können neue Instanzen erstellen, um die Berichtsdatenbank zu speichern, oder Sie können eine neue Instanz erstellen, um genügend Headroom für die Unterstützung von HTAP zu erhalten. Ich befürworte dieses Muster nicht. Es funktioniert möglicherweise nicht für Sie. Ich wollte Sie nur darauf aufmerksam machen, dass es existiert.

— Michael Green

Antworten:

Müssen wir in Betracht ziehen, jede Datenbank einzeln zu replizieren und dann möglicherweise eine Art Datenvirtualisierungstechnik zu verwenden, um Daten aus den verschiedenen replizierten Quellen zu kombinieren?

Ja. Sie können mehrere Abonnentendatenbanken auf einer einzelnen Instanz hosten und diese dann mit Ansichten abfragen oder in eine konsolidierte Datenbank laden.

— David Browne - Microsoft
quelle

Gibt es eine elegantere Möglichkeit, diese Ansichten einzurichten, als ... SELECT Field1, Field2, Field3 FROM [Database1]. [Schema]. [TableName] UNION ALL SELECT Field1, Field2, Field3 FROM [Database2]. [Schema ]. [TableName]

— bperry

Gemäß Ihrer obigen Beschreibung hilft Ihnen der folgende Link und ich arbeite auch an demselben Szenario. Mehrere Herausgeber mit einem einzelnen Abonnenten.

Fügen Sie eine weitere Spalte wie server_id mit einem Standardwert wie 1,2,3 usw. hinzu und erstellen Sie einen zusammengesetzten Primärschlüssel.
Beim Erstellen der Veröffentlichungen und Hinzufügen von Artikeln muss die Artikeleigenschaft Aktion, wenn der Name verwendet wird, auf Daten löschen gesetzt werden. Wenn der Artikel über einen Zeilenfilter verfügt, löschen Sie nur Daten, die dem Filter entsprechen. Dies kann im Dialogfeld "Artikeleigenschaften des Assistenten für neue Veröffentlichungen" oder mithilfe der gespeicherten Replikationsprozeduren sp_addarticle und der Angabe des Löschwerts für das Argument @pre_creation_cmd festgelegt werden. Auf diese Weise bleiben zuvor angewendete Snapshot-Daten erhalten, wenn der zentrale Abonnent aus mehreren Veröffentlichungs-Snapshots initialisiert oder neu initialisiert wird, da nur Daten gelöscht werden, die mit der Filterklausel übereinstimmen.

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

— Gulrez Khan
quelle

danke für den Artikel. Haben Sie anhand des zentralen Abonnentenmodells herausgefunden, wie Sie mit Aktualisierungen des Schemas Ihres Publishers umgehen (z. B. mit Versionsaktualisierungen)? Erzwingen Sie die gleichzeitige Aktualisierung aller Publisher-Datenbanken? In meiner Umgebung haben wir diese Option nicht immer, und das war mein Hauptzögern bei der Verfolgung eines zentralen Teilnehmerreplikationsmodells. Wenn es einen Weg gibt, um diese Barriere zu umgehen, würde ich gerne wissen!

— Bperry

Ich verwende 'Update Publisher' nicht. Ich habe die Datenbank in zwei Teile geteilt, z. B. (zwei Arten der Replikation), einige Tabellen im detaillierten Herausgeber (Herausgeber an zentralisierten Abonnenten) und einige sind Master-Herausgeber (zentraler Abonnent an alle Herausgeber). Mein zentraler Abonnent ist auch Teil der AlwaysOn-Verfügbarkeitsgruppe, sodass mein sekundäres Replikat als Berichtsserver fungiert.

— Gulrez Khan

Lassen Sie mich sicherstellen, dass ich Ihre Lösung verstehe. Angenommen, Publisher A ist auf Version 1 und Publisher B auf Version 2. 1) Sie haben die Replikation von Schemaänderungen auf beiden Publishern deaktiviert (unter Verwendung von replicate_ddl = 0 beim Setup). 2) Version 2 enthält eine neue Spalte, sodass Sie sie manuell beim zentralen Teilnehmer hinzufügen können. 3) Bei Publisher B (aktualisiert) würden Sie die neue Spalte dann manuell zur Replikation hinzufügen (mithilfe von sp_articlecolumn). Bei Publisher A werden keine Änderungen vorgenommen. Würden beide Publisher weiterhin auf den zentralen Abonnenten replizieren können, ohne die Replikation zu unterbrechen?

— Bperry

siehe unten link .. dba.stackexchange.com/questions/142449/…

— Gulrez Khan

siehe auch .. dba.stackexchange.com/questions/146070/…

— Gulrez Khan

Eine mögliche Architektur:

Betrachten Sie das Reporting als eine Data Warehouse-basierte Lösung.

In der Regel ist ein Data Warehouse eine Datenbank mit einem Schema, das die erforderliche Teilmenge der Quellsysteme darstellt. AdventureWorks und AdventureworksDW demonstrieren diese Modellierung.

Als nächstes die ETL: Verschieben von Daten aus Quellen in das Data Warehouse.

Eine mögliche Implementierung ist hier die Verwendung der Änderungsverfolgung.

Erstens kann man Ansichten implementieren, die versionsspezifisch in Bezug auf das, was sie verbrauchen, aber in Bezug auf das, was sie zurückgeben, einheitlich sind. Beispiel: Wenn Person.Gender in Version 2, aber nicht in Version 1 vorhanden ist, kann die Personenansicht für Version 1 beispielsweise null für Version 1 zurückgeben.

Für den Lagerkonsumenten, der nur die Ansichten liest, haben die Daten dieselbe Form (mit unterschiedlicher Vollständigkeit).

Die Änderungsverfolgung bietet eine (relativ) einfache Möglichkeit, um zu bestimmen, welche Daten bei jeder Aktualisierung geändert werden müssen.

Die Implementierung der oben genannten Funktionen basiert auf handwerklichen Tools. Sie müssen also mit der SQL-Codierung vertraut sein und Leistungsszenarien testen, um festzustellen, wie schnell die Inkremente ausgeführt werden. In vielen Fällen können sie unter 1 Sekunde liegen, aber einige hohe Transaktionstabellen können eine hohe Belastung bei der Verarbeitung von Änderungen verursachen. (Change Tracking ist 'relativ' leicht ... nur Tests beweisen es).

Das Gute daran ist, dass Sie ein hohes Maß an Kontrolle darüber haben, wie sich Schemaunterschiede manifestieren, und dass bei der Nachverfolgung von Änderungen bei korrekter Implementierung keine Möglichkeit von Integritätsproblemen besteht, da die Nachverfolgung auf Engine-Ebene erfolgt.

Ob dies definitiv für Sie richtig ist, ist schwer zu sagen.

— Paul Holmes
quelle