Llamando a los arroyos de Neptune REST API - Amazon Neptune

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Llamando a los arroyos de Neptune REST API

Para acceder a Neptune Streams, utilice un dispositivo REST API que envíe una HTTP GET solicitud a uno de los siguientes puntos finales locales:

  • Para una base de datos SPARQL gráfica:. https://Neptune-DNS:8182/sparql/stream

  • Para un Gremlin o una base de datos openCypher gráfica: https://Neptune-DNS:8182/propertygraph/stream o. https://Neptune-DNS:8182/pg/stream

nota

A partir de la versión 1.1.0.0 del motor, el punto de conexión de flujo de Gremlin (https://Neptune-DNS:8182/gremlin/stream) está en desuso, junto con su formato de salida asociado (GREMLIN_JSON). Sigue siendo compatible con versiones anteriores, pero es posible que se elimine en futuras versiones.

Solo se permite una HTTP GET operación.

Neptune admite la gzip compresión de la respuesta, siempre que la HTTP solicitud incluya un Accept-Encoding encabezado que se especifique gzip como formato de compresión aceptado (es decir,"Accept-Encoding: gzip").

Parámetros
  • limit: largo, opcional. Rango: 1–100 000. Predeterminado: 10.

    Especifica el número máximo de registros que se van a devolver. También existe un límite de tamaño de 10 MB en la respuesta que no se puede modificar y que prevalece sobre el número de registros especificado en el parámetro limit. La respuesta incluye un registro de incumplimiento de umbral si se alcanzó el límite de 10 MB.

  • iteratorType: cadena, opcional.

    Este parámetro puede tener uno de los siguientes valores:

    • AT_SEQUENCE_NUMBER (predeterminado): indica que la lectura debe comenzar con el número de secuencia de eventos especificado conjuntamente por los parámetros commitNum y opNum.

    • AFTER_SEQUENCE_NUMBER: indica que la lectura debe comenzar justo después del número de secuencia de eventos especificado conjuntamente por los parámetros commitNum y opNum.

    • TRIM_HORIZON: indica que la lectura debe comenzar en el último registro no recortado del sistema, que es el registro más antiguo que no ha caducado (aún no se ha eliminado) del flujo de registro de cambios. Este modo es útil durante el inicio de la aplicación, cuando no tiene un número secuencial de evento inicial específico.

    • LATEST: indica que la lectura debe comenzar en el registro más reciente del sistema, que es el último registro que no ha caducado (aún no se ha eliminado) del flujo de registro de cambios. Esto resulta útil cuando es necesario leer los registros de la parte superior actual de los flujos para no procesar registros antiguos, por ejemplo, durante una recuperación de desastres o una actualización sin tiempo de inactividad. Tenga en cuenta que, en este modo, solo se devuelve como máximo un registro.

  • commitNum— largo, obligatorio cuando iteratorType es AT_SEQUENCE_NUMBER oAFTER_SEQUENCE_NUMBER.

    El número de confirmación del registro de inicio que se va a leer del flujo de registro de cambios.

    Este parámetro se omite cuando iteratorType es TRIM_HORIZON o LATEST.

  • opNum: largo, opcional (el valor predeterminado es 1).

    El número secuencial de la operación dentro de la confirmación especificada desde la que empezar a leer en los datos del flujo de registro de cambios.

Las operaciones que cambian los datos del SPARQL gráfico generalmente solo generan un registro de cambios por operación. Sin embargo, las operaciones que cambian los datos de gráficos de Gremlin pueden generar varios registros de cambio por operación, como en los siguientes ejemplos:

  • INSERT: un vértice de Gremlin puede tener varias etiquetas y un elemento de Gremlin puede tener varias propiedades. Se genera un registro de cambio independiente para cada etiqueta y propiedad cuando se inserta un elemento.

  • UPDATE: cuando se modifica una propiedad de un elemento de Gremlin, se generan dos registros de cambios: el primero para eliminar el valor anterior y el segundo para insertar el nuevo valor.

  • DELETE: se genera un registro de cambios independiente para cada propiedad del elemento que se elimina. Por ejemplo, cuando se elimina un borde Gremlin con propiedades, se genera un registro de cambio para cada una de las propiedades y, a continuación, se genera uno para la eliminación de la etiqueta de borde.

    Cuando se elimina un vértice Gremlin, se eliminan primero todas las propiedades de borde de entrada y salida, después las etiquetas de borde, a continuación las propiedades de vértice y, por último, las etiquetas de vértice. Cada una de estas eliminaciones genera un registro de cambios.