Modèle de piscine pour RDF

Le Resource Description Framework (RDF) utilise le concept de graphes nommés, qui fournit un moyen logique de séparer les données. Dans Amazon Neptune, vous disposez d'un graphe nommé par défaut et de graphes nommés définis par l'utilisateur. Vous pouvez créer autant de graphes nommés que vous le souhaitez. Collectivement, ils sont appelés RDF ensemble de données. Tous les graphes nommés, qu'ils soient définis par défaut ou définis par l'utilisateur, sont définis par un identifiant de ressource internationalisé (IRI) au sein du RDF jeu de données. Dans Neptune, à moins qu'un utilisateur n'ait déclaré un graphe nommé lors de l'écriture de données, tous les triplets sont considérés comme faisant partie du graphe nommé par défaut.

Il existe plusieurs cas d'utilisation pour les graphes nommés :

• Partitionnement et isolation des données

• Provenance des données

• Gestion des versions

• Inférence

Ce guide se concentre sur le cas d'utilisation du partitionnement des données. Nous recommandons de créer un graphe nommé défini par l'utilisateur pour chaque locataire.

SPARQLoptions de requête à l'aide du HTTP protocole Graph Store

Les exemples de requêtes suivants utilisent le SPARQL protocole et le langage de RDF requête (SPARQL) et le HTTP protocole Graph Store pour interroger ou créer un graphe nommé pour un locataire.

• HTTP GET‒ Pour récupérer un graphique spécifique d'un locataire :

  curl --request GET 'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'

• HTTP PUT‒ Pour créer ou remplacer un graphe nommé spécifique par une charge utile spécifiée dans la demande :

  curl --request PUT -H "Content-Type: text/turtle" \  --data-raw "@prefix ex: http://example.com/ . ex:subject ex:predicate ex:object ." \ 
  'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'

  DansRDF, un objet est un triple.

• HTTP POST‒ Pour créer un nouveau graphe nommé s'il n'en existe pas, ou pour le fusionner avec un graphique existant :

  curl --request POST -H "Content-Type: text/turtle" \
  --data-raw “@prefix ex: http://example.com/ . ex:subject ex:predicate ex:object ." \  
  'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'

Isolation des locataires pour RDF

Pour une isolation logique des données avec les garde-fous nécessaires en place au niveau de la couche application, créez un mappage entre le locataire et les graphes nommés définis par l'utilisateur. Lorsque vous concevez une solution mutualisée pour un RDF ensemble de données, tenez compte des aspects suivants de RDF et : SPARQL

• Dans Neptune, lorsque vous effectuez une requête sans spécifier de graphe nommé, il récupère tous les triplets correspondant au modèle dans tous les graphes nommés de la base de données.

• DansRDF, il n'existe aucune contrainte concernant les connexions entre les nœuds de graphes nommés différents. Par exemple, dans le schéma précédent, un nœud en entrée :G1 peut être connecté à un nœud en : G2 via une arête.

Par exemple, si l'utilisateur final d'un locataire particulier soumet une requête auAPI, il API doit valider les exigences suivantes avant de soumettre la requête à la base de données Neptune :

• Toute requête étendue à un seul locataire doit spécifier un graphe nommé. Dans le cas contraire, vous risquez de divulguer des données entre locataires.

• Les requêtes de mise à jour ou de suppression doivent toujours spécifier un graphe nommé.

• Les nœuds situés de part et d'autre d'une arête ou d'une relation doivent toujours appartenir au graphe nommé correctement.

Pour plus d'informations sur les bonnes pratiques, consultez la documentation de Neptune.