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.
Consultas federadas de SPARQL en Neptune mediante la extensión SERVICE
Amazon Neptune admite totalmente la extensión de consulta federada de SPARQL que utiliza la palabra clave SERVICE. Para obtener más información, consulte Consulta federada de SPARQL 1.1
nota
Esta característica está disponible a partir de Versión 1.0.1.0.200463.0 (15/10/2019).
La palabra clave SERVICE indica al motor de consultas SPARQL que ejecute una parte de la consulta en un punto de enlace SPARQL remoto y que componga el resultado final de la consulta. Solo son posibles las operaciones READ. Las operaciones WRITE y DELETE no se admiten. Neptune solo puede ejecutar consultas federadas con respecto a puntos de conexión de SPARQL a los que se pueda acceder desde su nube privada virtual (VPC). Sin embargo, también puede utilizar un proxy inverso en la VPC para hacer accesible un origen de datos externo dentro de la VPC.
nota
Cuando se utiliza SERVICE de SPARQ para federar una consulta en dos o más clústeres de Neptune situados en la misma VPC, los grupos de seguridad deben estar configurados de modo que permitan que todos esos clústeres de Neptune se comuniquen entre sí.
importante
La federación SPARQL 1.1 realiza solicitudes de servicio en su nombre al pasar consultas y parámetros a puntos de enlace SPARQL externos. Es su responsabilidad verificar que los puntos de enlace SPARQL externos satisfagan los requisitos de seguridad y gestión de datos de su aplicación.
Ejemplo de una consulta federada de Neptune
El siguiente ejemplo sencillo muestra cómo funcionan las consultas federadas SPARQL.
Supongamos que un cliente envía la siguiente consulta a Neptune-1 en http://neptune-1:8182/sparql.
SELECT * WHERE { ?person rdf:type foaf:Person . SERVICE <http://neptune-2:8182/sparql> { ?person foaf:knows ?friend . } }
Neptune-1 evalúa el primer patrón de consulta (Q-1), que es
?person rdf:type foaf:Person, utiliza los resultados para resolver?personen Q-2 (?person foaf:knows ?friend) y reenvía el patrón a Neptune-2 enhttp://neptune-2:8182/sparql.Neptune-2 evalúa Q-2 y vuelve a enviar los resultados a Neptune-1.
Neptune-1 combina las soluciones para ambos patrones y vuelve a enviar los resultados al cliente.
Este flujo se muestra en el siguiente diagrama.
nota
De forma predeterminada, el optimizador determina en qué punto de la ejecución de la consulta se ejecuta la instrucción SERVICE. Puede anular esta ubicación utilizando la sugerencia de consulta joinOrder.
Control de acceso para consultas federadas en Neptune
Neptune usa AWS Identity and Access Management (IAM) para la autenticación y la autorización. El control de acceso de una consulta federada puede implicar más de una instancia de base de datos de Neptune. Estas instancias pueden tener diferentes requisitos de control de acceso. En determinadas circunstancias, esto puede limitar su capacidad para realizar una consulta federada.
Analice el sencillo ejemplo que se presenta en la sección anterior. Neptune-1 llama a Neptune-2 con las mismas credenciales con las que se ha llamado.
Si Neptune-1 requiere autenticación y autorización de IAM, pero Neptune-2 no, lo único que necesita son los permisos de IAM adecuados para que Neptune-1 realice la consulta federada.
Si Neptune-1 y Neptune-2 requieren autenticación y autorización de IAM, debe asociar permisos de IAM para ambas bases de datos para realizar la consulta federada. Ambos clústeres también deben estar en la misma AWS cuenta y en la misma región. Actualmente, no se admiten las arquitecturas de consultas federadas entre regiones o entre cuentas.
Sin embargo, en el caso en el que Neptune-1 no disponga de IAM, pero Neptune-2 sí, no podrá realizar una consulta federada. El motivo es que Neptune-1 no puede recuperar sus credenciales de IAM y pasarlas a Neptune-2 para autorizar la segunda parte de la consulta.
