Version 1.2.0.0 du moteur Amazon Neptune (21/07/2022) - Amazon Neptune
Versions de correctifsNouvelles fonctionsAméliorationsDéfauts corrigésVersions de langage de requête prises en chargeChemins de mise à niveauMise à niveau

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Version 1.2.0.0 du moteur Amazon Neptune (21/07/2022)

Depuis le 21 juillet 2022, la version 1.2.0.0 du moteur est déployée globalement. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.

Note

En cas de mise à niveau à partir d'une version de moteur antérieure à 1.2.0.0 :

  • La version 1.2.0.0 du moteur implique un nouveau format pour les groupes de paramètres personnalisés et les groupes de paramètres de cluster personnalisés. Par conséquent, si vous effectuez une mise à niveau d'une version de moteur antérieure vers la version 1.2.0.0 ou une version supérieure, vous devrez recréer tous vos groupes de paramètres personnalisés et groupes de paramètres de cluster personnalisés existants à l'aide de la famille de groupes de paramètres neptune1.2. Les versions antérieures utilisaient une famille de groupes de paramètres neptune1, lesquels ne sont pas compatibles avec les versions 1.2.0.0 et supérieures. Pour plus d'informatons, consultez Groupes de paramètres Amazon Neptune.

  • La version 1.2.0.0 du moteur comprend également un nouveau format pour les journaux d'annulation. Par conséquent, tous les journaux d'annulation créés par une version antérieure du moteur doivent être purgés, et la métrique CloudWatch UndoLogsListSize doit tomber à zéro avant que toute mise à niveau depuis une version antérieure vers la version 1.2.0.0 puisse commencer. S'il existe trop d'enregistrements de journaux d'annulation (200 000 entrées ou plus) lorsque vous essayez de démarrer une mise à jour, la tentative de mise à niveau peut expirer en attendant que la purge des journaux d'annulation soit terminée.

    Vous pouvez accélérer le taux de purge en mettant à niveau l'instance d'enregistreur du cluster, où la purge a lieu. Suivre cette étape avant d'essayer de procéder à la mise à niveau contribue à réduire le nombre de journaux d'annulation avant de commencer. L'augmentation de la taille de l'enregistreur dans un type d'instance 24XL peut accroître le taux de purge, permettant ainsi de traiter plus d'un million d'enregistrements par heure.

    Si la métrique CloudWatch UndoLogsListSize est trop élevée, vous pouvez soumettre une demande d'assistance pour explorer d'autres stratégies afin de la réduire.

  • Enfin, une modification majeure a été apportée à la version 1.2.0.0. Celle-ci concerne le code antérieur qui utilisait le protocole Bolt avec l'authentification IAM. À partir de la version 1.2.0.0, Bolt a besoin d'un chemin de ressources pour la signature IAM. En Java, la définition du chemin de ressources peut ressembler à ceci : request.setResourcePath("/openCypher"));. Dans d'autres langages, /openCypher peut être ajouté à l'URI du point de terminaison. Pour obtenir des exemples, consultez Utilisation du protocole Bolt.

Versions de correctifs ultérieures pour cette version

Nouvelles fonctionnalités pour cette version du moteur

  • Ajout de la prise en charge des bases de données globales. Une base de données Neptune globale couvre plusieurs Régions AWS et se compose d'un cluster de bases de données principal dans une seule région et de jusqu'à cinq clusters de bases de données secondaires dans d'autres régions.

  • Ajout de la prise en charge d'un contrôle d'accès plus granulaire dans les politiques IAM Neptune que ce qui était disponible auparavant, sur la base des actions du plan de données. Il s'agit d'un changement radical dans la mesure où les politiques IAM existantes basées sur l'action connect obsolète doivent être ajustées pour utiliser les actions du plan de données plus granulaires. Consultez Types de IAM politiques.

  • Disponibilité améliorée des instances de lecteur. Auparavant, lors du redémarrage d'une instance d'enregistreur, toutes les instances de lecteur d'un cluster Neptune redémarraient également. À partir de la version 1.2.0.0 du moteur, les instances de lecteur restent actives après le redémarrage de l'instance d'enregistreur, ce qui améliore la disponibilité des instances de lecteur. Les instances de lecteur peuvent être redémarrées séparément pour prendre en compte les modifications apportées aux groupes de paramètres. Consultez Redémarrage d'une instance de base de données dans Amazon Neptune.

  • Ajout d'un nouveau paramètre de cluster de bases de données neptune_streams_expiry_days qui vous permet de définir le nombre de jours pendant lesquels les enregistrements de flux sont conservés sur le serveur avant d'être supprimés. Cette plage est comprise entre 1 et 90, et la valeur par défaut est 7.

Améliorations de cette version du moteur

  • Amélioration des performances de sérialisation Gremlin pour les requêtes ByteCode.

  • Neptune traite désormais les prédicats de texte à l'aide du moteur DFE, pour de meilleures performances.

  • Neptune traite désormais les étapes limit() Gremlin à l'aide du moteur DFE, y compris les limites de traversée hors terminal et enfant.

  • Modification de la gestion DFE de l'étape union() Gremlin pour qu'elle fonctionne avec d'autres nouvelles fonctionnalités, ce qui signifie que les nœuds de référence apparaissent dans les profils de requête comme prévu.

  • Performances améliorées jusqu'à cinq fois de certaines opérations de jointure coûteuses au sein du DFE en les parallélisant.

  • Ajout de la prise en charge de la modulation by() pour OrderGlobalStep order(global) pour le moteur DFE Gremlin.

  • Ajout de l'affichage des valeurs statiques injectées dans les détails de la fonctionnalité explain du DFE.

  • Amélioration des performances lors du nettoyage des modèles dupliqués.

  • Ajout de la prise en charge de la préservation des commandes dans le moteur DFE Gremlin.

  • Amélioration des performances des requêtes Gremlin comportant des filtres vides, par exemple :

    g.V().hasId(P.within([]))
    g.V().hasId([])

  • Amélioration des messages d'erreur lorsqu'une requête SPARQL utilise une valeur numérique trop grande pour que Neptune puisse la représenter en interne.

  • Amélioration des performances de la suppression de sommets associés à des arêtes en réduisant les recherches d'index lorsque les flux sont désactivés.

  • Prise en charge du DFE étendue à un plus grand nombre de variantes de l'étape has(), en particulier à hasKey(), hasLabel() et aux prédicats de plage pour les chaînes/URI dans has(). Cela concerne les requêtes telles que les suivantes :

    // hasKey() on properties
g.V().properties().hasKey("name")
g.V().properties().has(T.key, TextP.startingWith("a"))
g.E().properties().hasKey("weight")
g.E().properties().hasKey(TextP.containing("t"))

// hasLabel() on vertex properties
g.V().properties().hasLabel("name")

// range predicates on ID and Label fields
g.V().has(T.label, gt("person"))
g.E().has(T.id, lte("(an ID value)"))

  • Ajout d'une fonction openCypher join() spécifique à Neptune qui concatène les chaînes d'une liste en une seule chaîne.

  • Mise à jour des politiques gérées par Neptune afin d'inclure les autorisations d'accès aux données et les autorisations pour les nouvelles API de base de données globales.

Défauts corrigés dans cette version du moteur

  • Correction d'un bogue en raison duquel une requête HTTP sans type de contenu spécifié échouait automatiquement.

  • Correction d'un bogue SPARQL dans l'optimiseur de requêtes qui empêchait l'utilisation d'un appel de service dans une requête.

  • Correction d'un bogue SPARQL dans l'analyseur Turtle RDF à cause duquel une combinaison particulière de données Unicode provoquait un échec.

  • Correction d'un bogue SPARQL en raison duquel une combinaison particulière de clauses GRAPH et SELECT générait des résultats de requête incorrects.

  • Correction d'un bogue Gremlin qui provoquait un problème d'exactitude pour les requêtes utilisant n'importe quelle étape de filtre au sein d'une étape d'union, comme suit : 

    g.V("1").union(hasLabel("person"), out())

  • Correction d'un bogue Gremlin où la valeur count() de both().simplePath() multipliait par deux le nombre réel de résultats renvoyés sans count().

  • Correction d'un bogue openCypher en raison duquel une exception de non-correspondance de signature défectueuse était générée par le serveur pour les requêtes Bolt adressées aux clusters avec l'authentification IAM activée.

  • Correction d'un bogue openCypher où une requête utilisant HTTP keep-alive pouvait être fermée de manière incorrecte si elle était soumise après l'échec d'une demande.

  • Correction d'un bogue openCypher qui pouvait provoquer le déclenchement d'une erreur interne lorsqu'une requête renvoyant une valeur de constante était soumise.

  • Correction d'un bogue lié aux détails de la fonctionnalité explaon, de sorte que la sous-requête DFE Time(ms) additionne désormais correctement les temps CPU des opérateurs au sein de la sous-requête DFE. Prenons l'extrait suivant représentant la sortie de la fonctionnalité explain à titre d'exemple :

    subQuery1
╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗
║ ID │ Out #1 │ Out #2 │ Name                  │ Arguments                         │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║
╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣
  ...
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 1  │ 2      │ -      │ DFEChunkLocalSubQuery │ subQuery=...graph#336e.../graph_1 │ -    │ 1        │ 1         │ 1.00  │ 0.38      ║
║    │        │        │                       │ coordinationTime(ms)=0.026        │      │          │           │       │           ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
  ...
subQuery=...graph#336e.../graph_1
╔════╤════════╤════════╤═══════════════════════╤═══════════════════════════════════╤══════╤══════════╤═══════════╤═══════╤═══════════╗
║ ID │ Out #1 │ Out #2 │ Name                  │ Arguments                         │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║
╠════╪════════╪════════╪═══════════════════════╪═══════════════════════════════════╪══════╪══════════╪═══════════╪═══════╪═══════════╣
║ 0  │ 1      │ -      │ DFESolutionInjection  │ solutions=[?100 -> [-10^^<LONG>]] │ -    │ 0        │ 1         │ 0.00  │ 0.04      ║
║    │        │        │                       │ outSchema=[?100]                  │      │          │           │       │           ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 1  │ 3      │ -      │ DFERelationalJoin     │ joinVars=[]                       │ -    │ 2        │ 1         │ 0.50  │ 0.29      ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 2  │ 1      │ -      │ DFESolutionInjection  │ outSchema=[]                      │ -    │ 0        │ 1         │ 0.00  │ 0.01      ║
╟────┼────────┼────────┼───────────────────────┼───────────────────────────────────┼──────┼──────────┼───────────┼───────┼───────────╢
║ 3  │ -      │ -      │ DFEDrain              │ -                                 │ -    │ 1        │ 0         │ 0.00  │ 0.02      ║
╚════╧════════╧════════╧═══════════════════════╧═══════════════════════════════════╧══════╧══════════╧═══════════╧═══════╧═══════════╝

    Le total des durées des sous-requêtes dans la dernière colonne du tableau inférieur s'élève à 0,36 ms (.04 + .29 + .01 + .02 = .36). Lorsque vous ajoutez le temps de coordination de cette sous-requête (.36 + .026 = .386), vous obtenez un résultat proche de a durée de la sous-requête enregistrée dans la dernière colonne du tableau supérieur, à savoir 0.38 ms.

Versions de langage de requête prises en charge dans cette version

Avant de mettre à niveau un cluster de bases de données vers la version 1.2.0.0, assurez-vous que votre projet est compatible avec les versions de langage de requête suivantes :

  • Première version de Gremlin prise en charge : 3.5.2

  • Dernière version de Gremlin est prise en charge : 3.5.4

  • Version d'openCypher : Neptune-9.0.20190305-1.0

  • Version SPARQL : 1.1

Chemins de mise à niveau vers la version de moteur 1.2.0.0

Comme il s'agit d'une version majeure du moteur, la mise à niveau n'est pas automatique.

Vous ne pouvez effectuer une mise à niveau pour publier 1.2.0.0 manuellement qu'à partir de la dernière version de correctif du moteur 1.1.1.0. Les versions antérieures du moteur doivent d'abord être mises à niveau vers la dernière version 1.1.1.0 avant de pouvoir passer à la version 1.2.0.0.

Par conséquent, avant d'essayer de passer à cette version, veuillez vérifier que vous exécuté actuellement le dernier correctif de la version 1.1.1.0. Si ce n'est pas le cas, commencez par effectuer une mise à niveau vers la dernière version du correctif de 1.1.1.0.

Avant la mise à niveau, vous devez également recréer tout groupe de paramètres de cluster de bases de données personnalisé que vous utilisiez avec votre version précédente, à l'aide de la famille neptune1.2 de groupes de paramètres. Pour plus d'informatons, consultez Groupes de paramètres Amazon Neptune.

Si vous effectuez d'abord une mise à niveau vers une version, 1.1.1.0 puis immédiatement vers une version 1.2.0.0, vous risquez de rencontrer une erreur telle que la suivante :

   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.

Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer (voir Maintenance du cluster de bases de données Amazon Neptune).

Mise à niveau vers cette version

Si un cluster de bases de données exécute une version de moteur à partir de laquelle il existe un chemin de mise à niveau vers cette version, il peut être mis à niveau dès maintenant. Vous pouvez mettre à niveau n'importe quel cluster éligible à l'aide des opérations de cluster de bases de données sur la console ou à l'aide du kit SDK. La commande CLI suivante met immédiatement à niveau un cluster éligible :

Pour Linux, OS X ou Unix :

aws neptune modify-db-cluster \
    --db-cluster-identifier (your-neptune-cluster) \
    --engine-version 1.2.0.0 \
    --allow-major-version-upgrade \
    --apply-immediately

Pour Windows :

aws neptune modify-db-cluster ^
    --db-cluster-identifier (your-neptune-cluster) ^
    --engine-version 1.2.0.0 ^
    --allow-major-version-upgrade ^
    --apply-immediately

Au lieu d'--apply-immediately, vous pouvez spécifier --no-apply-immediately. Pour effectuer une mise à niveau de version majeure, le paramètre allow-major-version-upgrade est obligatoire. Assurez-vous également d'inclure la version du moteu. Dans le cas contraire, le moteur sera peut-être mis à niveau vers une autre version.

Si votre cluster utilise un groupe de paramètres de cluster personnalisé, veillez à inclure ce paramètre pour le spécifier :

    --db-cluster-parameter-group-name (name of the custom DB cluster parameter group)

De même, si des instances du cluster utilisent un groupe de paramètres de base de données personnalisé, veillez à inclure ce paramètre pour le spécifier :

    --db-instance-parameter-group-name (name of the custom instance parameter group)

Toujour effectuer des tests avant la mise à niveau

Lorsqu'une nouvelle version majeure ou mineure du moteur Neptune est publiée, testez toujours vos applications Neptune sur cette version avant de procéder à la mise à niveau. Même une mise à niveau mineure peut introduire de nouvelles fonctionnalités ou de nouveaux comportements susceptibles d'affecter le code.

Commencez par comparer les pages de notes de mise à jour de votre version actuelle à celles de la version cible pour déterminer s'il existe des modifications des versions de langage de requête ou d'autres changements majeurs.

Le meilleur moyen de tester une nouvelle version avant de mettre à niveau le cluster de bases de données de production est de cloner ce cluster pour qu'il exécute cette nouvelle version du moteur. Vous pouvez ainsi exécuter des requêtes sur le clone sans affecter le cluster de bases de données de production.

Toujours créer un instantané manuel avant de procéder à la mise à niveau

Avant la mise à niveau, nous vous recommandons vivement de toujours créer un instantané manuel du cluster de bases de données. Un instantané automatique n'offre qu'une protection à court terme, tandis qu'un instantané manuel reste disponible jusqu'à ce que vous le supprimiez explicitement.

Dans certains cas, Neptune crée un instantané manuel pour vous dans le cadre du processus de mise à niveau, mais il est préférable de ne pas compter sur ce mécanisme et de créer dans tous les cas votre propre instantané manuel.

Lorsque vous êtes certain de ne pas avoir besoin de rétablir l'état antérieur à la mise à niveau de votre cluster de bases de données, vous pouvez supprimer explicitement l'instantané manuel que vous avez créé vous-même, ainsi que celui que Neptune a éventuellement créé. Si Neptune crée un instantané manuel, il porte un nom commençant par preupgrade, suivi du nom de votre cluster de bases de données, de la version du moteur source, de la version du moteur cible et de la date.

Note

Si vous essayez de procéder à une mise à niveau alors qu'une action en attente est en cours, une erreur telle que la suivante peut survenir :

   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.

Si vous rencontrez cette erreur, attendez que l'action en attente soit terminée ou déclenchez immédiatement une fenêtre de maintenance pour laisser la mise à niveau précédente se terminer.

Pour plus d'informations sur la mise à niveau de la version du moteur , consultez Maintenance du cluster de bases de données Amazon Neptune. En cas de question ou de doute, l'équipe AWS Support est disponible sur les forums de la communauté et via AWS Premium Support.