Modellazione dei dati graph con Azure Cosmos DB per Apache Gremlin

  • Articolo

SI APPLICA A: Gremlin

Questo articolo fornisce raccomandazioni per l'uso di modelli di dati graph. Queste procedure consigliate sono fondamentali per garantire la scalabilità e le prestazioni di un sistema di database a grafo man mano che i dati si evolve. Un modello di dati efficiente è particolarmente importante per i grafici su larga scala.

Requisiti

Il processo descritto in questa guida è basato sui presupposti seguenti:

  • Le entità nello spazio del problema sono identificate. Queste entità devono essere utilizzate in modo atomico per ogni richiesta. Questo significa che il sistema di database non è progettato per il recupero dei dati di una singola entità in più richieste di query.
  • È disponibile una conoscenza dei requisiti di lettura e scrittura per il sistema di database. Questi requisiti guidano le ottimizzazioni necessarie per il modello di dati graph.
  • I principi dello standard per grafi di proprietà Apache Tinkerpop sono stati compresi.

Quando è necessario un database a grafo?

Una soluzione di database a grafo può essere usata in modo ottimale se le entità e le relazioni in un dominio dati hanno una delle caratteristiche seguenti:

  • Le entità sono altamente connesse tramite relazioni descrittive. Il vantaggio in questo scenario è che le relazioni vengono mantenute nell'archiviazione.
  • Sono presenti relazioni cicliche o entità che fanno riferimento a se stesse. Questo modello è spesso una sfida quando si usano database relazionali o documenti.
  • Sono presenti relazioni a evoluzione dinamica tra le entità. Questo criterio è applicabile soprattutto a dati gerarchici o con struttura ad albero con numerosi livelli.
  • Sono presenti relazioni molti-a-molti tra le entità.
  • Sono presenti requisiti di scrittura e lettura per entità e relazioni.

Se i criteri precedenti sono soddisfatti, un approccio di database a grafo offre probabilmente vantaggi per la complessità delle query, la scalabilità del modello di dati e le prestazioni delle query.

Il passaggio successivo consiste nel determinare se il grafo verrà usato per scopi analitici o transazionali. Se il grafico è destinato a essere usato per carichi di lavoro di calcolo e elaborazione dati pesanti, vale la pena esplorare il connettore Spark Cosmos DB e la libreria GraphX.

Come usare gli oggetti del grafo

Lo standard della proprietà Apache Tinkerpop definisce due tipi di oggetti: vertici e bordi.

Di seguito sono riportate le procedure consigliate per le proprietà negli oggetti graph:

Oggetto Proprietà Type Note
Vertice ID string Imposto in modo univoco per partizione. Se un valore non viene fornito al momento dell'inserimento, viene archiviato un GUID generato automaticamente.
Vertice Etichetta string Questa proprietà viene usata per definire il tipo di entità rappresentata dal vertice. Se non viene specificato un valore, viene usato un vertice di valore predefinito.
Vertice Proprietà Stringa, booleana, numerica Elenco di proprietà separate archiviate come coppie chiave-valore in ogni vertice.
Vertice Chiave di partizione Stringa, booleana, numerica Questa proprietà definisce la posizione in cui vengono archiviati i vertici e i relativi bordi in uscita. Per altre informazioni, vedere l'articolo sul partizionamento di grafi.
Microsoft Edge ID string Imposto in modo univoco per partizione. Generato automaticamente per impostazione predefinita. I bordi in genere non devono essere recuperati in modo univoco da un ID.
Microsoft Edge Etichetta string Questa proprietà viene usata per definire il tipo di relazione tra due vertici.
Microsoft Edge Proprietà Stringa, booleana, numerica Elenco di proprietà separate archiviate come coppie chiave-valore in ogni arco.

Nota

I bordi non richiedono un valore chiave di partizione, poiché il valore viene assegnato automaticamente in base al vertice di origine. Altre informazioni sull'uso di un grafico partizionato in Azure Cosmos DB.

Linee guida per la modellazione di entità e relazioni

Le linee guida seguenti consentono di approcciarsi alla modellazione dei dati per un database del grafico azure Cosmos DB per Apache Gremlin . Queste linee guida presuppongono l'esistenza di una definizione di un dominio di dati e di query per tale dominio.

Nota

I passaggi seguenti vengono presentati come raccomandazioni. È consigliabile valutare e testare il modello finale prima di considerarlo come pronto per la produzione. Inoltre, le raccomandazioni sono specifiche per l'implementazione dell'API Gremlin di Azure Cosmos DB.

Modellazione di vertici e proprietà

Il primo passaggio per la creazione di un modello di dati del grafo consiste nell'eseguire il mapping di ogni entità identificata a un oggetto vertice. Un mapping uno-a-uno di tutte le entità ai vertici deve essere un passaggio iniziale e soggetto a modifiche.

Un errore comune consiste nell'eseguire il mapping delle proprietà di una singola entità come vertici separati. Si consideri l'esempio seguente, in cui la stessa entità è rappresentata in due modi diversi:

  • Proprietà basate su vertice: in questo approccio l'entità usa tre vertici separati e due bordi per descrivere le relative proprietà. Pur riducendo la ridondanza, questo approccio implica un incremento della complessità del modello e di conseguenza una maggiore latenza, una maggiore complessità delle query e un aumento del costo di calcolo. Questo modello può anche presentare problemi relativi al partizionamento.

    Diagramma del modello di entità con vertici per le proprietà.

  • Vertici incorporati in proprietà: questo approccio sfrutta l'elenco di coppie chiave-valore per rappresentare tutte le proprietà dell'entità all'interno di un vertice. Questo approccio riduce la complessità del modello, che comporta query più semplici e attraversamenti più efficienti in termini di costi.

    Diagramma del vertice luis dal diagramma precedente con ID, etichetta e proprietà.

Nota

I diagrammi precedenti mostrano un modello di grafo semplificato che confronta solo i due modi di dividere le proprietà dell'entità.

Il criterio basato su vertici incorporati nelle proprietà offre in genere un approccio più scalabile ed efficiente dal punto di vista delle prestazioni. L'approccio predefinito a un nuovo modello di dati grafico deve gravitare verso questo modello.

Tuttavia, ci sono scenari in cui fare riferimento a una proprietà potrebbe offrire vantaggi. Ad esempio, se la proprietà a cui si fa riferimento viene aggiornata di frequente. Usare un vertice separato per rappresentare una proprietà che cambia costantemente per ridurre al minimo la quantità di operazioni di scrittura necessarie per l'aggiornamento.

Modelli di relazione con direzioni perimetrali

Dopo aver modellato i vertici è possibile aggiungere gli archi per denotare le relazioni tra loro. Il primo aspetto da valutare è la direzione della relazione.

Gli oggetti Edge hanno una direzione predefinita seguita da un attraversamento quando si usano le out() funzioni o outE() . L'uso della direzione naturale contribuisce all'efficienza dell'operazione perché tutti i vertici vengono archiviati con gli archi in uscita.

Tuttavia, l'attraversamento nella direzione opposta di un bordo, usando la in() funzione, comporta sempre una query tra partizioni. Per altre informazioni, vedere l'articolo sul partizionamento di grafi. Se è necessario eseguire costantemente attraversamenti con la funzione in(), è consigliabile aggiungere archi in entrambe le direzioni.

È possibile determinare la direzione perimetrale usando i .to() predicati o .from() con il .addE() passaggio Gremlin. In alternativa, è possibile usare la libreria dell'executor bulk per l'API Gremlin.

Nota

Agli oggetti arco è assegnata una direzione per impostazione predefinita.

Etichette di relazione

L'uso di etichette di relazione descrittive consente di migliorare l'efficienza delle operazioni di risoluzione degli archi. È possibile applicare questo modello nei modi seguenti:

  • Usare termini non generici per etichettare una relazione.
  • Associare l'etichetta del vertice di origine per l'etichetta del vertice di destinazione con il nome della relazione.

Diagramma degli esempi di etichettatura delle relazioni.

Più specifica l'etichetta usata dall'attraversatore per filtrare i bordi, meglio. Questa decisione può avere un effetto significativo anche sul costo della query. È possibile valutare il costo della query in qualsiasi momento usando il passaggio executionProfile.

Passaggi successivi