Version 1.2.1.0.R3 du moteur Amazon Neptune (13/06/2023)

Depuis le 13 juin 2023, la version 1.2.1.0.R3 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.

Important

Les modifications apportées à cette version du moteur peuvent, dans certains cas, entraîner une dégradation des performances de chargement en bloc. Par conséquent, les mises à niveau de cette version ont été temporairement suspendues jusqu'à ce que le problème soit résolu.

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.

Nouvelles fonctionnalités pour cette version du moteur

• Ajout de la prise en charge du chargement en bloc entre comptes à l'aide du chaînage des rôles IAM.

Améliorations de cette version du moteur

• Amélioration de l'étape fail() utilisée par Gremlin pour différencier l'exception produite à partir d'une exception InternalFailureException générique et pour garantir que tout message fourni par l'utilisateur soit retransmis à l'appelant.

• Amélioration des optimisations du moteur de requêtes Gremlin pour store, aggregate, cap, limit et hasLabel.

• Ajout de la prise en charge des fonctions trignométriques openCypher :

  • acos()

  • asin()

  • atan()

  • atan2()

  • cos()

  • cot()

  • degrees()

  • pi()

  • radians()

  • sin()

  • tan()

• Ajout de la prise en charge de plusieurs fonctions d'agrégation openCypher :

  • percentileDisc()

  • stDev()

• Ajout de la prise en charge de la fonction epochmillis() openCypher qui convertit un objet datetime en epochmillis. Par exemple :

  MATCH (n) RETURN epochMillis(n.someDateTime)
  1698972364782

• Ajout de la prise en charge de l'opérateur modulo (%) openCypher.

• Ajout de la prise en charge de l'outil openCypher Static Debug Explain.

• Ajout de la prise en charge de la fonction openCypher randomUUID().

• Amélioration des performances d'openCypher :

  • Amélioration de l'analyseur et du planificateur de requêtes.

  • Utilisation améliorée du CPU dans le moteur DFE.

  • Amélioration des performances des requêtes contenant plusieurs clauses de mise à jour réutilisant les mêmes variables. Voici quelques exemples :

    MERGE (n {name: 'John'})
      or
    MERGE (m {name: 'Jim'})
      or
    MERGE (n)-[:knows {since: 2023}]→(m)

  • Plans de requêtes optimisés pour les modèles de requêtes à sauts multiples tels que :

    MATCH (n)-->()-->()-->(m)
    RETURN n m

  • Amélioration des performances de l'injection de listes et de mappages grâce à des requêtes paramétrées. Par exemple :

    UNWIND $idList as id MATCH (n {`~id`: id})
    RETURN n.name

  • Amélioration de l'exécution des requêtes contenant WITH en en faisant une barrière appropriée.

  • Optimisation pour éviter la matérialisation redondante des valeurs Unfold et dans les fonctions d'agrégation.

• Amélioration des performances des requêtes SPARQL qui contiennent un grand nombre d'entrées statiques dans la clause VALUES, telles que :

  SELECT ?n WHERE { VALUES (?name) { ("John") ("Jim") ... many values ... } ?n a ?n_type . ?n ?name . }

• Amélioration des performances des requêtes SPARQL CBD.

Défauts corrigés dans cette version du moteur

• Correction d'un bogue Gremlin à cause duquel les requêtes longues avec imbrication profonde entraînaient une utilisation élevée du CPU et l'expiration des requêtes pendant la phase de planification des requêtes.

• Correction d'un bogue Gremlin où une exception NullPointerException non valide pouvait être levée lors de l'utilisation de mergeV ou mergeE.

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.1.0.R3, 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.6.2

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

• Version d'openCypher : Neptune-9.0.20190305-1.0

• Version SPARQL : 1.1

Chemins de mise à niveau vers la version de moteur 1.2.1.0.R3

Mise à niveau vers cette version

Amazon Neptune 1.2.1.0.R3 est désormais disponible globalement.

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.1.0 \
    --apply-immediately

Pour Windows :

aws neptune modify-db-cluster ^
    --db-cluster-identifier (your-neptune-cluster) ^
    --engine-version 1.2.1.0 ^
    --apply-immediately

Les mises à jour sont appliquées simultanément à toutes les instances figurant dans un cluster de bases de données. Une mise à jour nécessite un redémarrage de la base de données sur ces instances. Vous subirez donc un temps d'arrêt allant de 20-30 secondes à plusieurs minutes, après quoi vous pourrez reprendre l'utilisation du cluster de bases de données.

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.