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.
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
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 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 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) hinzugefügt werden, als auch vertikal zu jeder beliebigen Instance-Größe, die auf der Neptune-Preisseite
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.
Für Anwendungen, bei denen Konnektivität und Workload nicht vorhersehbar sind, unterstützt Neptune auch ein Auto-Scaling-Feature, 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 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 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 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 Anzahl der Threads durch 2 dividieren, erhalten Sie die Anzahl der benötigten vCPUs, die dann auf der Neptune-Preisseite
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 der vCPUs in einer Instance korrelieren, erhalten wir eine grobe Schätzung, dass r5.4xlarge die empfohlene Instance für diesen Workload wäre. 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 E/A-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-Seite.
