Partizionamento e scalabilità orizzontale in Azure Cosmos DB

SI APPLICA A: Nosql Mongodb Cassandra Gremlin Tabella

Azure Cosmos DB usa il partizionamento per dimensionare singoli contenitori in un database al fine di soddisfare le esigenze dell'applicazione in termini di prestazioni. Nel partizionamento gli elementi in un contenitore sono suddivisi in subset distinti, denominati partizioni logiche. Le partizioni logiche vengono formate in base al valore di una chiave di partizione associata a ogni elemento in un contenitore. Tutti gli elementi in una partizione logica hanno lo stesso valore di chiave di partizione.

Ad esempio, un contenitore contiene elementi. A ogni elemento è associato un valore univoco per la proprietà UserID. Se UserID funge da chiave di partizione per gli elementi in un contenitore e se sono presenti 1.000 valori UserID univoci, vengono create 1.000 partizioni logiche per il contenitore.

Oltre a una chiave di partizione che determina la partizione logica dell'elemento, ogni elemento in un contenitore ha un ID elemento (univoco all'interno di una partizione logica). La combinazione di chiave di partizione e ID elemento crea l'indice dell'elemento, che identifica l'elemento in modo univoco. La scelta di una chiave di partizione è una decisione importante che influirà sulle prestazioni dell'applicazione.

Questo articolo illustra la relazione tra partizioni logiche e fisiche. Illustra anche le procedure consigliate per il partizionamento e offre una visualizzazione approfondita del funzionamento del ridimensionamento orizzontale in Azure Cosmos DB. Non è necessario comprendere questi dettagli interni per selezionare la chiave di partizione, ma sono stati trattati in modo da avere chiarezza sul funzionamento di Azure Cosmos DB.

Partizioni logiche

Una partizione logica è costituita da un set di elementi che hanno la stessa chiave di partizione. Ad esempio, in un contenitore che contiene dati sull'alimentazione, tutti gli elementi contengono una proprietà foodGroup. È possibile usare foodGroup come chiave di partizione per il contenitore. I gruppi di elementi con valori specifici per foodGroup, ad esempio Beef Products, Baked Products e Sausages and Luncheon Meats, formano partizioni logiche distinte.

Una partizione logica definisce anche l'ambito delle transazioni di database. È possibile aggiornare gli elementi all'interno di una partizione logica usando una transazione con isolamento dello snapshot. Quando vengono aggiunti nuovi elementi a un contenitore, le nuove partizioni logiche vengono create in modo trasparente dal sistema. Non è necessario preoccuparsi di eliminare una partizione logica quando i dati sottostanti vengono eliminati.

Non esiste alcun limite al numero di partizioni logiche nel contenitore. Ogni partizione logica può archiviare fino a 20 GB di dati. Le scelte valide per la chiave di partizione hanno un'ampia gamma di valori possibili. Ad esempio, in un contenitore in cui tutti gli elementi contengono una foodGroup proprietà, i dati all'interno della Beef Products partizione logica possono aumentare fino a 20 GB. La selezione di una chiave di partizione con un'ampia gamma di valori possibili garantisce che il contenitore sia in grado di ridimensionare.

È possibile usare gli avvisi di Monitoraggio di Azure per monitorare se le dimensioni di una partizione logica si avvicinano a 20 GB.

Partizioni fisiche

Un contenitore viene dimensionato distribuendo dati e velocità effettiva tra partizioni fisiche. Internamente, una o più partizioni logiche vengono associate a una singola partizione fisica. In genere i contenitori più piccoli includono molte partizioni logiche, ma richiedono solo una singola partizione fisica. A differenza delle partizioni logiche, le partizioni fisiche sono un'implementazione interna del sistema e sono interamente gestite da Azure Cosmos DB.

Il numero di partizioni fisiche nel contenitore dipende da quanto segue:

  • La quantità di velocità effettiva di cui è stato effettuato il provisioning (ogni singola partizione fisica può fornire una velocità effettiva fino a 10.000 unità richiesta al secondo). Il limite di 10.000 UR/s per le partizioni fisiche implica che anche le partizioni logiche prevedono un limite di 10.000 UR/s, dal momento che ogni partizione logica viene associata a una sola partizione fisica.

  • Spazio totale di archiviazione dei dati (ogni singola partizione fisica può archiviare fino a 50 GB di dati).

Nota

Le partizioni fisiche sono un'implementazione interna del sistema e sono interamente gestite da Azure Cosmos DB. Durante lo sviluppo delle soluzioni, non è necessario concentrarsi sulle partizioni fisiche perché non è possibile controllarle, ma ci si deve concentrare sulle chiavi di partizione. Se si sceglie una chiave di partizione che distribuisce in modo uniforme l'utilizzo della velocità effettiva tra partizioni logiche, si garantisce che l'utilizzo della velocità effettiva tra partizioni fisiche sia bilanciato.

Non esiste alcun limite al numero totale di partizioni fisiche nel contenitore. Man mano che aumenta la velocità effettiva o le dimensioni dei dati di cui è stato effettuato il provisioning, Azure Cosmos DB creerà automaticamente nuove partizioni fisiche suddividendo quelle esistenti. Le divisioni delle partizioni fisiche non influiscono sulla disponibilità dell'applicazione. Dopo la suddivisione della partizione fisica, tutti i dati all'interno di una singola partizione logica verranno comunque archiviati nella stessa partizione fisica. Una divisione di partizione fisica crea semplicemente un nuovo mapping di partizioni logiche a partizioni fisiche.

La velocità effettiva di cui è stato effettuato il provisioning per un contenitore è divisa in modo uniforme tra le partizioni fisiche. Quando una chiave di partizione non distribuisce le richieste in modo uniforme, è possibile che un numero eccessivo di richieste indirizzate a un piccolo subset di partizioni diventino "ad accesso frequente". Le partizioni ad accesso frequente comportano un uso inefficiente della velocità effettiva di cui è stato effettuato il provisioning, che potrebbe comportare una limitazione della velocità e un incremento dei costi.

È possibile visualizzare le partizioni fisiche del contenitore nella sezione Archiviazione del pannello Metriche del portale di Azure:

Visualizzazione del numero di partizioni fisiche

Nello screenshot precedente, un contenitore ha /foodGroup come chiave di partizione. Ognuna delle tre barre del grafico rappresenta una partizione fisica. Nell'immagine l'intervallo di chiavi di partizione corrisponde a una partizione fisica. La partizione fisica selezionata contiene le prime 3 partizioni logiche più significative: Beef Products, Vegetable and Vegetable Productse Soups, Sauces, and Gravies.

Se si effettua il provisioning di una velocità effettiva di 18.000 unità richiesta al secondo (UR/sec), ognuna delle tre partizioni fisiche può usare 1/3 della velocità effettiva totale con provisioning. All'interno della partizione fisica selezionata, le chiavi Beef Productsdi partizione logica , Vegetable and Vegetable Productse Soups, Sauces, and Gravies possono, collettivamente, usare le 6.000 UR/sec di cui è stato effettuato il provisioning della partizione fisica. Poiché la velocità effettiva con provisioning è divisa uniformemente tra le partizioni fisiche del contenitore, è importante scegliere una chiave di partizione che distribuisca in modo uniforme il consumo di velocità effettiva scegliendo la chiave di partizione logica corretta.

Gestione delle partizioni logiche

Azure Cosmos DB gestisce in modo trasparente e automatico il posizionamento di partizioni logiche in partizioni fisiche per soddisfare in modo efficiente le esigenze di scalabilità e prestazioni del contenitore. Man mano che aumentano i requisiti di velocità effettiva e archiviazione di un'applicazione, Azure Cosmos DB sposta le partizioni logiche per distribuire automaticamente il carico tra un numero maggiore di partizioni fisiche. Altre informazioni sulle partizioni fisiche.

Azure Cosmos DB usa il partizionamento basato su hash per distribuire partizioni logiche tra partizioni fisiche. Azure Cosmos DB esegue l'hash del valore della chiave di partizione di un elemento. Il risultato con hash determina la partizione fisica. Azure Cosmos DB alloca quindi lo spazio delle chiavi di hash delle chiavi di partizione in modo uniforme tra le partizioni fisiche.

Le transazioni (in stored procedure o trigger) sono consentite solo per gli elementi in una singola partizione logica.

Set di repliche

Ogni partizione fisica è costituita da un set di repliche, detto anche set di repliche. Ogni replica ospita un'istanza del motore di database. Un set di repliche rende i dati archiviati all'interno della partizione fisica durevoli, a disponibilità elevata e coerenti. Ogni replica che costituisce la partizione fisica eredita la quota di archiviazione della partizione. Tutte le repliche di una partizione fisica supportano collettivamente la velocità effettiva allocata alla partizione fisica. Azure Cosmos DB gestisce automaticamente i set di repliche.

In genere, i contenitori più piccoli richiedono solo una singola partizione fisica, ma avranno comunque almeno 4 repliche.

L'immagine seguente mostra il mapping delle partizioni logiche alle partizioni fisiche distribuite a livello globale. Il set di partizioni nell'immagine fa riferimento a un gruppo di partizioni fisiche che gestiscono le stesse chiavi di partizione logica in più aree:

Immagine che illustra il partizionamento di Azure Cosmos DB

Scegliere una chiave di partizione

Una chiave di partizione include due componenti: il percorso della chiave di partizione e il valore della chiave di partizione. Si consideri ad esempio un elemento { "userId" : "Andrew", "worksFor": "Microsoft" }. Se si sceglie "userId" come chiave di partizione, i due componenti della chiave di partizione saranno i seguenti:

  • Percorso della chiave di partizione (ad esempio: "/userId"). Il percorso della chiave di partizione accetta caratteri alfanumerici e caratteri di sottolineatura (_). È anche possibile usare oggetti annidati usando la notazione di percorso standard (/).

  • Valore della chiave di partizione (ad esempio: "Andrew"). Il valore della chiave di partizione può essere di tipo stringa o numerico.

Per informazioni sui limiti di velocità effettiva, archiviazione e lunghezza della chiave di partizione, vedere l'articolo Quote del servizio Azure Cosmos DB .

La selezione della chiave di partizione è una scelta di progettazione semplice ma importante in Azure Cosmos DB. Dopo aver selezionato la chiave di partizione, non è possibile modificarla localmente. Per modificare la chiave di partizione, sarà necessario spostare i dati in un nuovo contenitore con la nuova chiave di partizione desiderata. I processi di copia del contenitore sono utili per questo processo.

Per tutti i contenitori, la chiave di partizione deve avere le caratteristiche seguenti:

  • Essere una proprietà con un valore che non cambia. Se la chiave di partizione è una proprietà, non è possibile aggiornarne il valore.

  • Deve contenere String solo valori , o i numeri devono essere convertiti idealmente in un Stringoggetto , se è possibile che si trovino al di fuori dei limiti dei numeri di precisione doppia in base a IEEE 754 binary64. La specifica Json chiama i motivi per cui l'uso di numeri al di fuori di questo limite in generale è una procedura non valida a causa di probabili problemi di interoperabilità. Questi problemi sono particolarmente rilevanti per la colonna della chiave di partizione, perché non è modificabile e richiede la migrazione dei dati per modificarla in un secondo momento.

  • Avere una cardinalità elevata. In altre parole, la proprietà deve prevedere un'ampia gamma di valori possibili.

  • Ripartire in modo uniforme l'utilizzo dell'unità richiesta (UR) e l'archiviazione dati in tutte le partizioni logiche. Questo garantisce una distribuzione uniforme dell'utilizzo UR e dello spazio di archiviazione tra le partizioni fisiche.

Se sono necessarie transazioni ACID multi-item in Azure Cosmos DB, è necessario usare stored procedure o trigger. Tutte le stored procedure e i trigger basati su JavaScript sono con ambito in una singola partizione logica.

Nota

Se si dispone di una sola partizione fisica, il valore della chiave di partizione potrebbe non essere rilevante come tutte le query verranno destinate alla stessa partizione fisica.

Chiavi di partizione per contenitori con intensa attività di lettura

Per la maggior parte dei contenitori, tutti i criteri precedenti devono essere considerati quando si sceglie una chiave di partizione. Per contenitori di grandi dimensioni, tuttavia, è possibile scegliere una chiave di partizione che viene visualizzata spesso come filtro nelle query. Affinché le query vengano instradate in modo efficiente solo alle partizioni fisiche pertinenti, includere la chiave di partizione nel predicato del filtro.

Se la maggior parte delle richieste di carico di lavoro è costituita da query e la maggior parte delle query dispone di un filtro di uguaglianza nella stessa proprietà, questa proprietà può essere una buona soluzione come chiave di partizione. Ad esempio, se si esegue spesso una query che filtra in UserID, selezionare UserID come chiave di partizione ridurrebbe il numero di query tra partizioni.

Se tuttavia il contenitore è piccolo, probabilmente non si dispone di un numero di partizioni fisiche tale da creare preoccupazione per l'impatto sulle prestazioni delle query tra partizioni. La maggior parte dei contenitori di piccole dimensioni in Azure Cosmos DB richiede solo una o due partizioni fisiche.

Se esiste la possibilità che il contenitore si estenda a un numero di partizioni fisiche più elevato, è necessario assicurarsi di selezionare una chiave di partizione che riduca al minimo le query tra partizioni. Il contenitore richiederà un numero di partizioni fisiche più elevato se si verifica una delle condizioni seguenti:

  • Provisioning di oltre 30.000 UR nel contenitore

  • Archiviazione di oltre 100 GB di dati nel contenitore

Usare l'ID elemento come chiave di partizione

Se il contenitore ha una proprietà con un'ampia gamma di valori possibili, è probabilmente una scelta ottimale per la chiave di partizione. Un esempio possibile di una proprietà di questo tipo è rappresentato dall'ID elemento. Per contenitori di piccole dimensioni con intensa attività di lettura o contenitori con intensa attività di scrittura di qualsiasi dimensione, l'ID elemento è un'ottima scelta come chiave di partizione.

L'ID elemento di una proprietà di sistema è presente in ogni elemento di un contenitore. Anche altre proprietà possono rappresentare un ID logico di un elemento. In molti casi, queste costituiscono anche ottime scelte come chiave di partizione per gli stessi motivi dell'ID elemento.

L'ID elemento rappresenta un'ottima scelta come chiave di partizione per i motivi seguenti:

  • Esiste un'ampia gamma di valori possibili (un ID elemento univoco per ogni elemento).
  • Poiché esiste un ID elemento univoco per ogni elemento, l'ID elemento è la soluzione ideale per bilanciare in modo uniforme l'uso UR e l'archiviazione dati.
  • È possibile eseguire letture di punti in modo semplice ed efficiente perché si conoscerà sempre la chiave di partizione di un elemento se si conosce il relativo ID elemento.

Di seguito vengono elencati alcuni aspetti di cui tenere conto se si seleziona l'ID elemento come chiave di partizione:

  • Se viene usato come chiave di partizione, l'ID elemento diventerà un identificatore univoco nell'intero contenitore. Non sarà possibile avere elementi con ID elemento duplicato.
  • Se si dispone di un contenitore con intensa attività di lettura con molte partizioni fisiche, le query saranno più efficienti se disporranno di un filtro di uguaglianza con l'ID elemento.
  • Non è possibile eseguire stored procedure o trigger in più partizioni logiche.

Passaggi successivi