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. Gli elementi in un contenitore sono suddivisi in sottoinsiemi 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 influisce 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 sul 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 l'isolamento dello snapshot. Quando vengono aggiunti nuovi elementi a un contenitore, il sistema crea in modo trasparente nuove partizioni logiche. Non è necessario preoccuparsi di eliminare una partizione logica quando i dati sottostanti vengono eliminati.

Nel contenitore non è previsto alcun limite al numero di partizioni logiche. Ogni partizione logica può archiviare fino a 20 GB di dati. Le scelte di chiave di partizione valide 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 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 Azure Cosmos DB gestisce interamente le partizioni fisiche.

Il numero di partizioni fisiche nel contenitore dipende dalle caratteristiche seguenti:

• Quantità di velocità effettiva con provisioning (ogni singola partizione fisica può fornire una velocità effettiva fino a 10.000 unità di 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.

• L'archiviazione totale 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 è previsto alcun limite al numero totale di partizioni fisiche nel contenitore. Man mano che la velocità effettiva o le dimensioni dei dati di cui è stato effettuato il provisioning, Azure Cosmos DB crea automaticamente nuove partizioni fisiche suddividendole quelle esistenti. Le suddivisioni di 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 alle 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:

Si consideri ad esempio un contenitore con il percorso /foodGroup specificato come chiave di partizione. Il contenitore potrebbe avere un numero qualsiasi di partizioni fisiche, ma in questo esempio si presuppone che abbia tre. Una singola partizione fisica può contenere più chiavi di partizione. Ad esempio, la partizione fisica più grande potrebbe contenere le prime tre partizioni logiche più significative: Beef Products, Vegetable and Vegetable Productse Soups, Sauces, and Gravies.

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

Gestione delle partizioni logiche

Azure Cosmos DB in modo trasparente e gestisce automaticamente la posizione delle partizioni logiche nelle partizioni fisiche per soddisfare in modo efficiente le esigenze di scalabilità e prestazioni del contenitore. Poiché i requisiti di velocità effettiva e archiviazione di un'applicazione aumentano, Azure Cosmos DB sposta le partizioni logiche per distribuire automaticamente il carico in un numero maggiore di partizioni fisiche. Altre informazioni sulle partizioni fisiche sono disponibili.

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 hashed determina la partizione fisica. Azure Cosmos DB alloca quindi lo spazio chiave degli 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, definito anche set di repliche. Ogni replica ospita un'istanza del motore di database. Un set di repliche rende l'archivio dati all'interno della partizione fisica durevole, a disponibilità elevata e coerente. 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 hanno comunque almeno quattro repliche.

L'immagine seguente illustra come vengono mappate le 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:

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 della velocità effettiva, dell'archiviazione e della 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 sul posto. 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 di numeri a precisione doppia in base a IEEE 754 binary64. La specifica Json indica 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 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. Questa ripartizione garantisce anche la distribuzione uniforme dell'utilizzo di UR e dello spazio di archiviazione tra le partizioni fisiche.

• I valori non maggiori di 2048 byte sono in genere o 101 byte se le chiavi di partizione di grandi dimensioni non sono abilitate. Per altre informazioni, vedere Chiavi di partizione di grandi dimensioni

Se sono necessarie transazioni ACID a più elementi in Azure Cosmos DB, è necessario usare stored procedure o trigger. Tutte le stored procedure e i trigger basati su JavaScript hanno come ambito una singola partizione logica.

Nota

Se si dispone di una sola partizione fisica, il valore della chiave di partizione potrebbe non essere rilevante perché tutte le query avranno come destinazione la stessa partizione fisica.

Chiavi di partizione per contenitori con intensa attività di lettura

Per la maggior parte dei contenitori, i criteri precedenti sono tutti da considerare quando si sceglie una chiave di partizione. Per i contenitori di grandi dimensioni con operazioni di lettura, tuttavia, potrebbe essere necessario 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.

Questa proprietà può essere una scelta valida per la chiave di partizione se la maggior parte delle richieste del carico di lavoro sono query e la maggior parte delle query ha un filtro di uguaglianza sulla stessa proprietà. Ad esempio, se si esegue spesso una query che filtra in UserID, la selezione UserID come chiave di partizione ridurrà il numero di query tra partizioni.

Tuttavia, se il contenitore è di dimensioni ridotte, è probabile che non siano presenti partizioni fisiche sufficienti per preoccuparsi delle 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 richiede più di alcune partizioni fisiche quando una delle condizioni seguenti è vera:

• È stato effettuato il provisioning di oltre 30.000 UR nel contenitore

• Il contenitore archivia più di 100 GB di dati

Usare l'ID elemento come chiave di partizione

Nota

Questa sezione si applica principalmente all'API per NoSQL. Altre API, ad esempio l'API per Gremlin, non supportano l'identificatore univoco come chiave di partizione.

Se il contenitore ha una proprietà con un'ampia gamma di valori possibili, è probabile che sia 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 o contenitori con un numero elevato di operazioni di scrittura, l'ID elemento (/id) è naturalmente un'ottima scelta per la 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, questi ID sono anche ottime scelte di 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é è presente un ID elemento univoco per elemento, l'ID elemento offre un ottimo lavoro per bilanciare uniformemente il consumo di UR e l'archiviazione dei dati.
• È possibile eseguire facilmente letture efficienti dei punti perché si conosce 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 l'ID elemento è la chiave di partizione, diventa un identificatore univoco nell'intero contenitore. Non è possibile creare elementi con ID elemento duplicati.
• Se si dispone di un contenitore con un numero elevato di letture con molte partizioni fisiche, le query sono più efficienti se hanno un filtro di uguaglianza con l'ID elemento.
• Non è possibile eseguire stored procedure o trigger destinati a più partizioni logiche.

Passaggi successivi

• Informazioni sulla velocità effettiva con provisioning in Azure Cosmos DB.
• Informazioni sulla distribuzione globale in Azure Cosmos DB.
• Vedere il modulo di training su come modellare e partizionare i dati in Azure Cosmos DB.