Angenommen, Sie benötigen eine Datenmigration, bei der keine Ausfallzeiten toleriert werden und die für den Kunden vollkommen unbemerkt über die Bühne geht. In so einem Fall würde ein Big Bang oder ein Tranche-basierter Ansatz nicht ausreichen. Eine Null-Ausfallzeit kann nur durch eine Delta-Migrationsstrategie garantiert werden.

Sind Sie Architekt oder Projektmanager und für die Festlegung der Migrationsstrategie verantwortlich? Dann sollten Sie jetzt weiterlesen!

Durch diesen Artikel können Sie wertvolle Einblicke in eine wichtige Strategie gewinnen und   mit anderen möglichen Strategien vergleichen. Zuerst wird auf das Wie und Was von Delta-Migrationen näher eingegangen. Dann wird diese Strategie mit anderen häufig verwendeten Strategien verglichen. Zu guter Letzt wird konkludiert, dass Delta-Migrationen vor allem dann einen geeigneten Ausweg bieten, wenn Sie sich Ausfallzeiten nicht leisten können – und Sie es sich leisten können!

Die Idee

Die Idee hinter einer Delta-Migration ist einfach: Nehmen Sie sich die gesamte Laufzeit, die Sie für die Migration einer ersten Version der Daten benötigen, und führen Sie dann eine schnelle Aufholjagd am tatsächlichen Migrationswochenende durch, in dem Sie nur die Änderungen, die Deltas, verarbeiten, die zwischen dem Beginn der langen Migrationsperiode und dem Beginn der Aufholjagd aufgetreten sind. Die Idee dahinter ist, dass die Verarbeitung der Änderungen wirklich schnell vor sich geht, was zu einer sehr begrenzten Ausfallzeit führt.

Eine Delta-Migrationsstrategie ist eine Lösung, wenn die vollständige Migration mehr Zeit in Anspruch nimmt als die längste einkalkulierte Einfrierperiode. Dies geschieht, wenn der Datensatz groß oder die Einfrierperiode kurz ist.

Delta-Migrationen sind nur dann möglich, wenn die Erkennung von Änderungen und die Verarbeitung von Änderungen effizient erfolgen kann. Dies ist bei den meisten Migrationen möglich, obwohl es sich manchmal um einen komplexen Vorgang handeln kann.

Das Quellsystem bleibt auch nach der ersten Migration das führende System. Erst nach erfolgreicher Verarbeitung des Deltas im Zielsystem wird das Zielsystem zum führenden System.

Delta-Erkennung: Quelle oder Ziel?

Am häufigsten werden Deltas  in den Quelldaten bestimmt. Diese Deltas nennen wir „Quelldeltas“. Die Änderungen der Quelldaten zwischen Deltalauf und erstem Durchlauf werden zu Beginn des Deltalaufs erkannt. Der Deltalauf verarbeitet dann diese Unterschiede.

Eine weitere, weniger häufige Möglichkeit, Änderungen an den Zieldaten zu erkennen, befindet sich am Ende des zweiten Migrationslaufs, bevor Daten in das Zielsystem geladen werden. Diese Deltas werden als „Zieldeltas" bezeichnet. Der Deltalauf verarbeitet alle Quelldaten und berechnet die Unterschiede zwischen den Zieldaten im ersten Durchlauf und dem Deltadurchlauf. Dies kann dann gut eingesetzt werden, wenn das Migrationssystem schnell arbeitet und das Laden von Daten im Zielsystem langsam verläuft.

Verarbeitung von Deltas

Es gibt zwei Möglichkeiten, Deltas zu verarbeiten:

Alle geänderten Hauptentitäten werden in ihrer Gesamtheit migriert. Im Allgemeinen ermöglicht dies die Wiederverwendung von Zuordnungsregeln der ursprünglichen Migration.

Die Auswirkungen der Änderungen werden auf die Zieldaten berechnet. Dies ist in der Regel komplexer (und nicht für eine vollständige Migration konzipiert), außer die Transformation ist einfach.

Wie werden Delta-Migrationen gesteuert?

Die Überprüfung der Richtigkeit von Delta-Migrationen erfordert im Gegensatz zu anderen Migrationsstrategien eine genauere Aufmerksamkeit.

Der erste Durchlauf ist ein gewöhnlicher, alles verarbeitender Durchlauf, der auf die gleiche Weise überprüft werden kann wie jede Migration mit nur einem Durchlauf. Am Ende des Deltalaufs müssen die Daten im Zielsystem mit den Daten im Quellsystem zu Beginn des Durchlaufs übereinstimmen. Eine Komplikation besteht darin, dass das Migrationssystem am Ende des Deltalaufs keine Kopie der Daten im Zielsystem hat (und diese Daten auch nicht in den Zwischenmodellen enthalten sind). Aus diesem Grund kann der normale" Ansatz der Migrationssteuerung nicht  angewendet werden. Auf diese Komplikation wird in diesem Artikel nicht näher eingegangen.

Erweiterungen und Variation

Einige der von uns beschriebenen Techniken für Delta-Migrationen können erweitert und verfeinert werden.

Quell- und Zieldeltas können kombiniert werden, um die Anzahl der Aktualisierungen in den Zieldaten weiter zu reduzieren. In einem kombinierten Ansatz migriert der Deltalauf die geänderten Quellentitäten und bestimmt dann die Deltas in den Zieldaten. Die migrierten Daten einer Hauptentität können unverändert bleiben, auch wenn sich die Daten aus der Quellentität geändert haben. Wenn beispielsweise nur der erste oder größte Wert migriert wird und die Änderung der Quelldaten keine Auswirkungen auf den ersten oder größten Wert hatte.

Eine weitere, praktischere Verfeinerung beschränkt die Deltaverarbeitung auf eine kleine Anzahl von Entitäten, z. B. Finanztransaktionen. Alle anderen Daten eines Kunden bleiben in der Periode nach dem ersten Durchlauf unverändert – etwas, das Sie garantieren können, indem Sie nach dem ersten Durchlauf die nicht-finanziellen Transaktionsprozesse nicht verarbeiten. Dadurch werden im Allgemeinen Einschränkungen für den Zeitrahmen zwischen dem ersten Durchlauf und dem Deltalauf auferlegt.

Wenn der Deltalauf zu viel Zeit in Anspruch nimmt, kann ein zweiter Deltalauf zur Verarbeitung der Änderungen verwendet werden, die während des ersten Deltalaufs aufgetreten sind (und ein dritter Deltalauf usw.). Auf diese Weise können auch Systeme mit sehr hoher Auslastung und großem Transaktionsvolumen (wie ein Kreditkartensystem) mit sehr begrenzter oder gar keiner Ausfallzeit migriert werden!

Überprüfung

Delta-Migrationen sind nicht billig. Die Delta-Erkennung ist ein zusätzlicher Schritt, der sorgfältig entworfen werden muss. Die Konzeption des Migrationssystems selbst muss in Hinblick auf die Deltaverarbeitung stattfinden. Das Überprüfen der Deltaverarbeitung wird mehr Zeit in Anspruch nehmen als die Prüfung einer vollständigen Migration.

Das Migrationssystem muss von Beginn an in Hinblick auf eine Deltaverarbeitung konzipiert und gebaut werden. Das DMS muss beispielsweise deterministisch sein oder Ergebnisse aus dem ersten Durchlauf verwenden.

Einige Migrationsschritte eignen sich nicht für die Deltaverarbeitung. Nehmen Sie z. B. die Gruppierung: um die Gruppierung zu bestimmen, müssen alle Quellentitäten verarbeitet werden. Wenn es nur um die Änderungen geht, kann die Gruppierung nicht bestimmt werden.

Solche Schritte machen die Bestimmung der geänderten Entitäten alles andere als einfach.

Ein weiteres potenzielles Problem besteht darin, dass Änderungen an den Quelldaten zu Ablehnungen unter den bereits migrierten Entitäten führen können. Diese Ablehnungen müssen im Deltalauf aus dem Zielsystem gelöscht werden.

Auch wenn Delta-Migrationen eine Einfrierperiode erfordern, handelt es sich um einen Zeitraum, der viel kürzer ist als bei einem vollständigen Durchlauf. Während des Deltalaufs ist das Quellsystem eingefroren und das Zielsystem noch nicht in Produktion. Transaktionen, die während des Deltalaufs auftreten, müssen für die spätere Verarbeitung im Zielsystem gepuffert werden. Deltaläufe reduzieren die Anzahl der gepufferten Transaktionen, eliminieren diese jedoch nicht vollständig.

Delta-Migrationen kosten zusätzlich Zeit und Geld für Design, Aufbau, Test und Durchlauf. Diese Zeit und dieses Geld wird für die Verarbeitung von Deltas ausgegeben - einem kleinen Teil des gesamten Datensatzes. Dessen sollten Sie sich bei der Auswahl Ihrer Migrationsstrategie bewusst sein.

Vor- und Nachteile von Delta-Migrationen

Kurze oder sogar keine Ausfallzeit

Die Migration findet fast unbemerkt für die Verbraucher statt

Die Leistung des ersten Durchlaufs ist weniger ausschlaggebend

Komplex

Schwierig zu überprüfen

Das Zielsystem muss Löschungen oder Aktualisierungen zulassen

Das Löschen/Aktualisieren von Daten im Zielsystem bedeutet einen zusätzlichen Schritt

Es wird ein effizienter Mechanismus zur Bestimmung von Änderungen benötigt

Ein komplexerer Kontrollrahmen ist notwendig

Ein Großteil des Budgets fließt in die Migration eines sehr kleinen Teils der Daten (d. h. der Deltas)

Alternativen

Es gibt mehrere Alternativen zu Delta-Migrationen. Die gebräuchlichsten sind die Migration in Tranchen, die Leistungsoptimierung der vollständigen Migration und die Verlängerung der Einfrierperiode.

Die Migration in Tranchen ist nur dann eine praktikable Alternative, wenn man Tranchen wählen kann, die so klein sind, dass sie sich in die größtmögliche Einfrierperiode einfügen lassen. Beachten Sie, dass eine Migration in Tranchen keine Big-Bang-Migration ist, da beide Systeme - die alten und neuen – solange in Produktion sind, bis die letzte Tranche migriert ist.

Im Falle der Leistungsoptimierung der vollständigen Migration muss der Durchlauf nach der Optimierung in die Einfrierperiode passen. Eine Leistungsoptimierung erfordert die Anschaffung einer schnelleren Hardware.

Selbst wenn ein Deltalauf unvermeidbar ist, kann ein schneller Durchlauf zu Beginn dazu beitragen, dass die Anzahl jener Änderungen reduziert wird, die im Deltalauf behandelt werden müssen. Vergessen Sie nicht, dass die Änderungen, die verarbeitet werden müssen, aus der Periode stammen, die mit dem Start des ersten Durchlaufs beginnt.

Die folgende Tabelle fasst die Charakteristika der Delta-Migrationen und Alternativen zusammen.

price tag

Dauer der Ausfallzeit
Ein führendes System
Auswirkungen auf Kunden
Komplexität

Delta

++
YES
++
--

Big Bang

--
YES
--
++

LEISTUNGS- OPTIMIERUNG

+-
YES
+-
-

TRANCHEN

+-
NO
+-
+

DX-Tipps zu bewährten Verfahren für die Verwendung von Delta-Migrationen.

Wenn Sie eine Delta-Migration als Migrationsstrategie auswählen, finden Sie hier einige der bewährten Methoden, die zu einer erfolgreichen Durchführung beitragen.

Entwurf für Delta-Migration

Entwerfen Sie Ihr Datenmigrationssystem, um Deltas zu verarbeiten. Die Deltaverarbeitung fungiert nicht als Zusatzoption, sie hat –  beim Entwurf beginnend – Auswirkung auf jede Phase in Ihrem Projekt!

Hoffen Sie auf das Beste, aber seien Sie auf das Schlimmste vorbereitet

Wenn eine kurze Einfrierperiode akzeptabel ist, dann führen Sie den ersten Durchlauf so schnell wie möglich aus - in der Hoffnung, dass sich ein Deltalauf erübrigt.

Wiederverwendung vorhandener Verarbeitungsfunktionen

Versuchen Sie, im Zielsystem sofern verfügbare vorhandene Austauschsysteme und Aktualisierungsmechanismen zu verwenden.

Selektives Einfrieren

Führen Sie ein sehr selektives Einfrieren durch: geben Sie nur Finanztransaktionen und einem sehr kleinen Satz kundenorientierter Prozesse die Erlaubnis dazu. Zum Beispiel dem Blockieren verlorener oder gestohlener Kredit- bzw. Zahlungskarten. Alle anderen Verarbeitungen werden eingefroren und verzögert.

Leistungsplan

Planen Sie den Deltalauf für den Zeitraum in der Woche, in dem die Anzahl der Änderungen/Transaktionen am geringsten ist. Bestimmen Sie diesen Zeitraum basierend auf historischen Transaktionsdaten im Quellsystem. In einem Kreditkartensystem zum Beispiel, finden in den frühen Morgenstunden eines Sonntagmorgens nur sehr wenige Transaktionen statt.

Schlussfolgerung

Das Berücksichtigen von kurzen Ausfallzeiten stellt beim Migrieren von Daten eine gewisse Herausforderung dar. In diesem Artikel wurde die Delta-Migrationsstrategie in Hinblick auf die Bewältigung dieser Herausforderung untersucht.

Bitte teilen Sie uns mit, falls Sie einen anderen Ansatz haben oder ein Verfahren kennen, dass sich besser bewährt hat!

Mehr erfahren?