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.
Amazon Neptune Engine Version 1.4.0.0 (06.11.2020)
Ab 2024-11-06 wird die Engine-Version 1.4.0.0 allgemein bereitgestellt. Bitte beachten Sie, dass es mehrere Tage dauert, bis eine neue Version in jeder Region verfügbar ist.
Anmerkung
Mit der Engine-Version 1.3.0.0 wurde ein neues Format für benutzerdefinierte Parametergruppen und benutzerdefinierte Cluster-Parametergruppen eingeführt. Wenn Sie ein Upgrade von einer Engine-Version vor 1.3.0.0 auf Engine-Version 1.3.0.0 oder höher durchführen, müssen Sie daher alle vorhandenen benutzerdefinierten Parametergruppen und benutzerdefinierten Cluster-Parametergruppen mithilfe der Parametergruppenfamilie neu erstellen. neptune1.3 In früheren Versionen wurde die Parametergruppenfamilie neptune1 oder neptune1.2 verwendet. Diese Parametergruppen funktionieren nicht mit Version 1.3.0.0 und höher. Ebenso sollten Sie 1.4.0.0-Cluster-Parametergruppen für Engine-Versionen 1.4.0.0 und höher verwenden. Weitere Informationen finden Sie unter Amazon-Neptune-Parametergruppen.
Warnung
Der Abfrageplan-Cache wird für den Anwendungsfall der Ausführung parametrisierter Abfragen mit numerischen Parameterwerten vorübergehend nicht unterstützt, da ein Fehler bei der Behandlung der doppelten Verwendung eines numerischen Parameters in der Abfrage aufgetreten ist. Beispiel:
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n UNION MATCH (n:show) WHERE n.duration>=$minutes RETURN n parameters={"minutes":130}
Bei Abfragen, die viele Indexsuchen für Anweisungen oder Wörterbuchindizes durchführen, kann es zu einer Leistungsregression von 5% kommen. Das Abrufen der Anzahl aller Scheitelpunkte oder das Abrufen aller Scheitelpunkte wäre beispielsweise id davon nicht betroffen. Das Abrufen aller Eigenschaften aller Scheitelpunkte könnte zu einer Regression von bis zu 5% führen.
Neue Funktionen in dieser Engine-Version
-
Wenn einem Eigenschaftsdiagramm eine Kante ohne explizite ID hinzugefügt wird, weist der Server standardmäßig eine UUID-based Kanten-ID zu, die im Wörterbuch gespeichert wird. Durch Setzen eines neuen Cluster-Parameters weist der Server nun IDs mithilfe einer intern verwalteten 8-Byte-Ganzzahl zu, ohne dass ein Wörterbuchaufwand entsteht.
neptune_enable_server_generated_edge_id = 1Dies führt zu Speichereinsparungen und einer verbesserten Abfrageleistung, ohne dass Änderungen an den Abfragen vorgenommen werden müssen. Diese Funktion wird derzeit nur für Einfügungen in der Gremlin-Abfragesprache unterstützt. -
Unterstützung für die Ausführung von Gremlin-Limit () -Schritten in verschachtelten Traversalen für die DFE-Engine hinzugefügt.
g.V().project("foo").by(out().order().by(T.id).limit(1))
Verbesserungen in dieser Engine-Version
Allgemeine Verbesserungen
-
Neptune gibt automatisch Undo-Speicher zurück, der bei großen Transaktionen gespeichert wurde, sobald die Transaktion abgeschlossen ist und keine Logs mehr für die Wiederherstellung benötigt werden.
-
Unterstützung für ein überlebensfähiges Replikat der globalen Datenbank. Diese Funktion ermöglicht es dem sekundären Cluster, während eines Neustarts der Writer-Instance auf dem primären Cluster weiterhin Leseanforderungen zu bearbeiten. Bisher wurden beim Neustart einer Writer-Instanz auch alle Reader-Instances in einem sekundären Cluster neu gestartet. In dieser Version bearbeiten sekundäre Cluster-Reader-Instances während eines Neustarts der Writer-Instance weiterhin Leseanforderungen, wodurch die Leseverfügbarkeit im Cluster verbessert wird.
-
Audit-Logs werden jetzt synchron geschrieben, wodurch garantiert wird, dass jede Abfrage protokolliert wird. Dies kann die Leistung bei besonders großen Abfragen (>100 KB) oder Workloads mit hohem Durchsatz (>1000 qps) beeinträchtigen.
Verbesserungen bei Gremlin
-
Der Timeout pro Abfrage wird standardmäßig so erzwungen, dass er kleiner ist als der Timeout auf Clusterebene. In einer früheren Version wurde diese Prüfung eingeführt, musste aber explizit über den Labormodus-Parameter '' aktiviert werden. StrictTimeoutValidation In dieser Version ist 'StrictTimeoutValidation' standardmäßig aktiviert und muss explizit deaktiviert werden, um das alte Verhalten beizubehalten.
Verbesserungen bei OpenCypher
-
In einer früheren Version haben wir eine erweiterte Unterstützung für das Datetime-Format eingeführt, die über einen Lab-Modus-Parameter
DatetimeMillisecondaktiviert wurde. Diese erweiterte Unterstützung für Datetime-Formate ist jetzt standardmäßig aktiviert.
Verbesserungen bei SPARQL
-
Neue explizite IAM-Aktionen für Abfrageberechtigungen.
Previously: COPY: WriteDataViaQuery & ReadDataViaQuery MOVE: WriteDataViaQuery & DeleteDataViaQuery DELETEINSERT: ReadDataViaQuery & DeleteDataViaQuery Now, COPY: WriteDataViaQuery & ReadDataViaQuery & DeleteDataViaQuery MOVE: WriteDataViaQuery & ReadDataViaQuery & DeleteDataViaQuery DELETEINSERT: ReadDataViaQuery, WriteDataViaQuery if there is INSERT clause, DeleteDataViaQuery if there is DELETE clause.
In dieser Engine-Version wurden Fehler behoben
Allgemeine Korrekturen
-
Es wurde ein Problem mit serverlosen Instanzen behoben, das beim Hochskalieren zu einem Neustart der Datenbank führen konnte.
-
Es wurde ein Problem im Zusammenhang mit der Verwaltung von Audit-Logdateien behoben, das dazu führen konnte, dass Logdateien für den Download oder die Rotation nicht zugänglich waren und in einigen Fällen die CPU-Auslastung erhöhte.
-
Ein Abfrageproblem im Zusammenhang mit der Optimierung, das die Generierung der Kartenausgabe in der DFE-Engine verzögerte, wurde behoben.
-
Es wurde ein Problem behoben, das dazu führte, dass die Zeitstempel zwischen den Auditprotokollen und den Protokollen für langsame Abfragen nicht übereinstimmten.
Korrekturen für Gremlin
-
Es wurde ein Problem in der WebSocket Gremlin-Verbindungsverwaltung behoben, bei dem Abfragen, die für eine Zeit ausgeführt wurden, die den Timeout im Leerlauf der Verbindung überschritt, vorzeitig beendet wurden. Dies betraf insbesondere Python-Gremlin-Clients, die den AIOHTTP-Transport verwendeten.
OpenCypher-Korrekturen
-
Es wurde ein Problem im Sammelschritt behoben, das zu einer internen Fehlerausnahme führte, wenn während des Collect (distinct (n)) -Abfragekonstrukts Nullwerte vorhanden waren.
-
Es wurde ein Problem behoben, bei dem ein Fehler in Abfragen
NullPointerExceptionauftreten konnte, wenn der Abfrageplan-Cache aktiviert war. -
Es wurde ein Problem behoben, bei dem mehr Daten als nötig ausgewertet wurden, wenn eine Abfrage eine LIMIT-Klausel enthielt.
-
Es wurde ein Problem behoben, bei dem die Verwendung von Bereichsoperationen (<, <=, >, > =) in einer parametrisierten Abfrage mit einem Abfrageplan-Cache zu doppelten Ergebnissen führte.
-
Es wurde ein Problem behoben, bei dem Ergebnisspalten transponiert wurden, wenn UNION- und UNION ALL-Operationen mithilfe von Schraubverbindungen ausgeführt wurden.
Query-Language In dieser Version unterstützte Versionen
Stellen Sie vor dem Upgrade eines DB-Clusters auf Version 1.4.0.0 sicher, dass Ihr Projekt mit den folgenden Versionen der Abfragesprache kompatibel ist:
Die älteste unterstützte Version von Gremlin:
3.7.1Die neueste unterstützte Version von Gremlin:
3.7.1openCypher-Version:
Neptune-9.0.20190305-1.0SPARQL-Version:
1.1
Upgrade-Pfade zur Engine-Version 1.4.0.0
Sie können von der Engine-Version 1.2.0.0 oder höher auf diese Version aktualisieren.
Upgrade auf diesen Release
Wenn auf einem DB-Cluster eine Engine-Version ausgeführt wird, für die es einen Upgrade-Pfad zu dieser Version gibt, kann sie jetzt aktualisiert werden. Sie können jeden geeigneten Cluster mithilfe der DB-Cluster-Operationen auf der Konsole oder mithilfe des SDK aktualisieren. Mit dem folgenden CLI-Befehl wird ein geeignetes Cluster sofort aktualisiert:
Für Linux, OS X oder Unix:
aws neptune modify-db-cluster \ --db-cluster-identifier(your-neptune-cluster)\ --engine-version 1.4.0.0 \ --allow-major-version-upgrade \ --apply-immediately
Für Windows:
aws neptune modify-db-cluster ^ --db-cluster-identifier(your-neptune-cluster)^ --engine-version 1.4.0.0 ^ --allow-major-version-upgrade ^ --apply-immediately
Statt --apply-immediately können Sie --no-apply-immediately angeben. Für die Durchführung eines Hauptversions-Upgrades ist der allow-major-version-upgrade-Parameter erforderlich. Stellen Sie außerdem sicher, dass Sie die Engine-Version angeben, da Ihre Engine sonst möglicherweise auf eine andere Version aktualisiert wird.
Wenn Ihr Cluster eine benutzerdefinierte Cluster-Parametergruppe verwendet, müssen Sie diesen Parameter einschließen, um ihn zu anzugeben:
--db-cluster-parameter-group-name(name of the custom DB cluster parameter group)
Ebenso sollte für Instances im Cluster, die eine benutzerdefinierte DB-Parametergruppe verwenden, dieser Parameter eingeschlossen werden, um ihn zu spezifizieren:
--db-instance-parameter-group-name(name of the custom instance parameter group)
Testen Sie immer vor dem Upgrade
Wenn eine neue Haupt- oder Nebenversion der Neptune-Engine veröffentlicht wird, testen Sie Ihre Neptune-Anwendungen immer zuerst dafür, bevor Sie sie dazu aktualisieren. Selbst ein Nebenversions-Upgrade könnte neue Features oder Verhaltensweisen einführen, die sich auf Ihren Code auswirken können.
Vergleichen Sie zunächst die Seiten mit den Versionshinweisen Ihrer aktuellen Version mit denen der Zielversion, um festzustellen, ob es Änderungen an den Versionen der Abfragesprache oder andere wichtige Änderungen geben wird.
Die beste Methode, eine neue Version zu testen, bevor Sie Ihren Produktions-DB-Cluster aktualisieren, besteht darin, den Produktions-Cluster zu klonen, so dass auf dem Klon die neue Engine-Version ausgeführt wird. Sie können dann Abfragen auf dem Klon ausführen, ohne dass der Produktions-DB-Cluster davon betroffen wird.
Erstellen Sie vor einem Upgrade immer einen manuellen Snapshot
Bevor Sie ein Upgrade durchführen, wird dringend empfohlen, immer einen manuellen Snapshot Ihres DB-Clusters zu erstellen. Ein automatischer Snapshot bietet nur kurzfristigen Schutz, wohingegen ein manueller Snapshot verfügbar bleibt, bis Sie ihn explizit löschen.
In bestimmten Fällen erstellt Neptune im Rahmen des Upgrade-Prozesses einen manuellen Snapshot für Sie, aber Sie sollten sich nicht darauf verlassen und in jedem Fall Ihren eigenen manuellen Snapshot erstellen.
Wenn Sie sicher sind, dass Sie Ihren DB-Cluster nicht auf den Zustand vor dem Upgrade zurücksetzen müssen, können Sie den manuellen Snapshot, den Sie selbst erstellt haben, sowie den manuellen Snapshot, den Neptune möglicherweise erstellt hat, explizit löschen. Wenn Neptune einen manuellen Snapshot erstellt, hat dieser einen Namen, der mit preupgrade beginnt, gefolgt vom Namen Ihres DB-Clusters, der Quell-Engine-Version, der Ziel-Engine-Version und dem Datum.
Anmerkung
Wenn Sie versuchen, ein Upgrade durchzuführen, während eine ausstehende Aktion ausgeführt wird, kann ein Fehler wie der folgende auftreten:
We're sorry, your request to modify DB cluster (cluster identifier) has failed. Cannot modify engine version because instance (instance identifier) is running on an old configuration. Apply any pending maintenance actions on the instance before proceeding with the upgrade.
Wenn dieser Fehler auftritt, warten Sie, bis die ausstehende Aktion abgeschlossen ist, oder starten Sie sofort ein Wartungsfenster, damit das vorherige Upgrade abgeschlossen werden kann.
Weitere Informationen zum Upgraden Ihrer Engine-Version finden Sie unter Warten eines Amazon-Neptune-DB-Clusters. Wenn Sie Fragen oder Bedenken haben, steht Ihnen das AWS Support-Team in den Community-Foren und über den AWS Premium-Support zur Verfügung.