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 Neo4j zu Amazon Neptune
Neo4j und Amazon Neptune sind beide Graphdatenbanken, die für transaktionale Online-Graph-Workloads konzipiert wurden und das Labeled-Property-Graph-Datenmodell unterstützen. Aufgrund dieser Ähnlichkeiten ist Neptune eine beliebte Wahl für Kunden, die ihre aktuellen Neo4j-Anwendungen migrieren möchten. Bei diesen Migrationen handelt es sich jedoch nicht einfach um Lift-and-Shift-Lösungen, da es zwischen den beiden Datenbanken Unterschiede bei den Sprachen und der Feature-Unterstützung, den Betriebsmerkmalen, der Serverarchitektur und den Speicherkapazitäten gibt.
Auf dieser Seite wird der Migrationsprozess beschrieben und es werden Dinge aufgezeigt, die vor der Migration einer Neo4j-Graph-Anwendung zu Neptune zu beachten sind. Diese Überlegungen gelten generell für jede Neo4j-Graph-Anwendung, unabhängig davon, ob sie von einer Community-, Enterprise- oder Aura-Datenbank betrieben wird. Obwohl jede Lösung einzigartig ist und zusätzliche Verfahren erfordern kann, folgen alle Migrationen demselben allgemeinen Muster.
Jeder der in den folgenden Abschnitten beschriebenen Schritte beinhaltet Überlegungen und Empfehlungen zur Vereinfachung des Migrationsprozesses. Darüber hinaus gibt es [Open-Source-Tools und Blog-Beiträge](migration-resources.md), in denen der Prozess beschrieben wird, sowie einen [Abschnitt zur Feature-Kompatibilität](migration-compatibility.md) mit empfohlenen Architekturoptionen.
**Topics**
+ [
# Allgemeine Informationen zur Migration von Neo4j zu Neptune
](migrating-from-neo4j-general.md)
+ [
# Vorbereitung der Migration von Neo4j zu Neptune
](preparing-to-migrate-from-neo4j.md)
+ [
# Bereitstellung der Infrastruktur bei der Migration von Neo4j zu Neptune
](migration-provisioning-infrastructure.md)
+ [
# Datenmigration von Neo4j zu Neptune
](migration-data-migration.md)
+ [
# Anwendungsmigration von Neo4j zu Neptune
](migration-app-migration.md)
+ [
# Neptune-Kompatibilität mit Neo4j
](migration-compatibility.md)
+ [
# Umschreiben von Cypher-Abfragen zur Ausführung in openCypher auf Neptune
](migration-opencypher-rewrites.md)
+ [
# Ressourcen für die Migration von Neo4j zu Neptune
](migration-resources.md)
# Allgemeine Informationen zur Migration von Neo4j zu Neptune
Mit der [Unterstützung für die openCypher-Abfragesprache](feature-opencypher-compliance.md) durch Neptune können Sie die meisten Neo4j-Workloads, die das Bolt-Protokoll oder HTTPS verwenden, zu Neptune verschieben. OpenCypher ist jedoch eine Open-Source-Spezifikation, die die meisten, aber nicht alle Funktionen enthält, die von anderen Datenbanken wie Neo4j unterstützt werden.
Obwohl Neptune in vielerlei Hinsicht kompatibel ist, stellt es keinen direkten Ersatz für Neo4j dar. Neptune ist ein vollständig verwalteter Graphdatenbank-Service mit Enterprise-Features wie hohe Verfügbarkeit und hohe Datenbeständigkeit, der sich architektonisch von Neo4j unterscheidet. Neptune ist Instance-basiert und verfügt über eine einzige primäre Writer-Instance und bis zu 15 Lesereplikat-Instances, mit denen Sie die Lesekapazität horizontal skalieren können. Mit [Neptune Serverless](neptune-serverless.md) können Sie Ihre Datenverarbeitungskapazität je nach Abfragevolumen automatisch nach oben oder unten skalieren. Dies ist unabhängig vom Neptune-Speicher, der automatisch skaliert wird, wenn Sie Daten hinzufügen.
Neptune unterstützt die Open-Source-[Standardspezifikation OpenCypher, Version 9](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf). Wir bei glauben AWS, dass Open Source für alle gut ist, und wir setzen uns dafür ein, sowohl unseren Kunden den Wert von Open Source näherzubringen als auch Open-Source-Communities die operative Exzellenz AWS zu bieten.
Viele Anwendungen, die auf Neo4j laufen, verwenden jedoch auch proprietäre Features, die nicht als Open-Source-Funktionen verfügbar sind und die Neptune nicht unterstützt. Neptune unterstützt beispielsweise keine APOC-Prozeduren, einige Cypher-spezifische Klauseln und Funktionen sowie die Datentypen `Char`, `Date` oder `Duration`. Neptune wandelt die fehlenden Datentypen automatisch in [unterstützte Datentypen](bulk-load-tutorial-format-opencypher.md#bulk-load-tutorial-format-opencypher-data-types) um.
Neben OpenCypher unterstützt Neptune auch die [Apache TinkerPop Gremlin-Abfragesprache](https://tinkerpop.apache.org/docs/current/reference/#traversal) für Eigenschaftsdiagramme (sowie SPARQL für RDF-Daten). Gremlin kann mit openCypher auf demselben Eigenschaftsgraphen interoperieren und in vielen Fällen können Sie Gremlin verwenden, um Funktionen bereitzustellen, die openCypher nicht bietet. Im Folgenden finden Sie einen kurzen Vergleich der beiden Sprachen:
| | openCypher | Gremlin |
| --- | --- | --- |
| Style | Deklarativ | Unerlässlich |
| Syntax | Mustervergleich Match p=(a)-[:route]->(d)
WHERE a.code='ANC'
RETURN p
| Transversal-basiert g.V().has('code', 'ANC').
out('route').path().
by(elementMap()) |
| Benutzerfreundlichkeit | Von SQL-inspiriert, auch für Nicht-Programmierer lesbar | Steilere Lernkurve, ähnlich wie bei Programmiersprachen wie Java |
| Flexibilität | Niedrig | Hoch |
| Unterstützung für Abfragen | Zeichenfolgenbasierte Abfragen | Zeichenfolgenbasierte Abfragen oder Inline-Code, der von Client-Bibliotheken unterstützt wird |
| Clients | HTTPS und Bolt | HTTPS und Websockets |
Im Allgemeinen ist es nicht erforderlich, Ihr Datenmodell zu ändern, um von Neo4j zu Neptune zu migrieren, da sowohl Neo4j als auch Neptune Labeled Property Graph (LPG)-Daten unterstützen. Neptune weist jedoch einige Architektur- und Datenmodellunterschiede auf, die Sie zur Leistungsoptimierung nutzen können. Beispiel:
+ Neptune IDs werden als erstklassige Bürger behandelt.
+ Neptune verwendet [AWS Identity and Access Management (IAM)-Richtlinien](iam-auth.md), um den Zugriff auf Ihre Graphdaten auf flexible und detaillierte Weise zu sichern.
+ Neptune bietet mehrere Möglichkeiten zur [Verwendung von Jupyter-Notebooks](graph-notebooks.md), um Abfragen auszuführen und die [Ergebnisse zu visualisieren](notebooks-visualization.md). Neptune funktioniert auch mit [Visualisierungs-Tools von Drittanbietern](visualization-tools.md).
+ >Neptune hat zwar keinen direkten Ersatz für die Neo4j Graph Data Science (GDS)-Bibliothek, unterstützt aber Graphanalysen mit einer Vielzahl von Lösungen. In mehreren [Beispiel-Notebooks](https://github.com/aws/graph-notebook/tree/main/src/graph_notebook/notebooks/01-Neptune-Database/03-Sample-Applications/06-Data-Science-Samples) wird beispielsweise gezeigt, wie die [Neptune-Integration mit dem AWS Pandas SDK](https://github.com/amazon-archives/fully-automated-neo4j-to-neptune) in Python-Umgebungen genutzt werden kann, um Analysen von Grafikdaten durchzuführen.
Bitte wenden Sie sich an den AWS Support oder wenden Sie sich an Ihr AWS Account-Team, wenn Sie Fragen haben. Wir nutzen Ihr Feedback, um neue Features zu priorisieren, die Ihren Anforderungen entsprechen.
# 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](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/), Blog-Beitrag von Stephen Orban.
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.
# 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 like-to-like Vergleich anhand der Instanzgröße durchzuführen. Die Architekturen von Neo4j und Neptune weisen jedoch grundlegende Unterschiede auf. Neo4j basiert auf einem all-in-one Ansatz, bei dem das Laden von Daten, Daten-ETL, Anwendungsabfragen, Datenspeicherung und Verwaltungsvorgänge alle in demselben Satz von Rechenressourcen, wie z. B. EC2-Instances, ablaufen.
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](https://neo4j.com/docs/operations-manual/current/clustering/introduction/) 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](feature-overview-db-clusters.md) 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](neptune-serverless.md) 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](manage-console-autoscaling.md), um die Instance-Größen des Readers automatisch an den Workload anzupassen.
Mithilfe des [globalen Datenbank-Features](neptune-global-database.md) von Neptune können Sie einen Cluster in bis zu 5 anderen Regionen spiegeln.
Neptune ist außerdem [vom Design her fehlertolerant](backup-restore-overview-fault-tolerance.md):
+ Das Cluster-Volume, das Datenspeicher für alle Instances im Cluster bereitstellt, erstreckt sich über mehrere Availability Zones (AZs) in einer einzigen. 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](feature-overview-db-clusters.md#feature-overview-read-replicas) hinzu oder aktivieren Sie die [Neptune-Serverless](neptune-serverless.md)-Funktionalität.
+ Um die Verfügbarkeit zu verbessern, verteilen Sie die primäre Instance und die Read Replicas in Ihrem Cluster auf mehrere Availability Zones ()AZs.
+ 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](manage-console-add-replicas.md). 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](feature-overview-data-model.md), 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](limits.md#limits-properties) angegeben. Als Teil der Speicherarchitektur von Neptune werden Daten außerdem [automatisch indiziert](feature-overview-storage-indexing.md), 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](feature-overview-storage-indexing.md#feature-overview-storage-indexing-gremlin) und der [Transaktionssemantik](transactions.md) 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](backup-restore.md#backup-restore-overview-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](backup-restore.md)** – 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](manage-console-cloning.md)** – 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, sodass sie nach ihrer Erstellung nur minimalen zusätzlichen Speicherplatz benötigen. Das Klonen von Datenbanken ist eine effektive Methode, um neue Neptune-Features oder -Upgrades auszuprobieren, ohne den ursprünglichen Cluster zu beeinflussen.
+ **[Überwachung](monitoring.md)** – Neptune bietet verschiedene Methoden zur Überwachung der Leistung und Nutzung Ihres Clusters, darunter:
+ Instance-Status
+ Integration mit Amazon CloudWatch und AWS CloudTrail
+ Prüfprotokollfunktionen
+ Ereignismeldungen
+ Tagging
+ **[Sicherheit](security.md)** – 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 SSL verschlüsselt AWS KMS.
[Darüber hinaus lässt sich Neptune in AWS Identity and Access Management (IAM) integrieren, um eine Authentifizierung zu ermöglichen.](iam-auth.md) Durch die Angabe von [IAM-Bedingungsschlüsseln](iam-condition-keys.md) können Sie IAM-Richtlinien verwenden, um eine differenzierte Zugriffskontrolle für [Datenaktionen](iam-data-access-policies.md) 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 Rechenressourcen des Clusters, um Abfragen zu verarbeiten, nutzt aber auch andere best-in-class AWS Dienste für Funktionen wie Volltextsuche (mit OpenSearch), ETL (mit Glue) usw. Eine vollständige Liste dieser Integrationen finden Sie unter [Neptune-Integrationen](integrations.md).
# Bereitstellung der Infrastruktur bei der Migration von Neo4j zu Neptune
Amazon-Neptune-Cluster sind so konzipiert, dass sie in drei Dimensionen skalierbar sind: Speicher, Schreibkapazität und Lesekapazität. In den folgenden Abschnitten werden spezifische Optionen erörtert, die bei der Migration berücksichtigt werden sollten.
## Bereitstellen von Speicher
Der Speicher für jeden Neptune-Cluster wird automatisch bereitgestellt, ohne dass Sie zusätzlichen Verwaltungsaufwand haben. Die Größe wird dynamisch in 10-GB-Blöcken angepasst, wenn der Speicherbedarf des Clusters steigt. Daher ist es nicht erforderlich, Speicherplatz zu schätzen und bereitzustellen oder zu viel bereitzustellen, um das künftige Datenwachstum zu bewältigen.
## Bereitstellen von Schreibkapazität
Neptune bietet eine Single-Writer-Instance, die vertikal auf jede Instance-Größe skaliert werden kann, die auf der [Neptune-Preisseite](https://aws.amazon.com/neptune/pricing/) verfügbar ist. Beim Lesen und Schreiben von Daten in eine Writer-Instance sind alle Transaktionen ACID-konform, wobei die Datenisolation wie unter [Transaktionsisolierungsstufen in Neptune](transactions-neptune.md) definiert erfolgt.
Um die optimale Größe für eine Writer-Instance auszuwählen, müssen Lasttests durchgeführt werden, um die optimale Instance-Größe für Ihren Workload zu ermitteln. Die Größe jeder Instance in Neptune kann jederzeit geändert werden, indem die [DB-Instance-Klasse geändert](manage-console-instances-modify.md) wird. Sie können die Größe einer Start-Instance auf der Grundlage der Parallelität und der durchschnittlichen Abfragelatenz schätzen, wie weiter unten unter [Schätzen der optimalen Instance-Größe bei der Bereitstellung Ihres Clusters](#migration-provisioning-instance-sizing) beschrieben.
## Bereitstellen von Lesekapazität
Neptune wurde entwickelt, um Lesereplikat-Instances sowohl horizontal zu skalieren, indem bis zu 15 von ihnen innerhalb eines Clusters (oder mehr in einer [globalen Neptune-Datenbank](neptune-global-database.md)) hinzugefügt werden, als auch vertikal zu jeder beliebigen Instance-Größe, die auf der [Neptune-Preisseite](https://aws.amazon.com/neptune/pricing/) verfügbar ist. Alle Neptune-Lesereplikat-Instances verwenden dasselbe zugrunde liegende Speicher-Volume, was eine transparente Replikation von Daten mit minimaler Verzögerung ermöglicht.
Lesereplikate ermöglichen nicht nur die horizontale Skalierung von Leseanforderungen innerhalb eines Neptune-Clusters, sondern dienen auch als Failover-Ziele für die Writer-Instance, um eine hohe Verfügbarkeit zu gewährleisten. Vorschläge, wie Sie die richtige Anzahl und Platzierung von Lesereplikaten in Ihrem Cluster ermitteln können, finden Sie unter [Grundlegende Anleitungen für den Amazon-Neptune-Betrieb](best-practices-general-basic.md).
Für Anwendungen, bei denen Konnektivität und Workload nicht vorhersehbar sind, unterstützt Neptune auch [ein Auto-Scaling-Feature](manage-console-autoscaling.md), mit dem die Anzahl der Neptune-Replikate anhand der von Ihnen angegebenen Kriterien automatisch angepasst werden kann.
Um eine optimale Größe und Anzahl von Lesereplikat-Instances zu ermitteln, müssen Lasttests durchgeführt werden, um die Eigenschaften des Lese-Workloads zu ermitteln, den sie unterstützen müssen. Die Größe jeder Instance in Neptune kann jederzeit geändert werden, indem [die DB-Instance-Klasse geändert](manage-console-instances-modify.md) wird. Sie können die Größe einer Start-Instance auf der Grundlage der Parallelität und der durchschnittlichen Abfragelatenz schätzen, wie im [nächsten Abschnitt](#migration-provisioning-instance-sizing) beschrieben.
## Verwenden Sie Neptune Serverless, um Reader- und Writer-Instances automatisch nach Bedarf zu skalieren
Es ist zwar oft hilfreich, die Rechenkapazität abschätzen zu können, die Ihre erwarteten Workloads benötigen, aber Sie können das Feature [Neptune Serverless](neptune-serverless.md) so konfigurieren, dass die Lese- und Schreibkapazität automatisch nach oben und unten skaliert wird. Auf diese Weise können Sie Spitzenanforderungen erfüllen und gleichzeitig bei sinkender Nachfrage automatisch zurückskalieren.
## Schätzen der optimalen Instance-Größe bei der Bereitstellung Ihres Clusters
Um die optimale Instance-Größe zu schätzen, müssen Sie die durchschnittliche Abfragelatenz in Neptune kennen, wenn Ihr Workload ausgeführt wird, sowie die Anzahl der gleichzeitig verarbeiteten Abfragen. Eine grobe Schätzung der Instance-Größe kann berechnet werden, indem die durchschnittliche Abfragelatenz mit der Anzahl gleichzeitiger Abfragen multipliziert wird. Auf diese Weise erhalten Sie die durchschnittliche Anzahl gleichzeitiger Threads, die zur Bewältigung des Workloads benötigt werden.
[Jede vCPU in einer Neptune-Instance kann zwei gleichzeitige Abfrage-Threads unterstützen. Wenn Sie also die Threads durch 2 teilen, erhalten Sie die Anzahl der CPUs erforderlichen v, die dann auf der Neptune-Preisseite mit der entsprechenden Instance-Größe korreliert werden kann.](https://aws.amazon.com/neptune/pricing/) Beispiel:
```
Average Query Latency: 30ms (0.03s)
Number of concurrent queries: 1000/second
Number of threads needed: 0.03 x 1000 = 30 threads
Number of vCPUs needed: 30 / 2 = 15 vCPUs
```
Wenn wir dies mit der Anzahl von v CPUs in einer Instanz korrelieren, erhalten wir eine grobe Schätzung, dass a die empfohlene Instanz für diese `r5.4xlarge` Arbeitslast ist. Diese Schätzung ist grob und dient nur als erste Orientierung bei der Auswahl der Instance-Größe. Bei jeder Anwendung sollte die korrekte Dimensionierung durchgeführt werden, um die richtige Anzahl und Art(en) von Instances zu ermitteln, die für den Workload geeignet sind.
Die Speicheranforderungen sollten ebenso wie die Verarbeitungsanforderungen berücksichtigt werden. Neptune ist am leistungsfähigsten, wenn die Daten, auf die durch Abfragen zugegriffen wird, im Pufferpool-Cache des Hauptspeichers verfügbar sind. Durch die Bereitstellung von ausreichend Arbeitsspeicher können auch die I/O Kosten erheblich gesenkt werden.
Weitere Informationen und Anleitungen zur Dimensionierung von Instances in einem Neptune-Cluster finden Sie auf der [Dimensionieren von DB-Instances in einem Neptune-DB-Cluster](feature-overview-db-clusters.md#feature-overview-sizing-instances)-Seite.
# 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.
# Anwendungsmigration von Neo4j zu Neptune
Nachdem Sie Ihre Daten von Neo4j zu Neptune migriert haben, besteht der nächste Schritt darin, die Anwendung selbst zu migrieren. Wie bei den Daten gibt es mehrere Vorgehensweise für die Migration Ihrer Anwendung, die auf den von Ihnen verwendeten Tools, Anforderungen, architektonischen Unterschieden usw. basieren. Dinge, die Sie bei diesem Prozess normalerweise berücksichtigen müssen, werden im Folgenden beschrieben.
## Migration von Verbindungen von Neo4j zu Neptune
Wenn Sie die Bolt-Treiber derzeit nicht verwenden oder eine Alternative nutzen möchten, können Sie eine Verbindung zum [HTTPS-Endpunkt](access-graph-opencypher-queries.md) herstellen, der vollständigen Zugriff auf die zurückgegebenen Daten bietet.
Wenn Sie eine Anwendung haben, die das [Bolt-Protokoll](access-graph-opencypher-bolt.md) verwendet, können Sie diese Verbindungen zu Neptune migrieren und Ihre Anwendungen mit denselben Treibern verbinden lassen wie in Neo4j. Um eine Verbindung zu Neptune herzustellen, müssen Sie möglicherweise eine oder mehrere der folgenden Änderungen an Ihrer Anwendung vornehmen:
+ Die URL und der Port müssen aktualisiert werden, um die Cluster-Endpunkte und den Cluster-Port verwenden zu können (die Standardeinstellung ist 8182).
+ Neptune erfordert, dass alle Verbindungen SSL verwenden, daher müssen Sie für jede Verbindung angeben, dass sie verschlüsselt ist.
+ Neptune verwaltet die Authentifizierung durch die Zuweisung von [IAM-Richtlinien und -Rollen](iam-auth.md). IAM-Richtlinien und -Rollen ermöglichen eine äußerst flexible Benutzerverwaltung innerhalb der Anwendung. Daher ist es wichtig, die Informationen in der [IAM-Übersicht](iam-auth.md) zu lesen und zu verstehen, bevor Sie Ihren Cluster konfigurieren.
+ Bolt-Verbindungen verhalten sich in Neptune in mehrfacher Hinsicht anders als in Neo4j, wie in [Bolt-Verbindungsverhalten in Neptune](access-graph-opencypher-bolt.md#access-graph-opencypher-bolt-connections) erläutert.
+ Weitere Informationen und Vorschläge finden Sie unter [Bewährte Methoden für Neptune mit openCypher und Bolt](best-practices-opencypher.md).
Codebeispiele für häufig verwendete Sprachen wie Java, Python, .NET und NodeJS sowie für Verbindungsszenarien wie die Verwendung der IAM-Authentifizierung finden Sie in [Verwenden des Bolt-Protokolls für openCypher-Abfragen an Neptune](access-graph-opencypher-bolt.md).
## Weiterleiten von Abfragen an Cluster-Instances beim Übergang von Neo4j zu Neptune
Neo4j-Clientanwendungen verwenden einen [Routing-Treiber](https://neo4j.com/docs/driver-manual/1.7/client-applications/#routing_drivers_bolt_routing) und spezifizieren einen [Zugriffsmodus](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-access-mode), um Lese- und Schreibanforderungen an einen geeigneten Server in einem Kausal-Cluster weiterzuleiten.
Wenn Sie eine Client-Anwendung zu Neptune migrieren, verwenden Sie [Neptune-Endpunkte](feature-overview-endpoints.md), um Abfragen effizient an eine geeignete Instance in Ihrem Cluster weiterzuleiten:
+ Alle Verbindungen zu Neptune sollten `bolt://` statt `bolt+routing://` oder `neo4j://` in der URL verwenden.
+ Der Cluster-Endpunkt verbindet sich mit der aktuellen primären Instance in Ihrem Cluster. Verwenden Sie den Cluster-Endpunkt, um Schreibanforderungen an die primäre Instance weiterzuleiten.
+ Der Reader-Endpunkt [verteilt Verbindungen](best-practices-general-basic.md#best-practices-general-loadbalance) auf Lesereplikat-Instances in Ihrem Cluster. Wenn Sie einen Single-Instance-Cluster ohne Lesereplikat-Instances haben, stellt der Reader-Endpunkt eine Verbindung zur primären Instance her, die Schreibvorgänge unterstützt. Wenn der Cluster eine oder mehrere Lesereplikat-Instances enthält, generiert das Senden einer Schreibanforderung an den Reader-Endpunkt eine Ausnahme.
+ Jede Instance in Ihrem Cluster kann auch einen eigenen Instance-Endpunkt haben. Verwenden Sie einen Instance-Endpunkt, wenn Ihre Client-Anwendung eine Anfrage an eine bestimmte Instance im Cluster senden muss.
Weitere Informationen finden Sie unter [Überlegungen zu Neptune-Endpunkten](feature-overview-endpoints.md#feature-overview-endpoint-considerations).
## Datenkonsistenz in Neptune
Bei der Verwendung von Neo4j-Kausal-Clustern sind Lesereplikate letztlich konsistent mit den Core-Servern, aber Client-Anwendungen können die kausale Konsistenz sicherstellen, indem sie die [kausale Verkettung](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-causal-chaining) verwenden. Bei der kausalen Verkettung werden Lesezeichen zwischen Transaktionen übergeben, so dass eine Client-Anwendung auf einen Hauptserver schreiben und dann ihren eigenen Schreibvorgang aus einem Lesereplikat lesen kann.
In Neptune sind Lesereplikat-Instances letztlich mit dem Writer konsistent, wobei die Replikatverzögerung normalerweise weniger als 100 Millisekunden beträgt. Aktualisierungen vorhandener Edges und Scheitelpunkte sowie das Hinzufügen neuer Edges und Scheitelpunkte sind auf einer Replikat-Instance jedoch erst sichtbar, wenn eine Änderung repliziert wurde. Wenn Ihre Anwendung sofortige Konsistenz auf Neptune benötigt, indem sie jeden Schreibvorgang liest, verwenden Sie daher den Cluster-Endpunkt für den read-after-write Vorgang. Dies ist das einzige Mal, dass der Cluster-Endpunkt für Lesevorgänge genutzt wird. Verwenden Sie unter allen anderen Umständen den Reader-Endpunkt für Lesevorgänge.
## Migrieren von Abfragen von Neo4j zu Neptune
Obwohl die [Unterstützung für openCypher](https://aws.amazon.com/blogs/database/announcing-the-general-availability-of-opencypher-support-for-amazon-neptune/) in Neptune den Arbeitsaufwand für die Migration von Abfragen aus Neo4j drastisch reduziert, sind bei der Migration dennoch einige Unterschiede zu berücksichtigen:
+ Wie bereits unter [Datenmodelloptimierungen](migration-data-migration.md#migration-data-model-optimization) erwähnt, müssen Sie möglicherweise Änderungen an Ihrem Datenmodell vornehmen, um ein optimiertes Graphdatenmodell für Neptune zu erstellen, was wiederum Änderungen an Ihren Abfragen und Testverfahren erfordert.
+ Neo4j bietet eine Vielzahl von für Cypher spezifischen Spracherweiterungen, die nicht in der von Neptune implementierten openCypher-Spezifikation enthalten sind. Je nach Anwendungsfall und verwendetem Feature gibt es möglicherweise Problemumgehungen innerhalb der openCypher-Sprache bzw. mithilfe der Gremlin-Sprache oder durch andere Mechanismen, wie unter [Umschreiben von Cypher-Abfragen zur Ausführung in openCypher auf Neptune](migration-opencypher-rewrites.md) beschrieben.
+ Anwendungen verwenden anstelle der Bolt-Treiber selbst häufig andere Middleware-Komponenten, um mit der Datenbank zu interagieren. Bitte überprüfen Sie [Neptune-Kompatibilität mit Neo4j](migration-compatibility.md), um festzustellen, ob die von Ihnen verwendeten Tools oder Middleware-Komponenten unterstützt werden.
+ Im Falle eines Failovers stellt der Bolt-Treiber möglicherweise weiterhin eine Verbindung zur vorherigen Writer- oder Reader-Instance her, da der für die Verbindung bereitgestellte Cluster-Endpunkt zu einer IP-Adresse aufgelöst wurde. Die korrekte Fehlerbehandlung in Ihrer Anwendung sollte damit wie unter [Erstellen einer neuen Verbindung nach einem Failover](best-practices-opencypher.md#best-practices-opencypher-renew-connection) beschrieben umgehen.
+ Wenn Transaktionen aufgrund von nicht auflösbaren Konflikten oder der Überschreitung von Sperrwartezeiten abgebrochen werden, reagiert Amazon Neptune mit einer `ConcurrentModificationException`. Weitere Informationen finden Sie unter [Engine-Fehlercodes](errors-engine-codes.md). Als bewährte Methode sollten Clients diese Ausnahmen immer abfangen und verarbeiten.
Eine `ConcurrentModificationException` tritt gelegentlich auf, wenn mehrere Threads oder mehrere Anwendungen gleichzeitig in das System schreiben. Aufgrund der [Isolationsstufen für Transaktionen](transactions-neptune.md#transactions-neptune-mutation) können solche Konflikte manchmal unvermeidlich sein.
+ Neptune unterstützt die Ausführung von Gremlin- und OpenCypher-Abfragen für dieselben Daten. Dies bedeutet, dass Sie in manchen Szenarien möglicherweise in Betracht ziehen müssen, Gremlin mit seinen leistungsfähigeren Abfragefunktionen zu verwenden, um einige der Funktionen Ihrer Abfragen auszuführen.
Wie bereits in [Bereitstellen der Infrastruktur](migration-provisioning-infrastructure.md) erwähnt, sollte für jede Anwendung die Größe korrekt angepasst werden, um sicherzustellen, dass die Anzahl der Instances, die Instance-Größen und die Cluster-Topologie sämtlich für den spezifischen Workload der Anwendung optimiert sind.
Die hier besprochenen Überlegungen zur Migration Ihrer Anwendung sind die üblichsten, diese Liste ist aber nicht vollständig. Jede Anwendung ist einzigartig. Bitte wenden Sie sich an den AWS Support oder wenden Sie sich an Ihr Account-Team, wenn Sie weitere Fragen haben.
## Migration von Features und Tools, die spezifisch für Neo4j sind
Neo4j bietet eine Vielzahl von benutzerdefinierten Features und Add-Ons mit Funktionen, die Ihre Anwendung nutzen kann. Bei der Bewertung der Notwendigkeit, diese Funktionalität zu migrieren, ist es oft hilfreich, zu untersuchen, ob es einen besseren Ansatz gibt AWS , um dasselbe Ziel zu erreichen. [Angesichts der [architektonischen Unterschiede zwischen Neo4j und Neptune](migration-architectural-differences.md) können Sie oft effektive Alternativen finden, die andere AWS Dienste oder Integrationen nutzen.](integrations.md)
Eine Liste der für Neo4J spezifischen Features und Vorschläge für Problemumgehungen finden Sie unter [Neptune-Kompatibilität mit Neo4j](migration-compatibility.md).
# Neptune-Kompatibilität mit Neo4j
Neo4j verfolgt einen all-in-one architektonischen Ansatz, bei dem das Laden von Daten, Daten-ETL, Anwendungsabfragen, Datenspeicherung und Verwaltungsvorgänge alle in demselben Satz von Rechenressourcen, wie EC2 z. B. Instanzen, ablaufen. Amazon Neptune ist eine OLTP-orientierte Graphdatenbank mit offenen Spezifikationen, bei der die Architektur Abläufe voneinander trennt und Ressourcen entkoppelt, so dass sie dynamisch skaliert werden können.
Neo4j bietet eine Vielzahl von Features und Tools, einschließlich Tools von Drittanbietern, die nicht Teil der openCypher-Spezifikation, mit openCypher oder der openCypher-Implementierung von Neptune nicht kompatibel sind. Im Folgenden sind einige der gängigsten davon aufgeführt.
## Für Neo4j spezifische Features, die in Neptune nicht vorhanden sind
+ **`LOAD CSV`** – Neptune verfolgt ein anderes architektonisches Konzept zum Laden von Daten als Neo4j. Um eine bessere Skalierung und Kostenoptimierung zu ermöglichen, implementiert Neptune die Trennung der Bedenken in Bezug auf Ressourcen und empfiehlt, eine der [AWS -Serviceintegrationen](integrations.md) wie etwa AWS Glue zu verwenden, um die erforderlichen ETL-Prozesse durchzuführen, um Daten in einem [Format](bulk-load-tutorial-format.md) vorzubereiten, das vom [Neptune Bulk Loader](bulk-load.md) unterstützt wird.
Eine andere Möglichkeit besteht darin, dasselbe mit Anwendungscode zu tun, der auf AWS Rechenressourcen wie EC2 Amazon-Instances, Lambda-Funktionen, Amazon Elastic Container Service, AWS Batch Jobs usw. ausgeführt wird. Der Code könnte entweder den [HTTPS-Endpunkt](access-graph-opencypher-queries.md) oder den [Bolt-Endpunkt](access-graph-opencypher-bolt.md) von Neptune verwenden.
+ **Präzise Zugriffskontrolle** – Neptune unterstützt eine detaillierte Zugriffskontrolle für Datenzugriffsaktionen mithilfe von [IAM-Bedingungsschlüsseln](iam-data-access-policies.md). Auf Anwendungsebene kann eine zusätzliche detaillierte Zugriffskontrolle implementiert werden.
+ **Neo4j Fabric** – Neptune unterstützt den datenbankübergreifenden Abfrageverbund für RDF-Workloads mithilfe des SPARQL-Schlüsselworts [`SERVICE`](sparql-service.md). Da es derzeit keinen offenen Standard und keine Spezifikation für den Abfrageverbund für Eigenschaftsgraph-Workloads gibt, müsste diese Funktionalität auf Anwendungsebene implementiert werden.
+ **Rollenbasierte Zugriffskontrolle (RBAC)** – Neptune verwaltet die Authentifizierung durch die Zuweisung von [IAM-Richtlinien und -Rollen](iam-auth.md). IAM-Richtlinien und -Rollen ermöglichen eine äußerst flexible Benutzerverwaltung innerhalb einer Anwendung. Daher ist es wichtig, die Informationen in der [IAM-Übersicht](iam-auth.md) zu lesen und zu verstehen, bevor Sie Ihren Cluster konfigurieren.
+ **Bookmarking** – Neptune-Cluster bestehen aus einer einzigen Writer-Instance und bis zu 15 Lesereplikat-Instances. In die Writer-Instance geschriebene Daten sind ACID-konform und bieten eine starke Konsistenzgarantie bei nachfolgenden Lesevorgängen. Lesereplikate verwenden dasselbe Speicher-Volume wie die Writer-Instance und sind letztendlich konsistent, normalerweise in weniger als 100 ms nach dem Schreiben der Daten. Wenn in Ihrem Anwendungsfall die Lesekonsistenz neuer Schreibvorgänge sofort gewährleistet sein muss, sollten diese Lesevorgänge an den Cluster-Endpunkt statt an den Reader-Endpunkt geleitet werden.
+ **APOC-Verfahren** – Da APOC-Verfahren nicht in der openCypher-Spezifikation enthalten sind, bietet Neptune keine direkte Unterstützung für externe Verfahren. Stattdessen setzt Neptune auf [Integrationen mit anderen AWS Diensten](integrations.md), um ähnliche Endbenutzerfunktionen auf skalierbare, sichere und robuste Weise zu erreichen. Manchmal können APOC-Prozeduren in openCypher oder Gremlin umgeschrieben werden und manche sind für Neptune-Anwendungen nicht relevant.
Im Allgemeinen lassen sich APOC-Verfahren in die folgenden Kategorien einteilen:
+ **[Import](https://neo4j.com/labs/apoc/4.2/import/)** – Neptune unterstützt den Import von Daten in einer Vielzahl von Formaten mithilfe von Abfragesprachen, dem Neptune-[Bulk-Loader](bulk-load.md) oder als Ziel von [AWS Database Migration Service](dms-neptune.md). ETL-Operationen an Daten können unter Verwendung des [https://github.com/awslabs/amazon-neptune-tools/tree/master/neptune-python-utils](https://github.com/awslabs/amazon-neptune-tools/tree/master/neptune-python-utils)Open-Source-Pakets AWS Glue ausgeführt werden.
+ **[Export](https://neo4j.com/labs/apoc/4.2/export/)** – Neptune unterstützt den Export von Daten mithilfe des [`neptune-export`](neptune-data-export.md)-Dienstprogramms, das eine Vielzahl gängiger Exportformate und -methoden unterstützt.
+ **[Datenbankintegration](https://neo4j.com/labs/apoc/4.2/database-integration/)** — Neptune unterstützt die Integration mit anderen Datenbanken mithilfe von ETL-Tools wie AWS Glue oder Migrationstools wie dem. [AWS Database Migration Service](dms-neptune.md)
+ **[Graph-Updates](https://neo4j.com/labs/apoc/4.2/graph-updates/)** – Neptune unterstützt eine Vielzahl von Features zur Aktualisierung von Eigenschaftsgraphdaten, da es die Abfragesprachen openCypher und Gremlin unterstützt. Beispiele für Umschreibungen häufig verwendeter Verfahren finden Sie unter [Cypher-Umschreibungen](migration-opencypher-rewrites.md).
+ **[Datenstrukturen](https://neo4j.com/labs/apoc/4.2/data-structures/)** – Neptune unterstützt eine Vielzahl von Features zur Aktualisierung von Eigenschaftsgraphdaten, da es die Abfragesprachen openCypher und Gremlin unterstützt. Beispiele für Umschreibungen häufig verwendeter Verfahren finden Sie unter [Cypher-Umschreibungen](migration-opencypher-rewrites.md).
+ **[Zeitdaten (Datum/Uhrzeit)](https://neo4j.com/labs/apoc/4.2/temporal/)** – Neptune unterstützt eine Vielzahl von Features zur Aktualisierung von Eigenschaftsgraphdaten, da es die Abfragesprachen openCypher und Gremlin unterstützt. Beispiele für Umschreibungen häufig verwendeter Verfahren finden Sie unter [Cypher-Umschreibungen](migration-opencypher-rewrites.md).
+ **[Mathematische Daten](https://neo4j.com/labs/apoc/4.2/mathematical/)** – Neptune unterstützt eine Vielzahl von Features zur Aktualisierung von Eigenschaftsgraphdaten, da es die Abfragesprachen openCypher und Gremlin unterstützt. Beispiele für Umschreibungen häufig verwendeter Verfahren finden Sie unter [Cypher-Umschreibungen](migration-opencypher-rewrites.md).
+ **[Erweiterte Graph-Abfragen](https://neo4j.com/labs/apoc/4.2/graph-querying/)** – Neptune unterstützt eine Vielzahl von Features zur Aktualisierung von Eigenschaftsgraphdaten, da es die Abfragesprachen openCypher und Gremlin unterstützt. Beispiele für Umschreibungen häufig verwendeter Verfahren finden Sie unter [Cypher-Umschreibungen](migration-opencypher-rewrites.md).
+ **[Graph-Vergleich](https://neo4j.com/labs/apoc/4.2/comparing-graphs/)** – Neptune unterstützt eine Vielzahl von Features zur Aktualisierung von Eigenschaftsgraphdaten, da es die Abfragesprachen openCypher und Gremlin unterstützt. Beispiele für Umschreibungen häufig verwendeter Verfahren finden Sie unter [Cypher-Umschreibungen](migration-opencypher-rewrites.md).
+ **[Cypher-Ausführung](https://neo4j.com/labs/apoc/4.2/cypher-execution/)** – Neptune unterstützt eine Vielzahl von Features zur Aktualisierung von Eigenschaftsgraphdaten, da es die Abfragesprachen openCypher und Gremlin unterstützt. Beispiele für Umschreibungen häufig verwendeter Verfahren finden Sie unter [Cypher-Umschreibungen](migration-opencypher-rewrites.md).
+ **Benutzerdefinierte Verfahren** – Neptune unterstützt keine von Benutzern erstellten Verfahren. Diese Funktionalität müsste auf Anwendungsebene implementiert werden.
+ **Geospatial** — Obwohl Neptune keine native Unterstützung für Geodatenfunktionen bietet, können ähnliche Funktionen durch die Integration mit anderen AWS Diensten erreicht werden, wie in diesem Blogbeitrag gezeigt wird: [Kombinieren Sie Amazon Neptune und Amazon OpenSearch Service für Geodatenabfragen von Ross Gabay und](https://aws.amazon.com/blogs/database/combine-amazon-neptune-and-amazon-opensearch-service-for-geospatial-queries/) Abhilash Vinod (1. Februar 2022).
+ **Graph Data Science** – Neptune unterstützt Graphanalysen heute über [Neptune Analytics](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html), eine speicheroptimierte Engine, die eine Bibliothek von Graphanalysealgorithmen unterstützt.
Neptune bietet außerdem eine Integration mit dem [AWS -Pandas-SDK](https://github.com/amazon-archives/fully-automated-neo4j-to-neptune) und mehrere [Beispiel-Notebooks](https://github.com/aws/graph-notebook/tree/main/src/graph_notebook/notebooks/05-Data-Science), die zeigen, wie diese Integration in Python-Umgebungen genutzt werden kann, um Analysen von Graphdaten durchzuführen.
+ **Schema-Einschränkungen** – In Neptune ist die einzige verfügbare Schemaeinschränkung die Eindeutigkeit der ID eines Knotens oder eines Edges. Es gibt kein Feature, mit dem zusätzliche Schema- bzw. Eindeutigkeits- oder Werteinschränkungen für ein Element in einem Graphen angegeben werden könnten. ID-Werte in Neptune sind Zeichenfolgen und können mit Gremlin wie folgt gesetzt werden:
```
g.addV('person').property(id, '1') )
```
Für Anwendungen, die eine Eindeutigkeitseinschränkung nutzen müssen, sollte diese Vorgehensweise in Betracht gezogen werden, um eine solche 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'` repräsentiert werden, so dass eine komplexe Eindeutigkeitseinschränkung erreicht wird.
+ **Mehrere Mandanten** – Neptune unterstützt nur einen Graphen pro Cluster. Um ein Mehrmandantensystem mit Neptune aufzubauen, verwenden Sie entweder mehrere Cluster oder partitionieren Sie die Mandanten logisch in einem einzigen Graphen und verwenden anwendungsseitige Logik, um die Trennung zu erzwingen. Fügen Sie beispielsweise eine `tenantId`-Eigenschaft wie folgt in in jede Abfrage ein:
```
MATCH p=(n {tenantId:1})-[]->({tenantId:1}) RETURN p LIMIT 5)
```
[Neptune Serverless](neptune-serverless.md) macht es relativ einfach, Multi-Tenancy mithilfe mehrerer DB-Cluster zu implementieren, von denen jeder unabhängig und automatisch nach Bedarf skaliert wird.
## Neptune-Unterstützung für Neo4j-Tools
Neptune bietet die folgenden Alternativen zu Neo4j-Tools:
+ **[Neo4j Browser](https://neo4j.com/docs/operations-manual/current/installation/neo4j-browser/)** – Neptune bietet Open-Source-[Graph-Notebooks](graph-notebooks.md), die eine entwicklerorientierte IDE zum Ausführen von Abfragen und zur Visualisierung der Ergebnisse bieten.
+ **[Neo4j Bloom](https://neo4j.com/product/bloom/)** – Neptune unterstützt umfangreiche Graphvisualisierungen mithilfe von [Visualisierungslösungen von Drittanbietern](visualization-tools.md) wie Graph-Explorer, Tom Sawyer, Cambridge Intelligence, Graphistry, Metaphacts und G.V().
+ **[GraphQL](https://graphql.org/)** — Neptune unterstützt GraphQL derzeit durch benutzerdefinierte Integrationen. AWS AppSync Weitere Informationen finden Sie im Blogbeitrag [Build a graph application with Amazon Neptune and AWS Amplify](https://aws.amazon.com/blogs/database/build-a-graph-application-with-amazon-neptune-and-aws-amplify/) und im Beispielprojekt [Building Serverless Calorie Tracker application with AWS AppSync](https://github.com/aws-samples/aws-appsync-calorie-tracker-workshop) and Amazon Neptune.
+ **[NeoSemantics](https://neo4j.com/labs/neosemantics/4.0/)**— Neptune unterstützt das RDF-Datenmodell nativ. Kunden, die RDF-Workloads ausführen möchten, wird daher empfohlen, die RDF-Modellunterstützung von Neptune zu verwenden.
+ **[Arrows.app](https://arrows.app/)** – Die Cypher, die beim Exportieren des Modells mit dem Exportbefehl erstellt wurde, ist mit Neptune kompatibel.
+ **[Linkurious Ogma](https://doc.linkurious.com/ogma/latest/)** – Eine Beispielintegration mit Linkurious Ogma ist [hier verfügbar](https://github.com/aws-samples/amazon-neptune-samples/tree/master/gremlin/ogma-neptune).
+ **[Spring Data Neo4j](https://spring.io/projects/spring-data-neo4j)** – Dies ist derzeit nicht mit Neptune kompatibel.
+ **[Neo4j Spark Connector](https://neo4j.com/docs/spark/current/)** – Der Neo4j Spark Connector kann innerhalb eines Spark-Auftrags verwendet werden, um mithilfe von openCypher eine Verbindung zu Neptune herzustellen. Hier finden Sie Beispielcode und eine Anwendungskonfiguration:
**Beispiel-Code:**
```
SparkSession spark = SparkSession
.builder()
.config("encryption.enabled", "true")
.appName("Simple Application").config("spark.master", "local").getOrCreate();
Dataset df = spark.read().format("org.neo4j.spark.DataSource")
.option("url", "bolt://(your cluster endpoint):8182")
.option("encryption.enabled", "true")
.option("query", "MATCH (n:airport) RETURN n")
.load();
System.out.println("TOTAL RECORD COUNT: " + df.count());
spark.stop();
```
**Anwendungskonfiguration:**
```
org.neo4j
neo4j-connector-apache-spark_2.12-4.1.0
4.0.1_for_spark_3
```
### Neo4j-Features und -Tools, die hier nicht aufgeführt sind
Wenn Sie ein Tool oder eine Funktion verwenden, die hier nicht aufgeführt ist, sind wir uns nicht sicher, ob es mit Neptune oder anderen darin enthaltenen Diensten kompatibel ist. AWS Bitte wenden Sie sich an den AWS Support oder wenden Sie sich an Ihr Account-Team, wenn Sie weitere Fragen haben.
# Umschreiben von Cypher-Abfragen zur Ausführung in openCypher auf Neptune
openCypher ist eine deklarative Abfragesprache für Eigenschaftsdiagramme. Ursprünglich von Neo4j entwickelt, wurde sie 2015 als Open-Source-Software veröffentlicht und ist unter einer Apache-2-Open-Source-Lizenz für das [openCypher](https://www.opencypher.org/)-Projekt verfügbar. Wir bei glauben AWS, dass Open Source für alle gut ist, und wir setzen uns dafür ein, unseren Kunden den Wert von Open Source und den Open-Source-Communities die operative Exzellenz AWS zu bieten.
OpenCypher Die Syntax ist in der [Cypher Query Language Reference, Version 9,](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) dokumentiert.
Da OpenCypher eine Teilmenge der Syntax und Features der Cypher-Abfragesprache enthält, erfordern einige Migrationsszenarien entweder das Umschreiben von Abfragen in mit OpenCypher kompatible Form oder die Prüfung alternativer Methoden, um die gewünschte Funktionalität zu erreichen.
Dieser Abschnitt enthält Empfehlungen zum Umgang mit häufigen Unterschieden, die jedoch keineswegs erschöpfend sind. Sie sollten jede Anwendung, die diese Umschreibungen verwendet, gründlich testen, um sicherzustellen, dass die Ergebnisse Ihren Erwartungen entsprechen.
## Umschreiben von `None`-, `All`- und `Any`-Prädikatfunktionen
Diese Funktionen sind nicht Teil der openCypher-Spezifikation. Vergleichbare Ergebnisse können mit List Comprehension in openCypher erzielt werden.
Finden Sie zum Beispiel alle Pfade, die von Knoten `Start` zu Knoten `End` führen, wobei aber kein Pfad einen Knoten passieren darf, dessen Klasseneigenschaft `D` ist:
```
# Neo4J Cypher code
match p=(a:Start)-[:HOP*1..]->(z:End)
where none(node IN nodes(p) where node.class ='D')
return p
# Neptune openCypher code
match p=(a:Start)-[:HOP*1..]->(z:End)
where size([node IN nodes(p) where node.class = 'D']) = 0
return p
```
List Comprehension kann diese Ergebnisse können wie folgt erreichen:
```
all => size(list_comprehension(list)) = size(list)
any => size(list_comprehension(list)) >= 1
none => size(list_comprehension(list)) = 0
```
## Umschreiben der Cypher-Funktion `reduce()` zu openCypher
Die `reduce()`-Funktion ist nicht Teil der openCypher-Spezifikation. Sie wird häufig verwendet, um eine Aggregierung von Daten aus Elementen innerhalb einer Liste zu erstellen. In vielen Fällen können Sie eine Kombination aus List Comprehension und der `UNWIND`-Klausel verwenden, um ähnliche Ergebnisse zu erreichen.
Die folgende Cypher-Abfrage findet beispielsweise alle Flughäfen auf Wegen mit einer bis drei Stopps zwischen Anchorage (ANC) und Austin (AUS) und gibt die Gesamtentfernung für jeden Pfad zurück:
```
MATCH p=(a:airport {code: 'ANC'})-[r:route*1..3]->(z:airport {code: 'AUS'})
RETURN p, reduce(totalDist=0, r in relationships(p) | totalDist + r.dist) AS totalDist
ORDER BY totalDist LIMIT 5
```
Sie können dieselbe Abfrage in openCypher für Neptune wie folgt schreiben:
```
MATCH p=(a:airport {code: 'ANC'})-[r:route*1..3]->(z:airport {code: 'AUS'})
UNWIND [i in relationships(p) | i.dist] AS di
RETURN p, sum(di) AS totalDist
ORDER BY totalDist
LIMIT 5
```
## Umschreiben der Cypher-Klausel FOREACH zu openCypher
Die FOREACH–Klausel ist nicht Teil der openCypher-Spezifikation. Sie wird häufig verwendet, um Daten während einer Abfrage zu aktualisieren, oft anhand von Aggregierungen oder Elementen innerhalb eines Pfads.
Finden Sie als Beispiel für einen Pfad nach allen Flughäfen auf einem Pfad mit nicht mehr als zwei Stopps zwischen Anchorage (ANC) und Austin (AUS) und legen Sie für jeden von ihnen die Eigenschaft „besucht“ fest:
```
# Neo4J Example
MATCH p=(:airport {code: 'ANC'})-[*1..2]->({code: 'AUS'})
FOREACH (n IN nodes(p) | SET n.visited = true)
# Neptune openCypher
MATCH p=(:airport {code: 'ANC'})-[*1..2]->({code: 'AUS'})
WITH nodes(p) as airports
UNWIND airports as a
SET a.visited=true
```
Ein weiteres Beispiel ist:
```
# Neo4J Example
MATCH p=(start)-[*]->(finish)
WHERE start.name = 'A' AND finish.name = 'D'
FOREACH (n IN nodes(p) | SET n.marked = true)
# Neptune openCypher
MATCH p=(start)-[*]->(finish)
WHERE start.name = 'A' AND finish.name = 'D'
UNWIND nodes(p) AS n
SET n.marked = true
```
## Umschreiben der Neo4j-APOC-Prozeduren zu Neptune
In den folgenden Beispielen wird openCypher verwendet, um einige der am häufigsten verwendeten [APOC-Prozeduren](https://neo4j.com/blog/intro-user-defined-procedures-apoc/) zu ersetzen. Diese Beispiele dienen nur als Referenz und sollen einige Vorschläge zum Umgang mit gängigen Szenarien geben. In der Praxis ist jede Anwendung anders und Sie müssen Ihre eigenen Strategien entwickeln, um alle Funktionen bereitzustellen, die Sie benötigen.
### Umschreiben von `apoc.export`-Verfahren
Neptune bietet mithilfe des [Neptune-Export](https://github.com/aws/neptune-export)-Dienstprogramms eine Reihe von Optionen sowohl für vollständige Graph- als auch für abfragebasierte Exporte in verschiedenen Ausgabeformaten wie CSV und JSON (siehe [Exportieren von Daten aus einem Neptune-DB-Cluster](neptune-data-export.md)).
### Umschreiben von `apoc.schema`-Verfahren
Neptune hat kein explizit definiertes Schema, keine Indizes oder Einschränkungen, so dass viele `apoc.schema`-Prozeduren nicht mehr erforderlich sind. Beispiele sind:
+ `apoc.schema.assert`
+ `apoc.schema.node.constraintExists`
+ `apoc.schema.node.indexExists`,
+ `apoc.schema.relationship.constraintExists`
+ `apoc.schema.relationship.indexExists`
+ `apoc.schema.nodes`
+ `apoc.schema.relationships`
Neptune openCypher unterstützt das Abrufen ähnlicher Werte wie die Prozeduren, wie unten gezeigt, kann jedoch bei größeren Graphen zu Leistungsproblemen führen, da dafür ein großer Teil des Graphen gescannt werden muss, um die Antwort zurückzugeben.
```
# openCypher replacement for apoc.schema.properties.distinct
MATCH (n:airport)
RETURN DISTINCT n.runways
```
```
# openCypher replacement for apoc.schema.properties.distinctCount
MATCH (n:airport)
RETURN DISTINCT n.runways, count(n.runways)
```
### Alternativen zu `apoc.do`-Prozeduren
Diese Prozeduren werden verwendet, um eine bedingte Abfrageausführung zu ermöglichen, die mit anderen OpenCypher-Klauseln einfach zu implementieren ist. In Neptune gibt es mindestens zwei Möglichkeiten, ein ähnliches Verhalten zu erreichen:
+ Eine Möglichkeit besteht darin, die Listenverständnisfunktionen von OpenCypher mit der `UNWIND`-Klausel zu kombinieren.
+ Eine andere Möglichkeit besteht darin, die Schritte choose() und coalesce() in Gremlin zu verwenden.
Beispiele für diese Vorgehensweisen sind unten aufgeführt.
#### Alternativen zu apoc.do.when
```
# Neo4J Example
MATCH (n:airport {region: 'US-AK'})
CALL apoc.do.when(
n.runways>=3,
'SET n.is_large_airport=true RETURN n',
'SET n.is_large_airport=false RETURN n',
{n:n}
) YIELD value
WITH collect(value.n) as airports
RETURN size([a in airports where a.is_large_airport]) as large_airport_count,
size([a in airports where NOT a.is_large_airport]) as small_airport_count
# Neptune openCypher
MATCH (n:airport {region: 'US-AK'})
WITH n.region as region, collect(n) as airports
WITH [a IN airports where a.runways >= 3] as large_airports,
[a IN airports where a.runways < 3] as small_airports, airports
UNWIND large_airports as la
SET la.is_large_airport=true
WITH DISTINCT small_airports, airports
UNWIND small_airports as la
SET la.small_airports=true
WITH DISTINCT airports
RETURN size([a in airports where a.is_large_airport]) as large_airport_count,
size([a in airports where NOT a.is_large_airport]) as small_airport_count
#Neptune Gremlin using choose()
g.V().
has('airport', 'region', 'US-AK').
choose(
values('runways').is(lt(3)),
property(single, 'is_large_airport', false),
property(single, 'is_large_airport', true)).
fold().
project('large_airport_count', 'small_airport_count').
by(unfold().has('is_large_airport', true).count()).
by(unfold().has('is_large_airport', false).count())
#Neptune Gremlin using coalesce()
g.V().
has('airport', 'region', 'US-AK').
coalesce(
where(values('runways').is(lt(3))).
property(single, 'is_large_airport', false),
property(single, 'is_large_airport', true)).
fold().
project('large_airport_count', 'small_airport_count').
by(unfold().has('is_large_airport', true).count()).
by(unfold().has('is_large_airport', false).count())
```
#### Alternativen zu apoc.do.when
```
# Neo4J Example
MATCH (n:airport {region: 'US-AK'})
CALL apoc.case([
n.runways=1, 'RETURN "Has one runway" as b',
n.runways=2, 'RETURN "Has two runways" as b'
],
'RETURN "Has more than 2 runways" as b'
) YIELD value
RETURN {type: value.b,airport: n}
# Neptune openCypher
MATCH (n:airport {region: 'US-AK'})
WITH n.region as region, collect(n) as airports
WITH [a IN airports where a.runways =1] as single_runway,
[a IN airports where a.runways =2] as double_runway,
[a IN airports where a.runways >2] as many_runway
UNWIND single_runway as sr
WITH {type: "Has one runway",airport: sr} as res, double_runway, many_runway
WITH DISTINCT double_runway as double_runway, collect(res) as res, many_runway
UNWIND double_runway as dr
WITH {type: "Has two runways",airport: dr} as two_runways, res, many_runway
WITH collect(two_runways)+res as res, many_runway
UNWIND many_runway as mr
WITH {type: "Has more than 2 runways",airport: mr} as res2, res, many_runway
WITH collect(res2)+res as res
UNWIND res as r
RETURN r
#Neptune Gremlin using choose()
g.V().
has('airport', 'region', 'US-AK').
project('type', 'airport').
by(
choose(values('runways')).
option(1, constant("Has one runway")).
option(2, constant("Has two runways")).
option(none, constant("Has more than 2 runways"))).
by(elementMap())
#Neptune Gremlin using coalesce()
g.V().
has('airport', 'region', 'US-AK').
project('type', 'airport').
by(
coalesce(
has('runways', 1).constant("Has one runway"),
has('runways', 2).constant("Has two runways"),
constant("Has more than 2 runways"))).
by(elementMap())
```
## Alternativen zu listenbasierten Eigenschaften
Neptune unterstützt derzeit nicht das Speichern von auf Listen basierenden Eigenschaften. Ähnliche Ergebnisse können jedoch erzielt werden, wenn Listenwerte als kommagetrennte Zeichenfolge gespeichert und dann die Listeneigenschaft mithilfe der Funktionen `join()` und `split()` konstruiert und dekonstruiert wird.
Wenn wir beispielsweise eine Liste von Tags als Eigenschaft speichern möchten, könnten wir die Beispiel-Umschreibung verwenden, die zeigt, wie eine durch Kommata getrennte Eigenschaft abgerufen wird, und dann die Funktionen `split()` und `join()` mit List Comprehension verwenden, um vergleichbare Ergebnisse zu erzielen:
```
# Neo4j Example (In this example, tags is a durable list of string.
MATCH (person:person {name: "TeeMan"})
WITH person, [tag in person.tags WHERE NOT (tag IN ['test1', 'test2', 'test3'])] AS newTags
SET person.tags = newTags
RETURN person
# Neptune openCypher
MATCH (person:person {name: "TeeMan"})
WITH person, [tag in split(person.tags, ',') WHERE NOT (tag IN ['test1', 'test2', 'test3'])] AS newTags
SET person.tags = join(newTags,',')
RETURN person
```
## CALL-Unterabfragen umschreiben
`CALL`Neptune-Unterabfragen unterstützen die Syntax `CALL (friend) { ... }` für den Import von Variablen in den Unterabfragebereich nicht (in diesem `friend` Beispiel). Bitte verwenden Sie die `WITH` Klausel innerhalb der Unterabfrage für dasselbe, z. B. `CALL { WITH friend ... }`
Optionale `CALL` Unterabfragen werden derzeit nicht unterstützt.
## Weitere Unterschiede zwischen Neptune openCypher und Cypher
+ Neptune unterstützt nur TCP-Verbindungen für das Bolt-Protokoll. WebSocketsVerbindungen für Bolt werden nicht unterstützt.
+ Neptune openCypher entfernt Leerzeichen in den Funktionen `trim()`, `ltrim()` und `rtrim()`, wie in Unicode definiert.
+ In Neptune openCypher wechselt `tostring(`double`)` bei großen Double-Werten nicht automatisch zur E-Notation.
# Ressourcen für die Migration von Neo4j zu Neptune
Neptune bietet verschiedene Tools und Ressourcen, die den Migrationsprozess unterstützen können.
**Tools zur Unterstützung der Migration von Neo4j zu Neptune**
+ Die [CheatSheet](https://github.com/aws-samples/amazon-neptune-samples/blob/master/opencypher/Cheatsheet.md)OpenCypher.
+ [neo4 j-to-neptune](https://github.com/awslabs/amazon-neptune-tools/tree/master/neo4j-to-neptune) — Ein Befehlszeilenprogramm für die Migration von Daten von Neo4j nach Neptune. Dieses Tool bietet folgende Funktionen:
+ Exportieren Sie die Daten aus einem ordnungsgemäß konfigurierten Neo4j-Diagramm.
+ Konvertiert diese Daten in das Neptun-Format.
+ Laden Sie diese Daten massenweise in Neptune.
+ Führen Sie während der Konvertierung in das Neptun-Format einige grundlegende Datenkonvertierungen durch, z. B. das Umbenennen von Scheitelpunkt- oder Kantenbeschriftungen und das Generieren von Elementen.
+ Generieren Sie Eigenschaften für Knoten und Kanten mithilfe von Vorlagen (erstellen Sie beispielsweise einen `~id` Wert mithilfe einer Vorlage, z. B. `Person_{personid}` für Situationen, in denen Sie die eindeutige Kennung für ein Element erstellen müssen).
+ [OpenCypher Query Compatibility Checker](https://github.com/awslabs/amazon-neptune-tools/tree/master/opencypher-compatability-checker) — Dieses Tool nimmt die Eingabe von OpenCypher-Abfragen entgegen und wird:
+ Prüfen Sie die Kompatibilität mit der ausgewählten Version von Neptune.
+ Identifizieren Sie bestimmte Funktionen und Klauseln, die nicht unterstützt werden, mit ihren Positionen.
+ Schlagen Sie, falls verfügbar, Ersatzprodukte vor.
+ Geben Sie Fehlerbeschreibungen für alle anderen Syntaxfehler an.