Version 1.3.2.1 du moteur Amazon Neptune (20/06/2021) - Amazon Neptune
Défauts corrigésLes modifications apportées au 1.3.2.1 sont reportées du 1.3.2.0Chemins 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.3.2.1 du moteur Amazon Neptune (20/06/2021)

Depuis le 2024-06-20, la version 1.3.2.1 du moteur est généralement déployée. Notez que plusieurs jours sont nécessaires pour qu'une nouvelle version soit disponible dans chaque région.

Note

La version 1.3.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.3.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.3. Les versions antérieures utilisaient une famille de groupes de paramètres neptune1 ou neptune1.2, lesquels ne sont pas compatibles avec les versions 1.3.0.0 et supérieures. Pour plus d’informations, consultez Groupes de paramètres Amazon Neptune.

Avertissement

La version 1.3.2.1 du moteur a introduit des problèmes potentiels dont vous devez être conscient. Consultez la section ci-dessous Atténuation des problèmes dans la version 1.3.2.1 pour plus d'informations.

Défauts corrigés dans cette version du moteur

openCypher correctifs

  • Un bogue a été détecté dans la fonctionnalité de cache du plan de requêtes pour les requêtes paramétrées contenant une WITH clause interne ayant SKIP et en LIMIT tant que paramètres. Les LIMIT valeursSKIP/n'étaient pas correctement paramétrées et, par conséquent, les exécutions ultérieures du même plan de requête mis en cache avec des valeurs de paramètres différentes renverraient toujours les mêmes résultats que lors de la première exécution. Cela a été corrigé. 

    # insert some nodes
UNWIND range(1, 10) as i CREATE (s {name: i}) RETURN s

# sample query
MATCH (p) 
WITH p ORDER BY p.name SKIP $s LIMIT $l 
RETURN p.name as res

# first time executing with {"s": 2, "l": 1}
{
  "results" : [ {
    "res" : 3
  } ]
}

# second time executing with {"s": 2, "l": 10}
# due to bug, produces
{
  "results" : [ {
    "res" : 3
  } ]
}
# with fix, produces correct results: 
{
  "results" : [ {
    "res" : 3
  }, {
    "res" : 4
  }, {
    "res" : 5
  }, {
    "res" : 6
  }, {
    "res" : 7
  }, {
    "res" : 8
  }, {
    "res" : 9
  }, {
    "res" : 10
  } ]
}%

  • Correction d'un bogue où les requêtes de mutation paramétrées lançaient un InternalFailureException message lorsque le paramètre passé n'était pas déjà présent dans la base de données.

  • Correction d'un bug à cause duquel les requêtes Bolt paramétrées restaient bloquées après avoir atteint une condition de course lors du nettoyage des ressources de requête.

Les modifications apportées au 1.3.2.1 sont reportées du 1.3.2.0

Améliorations apportées depuis la version 1.3.2.0 du moteur

Améliorations générales

  • Support pour la TLS version 1.3, y compris les suites de chiffrement TLS _ AES _128_ _ SHA256 et _ GCM _256_ TLS _AES. GCM SHA384 TLS1.3 est une option, TLS 1.2 reste le minimum.

  • openCypher le support étendu du format datetime est en mode lab_pour cette version. Nous vous encourageons à le tester.

Améliorations apportées à Gremlin

  • TinkerPop Mise à niveau 3.7.x

  • StrictTimeoutValidation(uniquement lorsqu'il est activé via labmode StrictTimeoutValidation en incluantStrictTimeoutValidation=enabled) : Lorsque le StrictTimeoutValidation paramètre a une valeur deenabled, une valeur de délai par requête spécifiée en tant qu'option de demande ou indice de requête ne peut pas dépasser la valeur définie globalement dans le groupe de paramètres. Dans ce cas, Neptune lancera un. InvalidParameterException Ce paramètre peut être confirmé dans une réponse sur le /status terminal lorsque la valeur estdisabled, et dans les versions 1.3.2.0 et 1.3.2.1 de Neptune, la valeur par défaut de ce paramètre est. Disabled

openCypher améliorations

  • La version 1.3.2.0 du moteur Amazon Neptune fournit un débit jusqu'à 9 fois plus rapide et 10 fois plus élevé pour openCypher améliorer les performances des requêtes par rapport aux versions précédentes du moteur.

  • Requêtes à faible latence et amélioration des performances de débit : améliorations des performances globales pour les openCypher requêtes à faible latence. La nouvelle version améliore également le débit de ces requêtes. Les améliorations sont plus importantes lorsque des requêtes paramétrées sont utilisées.

  • Support pour le cache du plan de requête : lorsqu'une requête est soumise à Neptune, la chaîne de requête est analysée, optimisée et transformée en un plan de requête, qui est ensuite exécuté par le moteur. Les applications sont souvent soutenues par des modèles de requête courants instanciés avec des valeurs différentes. Le cache des plans de requêtes peut réduire la latence globale en mettant en cache les plans de requêtes et en évitant ainsi l'analyse et l'optimisation pour de tels modèles répétés. Pour plus d’informations, consultez Cache du plan de requête dans Amazon Neptune.

  • Amélioration des performances pour les requêtes DISTINCT d'agrégation.

  • Amélioration des performances pour les jointures impliquant des variables nullables.

  • Amélioration des performances pour les requêtes impliquant un prédicat non égal au prédicat id (node/relation).

  • Support étendu pour la fonctionnalité date/heure (uniquement activée en mode laboratoire DatetimeMillisecond en incluantDatetimeMillisecond=enabled. Pour de plus amples informations, veuillez consulter Support temporel dans l' openCypher implémentation de Neptune (Neptune Analytics et Neptune Database 1.3.2.0 et versions ultérieures).

Corrections de défauts reportées depuis la version 1.3.2.0 du moteur

Améliorations générales

  • Le message d'erreur NeptuneML a été mis à jour lors de la validation de l'accès aux compartiments Graphlytics.

Correctifs apportés à Gremlin

  • Correction d'informations d'étiquette manquantes dans la traduction des DFE requêtes, pour les scénarios dans lesquels les étapes ne contribuant pas au chemin contiennent des étiquettes. Par exemple :

    g.withSideEffect('Neptune#useDFE', true).
  V().
  has('name', 'marko').
  has("name", TextP.regex("mark.*")).as("p1").
  not(out().has("name", P.within("peter"))).
  out().as('p2').
  dedup('p1', 'p2')

  • Correction d'un NullPointerException bogue dans la traduction des DFE requêtes, qui se produit lorsqu'une requête est exécutée en deux DFE fragments et que le premier fragment est optimisé pour un nœud insatisfaisant. Par exemple :

    g.withSideEffect('Neptune#useDFE', true).
  V().
  has('name', 'doesNotExists').
  has("name", TextP.regex("mark.*")).
  inject(1).
  V().
  out().
  has('name', 'vadas')

  • Correction d'un bug en raison duquel Neptune pouvait lancer un modulateur InternalFailureException lorsqu'une requête contenait un modulateur ValueTraversal inside by () et que son entrée était Map. Par exemple :

    g.V().
  hasLabel("person").
  project("age", "name").by("age").by("name").
  order().by("age")
openCypher correctifs

  • Des UNWIND opérations améliorées (par exemple, étendre une liste de valeurs en valeurs individuelles) pour éviter les situations de manque de mémoire (OOM). Par exemple :

    MATCH (n)-->(m)
WITH collect(m) AS list
UNWIND list AS m
RETURN m, list

  • Optimisation de l'identifiant personnalisé fixe en cas d'MERGEopérations multiples où l'identifiant est injecté viaUNWIND. Par exemple :

    UNWIND [{nid: 'nid1', mid: 'mid1'}, {nid: 'nid2', mid: 'mid2'}] as ids
MERGE (n:N {`~id`: ids.nid})
MERGE (m:M {`~id`: ids.mid})

  • Correction d'une explosion de mémoire lors de la planification de requêtes complexes avec accès aux propriétés et de sauts multiples associés à des relations bidirectionnelles. Par exemple :

    MATCH (person1:person)-[:likes]->(res)-[:partOf]->(group)-[:knows]-(:entity {name: 'foo'}), 
       (person1)-[:knows]->(person2)-[:likes]-(res2), (comment)-[:presentIn]->(:Group {name: 'barGroup'}), 
       (person1)-[:commented]->(comment2:comment)-[:partOf]->(post:Post), (comment2)-[:presentIn]->(:Group {name: 'fooGroup'}), 
       (comment)-[:contains]->(info:Details)-[:CommentType]->(:CommentType {name: 'Positive'}),
       (comment2)-[:contains]->(info2:Details)-[:CommentType]->(:CommentType {name: 'Positive'}) 
WHERE datetime('2020-01-01T00:00') <= person1.addedAfter <= datetime('2023-01-01T23:59') AND comment.approvedBy = comment2.approvedBy 
MATCH (comment)-[:contains]->(info3:Details)-[:CommentType]->(:CommentType {name: 'Neutral'})
RETURN person1, group.name, info1.value,  post.ranking, info3.value

  • Requêtes d'agrégation fixes avec null en tant que groupe par variables. Par exemple :

    MATCH (n)
RETURN null AS group, sum(n.num) AS result
SPARQLcorrectifs

  • Correction de l'SPARQLanalyseur afin d'améliorer le temps d'analyse pour les requêtes volumineuses, telles que celles INSERT DATA contenant de nombreux triples et de gros jetons.

Atténuation des problèmes dans la version 1.3.2.1

  • Les requêtes utilisant des valeurs de filtre numériques peuvent renvoyer des résultats incorrects lors de l'utilisation du cache du plan de requêtes. Pour éviter ce problème, utilisez l'indice de requête QUERY:PLANCACHE "disabled" pour ignorer le cache du plan de requête. Par exemple, utilisez : 

    USING QUERY:PLANCACHE "disabled"
MATCH (n:person)
WHERE n.yearOfBirth > $year
RETURN n

parameters={"year":1950}

  • Les requêtes utilisant le même nom de paramètre plusieurs fois peuvent échouer avec l'erreurParameter name should not be a number and/or contain _internal_ or _modified_user_ string within it. These are reserved for planCache. Otherwise, rerun with HTTP parameter planCache=disabled. Dans ce cas, ignorez le cache du plan de requête comme ci-dessus ou dupliquez les paramètres comme dans cet exemple : 

    MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n 
UNION 
MATCH (n:show) WHERE n.duration>=$minutes RETURN n

parameters={"minutes":130}

    Utilisez le conseil QUERY:PLANCACHE "disabled" ou modifiez les paramètres : 

    MATCH (n:movie) WHERE n.runtime>=$rt_min RETURN n 
UNION 
MATCH (n:show) WHERE n.duration>=$dur_min RETURN n

parameters={"rt_min":130, "dur_min":130}

  • Les requêtes exécutées avec le protocole Bolt peuvent produire des résultats incorrects s'il s'agit d'une UNION ALL requête UNION ou. Pour éviter ce problème, envisagez d'exécuter la requête spécifique avec le HTTP point de terminaison. Vous pouvez également exécuter chaque partie de l'union séparément lorsque vous utilisez le protocole Bolt.

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

Avant de mettre à niveau un cluster de base de données vers la version 1.3.2.1, 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.7.1

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

  • openCypher version : Neptune-9.0.20190305-1.0

  • SPARQLversion : 1.1

Chemins de mise à niveau vers la version 1.3.2.1 du moteur

Vous pouvez effectuer une mise à niveau vers cette version à partir de la version 1.2.0.0 ou supérieure du moteur.

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 base de données sur la console ou à l'aide duSDK. La CLI commande suivante permet de mettre 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.3.2.1 \
    --allow-major-version-upgrade \
    --apply-immediately

Pour Windows :

aws neptune modify-db-cluster ^
    --db-cluster-identifier (your-neptune-cluster) ^
    --engine-version 1.3.2.1 ^
    --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 allow-major-version-upgrade paramètre 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. Si vous avez des questions ou des préoccupations, l'équipe de AWS support est disponible sur les forums communautaires et via le support AWS Premium.