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.
Vorbereitung der Migration von Neo4j zu Neptune
Die Migration von der Neo4j-Graphdatenbank zum Neptune-Graphdatenbankdienst kann auf zwei Arten angegangen werden: Re-Platforming oder Refactoring/Rearchitecting. Der Re-Platforming-Ansatz beinhaltet die Änderung des bestehenden Datenmodells und der Anwendungsarchitektur, um die Fähigkeiten von Neptune bestmöglich zu nutzen, während sich der Refactoring-Ansatz darauf konzentriert, äquivalente Komponenten in Neptune zu finden, um eine vergleichbare Implementierung zu erstellen. In der Praxis wird häufig eine Kombination dieser Strategien verwendet, da der Migrationsprozess ein Gleichgewicht zwischen der Neptune-Zielarchitektur und den Einschränkungen und Anforderungen der bestehenden Neo4j-Implementierung beinhaltet. Unabhängig vom Ansatz besteht der Schlüssel darin, ausgehend von den Anwendungsfällen der Anwendung das Datenmodell, die Abfragen und die Gesamtarchitektur zu entwerfen, die Ihren Anforderungen am besten entsprechen.
Konzepte für die Migration
Bei der Migration einer Neo4j-Anwendung zu Neptune empfehlen wir eine von zwei Strategien: entweder Re-Platforming oder Refactoring/Rearchitecting. Weitere Informationen zu Migrationsstrategien finden Sie unter 6 Strategien für die Migration von Anwendungen in die Cloud
Der Re-Platforming-Ansatz, der manchmal auch genannt wird lift-tinker-and-shift, umfasst die folgenden Schritte:
Identifizieren Sie die Anwendungsfälle, für die Ihre Anwendung gedacht ist.
Modifizieren Sie das bestehende Graphdatenmodell und die Anwendungsarchitektur, um diese Workload-Anforderungen mithilfe der Funktionen von Neptune bestmöglich zu erfüllen.
Ermitteln Sie, wie Daten, Abfragen und andere Teile der Quellanwendung zum Zielmodell und zur Zielarchitektur migriert werden sollen.
Dieser vom Ende zum Anfang vorgehende Ansatz ermöglicht Ihnen, Ihre Anwendung auf die Art von Neptune-Lösung zu migrieren, die Sie entwerfen würden, wenn es sich um ein völlig neues Projekt handeln würde.
Dagegen beinhaltet das Refactoring-Konzept:
Identifizieren der Komponenten der bestehenden Implementierung, einschließlich Infrastruktur, Daten, Abfragen und Anwendungsfunktionen.
Suchen nach Äquivalenten in Neptune, die verwendet werden können, um eine vergleichbare Implementierung zu erstellen.
Dieser vom Anfang zum Ende vorgehende Ansatz zielt darauf ab, eine Implementierung gegen eine andere auszutauschen.
In der Praxis werden Sie wahrscheinlich eine Mischung aus diesen beiden Konzepten wählen. Sie könnten mit einem Anwendungsfall beginnen, die Neptune-Zielarchitektur entwerfen, sich dann aber der bestehenden Neo4j-Implementierung zuwenden, um Einschränkungen und Invarianten zu identifizieren, die Sie beibehalten müssen. Möglicherweise müssen Sie die Integration mit anderen externen Systemen fortsetzen oder weiterhin spezielle APIs Angebote für Nutzer Ihrer Graph-Anwendung anbieten. Anhand dieser Informationen können Sie ermitteln, welche Daten bereits vorhanden sind, um sie in Ihr Zielmodell zu übertragen, und welche Daten aus anderen Quellen kommen müssen.
An anderen Stellen könnten Sie damit beginnen, einen bestimmten Teil Ihrer Neo4j-Implementierung als Informationsquelle zu der Aufgabe zu analysieren, für die Ihre Anwendung vorgesehen ist. Diese Art von „Archäologie“ in der bestehenden Anwendung kann dabei helfen, einen Anwendungsfall zu beschreiben, den Sie dann so ausrichten können, dass die Fähigkeiten von Neptune genutzt werden.
Unabhängig davon, ob Sie eine neue Anwendung mit Neptune erstellen oder eine bestehende Anwendung von Neo4j migrieren, empfehlen wir, ausgehend von Anwendungsfällen ein Datenmodell, eine Reihe von Abfragen und eine Anwendungsarchitektur zu entwerfen, die Ihren geschäftlichen Anforderungen entsprechen.
