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.
Ein Amazon Neptune-DB-Cluster verwaltet den Zugriff auf Ihre Daten über Abfragen. Ein Cluster besteht aus:
Einer primären DB-Instance.
Bis zu 15 Read-Replica-DB-Instances.
Alle Instances in einem Cluster nutzen dasselbe zugrunde liegende verwaltete Speichervolumen, das auf Zuverlässigkeit und hohe Verfügbarkeit ausgelegt ist.
Sie stellen die Verbindungen zu den DB-Instances in Ihrem DB-Cluster über Neptune-Endpunkte her.
Primäre DB-Instance in einem Neptune-DB-Cluster
Die primäre DB-Instance koordiniert alle Schreiboperationen auf dem Speichervolume, der dem DB-Cluster zugrunde liegt. Sie unterstützt auch Leseoperationen.
In einem Neptune-DB-Cluster kann es nur eine primäre DB-Instance geben. Wenn die primäre Instance nicht verfügbar ist, wechselt Neptune automatisch zu einer der Read-Replica-Instances mit einer Priorität, die Sie angeben können.
Read-Replica-DB-Instances in einem Neptune-DB-Cluster
Nach der Erstellung der primären Instance für einen DB-Cluster können Sie bis zu 15 Read-Replica-Instances im DB-Cluster erstellen, um schreibgeschützte Abfragen zu unterstützen.
Neptune-Read-Replica-DB-Instances sind gut für die Skalierung der Lesekapazitäten geeignet, da sie im Cluster-Volume vollständig für Leseoperationen dediziert sind. Alle Schreiboperationen werden von der primären Instance verwaltet. Jede Read-Replica-DB-Instance hat einen eigenen Endpunkt.
Da das Cluster-Speichervolume von allen Instances in einem Cluster gemeinsam genutzt wird, geben alle Read-Replica-Instances dieselben Daten für Abfrageergebnisse mit einer sehr geringen Replikationsverzögerung zurück. Diese Verzögerung beträgt in der Regel sehr viel weniger als 100 Millisekunden nach dem Schreiben eines Updates durch die primäre Instance. Sie kann jedoch etwas länger sein, wenn es sehr viele Schreiboperationen gibt.
Wenn eine oder mehrere Read-Replica-Instances in verschiedenen Availability Zones verfügbar sind, kann dies die Verfügbarkeit erhöhen, da Read-Replicas als Failover-Ziele für die primäre Instance dienen. Wenn die primäre Instance ausfällt, stuft Neptune eine Read-Replica-Instance zur primären Instance herauf. Es gibt eine kurze Unterbrechung, während die heraufgestufte Instance neu gestartet wird. Während dieser Zeit können Lese- und Schreibanfragen für die primäre Instance mit einer Ausnahmemeldung fehlschlagen.
Wenn Ihr DB-Cluster keine Read-Replica-Instances enthält, ist Ihr DB-Cluster bei einem Ausfall der primären Instance solange nicht verfügbar, bis sie neu erstellt wurde. Die Neuerstellung der primären Instance dauert erheblich länger als die Heraufstufung einer Read-Replica-Instance.
Um eine hohe Verfügbarkeit zu gewährleisten, sollten Sie eine oder mehrere Read-Replica-Instances erstellen, die dieselbe DB-Instance-Klasse wie die primäre Instance besitzen, sich jedoch in anderen Availability Zones befinden. Siehe Fehlertoleranz für einen Neptune-DB-Cluster.
Sie können über die Konsole eine Multi-AZ-Bereitstellung erstellen, indem Sie ganz einfach bei der Erstellung eines DB-Clusters die Option „Multi-AZ“ angeben. Wenn sich ein DB-Cluster in einer einzelnen Availability Zone befindet, können Sie diesen zu einem Multi-AZ-DB-Cluster machen, indem Sie eine Neptune-Replica in einer anderen Availability Zone hinzufügen.
Anmerkung
Sie können keine verschlüsselte Read-Replica-Instance für einen unverschlüsselten Neptune-DB-Cluster oder eine unverschlüsselte Read-Replica-Instance für einen verschlüsselten Neptune-DB-Cluster erstellen.
Informationen zum Erstellen einer Read-Replica-DB-Instance in Neptune finden Sie unter Erstellen einer Neptune-Reader-Instance über die Konsole.
Dimensionieren von DB-Instances in einem Neptune-DB-Cluster
Dimensionieren Sie die Instances in Ihrem Neptune-DB-Cluster entsprechend Ihren CPU- und Speicheranforderungen. Die Anzahl von v CPUs auf einer Instanz bestimmt die Anzahl der Abfrage-Threads, die eingehende Anfragen bearbeiten. Die Größe des Arbeitsspeichers einer Instance bestimmt die Größe des Puffer-Caches, der zum Speichern von Kopien der Datenseiten verwendet wird, die aus dem zugrunde liegenden Speichervolume abgerufen werden.
Jede Neptune-DB-Instance hat eine Anzahl von Abfrage-Threads, die 2 x Anzahl von v CPUs auf dieser Instance entspricht. Eine r5.4xlarge mit 16 V hat CPUs beispielsweise 32 Abfrage-Threads und kann daher 32 Abfragen gleichzeitig verarbeiten.
Zusätzliche Abfragen, die eingehen, wenn alle Abfrage-Threads belegt sind, werden in eine serverseitige Warteschlange eingereiht und nach dem FIFO-Prinzip verarbeitet, sobald Abfrage-Threads verfügbar werden. Diese serverseitige Warteschlange kann ungefähr 8 000 ausstehende Anfragen aufnehmen. Sobald sie voll ist, reagiert Neptune auf weitere Anfragen mit einer ThrottlingException. Sie können die Anzahl der ausstehenden Anfragen anhand der MainRequestQueuePendingRequests CloudWatch Metrik oder mithilfe des Status-Endpunkts der Gremlin-Abfrage mit dem Parameter überwachen. includeWaiting
Aus Client-Sicht umfasst die Ausführungszeit von Abfragen die gesamte Zeit, die diese in der Warteschlange verbringen, sowie die Zeit, die für die tatsächliche Ausführung der Abfrage benötigt wird.
Eine anhaltende gleichzeitige Schreiblast, die alle Abfrage-Threads auf der primären DB-Instance nutzt, weist idealerweise eine CPU-Auslastung von mindestens 90 % auf. Dies zeigt an, dass alle Abfrage-Threads auf dem Server aktiv sinnvolle Arbeit leisten. Die tatsächliche CPU-Auslastung ist jedoch häufig etwas niedriger, selbst bei anhaltender gleichzeitiger Schreiblast. Dies liegt in der Regel daran, dass Abfrage-Threads auf den Abschluss von E/A-Operationen für die zugrunde liegenden Speichervolumes warten. Neptune verwendet Quorum-Schreibvorgänge, bei denen sechs Kopien Ihrer Daten in drei Availability Zones erstellt werden. Vier dieser sechs Speicherknoten müssen einen Schreibvorgang bestätigen, damit dieser als dauerhaft angesehen wird. Wenn ein Abfrage-Thread auf dieses Quorum vom Speichervolume wartet, ist er blockiert, was die CPU-Auslastung reduziert.
Wenn Sie eine serielle Schreiblast ausführen, bei der Sie einen Schreibvorgang nach dem anderen ausführen und warten, bis der erste Schreibvorgang abgeschlossen ist, bevor Sie mit dem nächsten beginnen, können Sie davon ausgehen, dass die CPU-Auslastung noch geringer sein wird. Die genaue Menge hängt von der Anzahl der V CPUs - und Query-Threads ab (je mehr Abfrage-Threads, desto weniger CPU-Gesamtanzahl pro Abfrage), wobei eine gewisse Reduzierung durch das Warten auf I/O verursacht wird.
Weitere Informationen zur optimalen Dimensionierung von DB-Instances finden Sie unter Instance-Typen für Amazon Neptune auswählen. Die Preise für die einzelnen Instance-Typen finden Sie auf der Seite für Neptune-Preise
Überwachen der DB-Instance-Leistung in Neptune
Sie können CloudWatch Metriken in Neptune verwenden, um die Leistung Ihrer DB-Instances zu überwachen und die vom Client beobachtete Abfragelatenz zu verfolgen. Siehe Wird verwendet CloudWatch , um die Leistung der DB-Instance in Neptune zu überwachen.
