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.

Säule der Kostenoptimierung

Die Säule der Kostenoptimierung des AWS Well-Architected Framework konzentriert sich auf die Vermeidung unnötiger Kosten. Die folgenden Empfehlungen können Ihnen helfen, die Entwurfsprinzipien zur Kostenoptimierung und die bewährten Architekturpraktiken für Amazon Neptune zu erfüllen.

Die Säule Kostenoptimierung konzentriert sich auf die folgenden Schlüsselbereiche:

Verstehen Sie die Nutzungsmuster und die benötigten Dienste

Neptune eignet sich gut für Ihren Workload, wenn Ihr Datenmodell eine erkennbare Graphstruktur hat und Ihre Abfragen Beziehungen untersuchen und mehrere Hops durchlaufen müssen. Eine Graphdatenbank eignet sich nicht für die folgenden Muster:

Überlegen Sie, ob die gemeinsame Verwendung mehrerer speziell entwickelter Datenbanken für bestimmte Zugriffsmuster all Ihre Anforderungen erfüllen könnte. Beispiel:

Machen Sie sich mit den Kosten vertraut, die mit Diensten verbunden sind, die mit Neptune interagieren und diese ergänzen, einschließlich der folgenden:

Wählen Sie Ressourcen unter Berücksichtigung der Kosten aus

Die Neptune-Preise basieren auf den stündlichen Instanzkosten (oder den Verbrauch von Neptune-Recheneinheiten bei serverlosem Betrieb), Daten-I/O und Speichernutzung. Instanzen machen im Durchschnitt 85 Prozent der Gesamtkosten aus, sodass die richtige Dimensionierung erhebliche Auswirkungen auf die Kosten haben kann. Die beste Methode zur richtigen Größe von Instances besteht darin, die Anwendungsleistung auf einer Vielzahl von Instances zu testen und die folgenden Faktoren zu vergleichen:

Die Instanzkosten innerhalb derselben Instance-Familie skalieren linear mit der Größe. Die Stundenkosten der db.r6i.2xlarge Instance sind doppelt so hoch wie die der db.r6i.xlarge Instance und haben zudem die doppelte Ressourcenzuweisung. Die db.r6i.24xlarge Instanz kostet das 24-fache der stündlichen Kosten der db.r6i.xlarge Instanz.

Schätzen Sie die Anzahl der gleichzeitigen Abfragen, die Sie unterstützen müssen. Sie können zwischen null und fünfzehn Read Replicas für die Verarbeitung schreibgeschützter Abfragen verwenden. Wenn Ihre Anforderungen je nach Tages-, Wochen- oder Monatszeit variieren, können Sie mehrere kleinere Instances verwenden, um nach einem Zeitplan zu skalieren. Jede vCPU auf einer Instanz stellt zwei Threads für die Verarbeitung gleichzeitiger Abfragen bereit. Drei db.r6i.xlarge Read Replicas mit jeweils 4 vCPUs können 24 gleichzeitige Abfragen verarbeiten.

Wenn Ihr Datenverkehrsvolumen stattdessen in Abfragen pro Sekunde (QPS) gemessen wird, müssen Sie experimentieren, um die durchschnittliche Latenz Ihrer Abfragen zu ermitteln. Die Anzahl der Abfragen pro Sekunde, die ein Neptun-Cluster unterstützen kann, entspricht. vCPU × 2 × (1 second/average query latency) Wenn Sie beispielsweise über 4 vCPUs und eine Abfragelatenz von 100 Millisekunden (0,1 Sekunden) verfügen,. QPS = 4 × 2 × (1s/0.1s) = 80 queries per second

Für kontinuierliche, stabile und vorhersehbare Workloads sind bereitgestellte Instanzen günstiger als serverlose Instanzen. Serverless bietet Möglichkeiten zur Kostenoptimierung, wenn Sie eine Arbeitslast haben, die nur wenige Stunden pro Tag sehr stark ausgelastet ist (z. B.db.r6i.4xlarge) und dann für den Rest des Tages fast keinen Verkehr erfordert (z. B. 1 Neptune Compute Unit). Eine serverlose Instanz, die für einige Stunden hochskaliert und dann wieder heruntergefahren wird, ist günstiger als die ganztägige Nutzung einer bereitgestellten db.r6i.4xlarge Instanz.

Erwägen Sie ein Upgrade auf Neptune 1.4.5.0 oder höher und die Nutzung von r8g Instances, um einen besseren Lese- und Schreibdurchsatz zu geringeren Kosten als Instances älterer Generationen wie oder zu erzielen. r7g r6g Weitere Informationen finden Sie unter 4,7-mal besseres Preis-Leistungs-Verhältnis beim Schreiben von Abfragen mit AWS Graviton4 R8g-Instances mit Amazon Neptune v1.4.5 (Blogbeitrag).AWS

Neptune-Cluster werden standardmäßig mit Standardspeicher erstellt (wenn Sie sie mit der Konsole erstellen, wählt sie standardmäßig I/O-optimized storage). With I/O-optimized storage, you pay a slightly higher cost for storage and instances, but there are no I/O costs. This leads to more predictable recurring costs, but if your I/O usage is generally low, it may be more cost efficient to utilize standard storage. If you intend to load a lot of data initially, you can optimize cost by choosing I/O -optimierten Speicher aus, führt den ersten Datenladevorgang durch und wechselt dann zum Standardspeicher. Der Speichertyp wirkt sich nur auf das Abrechnungsmodell aus und hat keinen technischen Unterschied in der Neptune-DB-Cluster- oder Instance-Konfiguration. Sie können den Speichertyp einmal alle 30 Tage ändern. Überprüfe nach 30 Tagen deine detaillierten Neptun-Kosten und berechne anhand der Neptune-Preisseite, ob deine Kosten mit -optimized höher gewesen wären. I/O-optimized storage. If they would have been, continue to use standard storage, otherwise switch back to I/O

Wählen Sie die beste Neptune-Instanzkonfiguration für Ihren Workload

Wenn du dein Spiel AWS-Konto vor dem 15. Juli 2025 erstellt hast, kannst du das AWS kostenlose Kontingent für Experimente mit Neptune auf Einstiegsebene nutzen. Die 750 kostenlosen Stunden db.t3.medium und die Nutzung der db.t4g.medium Instanzen reichen aus, um Neptune in geringem Umfang gut zu verstehen. Ihr Cluster bleibt auch nach Ablauf der kostenlosen Testphase bestehen, obwohl Ihnen ab diesem Zeitpunkt die Nutzung in Rechnung gestellt wird.

Die db.t4g.medium Instanzen db.t3.medium und eignen sich gut für kostengünstige Entwicklungsumgebungen, in denen Sie OpenCypher, Graph Explorer oder verschiedene generative KI-Integrationen nicht verwenden. Diese Instanzen haben ein kleineres RAM-to-vCPU Verhältnis (2:1) als die R Familieninstanzen (8:1) oder X Familieninstanzen (16:1). Dies reduziert das Verhältnis und verhindert die Verwendung von Statistiken der DFE-Engine, die die Leistung von OpenCypher, GenAI-Integrationen (um das LLM über das Graphschema zu informieren) und Graph Explorer. Bei der Verwendung von T Familieninstanzen können sich die Leistungsprofile erheblich unterscheiden, insbesondere bei den zuvor genannten Workloads. Diese Instanzen können auch dazu führen, dass Abfragen häufiger vorkommenOutOfMemoryExceptions, wenn sie sich über einen wesentlichen Teil des Diagramms bewegen. Überprüfen Sie die BufferCacheHitRatio CloudWatch Metrik, um festzustellen, ob die letztgenannte Bedingung betroffen sein könnte.

Wir raten dringend davon ab, Leistungs- oder Lasttests mit T Familieninstanzen durchzuführen, da es zu inkonsistenten Ergebnissen kommen kann, die nicht auf eine Produktionsumgebung hinweisen.

Bereitgestellte Instanzen bieten Ihnen die beste Kombination aus Kosten und Leistung, wenn Ihre Arbeitslast relativ stabil und vorhersehbar ist. Wählen Sie die Instanzgröße auf der Grundlage der erforderlichen Parallelität der Anfragen und der Komplexität der Abfrage. Für eine höhere Parallelität ist mehr v erforderlich. CPUs Eine höhere Abfragekomplexität erfordert mehr RAM. Ermitteln Sie anhand der MainRequestQueuePendingRequests CloudWatch Metrik, wie sich Ersteres auswirkt (ein Wert größer als Null steht für mehr gleichzeitige Anfragen, als bearbeitet werden können). Verwenden Sie die BufferCacheHitRatio CloudWatch Metrik, um die Auswirkung der letzteren zu ermitteln. Ein Verhältnis, das häufig unter 99,9 Prozent fällt, deutet darauf hin, dass nicht genug RAM vorhanden ist, um den aktiven Teil des auszuwertenden Diagramms aufzunehmen, was zu häufigerem Cache-Swapping führt. Wenn die R-Instance-Familie ausreichend Parallelität, aber nicht genug RAM bietet, sollten Sie die X Instance-Familie ausprobieren.

Ideale Anwendungsfälle für serverlose Instanzen sind in der Neptune-Dokumentation beschrieben. Wenn Sie sich nicht sicher sind, ob bereitgestellte oder serverlose Workloads für Sie am besten geeignet sind und die Kosten Ihr Hauptanliegen sind, testen Sie Ihren Workload im serverlosen Modus, um die Anzahl der NCUs genutzten Workloads zu ermitteln und die Kosten für bereitgestellte () mit denen von serverlos () zu vergleichen. N hours × hourly provisioned cost sum of NCUs × hourly cost per NCU Wenn Sie sich nicht sicher sind, welche Provision-Instanz die entsprechende Größe hat, entspricht eine NCU etwa 2 GB RAM und der zugehörigen vCPU und dem Netzwerk. Wenn Ihre bereitgestellte Instanz aus der r6i Familie stammt, beträgt das Verhältnis 1 vCPU pro 8 GB RAM oder 4 NCUs, zusammen mit dem zugehörigen Netzwerk. Der Amazon Neptune Neptune-Preisrechner bietet auch einen Vergleich, der Ihnen bei der Entscheidung für Ihre optimale Kostenkonfiguration hilft.

Wenn Sie Serverless für Primär- und Replikat-Instances verwenden, denken Sie daran, dass Read Replicas der Promotion-Stufen 0 und 1 entsprechend der Writer-Instance skaliert werden, sodass sie bei einem Failover-Ereignis ordnungsgemäß skaliert werden. NCUs Legen Sie Ihre NCU-Grenzwerte für diese Instances danach fest, welche Ihrer Instances — Writer oder Reader — den meisten Traffic erhalten.

In Umgebungen, in denen der Cluster nicht 24 Stunden am Tag, 7 Tage die Woche benötigt wird, sollten Sie in Erwägung ziehen, Skripte zu schreiben, die die Neptune-Instanzen ausschalten, wenn sie nicht verwendet werden, und sie erneut starten, bevor sie verwendet werden. Neptune-Instanzen werden automatisch alle 7 Tage neu gestartet, um sicherzustellen, dass die erforderlichen Wartungsupdates installiert werden. Wenn Sie beabsichtigen, die Instanzen für längere Zeit ausgeschaltet zu lassen, verwenden Sie ein wöchentliches Skript, um sie wieder herunterzufahren.

Datenspeicherung und -übertragung in der richtigen Größe

Effizientere Abfragen (z. B. Abfragen, die weniger Knoten, Kanten und Eigenschaften im Diagramm berühren müssen) erfordern weniger I/O Übertragung und können möglicherweise kleinere Instanzen verwenden, da weniger Puffer-Cache erforderlich ist. Verwenden Sie das Profil oder die Explain-Endpunkte für Ihre Abfragesprache, um Ihre Abfrage zu optimieren, und ziehen Sie in Betracht, Ihr Grafikmodell im Hinblick auf Ihre Abfrageleistung zu optimieren.

Neptune verwendet die Wörterbuchkodierung für große Zeichenketten, und dieses Wörterbuch ist für Leistung und nicht für Effizienz optimiert. Wenn Sie große BLOBs, JSON-Zeichenketten oder häufig wechselnde Zeichenketten für Eigenschaften haben, sollten Sie erwägen, diese außerhalb von Neptune in Amazon S3, Amazon DynamoDB oder Amazon DocumentDB zu speichern und nur eine Referenz innerhalb des Neptune-Knotens zu speichern.

In einigen Fällen kann es günstiger sein, eine größere Instance-Größe zu wählen. Wenn Ihre I/O Kosten aufgrund einer niedrigen Version sehr hoch sindBufferCacheHitRatio, ist es möglich, dass der größere Puffer-Cache diese Kosten erheblich reduzieren würde. Das liegt daran, dass alle Daten in den Cache passen würden, anstatt häufig aus dem Speicher ausgelagert zu werden und die I/O Übertragungsrate zu erhöhen.

Neptune verwendet copy-on-write Klonen. Beim Klonen, um ein Diagramm in mehrere Shards aufzuteilen, ist es möglicherweise effizienter, die unerwünschten Daten auf dem geklonten Cluster nicht zu löschen, da dafür neue Datenseiten erstellt werden müssen, was zu erhöhten Speicherkosten führt. Daten, die gegenüber der Zeit vor dem Klonen unverändert geblieben sind, befinden sich auf einer einzigen Datenseite, die von den beiden Clustern gemeinsam genutzt wird, und es fallen nur Gebühren für diese einzelne Kopie an.

Aktivieren Sie den OSGP-Index nicht und verwenden Sie keine R5d-Instances, es sei denn, Sie haben getestet, um zu bestätigen, dass sie einen wesentlichen Unterschied in Ihrer Arbeitslast bewirken. Beide sind für selten auftretende Szenarien konzipiert und können Ihre Kosten erhöhen, wenn Sie nur minimale oder gar keine Gewinne erzielen.