Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Migration von einer relationalen Datenbank zu DynamoDB
Die Migration einer relationalen Datenbank zu DynamoDB erfordert eine sorgfältige Planung, um ein erfolgreiches Ergebnis sicherzustellen. In diesem Leitfaden erfahren Sie, wie dieser Prozess funktioniert, welche Tools Ihnen zur Verfügung stehen und wie Sie anschließend mögliche Migrationsstrategien bewerten und eine auswählen können, die Ihren Anforderungen entspricht.
Themen
- Gründe für die Migration zu DynamoDB
- Überlegungen bei der Migration einer relationalen Datenbank zu DynamoDB
- Verstehen, wie eine Migration zu DynamoDB funktioniert
- Tools zur Unterstützung bei der Migration zu DynamoDB
- Auswahl der geeigneten Strategie für die Migration zu DynamoDB
- Durchführen einer Offline-Migration zu DynamoDB
- Durchführung einer Hybridmigration zu DynamoDB
- Durchführung einer Online-Migration zu DynamoDB, indem jede Tabelle 1:1 migriert wird
- Führen Sie mithilfe einer benutzerdefinierten Staging-Tabelle eine Online-Migration zu DynamoDB durch
Gründe für die Migration zu DynamoDB
Die Migration zu Amazon DynamoDB bietet eine Reihe überzeugender Vorteile für Unternehmen und Organisationen. Hier sind einige der wichtigsten Vorteile, die DynamoDB zu einer attraktiven Wahl für die Datenbankmigration machen:
-
Skalierbarkeit: DynamoDB ist darauf ausgelegt, massive Workloads zu bewältigen und nahtlos zu skalieren, um wachsenden Datenmengen und Datenströmen gerecht zu werden. Mit DynamoDB können Sie Ihre Datenbank je nach Bedarf einfach nach oben oder unten skalieren und so sicherstellen, dass Ihre Anwendungen plötzliche Datenverkehrsspitzen ohne Leistungseinbußen bewältigen können.
-
Leistung: DynamoDB bietet Datenzugriff mit niedriger Latenz, sodass Anwendungen Daten mit außergewöhnlicher Geschwindigkeit abrufen und verarbeiten können. Die verteilte Architektur stellt sicher, dass Lese- und Schreibvorgänge auf mehrere Knoten verteilt werden, sodass selbst bei hohen Anforderungsraten konsistente Reaktionszeiten im einstelligen Millisekundenbereich erzielt werden.
-
Vollständig verwaltet: DynamoDB ist ein vollständig verwalteter Service von AWS. Das bedeutet, dass AWS kümmert sich um die betrieblichen Aspekte des Datenbankmanagements, einschließlich Bereitstellung, Konfiguration, Patching, Backups und Skalierung. Auf diese Weise können Sie sich mehr auf die Entwicklung Ihrer Anwendungen und weniger auf Datenbankverwaltungsaufgaben konzentrieren.
-
Serverlose Architektur: DynamoDB unterstützt ein serverloses Modell, bekannt als DynamoDB on-Demand, bei dem Sie nur für die tatsächlichen Lese- und Schreibanforderungen zahlen, die Ihre Anwendung stellt, ohne dass vorab Kapazitäten bereitgestellt werden müssen. Dieses pay-per-request Modell bietet Kosteneffizienz und minimalen Betriebsaufwand, da Sie nur für die Ressourcen zahlen, die Sie verbrauchen, ohne dass Kapazitäten bereitgestellt und überwacht werden müssen.
-
Keine SQL Flexibilität: Im Gegensatz zu herkömmlichen relationalen Datenbanken folgt DynamoDB einem SQL No-Data-Modell, was Flexibilität beim Schemadesign bietet. Mit DynamoDB können Sie strukturierte, halbstrukturierte und unstrukturierte Daten speichern, sodass sie sich gut für den Umgang mit unterschiedlichen und sich weiterentwickelnden Datentypen eignen. Diese Flexibilität ermöglicht schnellere Entwicklungszyklen und eine einfachere Anpassung an sich ändernde Geschäftsanforderungen.
-
Hohe Verfügbarkeit und Beständigkeit: DynamoDB repliziert Daten über mehrere Availability Zones innerhalb einer Region und gewährleistet so hohe Verfügbarkeit und Datenbeständigkeit. Es übernimmt automatisch Replikation, Failover und Wiederherstellung und minimiert so das Risiko von Datenverlusten oder Serviceunterbrechungen. DynamoDB bietet eine Verfügbarkeit SLA von bis zu 99,999%
-
Sicherheit und Compliance: DynamoDB lässt sich integrieren mit AWS Identity and Access Management für eine differenzierte Zugriffskontrolle. Es bietet Verschlüsselung im Ruhezustand und bei der Übertragung und gewährleistet so die Sicherheit Ihrer Daten. DynamoDB hält sich auch an verschiedene Compliance-Standards, darunter, und HIPAA PCI DSSGDPR, sodass Sie regulatorische Anforderungen erfüllen können.
-
Integration mit AWS Ökosystem: Als Teil des AWS Ökosystem, DynamoDB lässt sich nahtlos in andere integrieren AWS Dienste, wie AWS Lambda, AWS CloudFormation, und AWS AppSync. Diese Integration ermöglicht es Ihnen, serverlose Architekturen zu erstellen, Infrastruktur als Code zu nutzen und datengesteuerte Echtzeitanwendungen zu erstellen.
Überlegungen bei der Migration einer relationalen Datenbank zu DynamoDB
Relationale Datenbanksysteme und SQL No-Datenbanken haben unterschiedliche Stärken und Schwächen. Aufgrund dieser Unterschiede unterscheidet sich das Datenbankdesign zwischen den beiden Systemen.
| Aufgabentyp | Relationale Datenbank | Keine SQL Datenbank |
|---|---|---|
| Die Datenbank wird abgefragt | In relationalen Datenbanken können Daten flexibel abgefragt werden, Abfragen sind jedoch relativ teuer und lassen sich in Situationen mit hohem Datenaufkommen nicht gut skalieren (siehe). Erste Schritte für die Modellierung relationaler Daten in DynamoDB Eine relationale Datenbankanwendung kann Geschäftslogik in gespeicherten Prozeduren, SQL Unterabfragen, Massenaktualisierungsabfragen und Aggregationsabfragen implementieren. | In einer SQL No-Datenbank wie DynamoDB können Daten auf eine begrenzte Anzahl von Arten effizient abgefragt werden. Andernfalls können Abfragen teuer und langsam sein. Schreibvorgänge in DynamoDB sind Singletons. Die Geschäftslogik von Anwendungen, die früher in gespeicherten Prozeduren ausgeführt wurden, muss so umgestaltet werden, dass sie außerhalb von DynamoDB in benutzerdefiniertem Code ausgeführt wird, der auf einem Host wie Amazon Amazon oder EC2 AWS Lambda. |
| Entwerfen der Datenbank | Sie legen Wert auf Flexibilität, ohne sich Gedanken über Implementierungsdetails oder Leistung machen zu müssen. Die Optimierung von Abfragen wirkt sich im Allgemeinen nicht auf das Schemadesign aus, eine Standardisierung ist jedoch wichtig. | Sie entwerfen Ihr Schema speziell, um die gängigsten und wichtigsten Abfragen so schnell und kostengünstig wie möglich zu gestalten. Ihre Datenstrukturen sind an die spezifischen Anforderungen Ihrer geschäftlichen Anwendungsfälle angepasst. |
Das Entwerfen für keine SQL Datenbank erfordert eine andere Denkweise als das Entwerfen für ein relationales Datenbankmanagementsystem ()RDBMS. Für ein können Sie ein normalisiertes Datenmodell erstellenRDBMS, ohne über Zugriffsmuster nachdenken zu müssen. Anschließend können Sie es erweitern, wenn neue Fragen und Abfrageanforderungen entstehen. Sie können jeden einzelnen Typ von Daten in einer eigenen Tabelle organisieren.
Ohne SQL Design können Sie Ihr Schema für DynamoDB entwerfen, wenn Sie wissen, welche Fragen es beantworten muss. Es ist wichtig, die Geschäftsprobleme und die Lese- und Schreibmuster der Anwendung zu verstehen. Sie sollten auch versuchen, so wenige Tabellen wie möglich in einer DynamoDB-Anwendung zu verwalten. Weniger Tabellen sorgen dafür, dass die Dinge besser skalierbar sind, weniger Berechtigungsmanagement erforderlich sind und der Overhead für Ihre DynamoDB-Anwendung reduziert wird. Dies kann auch dazu beitragen, die Backup-Kosten insgesamt niedrig zu halten.
Die Aufgabe, relationale Daten für DynamoDB zu modellieren und eine neue Version der Front-End-Anwendung zu erstellen, ist ein separates Thema. In diesem Handbuch wird davon ausgegangen, dass Sie über eine neue Version Ihrer Anwendung verfügen, die für die Verwendung von DynamoDB entwickelt wurde. Sie müssen jedoch noch herausfinden, wie Sie historische Daten während der Umstellung am besten migrieren und synchronisieren können.
Überlegungen zur Größenbestimmung
Die maximale Größe jedes Elements (Zeile), das Sie in einer DynamoDB-Tabelle speichern, beträgt 400 KB. Weitere Informationen finden Sie unter Service-, Konto- und Tabellenkontingente in Amazon DynamoDB. Die Elementgröße wird durch die Gesamtgröße aller Attributnamen und Attributwerte in einem Element bestimmt. Weitere Informationen finden Sie unter DynamoDB-Elementgrößen und -formate.
Wenn Ihre Anwendung mehr Daten in einem Artikel speichern muss, als die DynamoDB-Größenbeschränkung zulässt, teilen Sie den Artikel in eine Artikelsammlung auf, komprimieren Sie die Artikeldaten oder speichern Sie den Artikel als Objekt in Amazon Simple Storage Service (Amazon S3), während Sie die Amazon S3-Objekt-ID in Ihrem DynamoDB-Artikel speichern. Siehe Bewährte Methoden für das Speichern großer Elemente und Attribute in DynamoDB. Die Kosten für die Aktualisierung eines Artikels basieren auf der vollen Größe des Artikels. Bei Workloads, die häufige Aktualisierungen vorhandener Elemente erfordern, kostet die Aktualisierung kleiner Elemente mit einer Größe von ein oder zwei KB weniger als die Aktualisierung größerer Elemente. Elementsammlungen — wie man one-to-many Beziehungen in DynamoDB modelliertWeitere Informationen zu Artikelsammlungen finden Sie unter.
Bei der Auswahl der Schlüsselattribute für Partition und Sortierung, anderer Tabelleneinstellungen, Elementgröße und -struktur und der Frage, ob Sekundärindizes erstellt werden sollen, sollten Sie unbedingt die DynamoDB Modeling-Dokumentation sowie den Leitfaden für lesen. Optimierung der Kosten für DynamoDB-Tabellen Testen Sie unbedingt Ihren Migrationsplan, damit Ihre DynamoDB-Lösung kosteneffizient ist und den Funktionen und Einschränkungen von DynamoDB entspricht.
Verstehen, wie eine Migration zu DynamoDB funktioniert
Bevor Sie sich mit den Migrationstools befassen, die uns zur Verfügung stehen, sollten Sie sich überlegen, wie Schreibvorgänge von DynamoDB verarbeitet werden.
Die standardmäßige und am häufigsten verwendete Schreiboperation ist eine einzelne PutItemAPIOperation. Sie können eine PutItem Operation in einer Schleife ausführen, um Datensätze zu verarbeiten. DynamoDB unterstützt praktisch unbegrenzt viele gleichzeitige Verbindungen. Wenn Sie also eine umfangreiche Multithread-Laderoutine wie MapReduce oder Spark konfigurieren und ausführen können, ist die Geschwindigkeit von Schreibvorgängen nur durch die Kapazität der Zieltabelle begrenzt (die im Allgemeinen ebenfalls unbegrenzt ist).
Beim Laden von Daten in DynamoDB ist es wichtig, die Schreibgeschwindigkeit Ihres Loaders zu verstehen. Wenn die Elemente (Zeilen), die Sie laden, eine Größe von 1 KB oder weniger haben, ist diese Geschwindigkeit einfach die Anzahl der Elemente pro Sekunde. Die Zieltabelle kann dann mit ausreichend WCU (Schreibkapazitätseinheiten) ausgestattet werden, um diese Rate zu bewältigen. Wenn Ihr Loader die bereitgestellte Kapazität in einer bestimmten Sekunde überschreitet, werden die zusätzlichen Anfragen möglicherweise gedrosselt oder ganz zurückgewiesen. Sie können in den CloudWatch Diagrammen auf der Registerkarte Überwachung der DynamoDB-Konsole nach Drosselungen suchen.
Die zweite Operation, die ausgeführt werden kann, erfolgt mit einem verwandten Aufruf. API BatchWriteItem BatchWriteItemermöglicht es Ihnen, bis zu 25 Schreibanforderungen zu einem API Anruf zusammenzufassen. Diese werden vom Service empfangen und als separate PutItem Anfragen an die Tabelle verarbeitet. Derzeit erhalten Sie bei der Auswahl BatchWriteItem nicht den Vorteil der automatischen Wiederholungsversuche, die im Lieferumfang enthalten sind AWS SDKbei Singleton-Anrufen mit. PutItem Wenn also Fehler auftreten (z. B. Drosselungsausnahmen), müssen Sie beim Antwortaufruf nach der Liste der fehlgeschlagenen Schreibvorgänge suchen. BatchWriteItem Weitere Informationen zum Umgang mit Drosselungswarnungen für den Fall, dass diese in den Drosselungstabellen erkannt werden, finden Sie CloudWatch unter. Drosselungsprobleme für DynamoDB
Die dritte Art des Datenimports ist mit der Funktion DynamoDB Import from S3PutItem wie erfordert es einen Upstream-Prozess und schreibt die Daten im von Ihnen gewählten Format in einen Amazon S3 S3-Bucket.
Tools zur Unterstützung bei der Migration zu DynamoDB
Es gibt mehrere gängige Migrations- und ETL Tools, mit denen Sie Daten nach DynamoDB migrieren können.
Amazon bietet eine Vielzahl von Datentools, die bei der Migration verwendet werden können, darunter AWS Database Migration Service (DMS), AWS GlueEMR, Amazon und Amazon Managed Streaming for Apache Kafka. All diese Tools können verwendet werden, um eine Downtime-Migration durchzuführen, und sie können die Funktionen der relationalen Datenbank Change Data Capture (CDC) nutzen, um Online-Migrationen zu unterstützen. Bei der Auswahl eines Tools ist es hilfreich, die Fähigkeiten und Erfahrungen zu berücksichtigen, über die Ihr Unternehmen mit den einzelnen Tools verfügt, sowie deren Funktionen, Leistung und Kosten.
Viele Kunden entscheiden sich dafür, ihre eigenen Migrationsskripte und Jobs zu schreiben, um benutzerdefinierte Datentransformationen für den Migrationsprozess zu erstellen. Wenn Sie planen, eine DynamoDB-Tabelle mit hohem Schreibvolumen oder regelmäßigen großen Massenladeaufträgen zu betreiben, möchten Sie möglicherweise selbst Migrationscode schreiben, um sich mit dem Verhalten von DynamoDB bei hohem Schreibverkehr vertraut zu machen. Szenarien wie die Handhabung von Drosselungen und die effiziente Bereitstellung von Tabellen können bereits zu Beginn des Projekts bei der Durchführung einer Praxismigration erlebt werden.
Auswahl der geeigneten Strategie für die Migration zu DynamoDB
Eine große relationale Datenbankanwendung kann sich über einhundert oder mehr Tabellen erstrecken und mehrere verschiedene Anwendungsfunktionen unterstützen. Wenn Sie sich einer großen Migration nähern, sollten Sie erwägen, Ihre Anwendung in kleinere Komponenten oder Microservices aufzuteilen und jeweils nur eine kleine Gruppe von Tabellen zu migrieren. Anschließend können Sie weitere Komponenten wellenweise zu DynamoDB migrieren.
Bei der Auswahl einer Migrationsstrategie können verschiedene Faktoren dazu führen, dass Sie sich für die eine oder andere Lösung entscheiden. Wir können diese Optionen in einem Entscheidungsbaum präsentieren, um die Optionen zu vereinfachen, die uns angesichts unserer Anforderungen und verfügbaren Ressourcen zur Verfügung stehen. Die Konzepte werden hier kurz erwähnt (werden aber später im Leitfaden ausführlicher behandelt):
-
Offline-Migration: Wenn Ihre Anwendung während der Migration einige Ausfallzeiten toleriert, vereinfacht dies den Migrationsprozess.
-
Hybridmigration: Dieser Ansatz ermöglicht eine teilweise Verfügbarkeit während einer Migration, z. B. das Zulassen von Lesevorgängen, aber keine Schreibvorgänge oder das Zulassen von Lese- und Einfügevorgängen, jedoch keine Aktualisierungen und Löschungen.
-
Online-Migration: Anwendungen, die während der Migration keine Ausfallzeiten erfordern, sind weniger einfach zu migrieren und erfordern möglicherweise eine umfangreiche Planung und kundenspezifische Entwicklung. Eine wichtige Entscheidung besteht darin, die Kosten für die Erstellung eines maßgeschneiderten Migrationsprozesses abzuschätzen und gegen die Kosten abzuwägen, die dem Unternehmen durch ein Ausfallzeitfenster während der Umstellung entstehen.
| Wenn | And | Dann |
|---|---|---|
| Sie können die Anwendung während eines Wartungsfensters für einige Zeit herunterfahren, um die Datenmigration durchzuführen. Dies ist eine Offline-Migration. |
Verwenden Sie AWS DMS und führen Sie eine Offline-Migration mit einer Volllastaufgabe durch. Vorformen Sie die Quelldaten bei SQL |
|
| Sie können die Anwendung während der Migration im schreibgeschützten Modus ausführen. Dies ist eine Hybridmigration. | Deaktivieren Sie Schreibvorgänge innerhalb der Anwendungs- oder Quelldatenbank. Verwenden Sie AWS DMS und führen Sie eine Offline-Migration mithilfe einer Vollladeaufgabe durch. | |
| Sie können die Anwendung während der Migration mit Lesevorgängen und Einfügungen neuer Datensätze, aber ohne Aktualisierungen oder Löschungen ausführen. Dies ist eine Hybridmigration. | Sie verfügen über Kenntnisse in der Anwendungsentwicklung und können die bestehende relationale App aktualisieren, um duale Schreibvorgänge, auch in DynamoDB, für alle neuen Datensätze durchzuführen | Verwenden Sie AWS DMS und führen eine Offline-Migration mithilfe einer Vollladeaufgabe durch. Stellen Sie gleichzeitig eine Version der vorhandenen App bereit, die Lesevorgänge und duale Schreibvorgänge ermöglicht. |
| Sie benötigen eine Migration mit minimalen Ausfallzeiten. Dies ist eine Online-Migration. |
|
Verwenden Sie AWS DMS um eine Online-Datenmigration durchzuführen. Führen Sie eine Massenladeaufgabe gefolgt von einer CDC Synchronisierungsaufgabe aus. |
| Sie benötigen eine Migration mit minimalen Ausfallzeiten. Dies ist eine Online-Migration. |
|
Erstellen Sie die Tabelle No SQL -ready in der SQL Datenbank. Füllen und synchronisieren Sie sie mithilfe vonJOINs, UNIONsVIEWs, Triggern und gespeicherten Prozeduren. |
| Sie benötigen eine Migration mit minimalen Ausfallzeiten. Dies ist eine Online-Migration. |
|
Ziehen Sie die Hybrid- oder Offline-Migrationsansätze in Betracht. |
| Sie benötigen eine Migration mit minimalen Ausfallzeiten. Dies ist eine Online-Migration. | Sie können die Migration historischer Transaktionsdaten überspringen oder sie in Amazon S3 archivieren, anstatt sie zu migrieren. Sie müssen nur ein paar kleine statische Tabellen migrieren. | Schreiben Sie ein Skript oder verwenden Sie ein beliebiges ETL Tool, um die Tabellen zu migrieren. SQLVIEWFalls gewünscht, geben Sie den Quelldaten eine Form vor. |
Durchführen einer Offline-Migration zu DynamoDB
Offline-Migrationen eignen sich, wenn Sie für die Durchführung der Migration ein Ausfallzeitfenster einplanen können. Relationale Datenbanken haben in der Regel jeden Monat mindestens eine gewisse Ausfallzeit für Wartung und Patches oder längere Ausfallzeiten für Hardware-Upgrades oder Major-Release-Upgrades.
Amazon S3 kann während einer Migration als Staging-Bereich verwendet werden. Daten, die im Format CSV (durch Kommas getrennte Werte) oder im JSON DynamoDB-Format gespeichert sind, können mithilfe der Funktion DynamoDB-Import aus S3 automatisch in eine neue DynamoDB-Tabelle importiert werden.
Möglicherweise möchten Sie Tabellen kombinieren, um einzigartige Muster ohne SQL Zugriff zu nutzen (z. B. um vier Legacy-Tabellen in eine einzige DynamoDB-Tabelle umzuwandeln). Eine Dokumentanforderung mit einem einzigen Schlüsselwert oder eine Abfrage für eine vorgruppierte Elementsammlung wird in der Regel mit einer besseren Latenz zurückgegeben als eine SQL Datenbank, die eine Verknüpfung mit mehreren Tabellen durchführt. Dies macht die Migrationsaufgabe jedoch schwieriger. Eine SQL Ansicht könnte die Arbeit innerhalb der Quelldatenbank erledigen, um einen einzelnen Datensatz vorzubereiten, der alle vier Tabellen in einem Satz darstellt.
Diese Ansicht kann JOIN Tabellen in eine denormalisierte Form umwandeln, oder sie könnte die Entitäten normalisieren und Tabellen mithilfe von a stapeln. SQL UNION In diesem Video werden wichtige Entscheidungen im Zusammenhang mit der Umgestaltung relationaler Daten behandelt.
Planen
Führen Sie eine Offline-Migration mit Amazon S3 durch
Tools
-
Ein ETL Job zum Extrahieren und Transformieren von SQL Daten und zum Speichern in einem S3-Bucket wie:
-
AWS Database Migration Service, ein Dienst, der historische Daten massenweise laden und auch Change Data Capture (CDC) -Datensätze verarbeiten kann, um Quell- und Zieltabellen zu synchronisieren.
-
AWS Glue
-
Amazon EMR
-
Ihr eigener benutzerdefinierter Code
-
-
Die DynamoDB-Funktion zum Import aus S3
Schritte zur Offline-Migration:
-
Erstellen Sie einen ETL Job, der die SQL Datenbank abfragen, Tabellendaten in DynamoDB JSON oder ein CSV Format umwandeln und in einem S3-Bucket speichern kann.
-
Die Funktion DynamoDB Import from S3 wird aufgerufen, um eine neue Tabelle zu erstellen und automatisch Daten aus Ihrem S3-Bucket zu laden.
Die vollständige Offline-Migration ist einfach und unkompliziert, aber sie ist bei Anwendungsbesitzern und -benutzern möglicherweise nicht beliebt. Die Benutzer würden davon profitieren, wenn die Anwendung während der Migration weniger Dienste bereitstellen könnte, anstatt überhaupt keine Dienste bereitzustellen.
Sie könnten Funktionen hinzufügen, um Schreibvorgänge während der Offlinemigration zu deaktivieren, während die Lesevorgänge wie gewohnt fortgesetzt werden können. Anwendungsbenutzer können weiterhin sicher nach vorhandenen Daten suchen und diese abfragen, während die relationalen Daten migriert werden. Wenn Sie danach suchen, lesen Sie weiter, um mehr über Hybridmigrationen zu erfahren.
Durchführung einer Hybridmigration zu DynamoDB
Zwar führen alle Datenbankanwendungen Lese- und Schreibvorgänge durch, bei der Planung einer Hybrid- oder Online-Migration sollten jedoch die Arten der auszuführenden Schreibvorgänge berücksichtigt werden. Datenbank-Schreibvorgänge können in drei Bereiche eingeteilt werden: Einfügungen, Aktualisierungen und Löschungen. Bei einigen Anwendungen ist möglicherweise keine sofortige Verarbeitung von Löschungen erforderlich. Bei diesen Anwendungen können Löschungen beispielsweise auf einen Massenbereinigungsprozess am Monatsende verschoben werden. Diese Arten von Anwendungen lassen sich einfacher migrieren und ermöglichen gleichzeitig eine teilweise Verfügbarkeit.
Planen
Führen Sie eine hybride Online-/Offline-Migration mit dualen Schreibvorgängen für Anwendungen durch
Tools
-
Ein ETL Job zum Extrahieren und Transformieren von SQL Daten und zum Speichern in einem S3-Bucket wie:
-
AWS DMS
-
AWS Glue
-
Amazon EMR
-
Ihr eigener benutzerdefinierter Code
-
Schritte zur hybriden Migration:
-
Erstellen Sie die DynamoDB-Zieltabelle. Diese Tabelle empfängt sowohl historische Massendaten als auch neue Live-Daten
-
Erstellen Sie eine Version der Legacy-Anwendung, bei der Löschungen und Aktualisierungen deaktiviert sind, während alle Einfügungen als duale Schreibvorgänge sowohl in die SQL Datenbank als auch in DynamoDB ausgeführt werden.
-
Beginnen Sie mit dem Job oder ETL AWS DMS Aufgabe, bestehende Daten aufzufüllen und gleichzeitig die neue Anwendungsversion bereitzustellen
-
Wenn der Backfill-Job abgeschlossen ist, verfügt DynamoDB über alle vorhandenen und neuen Datensätze und ist bereit für die Übernahme der Anwendung
Anmerkung
Der Backfill-Job schreibt direkt von SQL zu DynamoDB. Wir können die S3-Importfunktion nicht wie im Offline-Migrationsbeispiel verwenden, da diese Funktion eine neue Tabelle erstellt, die erst verfügbar ist, nachdem DynamoDB die Daten geladen hat.
Durchführung einer Online-Migration zu DynamoDB, indem jede Tabelle 1:1 migriert wird
Viele relationale Datenbanken verfügen über eine Funktion namens Change Data Capture (CDC), mit der Benutzer anhand der Datenbank eine Liste der Änderungen an einer Tabelle anfordern können, die vor oder nach einem bestimmten Zeitpunkt vorgenommen wurden. CDCverwendet interne Protokolle, um diese Funktion zu aktivieren, und es ist nicht erforderlich, dass die Tabelle über eine Zeitstempelspalte verfügt, um zu funktionieren.
Wenn Sie ein Tabellenschema in eine SQL No-Datenbank migrieren, möchten Sie möglicherweise Ihre Daten kombinieren und in weniger SQL Tabellen umformen. Auf diese Weise können Sie Daten an einem einzigen Ort sammeln und müssen verwandte Daten nicht manuell in mehrstufigen Lesevorgängen zusammenfügen. Die Datenformung einzelner Tabellen ist jedoch nicht immer erforderlich, und manchmal migrieren Sie Tabellen 1-für-1 nach DynamoDB. Diese 1-zu-1-Tabellenmigrationen sind weniger kompliziert, da Sie die CDC Quelldatenbankfunktion nutzen können, indem Sie gängige ETL Tools verwenden, die diese Art der Migration unterstützen. Die Daten für jede Zeile können immer noch in neue Formate umgewandelt werden, der Umfang jeder Tabelle bleibt jedoch derselbe.
Erwägen Sie die Migration von SQL Tabellen 1-zu-1 nach DynamoDB mit dem Vorbehalt, dass DynamoDB keine serverseitigen Joins unterstützt. Sie müssen Ihrer Anwendung Logik hinzufügen, um Daten aus mehreren Tabellen zu kombinieren.
Planen
Führen Sie eine Online-Migration jeder Tabelle zu DynamoDB durch, indem Sie AWS DMS
Tools
Schritte zur Online-Migration:
-
Identifizieren Sie die Tabellen in Ihrem Quellschema, die migriert werden
-
Erstellen Sie dieselbe Anzahl von Tabellen in DynamoDB mit derselben Schlüsselstruktur wie in der Quelle
-
Erstellen Sie einen Replikationsserver in AWS DMS und konfigurieren Sie die Quell- und Zielendpunkte
-
Definieren Sie alle erforderlichen Transformationen pro Zeile (z. B. verkettete Spalten oder Konvertierung von Datumsangaben in das Zeichenkettenformat -8601) ISO
-
Erstellen Sie für jede Tabelle eine Migrationsaufgabe für Full Load und Change Data Capture
-
Überwachen Sie diese Aufgaben, bis die laufende Replikationsphase begonnen hat
-
Zu diesem Zeitpunkt können Sie alle Validierungsaudits durchführen und dann Benutzer zu der Anwendung wechseln, die in DynamoDB liest und schreibt.
Führen Sie mithilfe einer benutzerdefinierten Staging-Tabelle eine Online-Migration zu DynamoDB durch
Wie im obigen Offline-Migrationsszenario können Sie Tabellen kombinieren, um einzigartige Muster ohne SQL Zugriff zu nutzen (z. B. die Umwandlung von vier Legacy-Tabellen in eine einzige DynamoDB-Tabelle). A SQL VIEW könnte die Arbeit innerhalb der Quelldatenbank erledigen, um einen einzelnen Datensatz vorzubereiten, der alle vier Tabellen in einem Satz darstellt.
Bei Online-Migrationen mit sich ändernden Live-Daten können Sie die CDC Funktionen jedoch nicht nutzen, da sie für VIEW s nicht unterstützt werden. Wenn Ihre Tabellen eine Spalte mit den zuletzt aktualisierten Zeitstempeln enthalten und diese in die integriert sind, können Sie einen benutzerdefinierten ETL Job erstellenVIEW, der diese verwendet, um einen Massenladevorgang mit Synchronisation zu erreichen.
Ein neuer Ansatz zur Bewältigung dieser Herausforderung besteht darin, SQL Standardfunktionen wie Ansichten, gespeicherte Prozeduren und Trigger zu verwenden, um eine neue SQL Tabelle zu erstellen, die im endgültigen gewünschten DynamoDB-Format No SQL vorliegt.
Wenn Ihr Datenbankserver über die freie Kapazität verfügt, ist es möglich, diese einzelne Staging-Tabelle zu erstellen, bevor die Migration beginnt. Dazu schreiben Sie eine gespeicherte Prozedur, die aus vorhandenen Tabellen liest, Daten nach Bedarf transformiert und in die neue Staging-Tabelle schreibt. Sie können eine Reihe von Triggern hinzufügen, um Änderungen an Tabellen in Echtzeit in die Staging-Tabelle zu replizieren. Wenn Trigger laut Unternehmensrichtlinie nicht zulässig sind, können Änderungen an gespeicherten Prozeduren zum gleichen Ergebnis führen. Sie würden jeder Prozedur, die Daten schreibt, einige Codezeilen hinzufügen, um dieselben Änderungen zusätzlich in die Staging-Tabelle zu schreiben.
Diese Staging-Tabelle, die vollständig mit den Legacy-Anwendungstabellen synchronisiert ist, bietet Ihnen einen guten Ausgangspunkt für eine Live-Migration. Tools, die Datenbanken CDC zur Durchführung von Live-Migrationen verwenden, wie AWS DMS, kann jetzt für diese Tabelle verwendet werden. Ein Vorteil dieses Ansatzes besteht darin, dass er bekannte SQL Fähigkeiten und Funktionen nutzt, die in der relationalen Datenbank-Engine verfügbar sind.
Planen
Führen Sie eine Online-Migration mit einer SQL Staging-Tabelle durch AWS DMS
Tools
-
Benutzerdefinierte SQL gespeicherte Prozeduren oder Trigger
Schritte zur Online-Migration:
-
Stellen Sie sicher, dass in der relationalen Quelldatenbank-Engine etwas mehr Festplattenspeicher und Verarbeitungskapazität vorhanden sind.
-
Erstellen Sie eine neue Staging-Tabelle in der SQL Datenbank mit aktivierten Zeitstempeln oder Funktionen CDC
-
Schreiben Sie eine gespeicherte Prozedur und führen Sie sie aus, um vorhandene relationale Tabellendaten in die Staging-Tabelle zu kopieren
-
Stellen Sie Trigger bereit oder ändern Sie bestehende Prozeduren, um duales Schreiben in die neue Staging-Tabelle durchzuführen und gleichzeitig normale Schreibvorgänge in vorhandenen Tabellen durchzuführen
-
Ausführen AWS DMS um diese Quelltabelle zu einer DynamoDB-Zieltabelle zu migrieren und zu synchronisieren
In diesem Leitfaden wurden verschiedene Überlegungen und Ansätze für die Migration relationaler Datenbankdaten nach DynamoDB vorgestellt, wobei der Schwerpunkt auf der Minimierung von Ausfallzeiten und der Verwendung gängiger Datenbanktools und -techniken lag. Weitere Informationen finden Sie hier:
