Verwenden von DBREPLICATION beim Reduzieren von Datenbanken unter Microsoft SQL Server

Unternehmensbuchhaltungssysteme zeichnen sich durch eine allmähliche Zunahme des Datenbankvolumens aufgrund der Anhäufung historischer Informationen aus. Im Laufe der Zeit kann die Größe der Datenbank eine solche Größe erreichen, dass eine Reihe von Problemen hinsichtlich Leistung, Wartung, verfügbarem Speicherplatz und mehr auftreten. Heute betrachten wir zwei Ansätze zur Lösung dieses Problems: Erhöhung der Hardwareressourcen und Faltung historischer Daten.

Einführung

Dieser Artikel beschreibt das Problem des Faltens besonders großer Datenbanken auf der MS SQL Server-Plattform. Die Lösung für dieses Problem wird mithilfe der Replikationstechnologie DBREPLICATION von Softpoint beschrieben.

Problem

Jede Art von Buchhaltungssystem kann beginnen, ihre eigenen spezifischen Merkmale zu manifestieren. In Systemen, die auf einer 1C-Plattform basieren, treten beispielsweise Probleme bei Routineoperationen wie dem Aktualisieren der Konfiguration und dem Aktualisieren der 1C-Plattform auf. Mit dem Wachstum der Datenbank verschlechtert sich die Situation allmählich, früher oder später müssen Maßnahmen ergriffen werden.

Ansatz Nr. 1: Hardware

Die naheliegendste und technisch transparenteste Lösung besteht darin, die Hardwareressourcen zu erhöhen. Dies kann entweder der Kauf produktiverer Server, Festplattenspeicher usw. oder die Vermietung leistungsfähigerer Geräte in einem Rechenzentrum oder einer Cloud eines Drittanbieters sein.

Wenn Sie diesen Weg gehen, ist es eine gute Option, die Datenbank in der Microsoft Azure-Cloud zu platzieren. Azure bietet verschiedene Architekturoptionen zum Hosten der Datenbank: MS SQL auf der virtuellen Azure-Maschine und drei Optionen für die Azure SQL-Datenbank in der Cloud. Daher ist es möglich, die optimalste Platzierungsoption in Abhängigkeit von den Merkmalen einer bestimmten Datenbank und ihren Betriebsbedingungen auszuwählen.

Azure bietet gegenüber dem Kauf eigener Geräte eine Reihe von Vorteilen. Eine der wichtigsten ist die enorme Hardwarefunktion, die Azure bereitstellen kann. Sowie ein flexibler Ansatz zur Nutzung dieser Kapazitäten in Abhängigkeit von der tatsächlichen Belastung. Sie können beispielsweise zusätzliche Kapazitäten für den Zeitraum der „Hochsaison“ Ihres Unternehmens oder zum Ende des Berichtszeitraums erwerben, sodass Spitzen problemlos vergehen können. Verwenden Sie für den Rest der Zeit eine kostengünstigere Ressourcenkonfiguration. Einerseits haben Sie zum richtigen Zeitpunkt Zugriff auf das enorme Ressourcenpotenzial von Azure (das übrigens ständig wächst), und andererseits können Sie Überkapazitäten nicht überbezahlen, wenn Sie sie nicht benötigen.

Trotz seiner relativen Einfachheit ist die Erhöhung der Hardwareressourcen keine universelle Lösung. Erstens ist der positive Effekt oft nicht proportional zu Finanzinvestitionen (es gibt viele Investitionen - es gibt nur geringe Auswirkungen). Zweitens ist der Effekt vorübergehend, da die Basis weiter wächst und mehr Ressourcen und mehr Finanzinvestitionen erfordert.

In jedem Fall hat dieser Ansatz ein Recht auf Leben und ist weit verbreitet. Wir werden uns jedoch nicht mehr damit befassen, da der Hauptzweck des Artikels nicht ein "Hardware" -Ansatz ist, sondern ein "Software" -Ansatz, der unten beschrieben wird.

Ansatz Nr. 2: Faltung der Basis

Eine radikalere Lösung ist die Faltung der Datenbank, dh das Entfernen nicht relevanter historischer Daten aus der Datenbank. In der reduzierten Datenbank gibt es nur Daten für einen relativ kleinen Betriebszeitraum, normalerweise sind es nicht mehr als 1-2 Jahre. Offensichtlich ist der Grad der Reduzierung in jedem Fall unterschiedlich und es ist schwierig, bestimmte Zahlen zu benennen. Für eine Richtlinie nehmen wir jedoch einen Indikator für eine Abnahme der Basis um 50–70%, dh ungefähr das 2-3-fache, ungefähr die gleiche Menge, und es stellt sich in der Praxis heraus, dass weniger oder umgekehrt mehr - es ist selten.

Wir werden uns nicht mit den daraus resultierenden Gewinnen befassen. Wenn die Basis um das 2-3-fache oder mehr reduziert wird, ist der Leistungseffekt natürlich sehr leistungsfähig und langfristig, und zusätzliche Investitionen in die Hardwarekomponente können vermieden werden. Und der einmal entwickelte und eingeführte Faltungsmechanismus kann in Zukunft wiederverwendet werden. Im Allgemeinen ist dies eine sehr effektive Lösung mit garantierten Ergebnissen.

Die Komplexität der Faltungsimplementierung

Bei aller Wirksamkeit hat die Faltung ein sehr großes Problem. Und es geht nicht einmal darum, den Faltungsmechanismus selbst zu entwickeln. Ja, diese Entwicklung ist auch eine schwierige Aufgabe, aber sie ist irgendwie gelöst. Die Sache ist anders. Wenn die Datenbank eine Größe von mehreren hundert Gigabyte hat oder die Terabyte-Grenze überschritten hat, stellt sich heraus, dass es einfach physikalisch sehr schwierig ist, den Faltvorgang durchzuführen. Unweigerlich entsteht ein ganzer Komplex miteinander verbundener Schwierigkeiten, betrachten wir sie.

• Ressourcenintensität von Faltvorgängen - Ausrüstung ist stark belastet.
  
  • Während der Faltung wird nicht nur eine große Anzahl von Daten physisch gelöscht, sondern es werden auch viele verwandte ressourcenintensive Vorgänge ausgeführt: verschiedene Auswahlen, Überprüfungen, Gruppierungen, Indizierungen, Protokollierungen, Verschieben von Daten zwischen Tabellen usw. Diese Tatsache ist besonders wichtig, da die zusammenklappbare Datenbank in der Regel bereits stark ausgelastet ist und keinen Kapazitätsüberschuss aufweist.
• Eingriffe in Benutzer.
  
  • Es ist äußerst schwierig oder unmöglich, die Faltung direkt in der Arbeitsdatenbank parallel zur Arbeit des Benutzers durchzuführen, da durch den Faltungsprozess eine hohe zusätzliche Last und Sperren entstehen.
• Es gibt kein technologisches Fenster.
  
  • Ein technologisches Fenster von ausreichender Dauer, wenn Benutzer nicht arbeiten, steht einfach nicht für die Faltung zur Verfügung. Schließlich beträgt der Faltvorgang für Datenbanken dieser Größe in der Regel mehrere zehn Stunden oder mehrere Tage.
• Hohe Risiken beim direkten Zusammenklappen auf die Arbeitsbasis.
  
  • Der Ansatz, wenn der Faltungsalgorithmus direkt auf die Arbeitsbasis angewendet wird, ist selbst aus einer Reihe von Gründen sehr riskant. Eine davon - die Möglichkeiten zur endgültigen Überprüfung der Ergebnisse der Faltung sind sehr begrenzt (keine Zeit).
• Inakzeptable Dauer eines iterativen Ansatzes.
  
  • Sie können versuchen, einen Engpass zu vermeiden - ein technologisches Fenster - und die Iteration in iterativ kleinen Abschnitten direkt in der Produktionsbasis durchführen, indem Sie die Größe jedes Teils so auswählen, dass er in die vorhandenen technologischen Fenster passt. Dieser Weg ist jedoch meistens auch nicht anwendbar, da sich der Trimmprozess erstens über einen unannehmbar langen Zeitraum (viele Wochen oder Monate) erstreckt und zweitens die Komplexität des Faltmechanismus stark zunimmt und die Gesamtkosten für die Sicherstellung eines ununterbrochenen Trimmprozesses über einen so langen Zeitraum stark ansteigen Die Risiken des gesamten Projekts nehmen radikal zu.
• Wie komprimiere ich Hohlräume in einer Datendatei?
  
  • Während des Entfernens historischer Informationen aus der Datenbank nimmt die Datendatei nicht tatsächlich ab (und nimmt oft sogar geringfügig zu), sondern es entstehen einfach große Hohlräume in der Datenbank. Und Sie müssen sie irgendwie loswerden, damit die Datendatei reduziert wird. Andernfalls geht die Verstärkung in Bezug auf den Speicherplatz verloren. Eine Möglichkeit besteht darin, einen typischen SHRINK auszuführen. Und bei solchen Bänden ist es ein sehr langwieriger Vorgang (viele Stunden oder sogar zehn Stunden).

Daher ist die Faltung eine sehr nicht triviale Aufgabe. Es reicht nicht aus, einen Faltungsmechanismus zu entwickeln, er muss auch angewendet werden. Darüber hinaus wird die Anwendung häufig zu einem Engpass.

Hinweis: Als nächstes lassen wir die Entwicklung des Faltungsmechanismus selbst (mit anderen Worten des Algorithmus zum Löschen historischer Daten) in Klammern, unabhängig davon, was bedeutet, dass er erstellt wird. Und wir konzentrieren uns nur auf die Anwendung des bereits implementierten Mechanismus im Kampf.

Lösung mit DBREPLICATION

Es scheint eine Sackgasse zu sein. Es gibt aber noch Lösungen. Es gibt eine effektive Technik, mit der Sie das gesamte Gewirr von Schwierigkeiten lösen, Risiken beseitigen und das Ziel garantiert erreichen können. Es beinhaltet die Verwendung der DBREPLICATION-Datenaustauschtechnologie. Die Lösung eignet sich sowohl für die herkömmliche Infrastrukturoption als auch für das Cloud-basierte Microsoft Azure. Kurz gesagt, das Wesentliche ist wie folgt.

• Ein Klon der Datenbank wird erstellt, der einseitige Datenaustausch zwischen dem Klon und der Hauptdatenbank wird mithilfe von DBREPLICATION konfiguriert. Es ist zulässig, dass sich die Hauptdatenbank und / oder ihr Klon (beide oder einer von ihnen) in der Microsoft Azure-Cloud befinden.
• Im Klon arbeiten Benutzer nicht, dort beginnt der Faltungsprozess. Da der Faltvorgang niemanden stört, kann er dort den ganzen Tag ohne Unterbrechungen so lange dauern, wie es dauert. Somit verschwindet der Link zur Dauer des technologischen Fensters!
• Benutzer ohne Störung arbeiten in der Hauptdatenbank. Die DBREPLICATION-Technologie überträgt alle Änderungen automatisch mit hoher Geschwindigkeit von der Hauptdatenbank in die zusammenklappbare. Somit ist der Klon hinsichtlich der Betriebsdaten auf dem neuesten Stand.
• Nach Abschluss der Faltung erfolgt in der Regel eine detaillierte Überprüfung des Ergebnisses unter Einbeziehung von Fachleuten und Geschäftsanwendern des Kunden. Und dieser Prozess kann ziemlich lange dauern (mehrere Stunden oder Tage). In der betrachteten Methodik gibt es praktisch keine zeitliche Begrenzung, daher kann der Überprüfung so viel Zeit zugewiesen werden, wie erforderlich ist.
• Nach Abschluss der Faltung und Überprüfung wechseln alle Benutzer zum abgeschnittenen Klon und von diesem Moment an wird er zur Hauptbasis. Und die ursprüngliche unbeschnittene Basis dient als Archiv historischer Daten.
  
  • Ein zusätzlicher Vorteil ist die Möglichkeit, die Replikation in die entgegengesetzte Richtung zu wechseln, wenn Benutzer zu einer minimierten Datenbank wechseln. Dies bietet zusätzliche Sicherheit, denn wenn „etwas schief geht“, können Sie Benutzer schnell wieder in die unbeschnittene Datenbank wechseln, ohne die eingegebenen Daten zu verlieren.
• Wenn die Archivdatenbank auf dem neuesten Stand gehalten werden muss, können Sie die Replikation in die entgegengesetzte Richtung wechseln und die Änderungen von der minimierten Datenbank in die Archivdatenbank übertragen.

Abb. 1. Schematische Darstellung des Datenbank-Trimmens mithilfe der DBREPLICATION-Technologie.

Abb. 2. Option zum Hosten zusammenklappbarer Datenbanken in der MS Azure-Cloud.

Somit erweitert die beschriebene Faltungstechnik in der Klondatenbank alle Engpässe. Beseitigt die Abhängigkeit vom technologischen Fenster. Im Klon stört das Paket niemanden und niemand stört sie. Sie können die maximalen Ressourcen des Klons sicher nutzen und auch der endgültigen Überprüfung genügend Aufmerksamkeit schenken.

Es bleibt abzuwarten, welche Austauschtechnologie in diesem Schema verwendet werden kann. Warum DBReplication?

Warum DBReplication?

In der beschriebenen Methodik ist das Schlüsselelement die Austauschtechnologie, die die Synchronisation der zugeschnittenen Datenbank mit der Hauptdatenbank sicherstellt. Grundsätzlich kann die Austauschtechnologie eine beliebige sein, wenn sie drei wesentliche Schlüsselbedingungen erfüllt:

• Kompatibilität mit der Geschäftsanwendungsplattform, deren Basis zusammenbricht.

Beispiel: Wenn wir die 1C-Datenbank reduzieren, ist nicht jede Exchange-Technologie mit der 1C-Basisstruktur kompatibel. Insbesondere die klassische MS Transaction Replication ist nicht kompatibel, da Änderungen an der Tabellenstruktur vorgenommen werden.

• Leistung. Die Austauschtechnologie muss garantiert sein, um den Fluss von Änderungen zu bewältigen, der während der Faltung in der Arbeitsbasis auftritt.

Erläuterung: In diesem Artikel meinen wir hauptsächlich hoch geladene Datenbanken mit einer hohen Datenänderungsrate. Die Faltung wird Dutzende von Stunden dauern, vielleicht mehrere Tage, vielleicht wird es sogar mehr als eine Iteration der Faltung geben. Während dieser Zeit werden die Benutzer große Änderungen vornehmen. Viele Sharing-Technologien können damit einfach nicht umgehen. Und Sie müssen nicht nur fertig werden, es ist ratsam, mit dem Angebot fertig zu werden.

• Die hauptsächliche Anwendbarkeit auf die Bedingungen des Problems.

Erklärung: Vielleicht scheint dieser Punkt selbstverständlich zu sein, aber wir können ihn trotzdem herausgreifen. Nämlich: Vergessen Sie nicht, dass die Daten in der Quellendatenbank und im Klon nicht gleich sind! Diese Tatsache entfernt automatisch eine ganze Klasse leistungsstarker und produktiver Technologien, die auf der Synchronisierung von Transaktionsprotokollen basieren - immer aktiv, Protokollversand, Spiegelung usw.

Darüber hinaus sollte die Austauschtechnologie in Bezug auf andere Indikatoren wirksam sein:

• Zuverlässigkeit und Autonomie des Funktionierens. Da es sich um die Übertragung großer Datenmengen handelt und das Projektteam über einen längeren Zeitraum einfach nicht in der Lage ist, Austauschprobleme, Kollisionen und Ausfälle manuell zu beheben, die Datenqualität zu überprüfen usw. Daher sollte die Austauschtechnologie hinsichtlich der Qualität der übertragenen Daten so zuverlässig wie möglich, so autonom und automatisiert wie möglich sein.
• Hochwertige Benutzeroberflächen für Steuerung und Verwaltung.
• Einfach bereitzustellen und zu konfigurieren. Die Austauschtechnologie sollte keine übermäßig hohen Anforderungen an die Qualifikation von Fachleuten für ihre Anpassung stellen.

Ohne diese Eigenschaften droht die Austauschtechnologie, sich von einem sparenden Schlüsselelement der Methodik in ein „schwaches Glied“ zu verwandeln, birgt ernsthafte Risiken und bedroht das gesamte Projekt. Und dann verliert die ursprüngliche Idee ihre Bedeutung.

Die DBReplication-Technologie erfüllt jedoch mit Sicherheit alle Anforderungen und sichert den Erfolg des Rollup-Projekts.

Beachten Sie die Hauptfaktoren, aufgrund derer DBReplication bei dieser Aufgabe erfolgreich ist:

• Sehr hoher Wechselkurs. Beachten Sie einige Funktionen, die Geschwindigkeit bieten:
  
  • DBReplication ist eine Transaktionsreplikation. Jede Änderung wird unmittelbar nach dem Festschreiben der Transaktion übertragen.
  • Die interne Architektur des Transportsubsystems verwendet Lösungen wie die parallele Verarbeitung von Warteschlangen mit mehreren Threads, einen Pipeline-Ansatz, die Stream-Komprimierung, die Verarbeitung von Batch-Transaktionen, die Verwendung von Bulk Insert und andere.
• Der Transport basiert auf Windows-Diensten und ist mit vielen Funktionen ausgestattet, um einen reibungslosen Betrieb zu gewährleisten. Dazu gehören: automatische Wiederherstellung des Austauschs nach Kommunikationsunterbrechungen, Arbeiten an schwachen instabilen Kommunikationskanälen, automatische Verarbeitung von Versionskonflikten (für bidirektionalen Austausch), automatische Anpassung bei Änderungen in der Struktur von Tabellen einer Geschäftsanwendung und andere.
• Garantierter Datenlieferungsmechanismus. Strikte Einhaltung der Transaktionsintegrität und -konsistenz bei der Übertragung von Änderungen.
• Ändert nicht die Tabellenstruktur der Geschäftsanwendung. Daher kann es insbesondere beim Falten von 1C-Datenbanken erfolgreich eingesetzt werden.
• Entwickelte Benutzeroberfläche, mit der Sie das Austauschsystem "aus einem Fenster" zentral verwalten können. Alle Serviceinformationen werden online gesammelt und angezeigt.
• Einfach bereitzustellen und zu konfigurieren.
• Angepasst für 1C-Plattform. Der Benutzer arbeitet nicht mit Tabellen, sondern mit bekannten 1C-Metadatenobjekten.
• Jede Version von MS SQL ab 2005 von Standard bis Enterprise, sowohl lokal bereitgestellt als auch in der Cloud von MS Azure installiert. Aus Azure-Sicht sind sowohl Hostingoptionen für virtuelle Maschinen als auch Azure SQL DB-Hostingoptionen zulässig, einschließlich einer verwalteten Instanz der Azure SQL-Datenbank ( verwaltete Instanz ).
• DBReplication ist eine vorgefertigte, zuverlässige Lösung, die von vielen Projekten unter verschiedenen Bedingungen und Aufgaben getestet wurde.
• Wenn DBREPLICATION im Einweg-Austauschmodus verwendet wird, kann die Austauschrichtung umgeschaltet werden.

Darüber hinaus stellen wir ein weiteres wichtiges Merkmal fest:

• DBREPLICATION kann in einem bidirektionalen Austauschmodus betrieben werden, wenn es möglich ist, Daten gleichzeitig in alle am Austausch teilnehmenden Datenbanken einzugeben / zu ändern. Die Anzahl der Basen, die in der Austauschschaltung enthalten sein können, ist nicht begrenzt.

Praktisches Anwendungsbeispiel

Ein großes russisches Unternehmen verfügt über ein Anwendungsabrechnungssystem, das auf der 1C 8 + MS SQL Server-Plattform basiert. Die Hauptbetriebsbasis hat lange Zeit mehr als 2 Terabyte überschritten und wächst weiter. Gleichzeitig nimmt die Belastung immer mehr zu: sowohl transaktional als auch analytisch. Am Ende wurden eine Reihe von Gründen für die Faltung der Basis gebildet. Es wurde beschlossen, die historischen Daten für Anfang 2017 zu kürzen. Die hier unter Verwendung von DBReplication beschriebene Technik wurde ausgewählt.

An sich wurde beschlossen, den Faltungsalgorithmus hauptsächlich von TSQL mit kleinen Einschlüssen typischer 1C-Werkzeuge zu implementieren. Die Aufgabe wurde durch die Tatsache erschwert, dass nicht alle angewendeten Objekte (Tabellen) bis zum geplanten Datum reduziert werden konnten, da aufgrund von Geschäftsmerkmalen in einer Reihe der größten Subsysteme die historischen Daten bis zu einer Tiefe von 5 bis 7 Jahren vollständig vorhanden sein mussten. Aus Sicht des Volumens der Datenbank war der Effekt der Faltung daher nicht so groß, wie wir es gerne hätten. Es wurde eine vorläufige Analyse durchgeführt, die ergab, dass unter Berücksichtigung objektiver Beschränkungen etwa 33% des ursprünglichen Volumens abgeschnitten werden. Dies wurde vom Kunden jedoch als gutes Ergebnis bewertet, da der Gewinn nicht nur im Volumen der Datenbank als solcher, sondern auch in der Geschwindigkeit einzelner Tabellen liegt und das Volumen der Tabellen reduzierter Subsysteme um mehr als 33% abnahm - von 46% auf 77% (in 2- 3 mal).

Schauen wir uns einige Indikatoren und Fakten zur tatsächlichen Verwendung der Faltung genauer an. Die Dauer der direkten Datenfaltung betrug etwa 12 Stunden. Das Synchronisieren der akkumulierten Änderungen mit DBREPLICATION dauerte ca. 1 Stunde. Einer der wichtigsten Punkte des Projekts war die endgültige Überprüfung der minimierten Basis durch die Spezialisten des Kunden. Besonders hervorzuheben ist die Dauer - dieser Vorgang dauerte ca. 1 Woche. Diese Dauer war auf die Tatsache zurückzuführen, dass die Überprüfung sehr tiefgreifend und umfassend war, wobei Spezialisten verschiedener Profile einbezogen wurden, einschließlich der Erstellung eines Datenmodells in einem externen System. Während dieser ganzen Zeit wurde die minimierte Basis durch DBREPLICATION automatisch mit der aktuellen Kampfdatenbank synchronisiert. Die Überprüfung war erfolgreich. Und Benutzer wurden zu einer reduzierten Datenbank gewechselt. Die vorherige Datenbank wurde mit schreibgeschütztem Zugriff in den Archivstatus übertragen. Die nachfolgende Synchronisierung war nicht erforderlich, sodass die Replikation deaktiviert wurde.

Projektzusammenfassung:

• Die angewandte Technik hat sich vollständig ausgezahlt, da genügend Zeit vorhanden war, um die Faltung selbst abzuschließen und die Daten umfassend zu überprüfen, wodurch das Risiko des Überspringens bestimmter Fehler und des Wechsels zu einer reduzierten Datenbank radikal minimiert wurde.
• Faltung erfolgreich abgeschlossen:
  
  • Das Gesamtvolumen der operativen Datenbank verringerte sich um 33%. Aus objektiven Gründen war es aufgrund von Einschränkungen bei der Faltung einiger großer Subsysteme nicht möglich, eine größere Auswirkung auf das Volumen der Datenbank zu erzielen.
  • Das Volumen der aktiv verwendeten Tabellen kollabierter Subsysteme verringerte sich um 46-77% (2-3-fach).
  
  

Fazit

DBReplication ist eine fertige, zuverlässige Lösung, die seit vielen Jahren auf dem Markt ist und von vielen Projekten unter verschiedenen Bedingungen getestet wurde. In der betrachteten Faltungstechnik übernimmt DBReplication eine der wichtigsten Unteraufgaben - die Datenbanksynchronisation. Bei besonders großen Datenbanken werden sehr hohe Anforderungen an das Austauschsystem gestellt, und DBReplication erfüllt diese vollständig. Es löst seine Aufgabe zuverlässig und effizient und sichert so den Erfolg des gesamten Projekts.

Für welche anderen Aufgaben können Sie DBREPLICATION verwenden

Eine Reihe von Funktionen und Wettbewerbsvorteilen ermöglicht die Verwendung von DBReplication zur Lösung einer Reihe von Problemen. Als Referenz listen wir sie auf.

• Datenbankredundanz und Fehlertoleranz.
• Lastausgleich: Verteilen Sie ihn zwischen zwei oder mehr synchronen Datenbankinstanzen.
• Beim kontrollierten Übergang zu neuen Softwareversionen (MS SQL, 1C) ähnelt die Technik der Faltungstechnik.
• Aufbau eines verteilten Informationssystems mit Hochgeschwindigkeitsaustausch basierend auf DBReplication. Insbesondere das Ersetzen der vorhandenen Unternehmensaustauschtechnologie durch eine produktivere und effizientere - DBREPLICATION.