View a markdown version of this page

Modello di piscina per RDF - AWS Guida prescrittiva
Opzioni di interrogazione SPARQL che utilizzano il protocollo HTTP Graph StoreIsolamento dei tenant per RDF

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modello di piscina per RDF

Il Resource Description Framework (RDF) ha il concetto di grafici denominati, che fornisce un modo logico per separare i dati. In Amazon Neptune, hai un grafico con nome predefinito e grafici denominati definiti dall'utente. Puoi creare tutti i grafici con nome che desideri. Collettivamente, sono chiamati set di dati RDF. Tutti i grafici denominati, predefiniti o definiti dall'utente, sono definiti da un Internationalized Resource Identifier (IRI) all'interno del set di dati RDF. In Neptune, a meno che un utente non abbia dichiarato un grafico con nome durante la scrittura dei dati, tutte le triple sono considerate parte del grafico denominato predefinito.

Esistono diversi casi d'uso per i grafici con nome:

  • Partizionamento e isolamento dei dati

  • Provenienza dei dati

  • Controllo delle versioni

  • Inferenza

Questa guida si concentra sul caso d'uso del partizionamento dei dati. Consigliamo di creare un grafico denominato definito dall'utente per ogni tenant.

Opzioni di interrogazione SPARQL che utilizzano il protocollo HTTP Graph Store

Le seguenti query di esempio utilizzano il protocollo SPARQL e il linguaggio di interrogazione RDF (SPARQL) e il protocollo HTTP Graph Store per interrogare o creare un grafico denominato per un tenant.

  • HTTP GET‒ Per recuperare un grafico specifico di un tenant:

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

  • HTTP PUT‒ Per creare o sostituire uno specifico grafico denominato con un payload specificato nella richiesta:

    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'

    In RDF, un oggetto è triplo.

  • HTTP POST‒ Per creare un nuovo grafico con nome, se non ne esiste uno, o fonderlo con un grafo esistente:

    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'

Isolamento dei tenant per RDF

Per l'isolamento logico dei dati con le necessarie protezioni a livello di applicazione, create una mappatura tra il tenant e i grafici denominati definiti dall'utente. Quando progettate la multi-tenancy per un set di dati RDF, tenete presente i seguenti aspetti di RDF e SPARQL:

  • In Neptune, quando si esegue una query senza specificare un grafico denominato, vengono recuperate tutte le triple che corrispondono al modello in tutti i grafici denominati nel database.

  • In RDF, non ci sono vincoli relativi alle connessioni tra nodi di grafici con nomi diversi. Ad esempio, nel diagramma precedente, un nodo in :G1 può essere collegato a un nodo in: attraverso un bordo. G2

Ad esempio, se un utente finale di un determinato tenant invia una query all'API, l'API deve convalidare i seguenti requisiti prima di inviare la query al database Neptune:

  • Qualsiasi query con ambito a un singolo tenant deve specificare un grafico denominato. Altrimenti, rischi di far trapelare dati tra i tenant.

  • Le interrogazioni di aggiornamento o eliminazione devono sempre specificare un grafico denominato.

  • I nodi su entrambi i lati di uno spigolo o di una relazione devono sempre appartenere al grafico con nome corretto.

Per ulteriori informazioni sulle migliori pratiche, consulta la documentazione di Neptune.