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.
Auswahl von Instance-Typen für Amazon Neptune
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
Die verschiedenen in Neptune verwendeten Amazon-EC2-Instance-Typen und -Größen stellen jeweils eine definierte Menge an Rechenleistung (vCPUs) und Systemspeicher bereit. 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 benötigten vCPUs wie folgt schätzen, wobei die Latenz als durchschnittliche Abfragelatenz in Sekunden und die Gleichzeitigkeit als gewünschte Anzahl von Abfragen pro Sekunde gemessen wird:
vCPUs = (latency x concurrency) / 2
Anmerkung
SPARQL-Abfragen, openCypher-Abfragen und Gremlin-Leseabfragen, die die DFE-Abfrage-Engine verwenden, können unter bestimmten Umständen mehr als einen Ausführungsthread pro Abfrage verwenden. Sie sollten bei der anfänglichen Dimensionierung Ihres DB-Clusters annehmen, dass jede Abfrage einen einzelnen Ausführungsthread pro Ausführung nutzt, und dies hochskalieren, wenn Sie einen Gegendruck in Richtung der Abfragewarteschlange beobachten. Dies kann mithilfe der/gremlin/status, oder /sparql/status APIs beobachtet werden/oc/status, oder es kann auch anhand der MainRequestsPendingRequestsQueue CloudWatch Metrik beobachtet werden.
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 werden für den Pufferpool-Cache reserviert. Buffer-pool Cache wird verwendet, um die zuletzt verwendeten Komponenten des Diagramms zwischenzuspeichern, um bei Abfragen, die wiederholt auf diese Komponenten zugreifen, einen schnelleren Zugriff zu ermöglichen. 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 Messwerte 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.)
t3 - und t4g-Instance-Typen
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-Kontingent in Frage
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.
VERALTET — Die r4 Familie wurde bei der Markteinführung von Neptune im Jahr 2018 angeboten, aber jetzt bieten neuere Instance-Typen viel bessere Möglichkeiten. price/performance Ab Engine-Version 1.1.0.0 unterstützt Neptune die r4-Instance-Typen nicht mehr.
Instanztypen der r5-Familie
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. Beispielsweise hat eine r5.xlarge-Instance (4 vCPUs und 32 GiB Arbeitsspeicher) doppelt so viele vCPUs und doppelt so viel Arbeitsspeicher wie eine r5.large-Instance (2 vCPUs und 16 GiB Arbeitsspeicher). Eine r5.2xlarge-Instance (8 vCPUs und 64 GiB Arbeitsspeicher) hat doppelt so viele vCPUs und doppelt so viel Arbeitsspeicher wie eine r5.xlarge-Instance. 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.
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 NVMe-attached EBS-Volumes auf einem r5d Instance-Typ implementiert. Er wird über die Parametergruppe eines Clusters aktiviert. Wenn Daten aus dem indizierten Neptune-Speicher abgerufen werden, werden Eigenschaftswerte und RDF-Literale in diesem NVMe-Volume zwischengespeichert.
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.
Instanztypen der r6g-Familie
AWS hat einen eigenen ARM-based Prozessor namens Graviton entwickeltr6g-Familie verwendet den Graviton2-Prozessor. In unseren Tests bietet der Graviton2-Prozessor eine um 10-20% bessere Leistung für OLTP-style (eingeschränkte) Grafikabfragen. Größere OLAP-ish Abfragen sind mit den Graviton2-Prozessoren jedoch möglicherweise etwas weniger leistungsstark als mit Intel-Prozessoren, was auf die etwas geringere Leistung beim Speicher-Paging 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.
Instance-Typen der r6i-Familie
Amazon R6i-Instances
Instanztypen der x2g-Familie
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. Die x2g-Familie hat ein größeres Arbeitsspeicher-vCPU-Verhältnis als die r5- oder r6g-Familie. Die x2g-Instances nutzen ebenfalls den Graviton2-Prozessor und besitzen viele Leistungsmerkmale der r6g-Instance-Typen sowie einen größeren Pufferpool-Cache.
Wenn Sie unsere r6g Instance-Typen mit niedriger CPU-Auslastung und einer hohen Fehlerrate 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.
Instance-Typen der x2iezn-Familie
Die x2iezn Familie bietet speicheroptimierte Instances, die auf skalierbaren Intel Xeon Prozessoren mit hoher Frequenzleistung basieren. Diese Instances bieten ein hohes Verhältnis von Arbeitsspeicher zu vCPU (32 GiB pro vCPU) und eignen sich daher gut für speicherintensive Graph-Workloads, die von einer hohen Single-Thread-Leistung profitieren.
Zu den wichtigsten Funktionen gehören eine All-Core-Turbofrequenz von bis zu 4,5 GHz und die Verfügbarkeit in Größen von 2xlarge bis 12xlarge.
Instance-Typenfamilie x2iedn
Die x2iedn Familie bietet speicheroptimierte Instances mit lokalem NVMe-SSD-Speicher. Diese Instances kombinieren eine hohe Speicherkapazität (32 GiB pro vCPU) mit schnellem lokalen Speicher und eignen sich daher ideal für Graph-Workloads, die sowohl von großen In-Memory-Caches als auch von leistungsstarkem lokalem Festplatten-Caching profitieren.
Diese Instances werden von Intel Xeon Scalable-Prozessoren der dritten Generation angetrieben und sind in Größen von Xlarge bis 32xlarge erhältlich. Sie sind für umfangreiche Graphdatenbanken optimiert, die sowohl Arbeitsspeicher als auch Speicherleistung benötigen.
Instance-Typen der r8g-Familie
Die r8g Familie umfasst speicheroptimierte Instance-Typen, die auf Graviton4-Prozessoren basieren. AWS 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-20% bessere Leistung bei Grafikabfragen.
Die r8g Familie verwendet eine Dual-Socket-Plattform. Instance-Typen von r8g.large bis zur r8g.24xlarge Ausführung auf einem einzigen Socket, was bedeutet, dass die Leistung linear mit der Rechenkapazität in diesem Bereich skaliert wird. Der r8g.48xlarge verwendet beide Sockets und ist der größte Instance-Typ in der Familie. Wie bei anderen Dual-Socket-Familien sind die Leistungssteigerungen bei der Skalierung von r8g.24xlarge bis r8g.48xlarge möglicherweise nicht perfekt linear, da die Speicherverwaltung zwischen den Sockets erfordert.
Zu den wichtigsten Merkmalen der r8g Produktfamilie gehören:
Angetrieben von AWS Graviton4-Prozessoren ARM-based
Höhere Speicherbandbreite pro vCPU im Vergleich zu früheren Generationen
Hervorragendes price/performance Verhältnis sowohl für OLTP-style (eingeschränkte) Grafikabfragen als auch für analytische Workloads OLAP-style
Verbesserte Speicherverwaltungsfunktionen, die komplexen Graphdurchläufen zugute kommen
Die r8g Produktfamilie 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.
Instanztypen der r7g-Familie
Die r7g Familie verwendet den AWS Graviton3-Prozessor, der eine bessere price/performance Leistung bietet als frühere Instances. Graviton2-based In Tests bietet der Graviton3-Prozessor im Vergleich zu r6g-Instances eine 25-30% bessere Leistung bei OLTP-style 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 bis A skaliert wird r7g.16xlarge (der r7g.large größte Typ der Familie).
Zu den wichtigsten Merkmalen der r7g Produktfamilie gehören:
Angetrieben von AWS Graviton3-Prozessoren ARM-based
Verbesserte Speicherauslagerungsleistung im Vergleich zu r6g, was sowohl OLTP- als auch OLAP-Workloads zugute kommt
Verbesserte Effizienz des Pufferpool-Cache
Niedrigere Latenz für speicherintensive Operationen
Die r7g Produktfamilie eignet sich gut für Produktionsumgebungen mit unterschiedlichen Abfragemustern und ist besonders effektiv für Workloads, die von einer verbesserten Speicherbandbreite profitieren.
Instance-Typen der r7i-Familie
Die r7i Familie wird von skalierbaren Intel Xeon Prozessoren der 4. Generation (Codename Sapphire Rapids) angetrieben und bietet deutliche Verbesserungen gegenüber r6i-Instances. Diese Instances bieten 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:
Angetrieben von skalierbaren Intel Xeon Prozessoren der 4. Generation
Die Leistung skaliert linear mit einer Rechenkapazität von bis zu r7i.12xlarge
Verbesserte Speicherverwaltung zwischen physischen Prozessoren in der 2-Socket-Architektur
Verbesserte Leistung für speicherintensive Grafikoperationen
Für all diese Instance-Familien können Sie die Anzahl der benötigten vCPUs anhand derselben zuvor genannten Formel schätzen:
vCPUs = (latency x concurrency) / 2
Wobei die Latenz als durchschnittliche Abfragelatenz in Sekunden und die Parallelität als Zielanzahl von Abfragen pro Sekunde gemessen wird.
Serverloser Instanztyp
Mittels des Features Neptune Serverless kann die Instance-Größe anhand der Ressourcenanforderungen eines Workloads dynamisch skaliert werden. Anstatt zu berechnen, wie viele vCPUs für Ihre Anwendung benötigt werden, können Sie mit Neptune Serverless die unteren und oberen Rechenkapazitätsgrenzwerte (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.
