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 Compute (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 CPU v-Ressourcen zugewiesen, um zwei (2) Threads zur Abfrageausführung pro v zu unterstützen. CPU 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 vCPUs benötigten Abfragen 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
Anmerkung
SPARQLAbfragen, 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 von,, oder oder oder beobachtet werden /gremlin/status /oc/status /sparql/statusAPIs, 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 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.
Wenn Sie auf ein OutOfMemoryException (OOM) stoßen, sollten Sie mehr Thread-Speicher hinzufügen. OOMAusnahmen treten auf, wenn ein Thread mehr als den ihm zugewiesenen maximalen Speicher benötigt (dies ist nicht dasselbe, als ob der gesamten Instanz der Speicher ausgeht).
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
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
DEPRECATED— Die r4 Familie wurde bei der Markteinführung von Neptune im Jahr 2018 angeboten, aber jetzt bieten neuere Instance-Typen ein viel besseres Preis-/Leistungsverhä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 vCPUs und 32 GiB Arbeitsspeicher) doppelt so viel Speicher wie ein r5.large (2 vCPUs und 16 GiB Arbeitsspeicher), vCPUs und ein r5.2xlarge (8 vCPUs und 64 GiB Arbeitsspeicher) hat doppelt so viel Speicher wie ein. vCPUs r5.xlarge Die Abfrageleistung wird direkt entsprechend der Rechenleistung bis zum Instance-Typ r5.12xlarge skaliert.
Die r5 Instance-Familie hat eine Intel-Architektur mit zwei Sockeln. CPU 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 NVMe r5d Instance-Typ angehängten EBS Volumes implementiert. 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 Prozessor namens Gravitonr6g-Familie verwendet den Graviton2-Prozessor. In unseren Tests bietet der Graviton2-Prozessor eine um 10 bis 20% bessere Leistung für (eingeschränkte) Grafikabfragen im G-Stil. OLTP Größere Abfragen können mit Graviton2-Prozessoren jedoch etwas weniger leistungsfähig sein als mit OLAP 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
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 r5 r6g OR-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 r5 r6g Instance-Typen mit geringer CPU Auslastung und einer hohen Ausfallrate beim Pufferpool-Cache sind, versuchen Sie stattdessen, die x2g Familie zu verwenden. Auf diese Weise erhalten Sie den zusätzlichen Speicher, den Sie benötigen, ohne für mehr Kapazität bezahlen zu müssen. CPU
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 für Ihre Anwendung benötigt vCPUs 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.
