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.
**Anmerkung**
Einen vollständigen Überblick step-by-step über [ein Beispiel für die Durchführung einer Offline-Datenmigration finden Sie im [Datenbank-Blog unter Migration einer AWS Neo4j-Graphdatenbank](https://aws.amazon.com/blogs/?awsf.blog-master-category=category%23database) zu Neptune mit einem vollautomatischen Hilfsprogramm](https://aws.amazon.com/blogs/database/migrating-a-neo4j-graph-database-to-amazon-neptune-with-a-fully-automated-utility/).
## 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:
+ Ein Feed mit laufenden Änderungen an der Datenbank muss in Neo4j aktiviert werden, indem [Neo4j Streams als Quelle für einen Kafka-Cluster](https://neo4j.com/labs/kafka/4.0/producer/) konfiguriert wird.
+ Sobald dies abgeschlossen ist, kann ein Export des laufenden Systems durchgeführt werden. Folgen Sie dabei den Anweisungen unter [Exportieren von Daten aus Neo4j bei der Migration zu Neptune](#migration-data-exporting) und der angegebenen Zeit, um später eine Korrelation zum Kafka-Thema vorzunehmen.
+ Die exportierten Daten werden dann gemäß den Anweisungen unter [Importieren von Daten aus Neo4j bei der Migration zu Neptune](#migration-data-importing) in Neptune importiert.
+ Geänderte Daten aus dem Kafka-Stream können dann mithilfe einer Architektur, die der unter [Schreiben zu Amazon Neptune von Amazon Kinesis Data Streams](https://github.com/aws-samples/amazon-neptune-samples/tree/master/gremlin/stream-2-neptune) beschriebenen Architektur ähnelt, in den Neptune-Cluster kopiert werden. Beachten Sie, dass die Replikation der Änderungen parallel ausgeführt werden kann, um die neue Anwendungsarchitektur und Leistung zu validieren.
+ Nachdem die Datenmigration validiert wurde, kann der Anwendungsdatenverkehr zum Neptune-Cluster umgeleitet und die Neo4j-Instance außer Betrieb genommen werden.
## 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 eine lange Zahl. 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 es Ihnen, [Ihre eigene Zeichenkettenbasis IDs für](access-graph-gremlin-differences.md#feature-gremlin-differences-user-supplied-ids) Scheitelpunkte und Kanten anzugeben. Wenn Sie keine eigenen angeben IDs, generiert Neptune automatisch Zeichenkettendarstellungen UUIDs für neue Kanten und Scheitelpunkte.
Wenn Sie Daten von Neo4j zu Neptune migrieren, indem Sie sie aus Neo4j exportieren und dann massenweise in Neptune importieren, können Sie die von Neo4j beibehalten. IDs Die von Neo4j generierten numerischen Werte können IDs beim Import in Neptune als vom Benutzer bereitgestellte Werte dienen, wo sie als Zeichenketten 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 \$1id des Scheitelpunkts durch den nominierten Eigenschaftswert in Ihren CSV-Dateien zum Massenladen zu ersetzen. Wenn Sie dies tun, müssen Sie auch alle entsprechenden \$1from- und \$1to-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](feature-overview-storage-indexing.md), mit einem [optionalen vierten Index](features-lab-mode.md#features-lab-mode-features-osgp-index). Aufgrund der Art und Weise, in der Neptune [die Indizes erstellt und verwendet](feature-overview-storage-indexing.md), sind Abfragen, die ausgehenden Edges folgen, effizienter als Abfragen, die eingehende Kanten verwenden. Im Hinblick auf das [Graphdatenspeichermodell](feature-overview-data-model.md) 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](bulk-load-tutorial-format.md) 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](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp), 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](bulk-load-tutorial-format-opencypher.md#bulk-load-tutorial-format-opencypher-data-types) als Neo4j.
**Neo4j-Datentyp-Zuordnungen zu Datentypen, die Neptune unterstützt**
+ **Logisch**: `Boolean`
Zuordnung in Neptune zu `Bool` oder `Boolean`.
+ **Numerisch**: `Number`
Zuordnung in Neptune zum engsten der folgenden Neptune-OpenCypher-Typen, der alle Werte der fraglichen numerischen Eigenschaft unterstützen kann:
```
Byte
Short
Integer
Long
Float
Double
```
+ **Text**: `String`
Zuordnung in Neptune zu `String`.
+ **Zeitpunkt**:
```
Date
Time
LocalTime
DateTime
LocalDateTime
```
Zuordnung in Neptune zu `Date` als UTC unter Verwendung eines der folgenden folgenden ISO-8601-Formate, die Neptune unterstützt:
```
yyyy-MM-dd
yyyy-MM-ddTHH:mm
yyyy-MM-ddTHH:mm:ss
yyyy-MM-ddTHH:mm:ssZ
```
+ **Zeitdauer**: `Duration`
Zuordnung in Neptune zu einem numerischen Wert für die Datumsarithmetik, falls erforderlich.
+ **Spatial**: `Point`
Zuordnung in Neptune zu numerischen Komponentenwerten, von denen jeder dann zu einer separaten Eigenschaft wird, oder Ausdruck als Zeichenfolgenwert, der von der Client-Anwendung interpretiert wird. Beachten Sie, dass Sie mithilfe der [Volltextsuchintegration von Neptune Geolocation-Eigenschaften indizieren](full-text-search.md) können. OpenSearch
### Migration mehrwertiger Eigenschaften von Neo4j zu Neptune
Neo4j ermöglicht es, [homogene Listen einfacher Typen](https://neo4j.com/docs/cypher-manual/current/values-and-types/) als Eigenschaften von Knoten und Edges zu speichern. Diese Listen können doppelte Werte enthalten.
Neptune erlaubt jedoch nur [feste oder einfache Kardinalität](access-graph-gremlin-differences.md#feature-gremlin-differences-vertex-property-cardinality) 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:
+ Verwerfen Sie die doppelten Werte und konvertieren Sie die mehrwertige Neo4j-Knoteneigenschaft in eine Neptune-Scheitelpunkteigenschaft mit festgelegter Kardinalität. Beachten Sie, dass der Neptune-Satz dann möglicherweise nicht die Reihenfolge der Elemente in der ursprünglichen mehrwertigen Neo4j-Eigenschaft widerspiegelt.
+ Konvertieren Sie die mehrwertige Neo4j-Knoteneigenschaft zu einer Zeichenfolgendarstellung einer JSON-formatierten Liste in einer Neptune-Scheitelpunkt-Zeichenfolgeneigenschaft.
+ Extrahieren Sie jeden der mehrwertigen Eigenschaftswerte in einen separaten Scheitelpunkt mit einer Werteigenschaft und verbinden Sie diese Scheitelpunkte mithilfe einer Edge, die mit dem Eigenschaftsnamen beschriftet ist, mit dem übergeordneten Scheitelpunkt.
Ähnlich sind einige mögliche Strategien für die Migration mehrwertiger Neo4j-Beziehungseigenschaften mit mehreren Werten zu Neptune:
+ Konvertieren Sie die mehrwertige Neo4j-Beziehungseigenschaft zu einer Zeichenfolgendarstellung einer JSON-formatierten Liste und speichern Sie sie als Neptune-Edge-Zeichenfolgeneigenschaft.
+ Führen Sie einen Faktorwechsel der Neo4j-Beziehung in eingehende und ausgehende Neptune-Edges, die an einen Zwischenscheitelpunkt angefügt sind, durch. Extrahieren Sie jeden der mehrwertigen Eigenschaftswerte in einen separaten Scheitelpunkt mit einer Werteigenschaft und verbinden Sie diese Scheitelpunkte mithilfe einer Edge, die mit dem Eigenschaftsnamen beschriftet ist, mit dem übergeordneten Scheitelpunkt.
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 zu[CSV](https://neo4j.com/labs/apoc/4.1/export/csv/) oder zu [GraphML](https://neo4j.com/labs/apoc/4.1/export/graphml/) zu exportieren. Obwohl es möglich ist, in andere Formate zu exportieren, gibt es [Open-Source-Tools](https://github.com/awslabs/amazon-neptune-tools/tree/master/neo4j-to-neptune) zum Konvertieren von CSV-Daten, die aus Neo4j exportiert wurden, in das Neptune-Bulk-Load-Format sowie [Open-Source-Tools](https://github.com/awslabs/amazon-neptune-tools/tree/master/graphml2csv) 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](https://neo4j.com/labs/apoc/4.3/export/csv/#export-csv-s3-export) 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](bulk-load.md) oder mithilfe der Anwendungslogik in einer unterstützten Abfragesprache wie [openCypher](access-graph-opencypher.md) 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](bulk-load-optimize.md) befolgen. Der Bulk Loader unterstützt [zwei verschiedene CSV-Formate](bulk-load-tutorial-format.md), in die aus Neo4j exportierte Daten mithilfe der oben im Abschnitt [Exportieren von Daten](#migration-data-exporting) 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](access-graph-opencypher-queries.md) (was empfohlen wird) oder mithilfe des [Bolt-Treibers](access-graph-opencypher-bolt.md) übermitteln.