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 il ridimensionamento 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 il contenitore deve archiviare più di 20 GB di dimensioni o se si desidera allocare più di 10.000 unità di richiesta al secondo (UR). I dati vengono partizionati automaticamente in base alla chiave di partizione specificata. La chiave di partizione è necessaria se si creano contenitori di grafo dalla portale di Azure o dalle versioni 3.x o successive dei driver Gremlin. La chiave di partizione non è necessaria se si usano versioni 2.x o successive dei driver Gremlin.

Gli stessi principi generali del meccanismo di partizionamento di Azure Cosmos DB si applicano con alcune ottimizzazioni specifiche del grafo descritte di seguito.

Partizionamento grafico.

Meccanismo di partizionamento grafico

Le linee guida seguenti descrivono come funziona 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 definito durante la creazione di un nuovo contenitore e ha un 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 out() cardinalità nelle query dei grafici.

  • I bordi contengono riferimenti ai vertici a cui puntano. Tutti i bordi vengono archiviati con le chiavi di partizione e gli ID dei vertici a cui puntano. Questo calcolo rende sempre tutte le out() query di direzione una query partizionata con ambito e non una query tra partizioni cieco.

  • 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 in 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 specificare un elenco di valori chiave di partizione:

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

    • Usando la strategia di partizione all'inizio di una query e specificando 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 operazioni di adjacency successive verranno sempre con ambito a una partizione poiché i bordi contengono ID di riferimento e 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 in() query sarà sempre una query di fan-out costosa.

  • 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: