Vorbereitung der Migration von Neo4j zu Neptune

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, Blog-Beitrag von Stephen Orban.

Das Re-Platforming-Konzept, manchmal auch als Lift-Tinker-and-Shift bezeichnet, beinhaltet 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 den Nutzern Ihrer Graph-Anwendung weiterhin spezifische APIs 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.

Architektonische Unterschiede zwischen Neptune und Neo4j

Wenn Kunden zum ersten Mal erwägen, eine Anwendung von Neo4j zu Neptune zu migrieren, ist es oft verlockend, einen Direktvergleich anhand der Größe der Instances vorzunehmen. Die Architekturen von Neo4j und Neptune weisen jedoch grundlegende Unterschiede auf. Neo4j basiert auf einem All-in-One-Konzept, bei dem das Laden von Daten, Daten-ETL, Anwendungsabfragen, Datenspeicher und Verwaltungsvorgänge sämtlich in demselben Satz von Computing-Ressourcen, wie etwa EC2-Instances, ausgeführt werden.

Neptune ist hingegen eine OLTP-fokussierte Graphdatenbank, in der die Architektur die Verantwortlichkeiten voneinander trennt und in der Ressourcen entkoppelt sind, so dass sie dynamisch und unabhängig skaliert werden können.

Ermitteln Sie bei der Migration von Neo4j zu Neptune die Anforderungen an Datenbeständigkeit, Verfügbarkeit und Skalierbarkeit Ihrer Anwendung. Die Cluster-Architektur von Neptune vereinfacht das Design von Anwendungen, die hohe Datenbeständigkeit, Verfügbarkeit und Skalierbarkeit erfordern. Mit einem Verständnis der Cluster-Architektur von Neptune können Sie dann eine Neptune-Cluster-Topologie entwerfen, die diese Anforderungen erfüllt.

Die Cluster-Architektur von Neo4j

Viele Produktionsanwendungen nutzen das kausale Clustering von Neo4j, um Datenbeständigkeit, hohe Verfügbarkeit und Skalierbarkeit zu gewährleisten. Die Clustering-Architektur von Neo4j verwendet Core-Server- und Lesereplikat-Instances:

• Core-Server sorgen für Datenbeständigkeit und Fehlertoleranz, indem sie Daten mithilfe des Raft-Protokolls replizieren.

• Lesereplikate verwenden den Versand von Transaktionsprotokollen, um Daten für Workloads mit hohem Lesedurchsatz asynchron zu replizieren.

Jede Instance in einem Cluster, ob Core-Server oder Lesereplikat, enthält eine vollständige Kopie der Graphdaten.

Die Cluster-Architektur von Neptune

Ein Neptune-Cluster besteht aus einer primären Writer-Instance und bis zu 15 Lesereplikat-Instances. Alle Instances im Cluster nutzen denselben zugrunde liegenden verteilten Speicherservice, der von den Instances getrennt ist.

• Die primäre Writer-Instance koordiniert alle Schreibvorgänge in der Datenbank und ist vertikal skalierbar, um flexible Unterstützung für unterschiedliche Schreib-Workloads zu bieten. Sie unterstützt auch Lesevorgänge.

• Lesereplikat-Instances unterstützen Lesevorgänge vom zugrunde liegenden Speicher-Volume aus und ermöglichen eine horizontale Skalierung, um hohe Lese-Workloads zu unterstützen. Sie sorgen auch für hohe Verfügbarkeit, indem sie als Failover-Ziele für die primäre Instance dienen.

  Anmerkung

  Bei hohen Schreib-Workloads empfiehlt es sich, die Lesereplikat-Instances auf die gleiche Größe wie die Writer-Instance zu skalieren, um sicherzustellen, dass die Reader bei den Datenänderungen konsistent bleiben können.

• Das zugrundeliegende Volume skaliert die Speicherkapazität automatisch, wenn die Datenmenge in Ihrer Datenbank zunimmt, und zwar bis zu 128 Tebibyte (TiB) Speicher.

Die Instance-Größen sind dynamisch und unabhängig. Die Größe jeder Instance kann geändert werden, während der Cluster ausgeführt wird, und es können auch Lesereplikate hinzugefügt oder entfernt werden, während der Cluster läuft.

Das Feature Neptune Serverless kann Ihre Rechenkapazität bei steigendem und fallendem Bedarf automatisch hoch- und herunterskalieren. Dadurch können Sie nicht nur Ihren Verwaltungsaufwand verringern, sondern die Datenbank auch so konfigurieren, dass sie große Bedarfsspitzen bewältigen kann, ohne dass die Leistung beeinträchtigt wird oder Sie zu viel bereitstellen müssen.

Sie können einen Neptune-Cluster für bis zu sieben Tage anhalten.

Neptune unterstützt auch Auto Scaling, um die Instance-Größen des Readers automatisch an den Workload anzupassen.

Mithilfe des globalen Datenbank-Features von Neptune können Sie einen Cluster in bis zu 5 anderen Regionen spiegeln.

Neptune ist außerdem vom Design her fehlertolerant:

• Das Cluster-Volume, das Datenspeicher für alle Instances im Cluster bereitstellt, erstreckt sich über mehrere Availability Zones (AZs) in einer einzelnen AWS-Region. Jede AZ beinhaltet eine vollständige Kopie der Cluster-Daten.

• Wenn die primäre Instance nicht verfügbar ist, wechselt Neptune automatisch zu einem vorhandenen Lesereplikat ohne Datenverlust, normalerweise in weniger als 30 Sekunden. Wenn im Cluster keine Lesereplikate vorhanden sind, stellt Neptune automatisch eine neue primäre Instance bereit – auch dies ohne Datenverlust.

All dies bedeutet, dass Sie bei der Migration von einem Neo4j-Kausal-Cluster zu Neptune die Cluster-Topologie nicht explizit auf hohe Datenbeständigkeit und hohe Verfügbarkeit auslegen müssen. Auf diese Weise können Sie die Größe Ihres Clusters für die erwarteten Lese- und Schreib-Workloads und etwaige erhöhte Verfügbarkeitsanforderungen anpassen, und zwar auf verschiedene Arten:

• Um Lesevorgänge zu skalieren, fügen Sie Lesereplikat-Instances hinzu oder aktivieren Sie die Neptune-Serverless-Funktionalität.

• Wir empfehlen Ihnen, die primäre Instance und die Lesereplikate in Ihrem DB-Cluster über mehrere Availability Zones (AZs) zu verteilen, um die Verfügbarkeit Ihres DB-Clusters zu verbessern.

• Um die Failover-Zeit zu reduzieren, sollten Sie mindestens eine Lesereplikat-Instance bereitstellen, die als Failover-Ziel für die primäre Instance dienen kann. Sie können die Reihenfolge, in der Lesereplikat-Instances nach einem Ausfall zur primären Instance hochgestuft werden, anpassen, indem Sie jeder Replik eine Priorität zuweisen. Es hat sich bewährt, sicherzustellen, dass ein Failover-Ziel über eine Instance-Klasse verfügt, die in der Lage ist, die Schreib-Workloads Ihrer Anwendung zu bewältigen, wenn es zur primären Instance heraufgestuft wird.

Unterschiede bei der Datenspeicherung zwischen Neptune und Neo4j

Neptune verwendet ein Graphdatenmodell, das auf einem nativen Quad-Modell basiert. Bei der Migration Ihrer Daten zu Neptune gibt es mehrere Unterschiede bei der Architektur des Datenmodells und der Speicherebene, die Sie beachten sollten, um den von Neptune bereitgestellten verteilten und skalierbaren gemeinsamen Speicher optimal nutzen zu können:

• Neptune verwendet kein explizit definiertes Schema oder Einschränkungen. Damit können Sie Knoten, Edges und Eigenschaften dynamisch hinzufügen, ohne das Schema im Voraus definieren zu müssen. Neptune schränkt die Werte und Typen der gespeicherten Daten nicht ein, es sei denn, dies ist in den Neptune-Grenzwerten angegeben. Als Teil der Speicherarchitektur von Neptune werden Daten außerdem automatisch indiziert, so dass viele der gängigsten Zugriffsmuster verarbeitet werden. Durch diese Speicherarchitektur entfällt der betriebliche Aufwand für die Erstellung und Verwaltung des Datenbankschemas und der Indexoptimierung.

• Neptune bietet eine einzigartige verteilte und gemeinsam genutzte Speicherarchitektur, die automatisch in 10-GB-Blöcken skaliert wird, wenn der Speicherbedarf Ihrer Datenbank wächst, und zwar auf bis zu 128 Tebibyte (TiB). Diese Speicherebene ist zuverlässig, robust und fehlertolerant. Daten werden sechsmal kopiert, und zwar zweimal in jeder der drei Availability Zones. Dies bietet allen Neptune-Clustern standardmäßig eine hochverfügbare und fehlertolerante Datenspeicherebene. Die Speicherarchitektur von Neptune senkt die Kosten und macht die Bereitstellung oder Überversorgung von Speicher überflüssig, um künftiges Datenwachstum zu bewältigen.

Bevor Sie Ihre Daten zu Neptune migrieren, sollten Sie sich mit dem Eigenschaftsgraph-Datenmodell und der Transaktionssemantik von Neptune vertraut machen.

Operationale Unterschiede zwischen Neptune und Neo4j

Neptune ist ein vollständig verwalteter Service, der viele der normalen Betriebsaufgaben automatisiert, die Sie erledigen müssten, wenn Sie On-Premises- oder selbstverwaltete Datenbanken wie Neo4j Enterprise oder Community Edition verwenden würden:

• Automatisierte Backups – Neptune sichert Ihr Cluster-Volume automatisch und behält das Backup für einen von Ihnen festgelegten Aufbewahrungszeitraum bei (von 1 bis 35 Tagen). Diese Backups sind kontinuierlich und inkrementell, so dass Sie schnell eine Wiederherstellung zu einem beliebigen Punkt im Aufbewahrungszeitraum für Backups durchführen können. Es gibt keine Auswirkungen auf die Leistungsfähigkeit oder Unterbrechung von Datenbank-Services, während Backup-Daten geschrieben werden.

• Manuelle Snapshots – Mit Neptune können Sie einen Snapshot für das Volume mit Ihrem DB-Cluster erstellen, damit der gesamte DB-Cluster gesichert wird. Diese Art von Snapshot kann dann verwendet werden, um die Datenbank wiederherzustellen, eine Kopie davon zu erstellen und sie für mehrere Konten freizugeben.

• Klonen – Neptune unterstützt ein Klon-Feature, mit dem Sie schnell kostengünstige Klone einer Datenbank erstellen können. Die Klone verwenden ein Copy-on-Write-Protokoll, so dass nach ihrer Erstellung nur wenig zusätzlicher Speicherplatz benötigt wird. Das Klonen von Datenbanken ist eine effektive Methode, um neue Neptune-Features oder -Upgrades auszuprobieren, ohne den ursprünglichen Cluster zu beeinflussen.

• Überwachung – Neptune bietet verschiedene Methoden zur Überwachung der Leistung und Nutzung Ihres Clusters, darunter:

  • Instance-Status

  • Integration mit Amazon CloudWatch und AWS CloudTrail

  • Prüfprotokollfunktionen

  • Ereignis-Benachrichtigungen

  • Markierung

• Sicherheit – Neptune bietet standardmäßig eine sichere Umgebung. Ein Cluster befindet sich in einer privaten VPC, die die Netzwerkisolation von anderen Ressourcen ermöglicht. Der gesamte Datenverkehr wird über SSL verschlüsselt und alle Daten werden im Ruhezustand mit AWS KMS verschlüsselt.

  Darüber hinaus lässt sich Neptune in AWS Identity and Access Management (IAM) integrieren, um eine Authentifizierung zu ermöglichen. Durch die Angabe von IAM-Bedingungsschlüsseln können Sie IAM-Richtlinien verwenden, um eine differenzierte Zugriffskontrolle für Datenaktionen zu gewährleisten.

Unterschiede bei Tools und Integration zwischen Neptune und Neo4j

Neptune hat eine andere Architektur für Integrationen und Tools als Neo4j, was sich auf die Architektur Ihrer Anwendung auswirken kann. Neptune verwendet die Datenverarbeitungsressourcen des Clusters, um Abfragen zu verarbeiten, nutzt aber auch andere erstklassige AWS-Services für Funktionen wie Volltextsuche (mit OpenSearch), ETL (mit Glue) usw. Eine vollständige Liste dieser Integrationen finden Sie unter Neptune-Integrationen.