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.

Datenmigration von Neo4j zu Neptune

Bei der Migration von Neo4j zu Amazon Neptune ist die Migration der Daten ein wichtiger Schritt des Prozesses. Es gibt mehrere Vorgehensweisen für die Migration von Daten. Das richtige Konzept hängt von den Anforderungen der Anwendung, der Datengröße und der Art der gewünschten Migration ab. Bei vielen dieser Migrationen müssen jedoch dieselben Überlegungen berücksichtigt werden, von denen einige im Folgenden hervorgehoben werden.

Bewertung der Datenmigration von Neo4j zu Neptune

Der erste Schritt bei der Bewertung einer Datenmigration besteht darin, festzulegen, wie die Daten migriert werden sollen. Die Optionen hängen von der Architektur der zu migrierenden Anwendung, der Datengröße und den Verfügbarkeitsanforderungen während der Migration ab. Im Allgemeinen lassen sich Migrationen in eine von zwei Kategorien einteilen: online oder offline.

Offline-Migrationen sind in der Regel am einfachsten durchzuführen, da die Anwendung während der Migration keinen Lese- oder Schreibdatenverkehr akzeptiert. Wenn die Anwendung keinen Datenverkehr mehr akzeptiert, können die Daten exportiert, optimiert, importiert und die Anwendung getestet werden, bevor die Anwendung wieder aktiviert wird.

Online-Migrationen sind komplexer, da die Anwendung während der Datenmigration weiterhin Lese- und Schreibdatenverkehr akzeptieren muss. Die genauen Anforderungen der einzelnen Online-Migrationen können unterschiedlich sein, aber die allgemeine Architektur würde im Allgemeinen der folgenden ähneln:

Datenmodelloptimierungen für die Migration von Neo4j zu Neptune

Sowohl Neptune als auch Neo4j unterstützen beschriftete Eigenschaftsgraphen (LPG). Neptune weist jedoch einige Architektur- und Datenmodellunterschiede auf, die Sie zur Leistungsoptimierung nutzen können:

Optimierung von Knoten- und Edge-IDs

Neo4j generiert automatisch numerische lange IDs. Mit Cypher können Sie auf Knoten anhand ihrer ID verweisen, aber davon wird generell abgeraten; suchen Sie stattdessen anhand einer indizierten Eigenschaft nach Knoten.

Neptune ermöglicht Ihnen, Ihre eigenen auf Zeichenfolgen basierenden IDs für Scheitelpunkte und Edges anzugeben. Wenn Sie keine eigenen IDs angeben, generiert Neptune automatisch Zeichenfolgendarstellungen von UUIDs für neue Edges und Scheitelpunkte.

Wenn Sie Daten von Neo4j zu Neptune migrieren, indem Sie sie aus Neo4j exportieren und anschließend massenweise in Neptune importieren, können Sie die IDs von Neo4j beibehalten. Die von Neo4j generierten numerischen Werte können beim Import in Neptune als vom Benutzer angegebene IDs dienen, wo sie als Zeichenfolgen und nicht als numerische Werte dargestellt werden.

Es gibt jedoch Umstände, unter denen Sie eine Scheitelpunkteigenschaft möglicherweise zu einer Scheitelpunkt-ID heraufstufen möchten. So wie die Suche nach einem Knoten mithilfe einer indizierten Eigenschaft der schnellste Weg ist, einen Knoten in Neo4j zu finden, ist das Suchen eines Scheitelpunkts anhand der ID der schnellste Weg, einen Scheitelpunkt in Neptune zu finden. Wenn Sie also eine geeignete Scheitelpunkteigenschaft identifizieren können, die eindeutige Werte enthält, sollten Sie erwägen, die ~id des Scheitelpunkts durch den nominierten Eigenschaftswert in Ihren CSV-Dateien zum Massenladen zu ersetzen. Wenn Sie dies tun, müssen Sie auch alle entsprechenden ~from- und ~to-Edge-Werte in Ihren CSV-Dateien umschreiben.

Schemaeinschränkungen bei der Migration von Daten von Neo4j zu Neptune

In Neptune ist die einzige verfügbare Schemaeinschränkung die Eindeutigkeit der ID eines Knotens oder eines Edges. Für Anwendungen, die eine Eindeutigkeitseinschränkung nutzen müssen, sollte diese Vorgehensweise in Betracht gezogen werden, um eine solche durch Angabe der Knoten- oder Edge-ID zu erreichen. Wenn die Anwendung mehrere Spalten als Eindeutigkeitseinschränkung verwendet hat, kann die ID auf eine Kombination dieser Werte gesetzt werden. id=123, code='SEA' könnte beispielsweise als ID='123_SEA' dargestellt werden, um eine komplexe Eindeutigkeitsbeschränkung zu erreichen.

Optimierung der Edge-Richtung bei der Migration von Daten von Neo4j zu Neptune

Wenn Knoten, Edges oder Eigenschaften zu Neptune hinzugefügt werden, werden sie automatisch auf drei verschiedene Arten indiziert, mit einem optionalen vierten Index. Aufgrund der Art und Weise, in der Neptune die Indizes erstellt und verwendet, sind Abfragen, die ausgehenden Edges folgen, effizienter als Abfragen, die eingehende Kanten verwenden. Im Hinblick auf das Graphdatenspeichermodell von Neptune handelt es sich dabei um themenbasierte Suchen, die den SPOG-Index verwenden.

Wenn Sie bei der Migration Ihres Datenmodells und Ihrer Abfragen zu Neptune feststellen, dass Ihre wichtigsten Abfragen darauf beruhen, eingehende Edges zu durchqueren, bei denen ein hohes Maß an Fächerung besteht, sollten Sie in Betracht ziehen, Ihr Modell so zu ändern, dass diese Durchquerungen stattdessen ausgehenden Edges folgen, insbesondere wenn Sie nicht angeben können, welche Edge-Etiketten durchquert werden sollen. Kehren Sie dazu die Richtung der relevanten Edges um und aktualisieren Sie die Edge-Etiketten, um die Semantik dieser Richtungsänderung widerzuspiegeln. Sie können beispielsweise Folgendes ändern:

person_A — parent_of — person_B
   to:
person_B — child_of — person_A

Um diese Änderung in einer CSV-Datei mit Massenladefunktion für Edges vorzunehmen, tauschen Sie einfach die Spaltenüberschriften ~from und ~to gegeneinander aus und aktualisieren Sie die Werte der Spalte ~label.

Als Alternative zur Umkehrung der Edge-Richtung können Sie einen vierten Neptune-Index, den OSGP-Index, aktivieren, der das Durchqueren eingehender Edges oder objektbasierte Suchvorgänge wesentlich effizienter macht. Die Aktivierung dieses vierten Index senkt jedoch die Einfügungsraten und erfordert mehr Speicherplatz.

Filteroptimierung bei der Migration von Daten von Neo4j zu Neptune

Neptune ist so optimiert, dass es am besten funktioniert, wenn Eigenschaften auf die selektivste verfügbare Eigenschaft gefiltert werden. Wenn mehrere Filter verwendet werden, wird für jeden Filter der Satz übereinstimmender Elemente gefunden und anschließend wird die Überlappung aller übereinstimmenden Sätze berechnet. Wenn möglich, wird durch die Kombination mehrerer Eigenschaften zu einer einzigen Eigenschaft die Anzahl der Index-Suchvorgänge minimiert und die Latenz einer Abfrage verringert.

Diese Abfrage verwendet beispielsweise zwei Index-Suchvorgänge und eine Verknüpfung:

MATCH (n) WHERE n.first_name='John' AND n.last_name='Doe' RETURN n

Diese Abfrage ruft dieselben Informationen mithilfe eines einzigen Index-Suchvorgangs ab:

MATCH (n) WHERE n.name='John Doe' RETURN n

Neptune unterstützt andere Datentypen als Neo4j.

Migration mehrwertiger Eigenschaften von Neo4j zu Neptune

Neo4j ermöglicht es, homogene Listen einfacher Typen als Eigenschaften von Knoten und Edges zu speichern. Diese Listen können doppelte Werte enthalten.

Neptune erlaubt jedoch nur feste oder einfache Kardinalität für Scheitelpunkteigenschaften und einfache Kardinalität für die Eigenschaften von Edges in Eigenschaftsgraphdaten. Daher gibt es keine einfache Migration von Neo4j-Knotenlisteneigenschaften, die doppelte Werte enthalten, zu Neptune-Scheitelpunkteigenschaften oder von Neo4j-Beziehungslisteneigenschaften zu Neptune-Edge-Eigenschaften.

Einige mögliche Strategien für die Migration mehrwertiger Neo4j-Knoteneigenschaften mit doppelten Werten zu Neptune sind:

Ähnlich sind einige mögliche Strategien für die Migration mehrwertiger Neo4j-Beziehungseigenschaften mit mehreren Werten zu Neptune:

Beachten Sie, dass die Zeichenfolgendarstellung einer Liste im JSON-Format für die openCypher-Abfragesprache intransparent ist, obwohl openCypher ein CONTAINS-Prädikat enthält, das einfache Suchen innerhalb von Zeichenfolgenwerten ermöglicht.

Exportieren von Daten aus Neo4j bei der Migration zu Neptune

Verwenden Sie beim Exportieren von Daten aus Neo4j die APOC-Verfahren, um entweder zuCSV oder zu GraphML zu exportieren. Obwohl es möglich ist, in andere Formate zu exportieren, gibt es Open-Source-Tools zum Konvertieren von CSV-Daten, die aus Neo4j exportiert wurden, in das Neptune-Bulk-Load-Format sowie Open-Source-Tools zum Konvertieren von GraphML-Daten, die aus Neo4j exportiert wurden, in das Neptune-Bulk-Load-Format.

Mit den verschiedenen APOC-Verfahren können Sie Daten auch direkt in Amazon S3 exportieren. Der Export in einen Amazon-S3-Bucket ist standardmäßig deaktiviert, kann aber mithilfe der Verfahren aktiviert werden, die unter Exportieren zu Amazon S3 in der Neo4j-APOC-Dokumentation beschrieben sind.

Importieren von Daten aus Neo4j bei der Migration zu Neptune

Sie können Daten entweder mithilfe des Neptune Bulk Loaders oder mithilfe der Anwendungslogik in einer unterstützten Abfragesprache wie openCypher in Neptune importieren.

Der Neptune Bulk Loader ist das bevorzugte Verfahren für den Import großer Datenmengen, da er eine optimierte Importleistung bietet, wenn Sie die Bewährten Methoden befolgen. Der Bulk Loader unterstützt zwei verschiedene CSV-Formate, in die aus Neo4j exportierte Daten mithilfe der oben im Abschnitt Exportieren von Daten genannten Open-Source-Dienstprogramme konvertiert werden können.

Sie können auch openCypher verwenden, um Daten mit benutzerdefinierter Logik für das Parsen, Transformieren und Importieren zu importieren. Sie können die openCypher-Abfragen entweder über den HTTPS-Endpunkt (was empfohlen wird) oder mithilfe des Bolt-Treibers übermitteln.