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.
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, AnwendungsabfragenETL, Datenspeicherung und Verwaltungsvorgänge alle in demselben Satz von Rechenressourcen, wie z. B. Instanzen, ablaufen. EC2
Neptune hingegen ist eine OLTP fokussierte Graphdatenbank, in der die Architektur die Verantwortlichkeiten voneinander trennt und in der Ressourcen entkoppelt sind, sodass sie dynamisch und unabhängig skalieren 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
Core-Server sorgen für Datenbeständigkeit und Fehlertoleranz, indem sie Daten mithilfe des Raft-Protokolls replizieren.
Lesereplikate verwenden den Versand von Transaktionsprotokollen, um Daten für Workloads mit hohem Lesedurchsatz asynchron zu replizieren.
Jede Instance in einem Cluster, ob Core-Server oder Lesereplikat, enthält eine vollständige Kopie der Graphdaten.
Die Cluster-Architektur von Neptune
Ein Neptune-Cluster besteht aus einer primären Writer-Instance und bis zu 15 Lesereplikat-Instances. Alle Instances im Cluster nutzen denselben zugrunde liegenden verteilten Speicherservice, der von den Instances getrennt ist.
Die primäre Writer-Instance koordiniert alle Schreibvorgänge in der Datenbank und ist vertikal skalierbar, um flexible Unterstützung für unterschiedliche Schreib-Workloads zu bieten. Sie unterstützt auch Lesevorgänge.
-
Lesereplikat-Instances unterstützen Lesevorgänge vom zugrunde liegenden Speicher-Volume aus und ermöglichen eine horizontale Skalierung, um hohe Lese-Workloads zu unterstützen. Sie sorgen auch für hohe Verfügbarkeit, indem sie als Failover-Ziele für die primäre Instance dienen.
Anmerkung
Bei hohen Schreib-Workloads empfiehlt es sich, die Lesereplikat-Instances auf die gleiche Größe wie die Writer-Instance zu skalieren, um sicherzustellen, dass die Reader bei den Datenänderungen konsistent bleiben können.
Das zugrundeliegende Volume skaliert die Speicherkapazität automatisch, wenn die Datenmenge in Ihrer Datenbank zunimmt, und zwar bis zu 128 Tebibyte (TiB) Speicher.
Die Instance-Größen sind dynamisch und unabhängig. Die Größe jeder Instance kann geändert werden, während der Cluster ausgeführt wird, und es können auch Lesereplikate hinzugefügt oder entfernt werden, während der Cluster läuft.
Das Feature Neptune Serverless kann Ihre Rechenkapazität bei steigendem und fallendem Bedarf automatisch hoch- und herunterskalieren. Dadurch können Sie nicht nur Ihren Verwaltungsaufwand verringern, sondern die Datenbank auch so konfigurieren, dass sie große Bedarfsspitzen bewältigen kann, ohne dass die Leistung beeinträchtigt wird oder Sie zu viel bereitstellen müssen.
Sie können einen Neptune-Cluster für bis zu sieben Tage anhalten.
Neptune unterstützt auch Auto Scaling, um die Instance-Größen des Readers automatisch an den Workload anzupassen.
Mithilfe des globalen Datenbank-Features von Neptune können Sie einen Cluster in bis zu 5 anderen Regionen spiegeln.
Neptune ist außerdem vom Design her fehlertolerant:
Das Cluster-Volume, das Datenspeicher für alle Instances im Cluster bereitstellt, erstreckt sich über mehrere Availability Zones () AZs in einer 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 hinzu oder aktivieren Sie die Neptune-Serverless-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. 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.
