Amazon Neptune Engine versión 1.3.2.1 (2024-06-20)

A partir del 20 de junio de 2020, la versión 1.3.2.1 del motor se implementará de forma general. Tenga en cuenta que las versiones nuevas tardan unos días en estar disponibles en todas las regiones.

nota

En la versión 1.3.0.0 del motor, se introdujo un nuevo formato para los grupos de parámetros personalizados y los grupos de parámetros de clústeres personalizados. En consecuencia, si va a actualizar una versión de motor anterior a la 1.3.0.0 a una versión de motor 1.3.0.0 o posterior, debe volver a crear todos los grupos de parámetros personalizados y los grupos de parámetros de clúster personalizados existentes utilizando la familia de grupos de parámetros neptune1.3. En las versiones anteriores, se utilizaba la familia de grupos de parámetros neptune1 o neptune1.2, y esos grupos de parámetros no funcionan con la versión 1.3.0.0 y las versiones posteriores. Para obtener más información, consulte Grupos de parámetros de Amazon Neptune.

aviso

La versión 1.3.2.1 del motor introdujo algunos posibles problemas que debe tener en cuenta. Consulte la sección siguiente Se han solucionado los problemas de la versión 1.3.2.1 para obtener más información.

Defectos corregidos en esta versión del motor

openCypher arregla

• Se detectó un error en la función de caché del plan de consultas para las consultas parametrizadas que contienen una WITH cláusula interna que tiene SKIP y como LIMIT parámetros. LIMITLos valoresSKIP/no estaban correctamente parametrizados y, como resultado, las ejecuciones posteriores del mismo plan de consultas en caché con valores de parámetros diferentes seguirían arrojando los mismos resultados que en la primera ejecución. Se ha corregido este problema.

  # 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
    } ]
  }%

• Se ha corregido un error que provocaba que las consultas de mutación parametrizadas emitieran un error InternalFailureException cuando el parámetro pasado no estaba ya presente en la base de datos.

• Se ha corregido un error que provocaba que las consultas de Bolt parametrizadas se bloquearan tras alcanzar una condición de carrera durante la limpieza de un recurso de consulta.

Los cambios de la versión 1.3.2.1 se arrastraron desde la versión 1.3.2.0

Mejoras heredadas de la versión 1.3.2.0 del motor

Mejoras generales

• Support para la TLS versión 1.3, incluidos los conjuntos de cifrado TLS _ AES _128_ _ SHA256 y _ GCM _256_ TLS _AES. GCM SHA384 TLSLa 1.3 es una opción; TLS 1.2 sigue siendo la mínima.

• openCypher El soporte extendido para el formato dateime está en lab_mode para esta versión. Te animamos a que lo pruebes.

Mejoras en Gremlin

• TinkerPop Actualización a la versión 3.7.x

  • Proporciona una gran expansión del lenguaje Gremlin.

    • Nuevos pasos para procesar cadenas, listas y fechas.

    • Nueva sintaxis para especificar la cardinalidad dentro del mergeV() paso.

    • union()ahora se puede utilizar como paso inicial.

    • Para obtener más información sobre los cambios de la versión 3.7.x, consulte la documentación de TinkerPop actualización.

  • Al actualizar los controladores de lenguaje Gremlin del cliente para Java, tenga en cuenta que las clases de serializadores han sufrido algunos cambios de nombre. Deberá actualizar los nombres de los paquetes y las clases en sus archivos de configuración y en el código, si se especifica.

• StrictTimeoutValidation(solo cuando se habilita mediante labmode StrictTimeoutValidation mediante la inclusiónStrictTimeoutValidation=enabled): cuando el StrictTimeoutValidation parámetro tiene un valor deenabled, un valor de tiempo de espera por consulta especificado como opción de solicitud o sugerencia de consulta no puede superar el valor establecido globalmente en el grupo de parámetros. En tal caso, Neptune lanzará un. InvalidParameterException Esta configuración se puede confirmar en una respuesta en el /status punto final cuando el valor esdisabled, y en las versiones 1.3.2.0 y 1.3.2.1 de Neptune, el valor predeterminado de este parámetro es. Disabled

openCypher mejoras

• La versión 1.3.2.0 del motor Amazon Neptune ofrece un rendimiento de consultas hasta 9 veces más rápido y 10 veces superior en comparación con las versiones anteriores del motor. openCypher

• Consultas de baja latencia y mejora del rendimiento: mejoras generales del rendimiento de las consultas de baja latencia. openCypher La nueva versión también mejora el rendimiento de dichas consultas. Las mejoras son más significativas cuando se utilizan consultas parametrizadas.

• Soporte para Query Plan Cache: cuando se envía una consulta a Neptune, la cadena de consulta se analiza, optimiza y transforma en un plan de consulta, que luego es ejecutado por el motor. Las aplicaciones suelen estar respaldadas por patrones de consulta comunes que se instancian con valores diferentes. La caché del plan de consultas puede reducir la latencia general al almacenar en caché los planes de consulta y, por lo tanto, evitar el análisis y la optimización de dichos patrones repetidos. Consulte Caché del plan de consultas en Amazon Neptune para obtener más detalles.

• Mejora del rendimiento de las consultas de DISTINCT agregación.

• Mejora del rendimiento de las uniones que incluyen variables anulables.

• Mejora del rendimiento de las consultas que incluyen un predicado distinto de id (nodo/relación).

• Soporte ampliado para la funcionalidad de fecha y hora (solo se habilita en el modo laboratorio al incluir. DatetimeMillisecond DatetimeMillisecond=enabled Para obtener más información, consulte Soporte temporal en la openCypher implementación de Neptune (Neptune Analytics y Neptune Database 1.3.2.0 y versiones posteriores).

Correcciones de defectos incorporadas en la versión 1.3.2.0 del motor

Mejoras generales

• Se actualizó el mensaje de error de NeptuneML al validar el acceso a los depósitos de Graphlytics.

Correcciones de Gremlin

• Se corrigió la falta de información sobre las etiquetas en la traducción de DFE consultas, en situaciones en las que los pasos que no contribuían a la ruta contenían etiquetas. Por ejemplo:

  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')

• Se ha NullPointerException corregido un error en la traducción de la DFE consulta, que se producía cuando una consulta se ejecutaba en dos DFE fragmentos y el primer fragmento se optimizaba para convertirla en un nodo insatisfactorio. Por ejemplo:

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

• Se corrigió un error por el que Neptune podía lanzar un InternalFailureException cuando una consulta contenía el modulador by () ValueTraversal interno y su entrada era Map. Por ejemplo:

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

openCypher corrige

• UNWINDOperaciones mejoradas (por ejemplo, ampliar una lista de valores en valores individuales) para ayudar a evitar situaciones de falta de memoria (OOM). Por ejemplo:

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

• Se corrigió la optimización de la identificación personalizada en caso de múltiples MERGE operaciones en las que se inyectaba la identificación medianteUNWIND. Por ejemplo:

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

• Se corrigió el problema de la pérdida de memoria al planificar consultas complejas con acceso a propiedades y saltos múltiples con relaciones bidireccionales. Por ejemplo:

  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

• Se corrigieron las consultas de agregación con valores nulos agrupados por variables. Por ejemplo:

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

SPARQLcorrecciones

• Se ha corregido el SPARQL analizador para mejorar el tiempo de análisis en consultas de gran tamaño, como las INSERT DATA que contienen muchos triples y fichas grandes.

Se han solucionado los problemas de la versión 1.3.2.1

• Las consultas que utilizan valores de filtro numéricos pueden arrojar resultados incorrectos cuando se utiliza la caché del plan de consultas. Para evitar este problema, utilice la sugerencia de consulta QUERY:PLANCACHE "disabled" para omitir la caché del plan de consultas. Por ejemplo, utilice

  USING QUERY:PLANCACHE "disabled"
  MATCH (n:person)
  WHERE n.yearOfBirth > $year
  RETURN n
  
  parameters={"year":1950}

• Las consultas que utilizan el mismo nombre de parámetro varias veces pueden fallar y provocar el errorParameter 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. En estos casos, puede omitir la memoria caché del plan de consultas, como se indica anteriormente, o bien duplicar los parámetros, como en este ejemplo:

  MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n 
  UNION 
  MATCH (n:show) WHERE n.duration>=$minutes RETURN n
  
  parameters={"minutes":130}

  Utilice la sugerencia QUERY:PLANCACHE "disabled" o modifique los parámetros:

  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}

• Las consultas ejecutadas con el protocolo Bolt pueden producir resultados incorrectos si se trata de una consulta de tipo «UNIONo UNIONALL». Para evitar este problema, considere la posibilidad de ejecutar la consulta en cuestión con el HTTP punto final. Como alternativa, ejecute cada parte de la unión por separado cuando utilice el protocolo Bolt.

Versiones de lenguaje de consulta admitidas en esta versión

Antes de actualizar un clúster de base de datos a la versión 1.3.2.1, asegúrese de que su proyecto sea compatible con las siguientes versiones del lenguaje de consulta:

• Compatible con la primera versión de Gremlin: 3.7.1

• Compatible con la última versión de Gremlin: 3.7.1

• openCypher versión: Neptune-9.0.20190305-1.0

• SPARQLversión: 1.1

Rutas de actualización a la versión 1.3.2.1 del motor

Puede actualizar a esta versión desde la versión 1.2.0.0 o superior del motor.

Actualización a esta versión

Si un clúster de base de datos ejecuta una versión de motor desde la que existe una ruta de actualización a esta versión, puede actualizarse ahora. Puede actualizar cualquier clúster que cumpla los requisitos mediante las operaciones del clúster de base de datos en la consola o mediante el. SDK El siguiente CLI comando actualizará inmediatamente un clúster apto:

Para Linux, OS X o Unix:

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

Para Windows:

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

En lugar de --apply-immediately, puede especificar --no-apply-immediately. Para realizar una actualización de una versión principal, se requiere el allow-major-version-upgrade parámetro. Además, asegúrese de incluir la versión del motor, ya que es posible que el motor se actualice a otra versión.

Si el clúster utiliza un grupo de parámetros del clúster personalizado, asegúrese de incluir este parámetro para especificarlo:

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

Del mismo modo, si alguna instancia del clúster utiliza un grupo de parámetros de base de datos personalizado, asegúrese de incluir este parámetro para especificarlo:

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

Realice siempre una prueba antes de realizar la actualización

Cuando se publique una nueva versión principal o secundaria del motor de Neptune, pruebe siempre las aplicaciones de Neptune en ella antes de actualizar. Incluso en una actualización secundaria podría haber nuevas características o comportamientos que podrían afectar al código.

Comience por comparar las páginas de notas de la versión actual con las de la versión de destino para ver si hay cambios en las versiones del lenguaje de consulta u otros cambios importantes.

La mejor forma de probar una nueva versión antes de actualizar el clúster de base de datos de producción es clonar el clúster de producción para que el clon ejecute la nueva versión del motor. A continuación, puede ejecutar consultas en el clon sin que eso afecte al clúster de base de datos de producción.

Cree siempre una instantánea manual antes de realizar la actualización

Antes de realizar una actualización, se recomienda crear siempre una instantánea manual del clúster de base de datos. Una instantánea automática solo ofrece protección a corto plazo, mientras que una instantánea manual está disponible hasta que la elimine explícitamente.

En algunos casos, Neptune crea una instantánea manual para usted como parte del proceso de actualización, pero no debe confiar en eso y crear su propia instantánea manual.

Cuando tenga la seguridad de que no necesitará revertir el clúster de base de datos al estado anterior a la actualización, puede eliminar de forma explícita la instantánea manual que ha creado, así como la instantánea manual que Neptune podría haber creado. Si Neptune crea una instantánea manual, tendrá un nombre que empieza por preupgrade, seguido del nombre del clúster de base de datos, la versión del motor de origen, la versión del motor de destino y la fecha.

nota

Si intenta realizar la actualización mientras hay una acción pendiente en proceso, es posible que se produzca un error como el siguiente:

   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 se produce este error, espere a que finalice la acción pendiente o active inmediatamente un periodo de mantenimiento para que se complete la actualización anterior.

Para obtener más información sobre la actualización de la versión del motor, consulte Mantenimiento del clúster de base de datos de Amazon Neptune. Si tienes alguna pregunta o duda, el equipo de AWS Soporte está disponible en los foros de la comunidad y a través del Soporte AWS Premium.