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.
Speicher, Zuverlässigkeit und Verfügbarkeit von Amazon Neptune
Amazon Neptune verwendet eine verteilte und gemeinsam genutzte Speicherarchitektur, die automatisch entsprechend Ihren Anforderungen an den Datenbankspeicher skaliert wird.
Neptune-Daten werden in einem Cluster-Volume gespeichert, bei dem es sich um ein einzelnes virtuelles Volume handelt, das Laufwerke auf Basis von Non-Volatile Memory Express (NVMe) SSD verwendet. Der Cluster-Volume besteht aus einer Sammlung logischer Blöcke, die als „Segmente“ bezeichnet werden. Jedem dieser Segmente sind 10 Gigabyte (GB) Speicher zugewiesen. Die Daten in jedem Segment werden in sechs Kopien repliziert, die dann auf drei Availability Zones (AZs) in der AWS Region verteilt werden, in der sich der DB-Cluster befindet.
Wenn ein Neptune-DB-Cluster erstellt wird, wird ihm ein einzelnes Segment mit 10 GB zugeteilt. Wenn die Datenmenge zunimmt und den aktuell zugeteilten Speicherplatz überschreitet, erweitert Neptune das Cluster-Volume automatisch, indem neue Segmente hinzugefügt werden. Ein Neptun-Cluster-Volume kann in allen unterstützten Regionen mit Ausnahme von China auf eine maximale Größe von 128 Tebibyte (TiB) anwachsen GovCloud, wo es auf 64 TiB begrenzt ist. Für Engine-Versionen vor Release: 1.0.2.1.R6 (22.04.2020) ist die Größe der Cluster-Volumes jedoch in allen Regionen auf 64 TiB begrenzt.
Das DB-Cluster-Volume enthält alle Benutzerdaten, Indizes und Verzeichnisse (wie im Abschnitt Neptune-Diagrammdatenmodell beschrieben) sowie interne Metadaten, z. B. interne Transaktionsprotokolle. Diese Diagrammdaten, einschließlich Indizes und interner Protokolle, dürfen die maximale Größe des Cluster-Volumes nicht überschreiten.
E/A-optimierte Speicheroption
Neptune bietet zwei Preismodelle für Speicher an:
Standardspeicher: Der Standardspeicher bietet kostengünstigen Datenbankspeicher für Anwendungen mit mäßiger bis geringer E/A-Nutzung.
-
E/A-optimierter Speicher: Mit dem E/A-optimierten Speicher zahlen Sie nur für den Speicher, den Sie tatsächlich nutzen. Die Kosten sind dabei höher als beim Standardspeicher, aber Sie zahlen nicht für die E/A-Nutzung.
E/A-optimierter Speicher ist darauf ausgelegt, die Anforderungen E/A-intensiver Graph-Workloads zu vorhersehbaren Kosten zu erfüllen, wobei eine geringe E/A-Latenz und ein konstanter E/A-Durchsatz geboten werden.
Weitere Informationen finden Sie im Artikel zu E/A-optimiertem Speicher.
Neptune-Speicherzuteilung
Auch wenn ein Neptune-Cluster-Volume auf bis zu 128 TiB (oder 64 TiB in einigen wenigen Regionen) vergrößert werden kann, werden Ihnen nur die Kosten für den tatsächlich zugeteilten Speicherplatz berechnet. Der gesamte zugeteilte Speicherplatz wird durch die Speicherhöchstgrenze festgelegt. Dies ist der maximale Speicherplatz, der dem Cluster-Volume zu einem beliebigen Zeitpunkt während seines Bestehens zugeteilt wird.
Das bedeutet, dass selbst dann, wenn Benutzerdaten aus einem Cluster-Volume entfernt werden, z. B. durch eine Drop-Abfrage wie g.V().drop(), der gesamte zugeteilte Speicherplatz unverändert bleibt. Neptune optimiert automatisch den ungenutzten zugeteilten Speicherplatz für die zukünftige Wiederverwendung.
Zusätzlich zu den Benutzerdaten verbrauchen zwei weitere Inhaltstypen internen Speicherplatz: Verzeichnisdaten und interne Transaktionsprotokolle. Verzeichnisdaten werden zwar zusammen mit Diagrammdaten gespeichert, bleiben jedoch unbegrenzte Zeit bestehen, auch wenn die unterstützten Diagrammdaten gelöscht wurden. Daher können Einträge wiederverwendet werden, wenn erneut Daten eingeführt werden. Interne Protokolldaten werden in einem getrennten internen Speicherbereich gespeichert, der über einen eigenen Höchstwert verfügt. Wenn ein internes Protokoll abläuft, kann der belegte Speicherplatz für andere Protokolle wiederverwendet werden, jedoch nicht für Diagrammdaten. Die Menge an internem Speicherplatz, der für Protokolle zugewiesen wurde, ist in dem von der Metrik angegebenen Gesamtspeicher enthalten. VolumeBytesUsed CloudWatch
In Bewährte Methoden für Speicher finden Sie Möglichkeiten, den zugeteilten Speicherplatz auf ein Minimum zu beschränken und Speicherplatz wiederzuverwenden.
Neptune-Speicher-Fakturierung
Die Speicherkosten werden auf Grundlage des Speicherhöchstwerts abgerechnet, wie oben beschrieben. Ihre Daten werden zwar in sechs Kopien repliziert, Ihnen wird jedoch nur eine Kopie der Daten berechnet.
Sie können den aktuellen Speichergrenzwert Ihres DB-Clusters ermitteln, indem Sie die VolumeBytesUsed CloudWatch Metrik überwachen (sieheÜberwachung von Neptune mit Amazon CloudWatch).
Andere Faktoren, die sich auf die Neptune-Speicherkosten auswirken können, sind Datenbank-Snapshots und Backups, die getrennt als Backup-Speicher berechnet werden und auf den Neptune-Speicherkosten basieren (siehe CloudWatch Metriken, die für die Verwaltung des Neptune-Backup-Speichers nützlich sind).
Wenn Sie jedoch einen Klon Ihrer Datenbank erstellen, verweist der Klon auf dasselbe Cluster-Volume, das Ihr DB-Cluster selbst verwendet, sodass keine zusätzlichen Speichergebühren für die Originaldaten anfallen. Spätere Änderungen am Clone verwenden das copy-on-write Protokoll und führen zu zusätzlichen Speicherkosten.
Weitere Informationen zu Neptune-Preisen finden Sie unter Amazon-Neptune-Preise
Bewährte Methoden für Neptune-Speicher
Da bestimmte Datentypen permanenten Speicherplatz in Neptune verbrauchen, sollten Sie diese bewährten Methoden anwenden, um große Spitzen beim Speicherwachstum zu vermeiden:
Vermeiden Sie bei der Entwicklung Ihres Diagrammdatenmodells temporäre Eigenschaftsschlüssel und benutzerorientierte Werte, soweit möglich.
Wenn Sie Änderungen an Ihrem Datenmodell vornehmen möchten, laden Sie mit dem neuen Modell keine Daten in einen vorhandenen DB-Cluster, bis Sie die Daten in diesem DB-Cluster mithilfe des Fast Resets gelöscht habenAPI. Häufig ist es am besten, Daten, die ein neues Modell verwenden, in einen neuen DB-Cluster zu laden.
-
Transaktionen für große Datenmengen erzeugen entsprechend umfangreiche interne Protokolle, wodurch die Höchstgrenze für den internen Protokollbereich dauerhaft erhöht werden kann. Beispielsweise könnte eine einzelne Transaktion, die alle Daten in Ihrem DB-Cluster löscht, ein riesiges internes Protokoll erzeugen, das die Zuteilung eines großen Teils des internen Speichers erfordern und damit den für Diagrammdaten verfügbaren Speicherplatz dauerhaft reduzieren würde.
Um dies zu vermeiden, sollten Sie große Transaktionen in kleinere Transaktionen aufteilen und genügend Zeit zwischen ihnen einplanen, sodass die entsprechenden internen Protokolle ablaufen können und ihr interner Speicher für die Wiederverwendung durch nachfolgende Protokolle freigegeben wird.
Um das Wachstum Ihres Neptun-Clustervolumens zu überwachen, können Sie einen CloudWatch Alarm für die
VolumeBytesUsedCloudWatch Metrik einstellen. Dies kann besonders nützlich sein, wenn Ihre Daten die maximale Größe des Cluster-Volumes erreichen. Weitere Informationen finden Sie unter CloudWatch Amazon-Alarme verwenden.
Die einzige Möglichkeit, den von Ihrem DB-Cluster verwendeten Speicherplatz zu verringern, wenn Sie über eine große Menge an ungenutztem zugeteiltem Speicherplatz verfügen, besteht darin, alle Daten in Ihrem Diagramm zu exportieren und sie dann erneut in einen neuen DB-Cluster zu laden. Eine einfache Möglichkeit, Daten aus einem DB-Cluster zu exportieren, finden Sie unter Neptune-Service und -Hilfsprogramm für den Datenexport. Eine einfache Möglichkeit, Daten wieder in Neptune zu importieren, finden Sie unter Neptune-Bulk-Loader.
Anmerkung
Die Erstellung und Wiederherstellung eines Snapshots reduziert nicht die Menge des Speichers, der Ihrem DB-Cluster zugeteilt ist, da ein Snapshot das ursprüngliche Image des dem Cluster zugrunde liegenden Speichers beibehält. Wenn eine große Menge des zugeteilten Speichers nicht verwendet wird, können Sie den zugeteilten Speicher nur reduzieren, indem Sie die Diagrammdaten exportieren und in einen neuen DB-Cluster laden.
Speicherzuverlässigkeit und hohe Verfügbarkeit von Neptune
Amazon Neptune ist auf Zuverlässigkeit, Beständigkeit und Fehlertoleranz ausgelegt.
Die Tatsache, dass sechs Kopien Ihrer Neptune-Daten in drei Verfügbarkeitszonen (AZs) aufbewahrt werden, stellt sicher, dass die Daten äußerst dauerhaft gespeichert werden und die Wahrscheinlichkeit eines Datenverlusts sehr gering ist. Die Daten werden automatisch über die Availability Zones repliziert, unabhängig davon, ob es in ihnen DB-Instances gibt. Der Umfang der Replikation ist unabhängig von der Anzahl der DB-Instances in Ihrem Cluster.
Das bedeutet, dass Sie eine Read-Replica schnell hinzufügen können, da Neptune keine neue Kopie der Diagrammdaten erstellt. Stattdessen wird die Read-Replica mit dem Cluster-Volume verbunden, das Ihre Daten bereits enthält. Ebenso werden beim Entfernen einer Read-Replica die zugrunde liegenden Daten nicht entfernt.
Sie können das Cluster-Volume und dessen Daten erst löschen, wenn Sie alle zugehörigen DB-Instances gelöscht haben.
Neptune erkennt automatisch Fehler in den Segmenten, aus denen das Cluster-Volume besteht. Wenn eine Kopie der Daten in einem Segment beschädigt ist, repariert Neptune dieses Segment sofort und verwendet andere Kopien der Daten innerhalb desselben Segments, um sicherzustellen, dass die reparierten Daten aktuell sind. Dadurch vermeidet Neptune Datenverluste und reduziert die Notwendigkeit, nach einem Festplattenausfall eine point-in-time Wiederherstellung durchzuführen.
