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.

Instance-Typen für Amazon Neptune auswählen

Amazon Neptune stellt verschiedene Instance-Größen und -Familien mit verschiedenen Funktionen bereit, die für verschiedene Graph-Workloads geeignet sind. Dieser Abschnitt soll Ihnen helfen, den besten Instance-Typ für Ihre Anforderungen auszuwählen.

Die Preise für die einzelnen Instance-Typen in diesen Familien finden Sie auf der Seite für Neptune-Preise.

Übersicht über die Zuteilung von Instance-Ressourcen

Jeder EC2 Amazon-Instance-Typ und jede Größe, die in Neptune verwendet werden, bietet eine definierte Menge an Rechenleistung (vCPUs) und Systemspeicher. Der Primärspeicher für Neptune befindet sich außerhalb der DB-Instances in einem Cluster, damit Rechenleistung und Speicherkapazität unabhängig voneinander skaliert werden können.

Dieser Abschnitt beschreibt die Skalierung von Rechenressourcen und die Unterschiede zwischen den einzelnen Instance-Familien.

In allen Instance-Familien werden vCPU-Ressourcen zur Unterstützung von zwei (2) Abfrageausführungs-Threads pro vCPU zugewiesen. Diese Unterstützung ist von der Instance-Größe abhängig. Bei der Festlegung der richtigen Größe einer Neptune-DB-Instance müssen Sie die mögliche Gleichzeitigkeit Ihrer Anwendung und die durchschnittliche Latenz Ihrer Abfragen berücksichtigen. Sie können die Anzahl der CPUs benötigten v wie folgt abschätzen, wobei die Latenz als durchschnittliche Abfragelatenz in Sekunden und die Parallelität als die Zielanzahl von Abfragen pro Sekunde gemessen wird:

vCPUs=(latencyxconcurrency)/2

Der Systemspeicher der einzelnen Instances ist in zwei primäre Zuteilungen aufgeteilt: den Pufferpool-Cache und den Thread-Speicher für die Abfrageausführung.

Ungefähr zwei Drittel des verfügbaren Speichers in einer Instance sind für den Pufferpool-Cache reserviert. Der Pufferpool-Cache wird verwendet, um die zuletzt verwendeten Komponenten des Graphen zwischenzuspeichern, um schneller auf Abfragen, die wiederholt auf diese Komponenten zugreifen, zugreifen zu können. Instances mit einer größeren Menge an Systemspeicher verfügen über größere Pufferpool-Caches, die einen größeren Teil des Graphen lokal speichern können. Ein Benutzer kann die entsprechende Menge an Pufferpool-Cache einstellen, indem er die verfügbaren Metriken für Treffer und Fehlschläge im Puffercache überwacht. CloudWatch

Sie sollten die Größe Ihrer Instance erhöhen, wenn die Cache-Trefferrate für einen konsistenten Zeitraum unter 99,9 % sinkt. Dies deutet darauf hin, dass der Pufferpool nicht groß genug ist und die Engine häufiger Daten aus dem zugrunde liegenden Speichervolume abrufen muss, als es effizient ist.

Das verbleibende Drittel des Systemspeichers wird gleichmäßig auf die Threads zur Abfrageausführung verteilt, wobei ein Teil des Speichers für das Betriebssystem und ein kleiner dynamischer Pool für Threads reserviert werden, die wie notwendig verwendet werden können. Der für jeden Thread verfügbare Arbeitsspeicher nimmt von einer Instance-Größe zur nächsten leicht zu, bis ein 8xl-Instance-Typ erreicht ist, bei dem der pro Thread zugewiesene Arbeitsspeicher ein Maximum erreicht.

Sie müssen mehr Thread-Speicher hinzufügen, wenn OutOfMemoryException (OOM) auftritt. OOM-Ausnahmen treten auf, wenn ein Thread mehr als den ihm zugeteilten maximalen Speicher benötigt. (Das bedeutet nicht, dass der Arbeitsspeicher für die Instance insgesamt nicht ausreicht.)

Instance–Typen t3 und t4g

Die Instance-Familien t4g und t3 stellen kostengünstige Optionen für den Einstieg in Graphdatenbanken sowie in die anfängliche Entwicklung und Testen dar. Diese Instances kommen für das kostenlose Neptune-Angebot in Frage, mit dem Neukunden Neptune in den ersten 750 Instance-Stunden kostenlos nutzen können, wenn sie innerhalb eines eigenständigen AWS Kontos oder zusammengefasst unter einer AWS Organisation mit konsolidierter Abrechnung (Zahlerkonto) genutzt werden.

Die Instances t4g und t3 werden nur für mittelgroße Konfigurationen (t3.medium und t4g.medium) angeboten.

Sie sind nicht für die Verwendung in Produktionsumgebung vorgesehen.

Da diese Instances nur über sehr begrenzte Ressourcen verfügen, werden sie nicht zum Testen der Ausführungszeiten von Abfragen oder der allgemeinen Datenbankleistung empfohlen. Wenn Sie die Abfrageleistung bewerten möchten, sollten Sie ein Upgrade auf eine andere Instance-Familie ausführen.

r4-Familie von Instance-Typen

VERALTET — Die r4-Familie wurde bei der Markteinführung von Neptune im Jahr 2018 angeboten. Mittlerweile bieten neuere Instance-Typen ein sehr viel besseres Preis-Leistungs-Verhältnis. Ab Engine-Version 1.1.0.0 unterstützt Neptune die r4-Instance-Typen nicht mehr.

r5-Familie von Instance-Typen

Die r5-Familie enthält arbeitsspeicheroptimierte Instance-Typen, die für die meisten Graph-Anwendungsfälle gut geeignet sind. Die r5-Familie enthält Instance-Typen von r5.large bis r5.24xlarge. Ihre Rechenleistung kann linear entsprechend Ihren Anforderungen skaliert werden. Zum Beispiel hat ein r5.xlarge (4 V CPUs und 32 GiB Speicher) doppelt so viel V CPUs und Speicher wie ein r5.large (2 V CPUs und 16 GiB Speicher), und ein r5.2xlarge (8 V CPUs und 64 GiB Speicher) hat doppelt so viel V CPUs und Speicher wie einr5.xlarge. Die Abfrageleistung wird direkt entsprechend der Rechenleistung bis zum Instance-Typ r5.12xlarge skaliert.

Die r5-Instance-Familie verfügt über eine Intel-CPU-Architektur mit 2 Sockets. Der Instance-Typ r5.12xlarge und kleinere Typen verwenden einen einzelnen Socket und den Systemspeicher, der diesem Einzel-Socket-Prozessor zugewiesen ist. Die Typen r5.24xlarge und r5.16xlarge verwenden beide Sockets und den verfügbaren Arbeitsspeicher. Da zwischen zwei physischen Prozessoren in einer 2-Socket-Architektur ein gewisser Speicherverwaltungs-Overhead erforderlich ist, sind die Leistungssteigerungen beim Hochskalieren des Instance-Typs r5.12xlarge auf r5.16xlarge oder r5.24xlarge nicht so linear wie beim Hochskalieren kleinerer Instance-Typen.

r5d-Familie von Instance-Typen

Neptune besitzt ein Lookup-Cache-Feature, mit der die Leistung von Abfragen verbessert werden kann, die eine große Anzahl von Eigenschaftswerten und Literalen abrufen und zurückgeben müssen. Dieses Feature wird vor allem von Kunden verwendet, deren Abfragen zahlreiche Attribute zurückgeben müssen. Der Lookup-Cache steigert die Leistung dieser Abfragen, indem er diese Attributwerte lokal abruft, statt jeden einzelnen Wert immer wieder im indizierten Neptune-Speicher nachzuschlagen.

Der Lookup-Cache wird mithilfe eines an einen Instance-Typ NVMe angehängten EBS-Volumes implementiert. r5d Er wird über die Parametergruppe eines Clusters aktiviert. Wenn Daten aus dem Neptune-Indexspeicher abgerufen werden, werden Eigenschaftswerte und RDF-Literale in diesem Volume zwischengespeichert. NVMe

Wenn Sie das Lookup-Cache-Feature nicht benötigen, sollten Sie den Standard-Instance-Typ r5 anstelle von r5d verwenden, um die höheren Kosten für r5d zu vermeiden.

Die Instance-Typen der r5d-Familie haben die gleiche Größe wie die Instance-Typen der r5-Familie, von r5d.large bis r5d.24xlarge.

r6g-Familie von Instance-Typen

AWS hat einen eigenen ARM-basierten Prozessor namens Graviton entwickelt, der bessere Ergebnisse liefert als die Äquivalente von Intel und AMD. price/performance Die r6g-Familie verwendet den Graviton2-Prozessor. In unseren Tests bietet der Graviton2-Prozessor eine um 10 bis 20 % bessere Leistung für Graph-Abfragen des Typs OLTP (eingeschränkte Graph-Abfragen). Für größere Abfragen des Typs OLAP sind Graviton2-Prozessoren jedoch möglicherweise etwas weniger leistungsfähig als Intel-Prozessoren, was auf die etwas geringere Leistung bei der Speicherauslagerung zurückzuführen ist.

Sie sollten auch beachten, dass die r6g -Familie über eine Single-Socket-Architektur verfügt. Das bedeutet, dass die Leistung linear mit der Rechenkapazität von von r6g.large zu r6g.16xlarge (dem größten Typ in der Familie) skaliert wird.

r6i-Familie von Instance-Typen

Amazon R6i-Instances nutzen Intel Xeon Scalable-Prozessoren der 3. Generation (Codename Ice Lake) und sind ideal für speicherintensive Workloads geeignet. In der Regel bieten sie ein um bis zu 15 % besseres Preis-Leistungs-Verhältnis und eine um bis zu 20 % höhere Speicherbandbreite pro vCPU als vergleichbare R5-Instance-Typen.

x2g-Familie von Instance-Typen

In einigen Graph-Anwendungsfällen ist die Leistung besser, wenn Instances über größere Pufferpool-Caches verfügen. Die x2g-Familie wurde eingeführt, um diese Anwendungsfälle besser zu unterstützen. Bei der x2g Familie ist das memory-to-vCPU Verhältnis größer als bei der OR-Familie. r5 r6g Die x2g-Instances nutzen ebenfalls den Graviton2-Prozessor und besitzen viele Leistungsmerkmale der r6g-Instance-Typen sowie einen größeren Pufferpool-Cache.

Wenn Sie r6g Instance-Typen mit niedriger CPU-Auslastung und einer hohen Ausfallrate beim Pufferpool-Cache verwenden, versuchen Sie stattdessen, die x2g Familie zu verwenden. r5 Auf diese Weise erhalten Sie den zusätzlichen Arbeitsspeicher, den Sie benötigen, ohne für mehr CPU-Kapazität bezahlen zu müssen.

r8g-Familie von Instance-Typen

Die r8g Familie umfasst speicheroptimierte Instance-Typen, die auf AWS Graviton4-Prozessoren basieren. Diese Instances bieten erhebliche Leistungsverbesserungen gegenüber früheren Generationen und eignen sich daher gut für speicherintensive Graph-Workloads. Die R8G-Instances bieten im Vergleich zu R7G-Instances eine um etwa 15 bis 20% bessere Leistung für Grafikabfragen.

Die r8g Familie verfügt über eine Single-Socket-Architektur, was bedeutet, dass die Leistung linear mit der Rechenkapazität von A r8g.large nach an r8g.16xlarge (dem größten Typ in der Familie) skaliert.

Zu den wichtigsten Merkmalen der r8g Produktreihe gehören:

Die r8g Produktreihe eignet sich ideal für Produktionsworkloads, die eine hohe Speicherkapazität und gleichbleibende Leistung erfordern. Sie sind besonders effektiv für Anwendungen mit hohen Anforderungen an die Parallelität von Abfragen.

r7g-Familie von Instance-Typen

Die r7g Familie verwendet den AWS Graviton3-Prozessor, der bessere Ergebnisse liefert price/performance als frühere Graviton2-basierte Instances. In Tests bietet der Graviton3-Prozessor im Vergleich zu R6G-Instances eine um 25 bis 30% bessere Leistung für OLTP-Grafikabfragen.

Wie die r6g Produktfamilie verfügt auch die r7g Familie über eine Single-Socket-Architektur, was bedeutet, dass die Leistung linear mit der Rechenkapazität von A r7g.large nach an (dem größten Typ der Familie) skaliert. r7g.16xlarge

Zu den wichtigsten Merkmalen der r7g Produktreihe gehören:

Die r7g Produktreihe eignet sich gut für Produktionsumgebungen mit unterschiedlichen Abfragemustern und ist besonders effektiv für Workloads, die von einer verbesserten Speicherbandbreite profitieren.

r7i-Familie von Instance-Typen

Die r7i Produktreihe basiert auf skalierbaren Intel Xeon Prozessoren der 4. Generation (Codename Sapphire Rapids) und bietet deutliche Verbesserungen gegenüber R6i-Instances. Diese Instances bieten eine um etwa 15% bessere Rechenleistung price/performance und eine bis zu 20% höhere Speicherbandbreite pro vCPU als vergleichbare R6i-Instance-Typen.

Die r7i Instance-Familie verfügt über eine Intel-CPU-Architektur mit 2 Sockeln, die der Familie ähnelt. r5 Der Instance-Typ r7i.12xlarge und kleinere Typen verwenden einen einzelnen Socket und den Systemspeicher, der diesem Einzel-Socket-Prozessor zugewiesen ist. Die Typen r7i.24xlarge und r7i.16xlarge verwenden beide Sockets und den verfügbaren Arbeitsspeicher. Da zwischen zwei physischen Prozessoren in einer 2-Socket-Architektur ein gewisser Speicherverwaltungs-Overhead erforderlich ist, sind die Leistungssteigerungen beim Hochskalieren des Instance-Typs r7i.12xlarge auf r7i.16xlarge oder r7i.24xlarge nicht so linear wie beim Hochskalieren kleinerer Instance-Typen.

Zu den wichtigsten Merkmalen der r7i Familie gehören:

Für all diese Instanzfamilien können Sie die CPUs benötigte Anzahl von v anhand derselben Formel schätzen, die bereits erwähnt wurde:

vCPUs=(latencyxconcurrency)/2

Dabei wird die Latenz als durchschnittliche Abfragelatenz in Sekunden und die Parallelität als die Zielanzahl von Abfragen pro Sekunde gemessen.

serverless-Instance-Typ

Mittels des Features Neptune Serverless kann die Instance-Größe anhand der Ressourcenanforderungen eines Workloads dynamisch skaliert werden. Anstatt zu berechnen, wie viele v für Ihre Anwendung benötigt CPUs werden, können Sie mit Neptune Serverless Unter - und Obergrenzen für die Rechenkapazität (gemessen in Neptune-Kapazitätseinheiten) für die Instances in Ihrem DB-Cluster festlegen. Workloads mit schwankender Nutzung können hinsichtlich der Kosten optimiert werden, indem statt bereitgestellter Instances Serverless-Instances verwendet werden.

Sie können sowohl bereitgestellte als auch Serverless-Instances im selben DB-Cluster einrichten, um ein optimales Kosten-Leistungs-Verhältnis zu erzielen.