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.
# Bewährte betriebliche Verfahren für ISVs
Bei vielen der Richtlinien in diesem Abschnitt handelt es sich um bewährte Methoden für alle Kunden, für die sie jedoch an Bedeutung gewonnen haben. ISVs
## Aktualisiere deinen Neptun-Cluster mit den neuesten Versionen
In den [Versionshinweisen](https://docs.aws.amazon.com/neptune/latest/userguide/engine-releases.html) zu Amazon Neptune können Sie sehen, dass jede Version eine Reihe von Fehlerkorrekturen, Leistungsverbesserungen und neuen Funktionen enthält. Halten Sie Ihre Neptun-Cluster so weit wie möglich auf der neuesten Version.
Wenn Sie einen bisher unentdeckten Fehler in Ihrem Workload finden und Ihr Cluster die neueste Version verwendet, können die Neptune-Techniker einen privaten Patch für Ihren Cluster erstellen (sofern dies gerechtfertigt ist und Sie ihn wünschen). Der Patch kann bis zur nächsten Version überbrücken, wenn dieser Fix allgemein verfügbar sein wird. Verwenden Sie die [Neptune Blue/Green-Lösung](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-BG-deployments.html), um Ihre Cluster auf die neueste Version zu aktualisieren.
## Verwenden Sie Deltas anstelle von Löschen und Ersetzen für die Datenaufnahme
Sie können verschiedene Techniken verwenden, um Daten aufzunehmen oder in Neptune zu schreiben. Viele Kunden versuchen, ihre Datenaufnahme zu vereinfachen, indem sie ihr Diagramm jedes Mal löschen und erneut einfügen, wenn eine Änderung im Feed eingeht. Sie können jedem Knoten eine `last-modified` Eigenschaft hinzufügen und in regelmäßigen Abständen nach Knoten suchen, die seit einem bestimmten Datum nicht geändert wurden, und sie löschen. Diese Techniken vereinfachen zwar den Datenaufnahmeprozess, haben aber langfristige Auswirkungen auf den Zustand und die Skalierbarkeit Ihres Neptune-Clusters.
Erstens verwendet Neptune die [Wörterbuchkodierung von Zeichenketten](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-data-model.html#feature-overview-storage-dictionary). Sofern Sie die IDs Knoten und Kanten nicht explizit angeben, generiert Neptune eine GUID, die als Zeichenfolge für die ID dargestellt wird, und speichert diese Zeichenfolge im Wörterbuch. Wenn Sie ständig Objekte löschen und hinzufügen, führt das automatisch generierte IDs Objekt zu einer Aufblähung des Wörterbuches.
Zweitens skaliert Neptune so, dass er maximal etwa 120.000 Objekte pro Sekunde aufnimmt. Wenn Sie kontinuierlich Objekte löschen und hinzufügen, verbrauchen Sie einen Großteil dieser Bandbreite für Objekte, die sich im Grunde nicht ändern. Dies begrenzt die Anzahl der Mandanten, die Sie in einem Cluster hosten können, erfordert größere Writer-Instances in den Clustern und erfordert mehr I/O Operationen. All diese Faktoren erhöhen Ihre Kosten.
Wir empfehlen Ihnen dringend, eine Methode zur Berechnung des tatsächlichen Deltas der Änderungen zu entwickeln, anstatt die Methoden Löschen und Hinzufügen zu verwenden. Einige Datenquellen sind dafür jedoch nicht geeignet (z. B. API-Aufrufe, die den aktuellen Status zurückgeben, oder Ereignisse, die nicht genau nachverfolgen, was sich geändert hat). Wenn Ihre Rohdatenquelle nicht geeignet ist, Änderungen zu identifizieren, verwenden Sie Ihre ETL-Prozesse (Extrahieren, Transformieren und Laden), um das Delta zu berechnen. Sie können beispielsweise Schnappschüsse von jeder vorherigen Datenerfassung im Parquet-Format verwalten, die Unterschiede zwischen diesen Schnappschüssen berechnen und nur die Unterschiede an Neptune übertragen. AWS Glue
## Modellieren Sie, wie sich die Neptun-Kosten mit Ihren Mietern entwickeln
Unabhängig davon, ob Sie ein Silo-, Pool- oder Hybridmodell verwenden, werden Ihre Cloud-Kosten mit der Größe Ihrer Mieter skalieren. Mandanten, die mehr gleichzeitige Verbindungen benötigen, benötigen größere Instanzen oder mehr Read Replicas als Mandanten mit weniger gleichzeitigen Verbindungen. Das Gleiche gilt für Mandanten, die eine schnellere Datenaufnahme benötigen.
Die drei Komponenten der Neptune-Clusterkosten sind Instanzgröße (und Anzahl), Datengröße (GB-Monate) und I/O Operationen (pro Million). Diese Kosten sind zwar im Allgemeinen auslastungsspezifisch, sie skalieren jedoch mit der Größe und dem Datenvolumen und können mithilfe von Tools gemessen werden. AWS Verfolgen und verstehen Sie die Skaleneffekte anhand von Schlüsselindikatoren für die Größe Ihrer Mieter, einschließlich der Art und Weise, wie sich ihre Größe im Laufe der Zeit verändert. Wenn sich die Unvorhersehbarkeit Ihrer I/O Gebühren auf Ihre Margen auswirkt, sollten Sie erwägen, sich für [I/O-optimierten Speicher von Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/storage-types.html) zu entscheiden, um vorhersehbarere Kosten zu erzielen.
## Skalieren Sie Ihre Cluster entsprechend der Kundennachfrage
Es gibt keine bewährte Formel für die richtige Größe Ihrer Neptune-Instanzgröße. Die [Neptun-Dokumentation](https://docs.aws.amazon.com/neptune/latest/userguide/instance-types.html) bietet Hinweise, aber es gibt zu viele Variablen, um eine direkte Zuordnung zu empfehlen. Zu diesen Variablen gehören unter anderem die folgenden:
+ Datenmodell
+ Form der Daten
+ Gleichzeitigkeit von Abfragen
+ Komplexität der Abfrage.
Planen Sie Tests, um die optimale Größe für Ihre Workloads und Mandantenprofile zu ermitteln. Im Allgemeinen empfehlen wir die Verwendung bereitgestellter Instanzen aus Gründen der Kosteneffizienz und Vorhersehbarkeit. Wenn Ihre Kundenerlebnisziele der optimalen Skalierung Vorrang vor den Kosten einräumen, sollten Sie die Verwendung von [Neptune Serverless Instances](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless.html) in Betracht ziehen, um unabhängig von Workload-Schwankungen ein einheitlicheres Erlebnis zu gewährleisten.
[Wenn Ihre Tenant-Lese-Workloads erhebliche Schwankungen in ihren Höhen und Tiefen aufweisen, kombinieren Sie Neptune Serverless Instances mit Neptune auto-scaling.](https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-autoscaling.html) In der Regel dauert es 10 bis 15 Minuten, bis eine neue Read Replica nach der Initialisierung online ist. Das bedeutet, dass die auto-scaling allein lang anhaltende Verkehrsänderungen bewältigen kann, für sich schnell ändernde Aktivitätsspitzen jedoch nicht ausreicht. Durch die Kombination von Neptune Serverless und Neptune auto-scaling können Sie sowohl Instances nach oben oder unten skalieren als auch die Anzahl der Read Replicas ein- und ausschalten.
Wenn Ihre Mandanten deutlich unterschiedliche Workload-Profile oder Service Level Agreements (SLAs) haben, sollten Sie erwägen, [benutzerdefinierte Endpunkte](https://docs.aws.amazon.com/neptune/latest/userguide/feature-custom-endpoint-membership.html) und dedizierte Read Replicas zu verwenden, um den Traffic an Instanzen weiterzuleiten, die für diesen Traffic optimiert sind. Die Optimierung kann eine andere Größe der Instanz, bestimmte Abfragemuster oder das Vorwärmen des Puffer-Caches beinhalten.