SPARQLrequêtes fédérées dans Neptune à l'aide de l'extension SERVICE

Amazon Neptune prend entièrement en charge l'extension de requête SPARQL fédérée qui utilise le mot clé. SERVICE (Pour plus d'informations, voir SPARQL1.1 Requête fédérée.)

Note

Cette fonctionnalité est disponible à compter de la Version 1.0.1.0.200463.0 (15/10/2019).

Le SERVICE mot clé indique au moteur de SPARQL requête d'exécuter une partie de la requête sur un point de SPARQL terminaison distant et de composer le résultat final de la requête. Seules les opérations READ sont possibles. Les opérations WRITE et DELETE ne sont pas prises en charge. Neptune ne peut exécuter des requêtes fédérées que sur des SPARQL points de terminaison accessibles dans son cloud privé virtuel (). VPC Cependant, vous pouvez également utiliser un proxy inverse dans le VPC pour rendre une source de données externe accessible dans leVPC.

Note

Lorsqu'il SPARQL SERVICE est utilisé pour fédérer une requête vers deux clusters Neptune ou plus au sein d'un VPC même cluster, les groupes de sécurité doivent être configurés pour permettre à tous ces clusters Neptune de communiquer entre eux.

Important

SPARQL1.1 La fédération effectue des demandes de service en votre nom lorsque vous transmettez des requêtes et des paramètres à des SPARQL points de terminaison externes. Il est de votre responsabilité de vérifier que les SPARQL points de terminaison externes répondent aux exigences de gestion des données et de sécurité de votre application.

Exemple de requête fédérée Neptune

L'exemple simple suivant montre le fonctionnement des requêtes SPARQL fédérées.

Supposons qu'un client envoie la requête suivante à Neptune-1 à l'adresse http://neptune-1:8182/sparql.

SELECT * WHERE {
   ?person rdf:type foaf:Person .
   SERVICE <http://neptune-2:8182/sparql> {
       ?person foaf:knows ?friend .
    }
}

1. Neptune-1 évalue le premier modèle de requête (Q-1) qui est ?person rdf:type foaf:Person, utilise les résultats pour résoudre ?person dans Q-2 (?person foaf:knows ?friend) et transmet le modèle obtenu à Neptune-2 à l'adresse http://neptune-2:8182/sparql.

2. Neptune-2 évalue Q-2 et renvoie les résultats à Neptune-1.

3. Neptune-1 joint les solutions pour les deux modèles et renvoie les résultats au client.

Ce flux est illustré dans le diagramme suivant.

Note

« Par défaut, l'optimiseur détermine à quel moment de l'exécution de la requête la déclaration SERVICE est exécutée. Vous pouvez annuler ce placement à l'aide de l'indicateur de requête joinOrder.

Contrôle d'accès pour les requêtes fédérées dans Neptune

Neptune utilise AWS Identity and Access Management (IAM) pour l'authentification et l'autorisation. Le contrôle d'accès d'une requête fédérée peut impliquer plusieurs instances de base de données Neptune. Ces instances peuvent avoir des exigences différentes pour le contrôle d'accès. Dans certaines circonstances, cela peut limiter votre capacité à effectuer une requête fédérée.

Prenons l'exemple simple présenté dans la section précédente. Neptune-1 appelle Neptune-2 avec les mêmes informations d'identification avec lesquelles il a été appelé.

• Si Neptune-1 nécessite une IAM authentification et une autorisation, mais pas Neptune-2, vous n'avez besoin que des IAM autorisations appropriées pour que Neptune-1 puisse effectuer la requête fédérée.

• Si Neptune-1 et Neptune-2 nécessitent tous deux une IAM authentification et une autorisation, vous devez associer des IAM autorisations aux deux bases de données pour effectuer la requête fédérée. Les deux clusters doivent également se trouver dans le même cluster AWS compte et dans la même région. Les architectures de requêtes fédérées entre régions et/ou entre comptes ne sont actuellement pas prises en charge.

• Toutefois, dans le cas où Neptune-1 n'est pas IAM activé mais que Neptune-2 l'est, vous ne pouvez pas effectuer de requête fédérée. La raison en est que Neptune-1 ne peut pas récupérer vos IAM informations d'identification et les transmettre à Neptune-2 pour autoriser la deuxième partie de la requête.