Moteur Amazon Neptune version 1.2.0.0 (2022-07-21) - Amazon Neptune

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.

Moteur Amazon Neptune version 1.2.0.0 (2022-07-21)

À compter du 21 juillet 2021, la version 1.2.0.0 du moteur est généralement déployée. Veuillez noter que plusieurs jours sont nécessaires pour qu’une nouvelle version soit disponible dans chaque région.

Important

Les mises à niveau vers la version 1.2.0.0 du moteur sont temporairement désactivées. Vous pouvez toutefois créer un nouveau cluster de bases de données Neptune qui utilise la version 1.2.0.0 du moteur.

Note

À partir de cette version du moteur, tous les groupes de paramètres personnalisés et les groupes de paramètres de cluster personnalisés que vous utilisez doivent être créés à l'aide d'une famille de groupes de paramètresneptune1.2. Les versions précédentes utilisaient la famille de groupes de paramètresneptune1, et ces groupes de paramètres ne fonctionneront pas avec cette version. Pour plus d'informations, consultez Groupes de paramètres Amazon Neptune.

Note

Cette version apporte également une modification majeure au code utilisant le protocole Bolt avec authentification IAM. À partir de cette version du moteur, Bolt a besoin d'un chemin de ressources pour la signature IAM. En Java, la définition du chemin de la ressource peut ressembler à ceci :

request.setResourcePath("/openCypher"));

Dans d'autres langues, le/openCypherpeut ê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 deBases de données globales. Une base de données globale Neptune couvre plusieursRégions AWS, et se compose d'un cluster de bases de données principal dans une région et 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 précis dans les politiques Neptune IAM que ce qui était disponible auparavant, sur la base des actions du plan de données. Il s'agit d'un changement radical par rapport aux politiques IAM existantes qui sont basées sur lesconnectl'action doit être ajustée pour utiliser les actions plus précises du plan de données. Consultez Types de politiques IAM.

  • Disponibilité améliorée des instances de lecteur. Auparavant, lors du redémarrage d'une instance d'enregistreur, toutes les instances de lecteur du cluster Neptune ont également redémarré automatiquement. À partir de la version 1.2.0.0 du moteur, les instances de lecture restent actives après le redémarrage du scripteur, ce qui améliore la disponibilité du lecteur. Les instances Reader 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 nouveauneptune_streams_expiry_daysParamètre de cluster de base de données 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. La plage est comprise entre 1 et 90, et la valeur par défaut est de 7.

Améliorations de cette version du moteur

  • Performances de sérialisation Gremlin améliorées pour ByteCode query.

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

  • Neptune traite désormais Gremlinlimit()les étapes à suivre à l'aide du moteur DFE, y compris les limites de traversée pour les utilisateurs non terminaux et enfants

  • Modification de la gestion du Gremlin par DFEunion()étape pour travailler 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 jusqu'à 5 fois supérieures à certaines opérations de jointure coûteuses au sein de DFE en les parallélisant.

  • Ajoutéby()support de modulation pourOrderGlobalStep order(global)pour le moteur Gremlin DFE.

  • Ajout de l'affichage des valeurs statiques injectées dans les détails d'explication pour DFE.

  • Performances améliorées lors de la taille des modèles dupliqués

  • Ajout du support de préservation des commandes dans le moteur Gremlin DFE.

  • Amélioration des performances des requêtes Gremlin comportant des filtres vides, tels que :

    g.V().hasId(P.within([]))
    g.V().hasId([])
  • Amélioration du message d'erreur lorsqu'une requête SPARQL utilise une valeur numérique trop grande pour que Neptune puisse la représenter en interne.

  • Performances améliorées pour supprimer des sommets avec des arêtes associées en réduisant les recherches dans les index lorsque les flux sont désactivés.

  • Support DFE étendu à d'autres variantes duhas()étape, en particulier pourhasKey(),hasLabel(), et pour étendre les prédicats pour les chaînes/URI au sein dehas(). Cela a des répercussions sur les requêtes 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'un OpenChiffre spécifique à Neptunejoin()fonction qui concatène les chaînes d'une liste en une chaîne de caractères unique.

  • Mise à jour duStratégies gérées par Neptunepour inclure les autorisations d'accès aux données et les autorisations pour les nouvelles API de base de données mondiales.

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 RDF Turtle à cause duquel une combinaison particulière de données Unicode provoquait un échec.

  • Correction d'un bug SPARQL où une combinaison particulière deGRAPHetSELECTles clauses ont produit 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, telle que la suivante :

    g.V("1").union(hasLabel("person"), out())
  • Correction d'un bug Gremlin oùcount()deboth().simplePath()se traduirait par le double du nombre réel de résultats renvoyés sanscount().

  • Correction d'un bogue OpenCypher qui provoquait la génération par le serveur d'une exception de non-concordance de signature défectueuse pour les requêtes Bolt destinées aux clusters avec l'authentification IAM activée.

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

  • Correction d'un bogue d'OpenCypher qui pouvait provoquer le déclenchement d'une erreur interne lors de l'envoi d'une requête renvoyant une valeur constante.

  • Correction d'un bogue dans les détails d'explication de la sous-query DFETime(ms)additionne désormais correctement les temps CPU des opérateurs au sein de la sous-requête DFE. Prenons l'extrait suivant de la sortie d'explication à 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 ║ ╚════╧════════╧════════╧═══════════════════════╧═══════════════════════════════════╧══════╧══════════╧═══════════╧═══════╧═══════════╝

    Les temps de SubQuery dans la dernière colonne du tableau inférieur totalisent 0,36 ms (.04 + .29 + .01 + .02 = .36). Lorsque vous ajoutez le temps de coordination pour cette sous-requête (.36 + .026 = .386), vous obtenez un résultat proche de l'heure de la sous-requête enregistrée dans la dernière colonne du tableau supérieur, à savoir0.38ms.

Versions en 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 du langage de requête suivantes :

  • Version Gremlin : 3.5.2

  • Version d'OpenCrypher : Neptune-9.0.20190305-1.0

  • Version de SPARQL : 1.1

Chemins de mise à niveau vers la version 1.2.0.0

Comme il s'agit d'une version majeure du moteur, il n'y a pas de mise à niveau automatique.

Vous ne pouvez effectuer la mise à niveau que vers1.2.0.0manuellement, à partir de la dernière version du patch deversion du moteur 1.1.1.0. Les versions précédentes du moteur doivent d'abord être mises à niveau vers la dernière version de1.1.1.0avant qu'ils ne puissent être mis à niveau vers1.2.0.0.

Par conséquent, avant d'essayer de procéder à la mise à niveau vers cette version, veuillez vérifier que vous utilisez actuellement la dernière version de patch de la version1.1.1.0. Si ce n'est pas le cas, commencez par effectuer la mise à niveau vers la dernière version du patch de1.1.1.0.

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

Si vous effectuez la mise à niveau avant la sortie1.1.1.0puis immédiatement à1.2.0.0, vous pouvez rencontrer une erreur telle que la suivante :

Nous sommes désolés, votre demande de modification du cluster de base de données (identifiant du cluster) a échoué. Impossible de modifier la version du moteur car l'instance (identifiant d'instance) s'exécute sur une ancienne configuration. Appliquez toutes les actions de maintenance en attente sur l'instance avant de procéder à la mise à niveau.

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 terminer la mise à niveau précédente.

Mise à niveau vers cette version

Si un cluster de base de données exécute une version du 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 tout cluster éligible à l'aide des opérations du cluster de base de données sur la console ou à l'aide du SDK. La commande CLI suivante permet de mettre à niveau immédiatement un cluster éligible :

Pour Linux, OS X ou Unix :

aws neptune modify-db-cluster \ --db-cluster-identifier (your-neptune-cluster) \ --engine neptune \ --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 neptune ^ --engine-version 1.2.0.0 ^ --allow-major-version-upgrade ^ --apply-immediately

Au lieu de--apply-immediately, vous pouvez spécifier--no-apply-immediately. Pour effectuer une mise à niveau de version majeure, allow-major-version-upgrade le paramètre est obligatoire. Veillez également à inclure la version du moteur, sinon votre moteur pourrait être mis à niveau vers une version différente.

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)

Testez toujours avant la mise à niveau

Lorsqu'une nouvelle version majeure ou mineure du moteur Neptune est publiée, testez toujours vos applications Neptune dessus 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 votre code.

Commencez par comparer les pages de notes de publication de votre version actuelle à celles de la version cible pour voir s'il y aura des modifications dans les versions du langage de requête ou d'autres modifications majeures.

La meilleure façon de tester une nouvelle version avant de mettre à niveau votre cluster de base de données de production est de cloner votre cluster de production afin que le clone exécute la nouvelle version du moteur. Vous pouvez ensuite exécuter des requêtes sur le clone sans affecter le cluster de base de données de production.

Créez toujours un instantané manuel avant de procéder à la mise à niveau

Avant d'effectuer une mise à niveau, nous vous recommandons vivement de toujours créer un instantané manuel de votre cluster de bases de données. Un instantané automatique n'offre qu'une protection à court terme, alors 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 vous ne devez pas vous y fier et vous devez créer votre propre instantané manuel dans tous les cas.

Lorsque vous êtes certain de ne pas avoir besoin de rétablir l'état de votre cluster de bases de données avant la mise à niveau, vous pouvez supprimer explicitement l'instantané manuel que vous avez créé vous-même, ainsi que l'instantané manuel que Neptune a pu créer. Si Neptune crée un instantané manuel, il portera un nom commençant parpreupgrade, 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.

Pour de plus amples informations sur la mise à niveau de la version de votre moteurMises à jour du moteur Neptune. En cas de question supplémentaire, veuillez contacter leAWSL'équipe d'Support est disponible sur les forums de la communauté et viaAWSPrise en Support Premium.