Condividi tramite

Uso di un grafo partizionato in Azure Cosmos DB

  • Articolo

SI APPLICA A: Gremlin

Una delle funzionalità principali dell'API per Gremlin in Azure Cosmos DB è la possibilità di gestire grafici su larga scala tramite la scalabilità orizzontale. I contenitori possono essere ridimensionati in modo indipendente sia a livello di archiviazione che di velocità effettiva. È possibile creare contenitori in Azure Cosmos DB che possono essere ridimensionati automaticamente per archiviare i dati di un grafo. I dati vengono bilanciati automaticamente in base alla chiave di partizione specificata.

Il partizionamento viene eseguito internamente se si prevede che il contenitore archivi più di 20 GB o se si vogliono allocare più di 10.000 unità richiesta (UR) al secondo. Il partizionamento dei dati viene eseguito automaticamente in base alla chiave di partizione specificata. La chiave di partizione è necessaria se si creano contenitori di grafi nel portale di Azure oppure con la versione 3.x o superiore dei driver Gremlin. La chiave di partizione non è necessaria se si usa la versione 2.x o precedenti dei driver Gremlin.

Si applicano gli stessi principi generali del meccanismo di partizionamento di Azure Cosmos DB, con alcune ottimizzazioni specifiche del grafo descritte di seguito.

Partizionamento del grafo.

Meccanismo di partizionamento dei grafi

Le linee guida seguenti descrivono la strategia di partizionamento in Azure Cosmos DB:

  • Sia i vertici che gli archi vengono archiviati come documenti JSON.

  • Per i vertici è richiesta una chiave di partizione. Questa chiave determina in quali partizione verrà archiviato il vertice tramite un algoritmo di hash. Il nome della proprietà della chiave di partizione viene definita quando si crea un nuovo contenitore ce ha il formato: /partitioning-key-name.

  • Gli archi verranno archiviati insieme al relativo vertice di origine. In altre parole, per ogni vertice la relativa chiave di partizione definisce la posizione di archiviazione insieme ai relativi archi in uscita. Questa ottimizzazione viene eseguita per evitare query tra partizioni quando si usa la cardinalità out() nelle query su grafo.

  • Gli archi contengono riferimenti ai vertici a cui puntano. Tutti gli archi vengono archiviati con le chiavi di partizione e gli ID dei vertici a cui puntano. Con questo calcolo, tutte le query di direzione out() sono sempre query partizionate con ambito e non query tra partizioni di tipo blind.

  • Per le query sul grafo è necessario specificare una chiave di partizione. Per sfruttare appieno il partizionamento orizzontale in Azure Cosmos DB, è necessario specificare la chiave di partizione quando si seleziona un singolo vertice, ogni volta possibile. Le query seguenti consentono la selezione di uno o più vertici in un grafo partizionato:

    • /id e /label non sono supportati come chiavi di partizione per un contenitore nell'API per Gremlin.

    • Selezione di un vertice in base all'ID, quindi uso del passaggio .has() per specificare la proprietà chiave di partizione:

      g.V('vertex_id').has('partitionKey', 'partitionKey_value')

    • Selezione di un vertice specificando una tupla che include il valore della chiave di partizione e l'ID:

      g.V(['partitionKey_value', 'vertex_id'])

    • Selezione di un set di vertici con i relativi ID e specifica di un elenco di valori di chiavi di partizione:

      g.V('vertex_id0', 'vertex_id1', 'vertex_id2', …).has('partitionKey', within('partitionKey_value0', 'partitionKey_value01', 'partitionKey_value02', …)

    • Uso della strategia di partizionamento all'inizio di una query e specifica di una partizione per l'ambito del resto della query Gremlin:

      g.withStrategies(PartitionStrategy.build().partitionKey('partitionKey').readPartitions('partitionKey_value').create()).V()

Procedure consigliate quando si usa un grafo partizionato

Usare le linee guida seguenti per garantire prestazioni e scalabilità quando si usano grafi partizionati con contenitori illimitati:

  • Specificare sempre il valore della chiave di partizione quando si eseguono query su un vertice. Il recupero di un vertice da una partizione nota è il modo più efficiente in termini di prestazioni. Tutte le successive operazioni di adiacenza avranno sempre come ambito una partizione, perché gli archi contengono un ID riferimento e una chiave di partizione ai vertici di destinazione.

  • Usare la direzione in uscita quando si eseguono query sugli archi ogni volta che è possibile. Come indicato in precedenza, gli archi vengono archiviati con i rispettivi vertici di origine nella direzione in uscita. Ciò significa che le probabilità di ricorrere a query tra partizioni sono ridotte al minimo quando i dati e le query sono progettati tenendo conto di questo meccanismo. Al contrario, la query in() sarà sempre una query dispendiosa di tipo fan-out.

  • Scegliere una chiave di partizione che distribuisce i dati in modo uniforme tra le partizioni. Questa decisione dipende in gran parte dal modello di dati della soluzione. Per altre informazioni sulla creazione di una chiave di partizione appropriata, vedere Partizionamento e ridimensionamento in Azure Cosmos DB.

  • Ottimizzare le query per ottenere i dati entro i limiti di una partizione. Una strategia di partizionamento ottimale deve essere allineata ai modelli per l'esecuzione di query. Le query che ottengono dati da una singola partizione offrono le migliori prestazioni possibili.

Passaggi successivi

Successivamente si può procedere alla lettura degli articoli seguenti: