Condividi tramite

Partizionamento e scalabilità orizzontale in Azure Cosmos DB

Azure Cosmos DB usa il partizionamento per ridimensionare i contenitori in un database per soddisfare le esigenze di prestazioni dell'applicazione. Gli elementi in un contenitore sono suddivisi in sottoinsiemi distinti denominati partizioni logiche. Le partizioni logiche si formano 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 della chiave di partizione.

Ad esempio, un contenitore contiene elementi. Ogni elemento ha un valore univoco per la proprietà UserID. Se UserID funge da chiave di partizione per gli elementi nel contenitore e sono presenti 1.000 valori UserID univoci, vengono create 1.000 partizioni logiche per il contenitore.

Ogni elemento in un contenitore ha una chiave di partizione che determina la partizione logica e un ID elemento univoco all'interno di tale partizione. La combinazione della chiave di partizione e dell'ID elemento crea l'indice dell'elemento, che identifica in modo univoco l'elemento. 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 le procedure consigliate per il partizionamento e fornisce 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 questo articolo illustra come funziona Azure Cosmos DB.

Partizioni logiche

Una partizione logica è un insieme di elementi che condividono la stessa chiave di partizione. Ad esempio, in un contenitore che include dati sull'alimentazione, tutti gli elementi contengono una proprietà foodGroup. 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 tramite una transazione con isolamento dello snapshot. Quando vengono aggiunti nuovi elementi a un contenitore, il sistema crea nuove partizioni logiche in modo trasparente. Non è necessario preoccuparsi dell'eliminazione di una partizione logica quando vengono eliminati i dati sottostanti.

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

È 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 si ridimensiona distribuendo dati e velocità effettiva tra partizioni fisiche. Internamente, viene eseguito il mapping di una o più partizioni logiche a una singola partizione fisica. In genere, i contenitori più piccoli hanno molte partizioni logiche ma richiedono una sola partizione fisica. A differenza delle partizioni logiche, le partizioni fisiche sono un'implementazione di sistema interna e Azure Cosmos DB le gestisce completamente.

Il numero di partizioni fisiche in un contenitore dipende da queste caratteristiche:

  • Valore di velocità effettiva con 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 hanno un limite di 10.000 UR/s, poiché viene eseguito il mapping di ogni partizione logica solo a una partizione fisica.

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

Note

Le partizioni fisiche sono un'implementazione di sistema interna, completamente gestita da Azure Cosmos DB. Quando si sviluppano soluzioni, non concentrarsi sulle partizioni fisiche perché non è possibile controllarle. Concentrarsi invece sulle chiavi di partizione. La scelta di una chiave di partizione che distribuisca uniformemente il consumo di velocità effettiva tra partizioni logiche garantisce un consumo bilanciato di velocità effettiva tra partizioni fisiche.

Non esiste alcun limite al numero totale di partizioni fisiche in un contenitore. Man mano che la velocità effettiva o le dimensioni dei dati di cui è stato effettuato il provisioning aumentano, Azure Cosmos DB crea automaticamente nuove partizioni fisiche dividendo quelle esistenti. Le divisioni delle partizioni fisiche non influiscono sulla disponibilità dell'applicazione. Dopo la divisione 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 eseguito il provisioning per un contenitore si divide uniformemente tra partizioni fisiche. Il progetto di una chiave di partizione che non distribuisce le richieste in modo uniforme potrebbe comportare troppe richieste indirizzate a un piccolo sottoinsieme di partizioni che diventano "ad accesso frequente". Le partizioni ad accesso frequente causano un uso inefficiente della velocità effettiva di cui è stato eseguito il provisioning, il che può comportare una limitazione della velocità e costi più elevati.

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 presupporrà che ne abbia tre. Una singola partizione fisica può contenere più chiavi di partizione. Ad esempio, la partizione fisica più grande può contenere le prime tre partizioni logiche di dimensioni maggiori: Beef Products, Vegetable and Vegetable Products e 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ò usare un terzo della velocità effettiva totale di cui è stato eseguito il provisioning. All'interno della partizione fisica selezionata, le chiavi di partizione logica Beef Products, Vegetable and Vegetable Products e Soups, Sauces, and Gravies possono usare collettivamente le 6.000 UR/sec della partizione fisica di cui è stato effettuato il provisioning. 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. Per ulteriori informazioni, vedere Scelta della chiave di partizione logica corretta.

Gestione delle partizioni logiche

Azure Cosmos DB gestisce automaticamente il posizionamento delle partizioni logiche su partizioni fisiche per soddisfare le esigenze di scalabilità e di prestazioni del contenitore. Con l'aumento dei requisiti di archiviazione e di velocità effettiva di un'applicazione, Azure Cosmos DB consente di spostare le partizioni logiche per distribuire 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 le partizioni logiche tra le partizioni fisiche. Azure Cosmos DB esegue l'hash del valore della chiave di partizione di un elemento. Il risultato con hash determina la partizione logica. Quindi, Azure Cosmos DB alloca lo spazio chiave degli hash delle chiavi di partizione in modo uniforme tra le partizioni fisiche.

Le transazioni stored procedure o trigger sono consentite solo sugli elementi all'interno di una singola partizione logica.

Set di repliche

Ogni partizione fisica è costituita da un insieme di repliche, detto anche set di repliche. Ogni replica ospita un'istanza del motore di database. Un set di repliche rende i dati archiviati nella partizione fisica durevoli, altamente disponibili e coerenti. Ogni replica nella partizione fisica eredita la quota di archiviazione della partizione. Tutte 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 una singola partizione fisica, ma hanno comunque almeno quattro repliche.

Questa immagine mostra come viene eseguito 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:

Diagramma che mostra il partizionamento di Azure Cosmos DB.

Scegliere una chiave di partizione

Una chiave di partizione ha 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; di seguito sono indicati i due componenti della chiave di partizione:

  • Percorso della chiave di partizione (ad esempio: "/userId"). Il percorso della chiave di partizione accetta caratteri alfanumerici e caratteri trattino basso (_). È anche possibile utilizzare 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, sull'archiviazione e sulla 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. Se è necessario modificare la chiave di partizione, spostare i dati in un nuovo contenitore con la chiave di partizione desiderata. Le operazioni di copia dei contenitori aiutano in questo processo. In alternativa, è possibile aggiungere indici secondari globali (anteprima) per creare copie dei dati con chiavi di partizione diverse ottimizzate per modelli di query specifici.

Per tutti i contenitori, la chiave di partizione deve:

  • Una proprietà con un valore invariabile. Se una proprietà è la chiave di partizione, non è possibile aggiornare il valore di tale proprietà.

  • Contenere solo valori String, oppure numeri di conversione in un String se potrebbero superare i limiti dei numeri a precisione doppia in base a IEEE (Institute of Electrical and Electronics Engineers) 754 binary64. La specifica Json spiega perché l'uso di numeri esterni a questo limite è una procedura non valida a causa di problemi di interoperabilità. Questi problemi sono particolarmente rilevanti per la colonna chiave della partizione, poiché è invariabile e richiede la migrazione dei dati per la modifica in un secondo momento.

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

  • Distribuire l'uso delle unità di richiesta (UR) e l'archiviazione dei dati in maniera omogenea 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.

  • In genere, i valori non superano i 2048 byte, o 101 byte se le chiavi di partizione di grandi dimensioni non sono abilitate. Per ulteriori informazioni, vedere Chiavi di partizione di grandi dimensioni

Se si necessita di 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.

Note

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

Tipi di chiavi di partizione

Strategia di partizionamento Quando utilizzare Vantaggi Svantaggi
Chiave di partizione normale, ad esempio, CustomerId, OrderId Usare quando la chiave di partizione ha cardinalità elevata e si allinea ai modelli di query, ad esempio filtrando in base a CustomerId. Adatto per carichi di lavoro in cui le query sono destinate principalmente ai dati di un singolo cliente, ad esempio il recupero di tutti gli ordini per un cliente. Semplice da gestire. Query efficienti quando il modello di accesso corrisponde alla chiave di partizione, ad esempio eseguendo query su tutti gli ordini in base a CustomerId. Impedisce le query tra partizioni se i modelli di accesso sono coerenti. Rischio di partizioni ad accesso frequente se alcuni valori (ad esempio alcuni clienti con traffico elevato) generano più dati di altri. Potrebbe raggiungere il limite di 20 GB per partizione logica se il volume di dati per una chiave specifica aumenta rapidamente.
Chiave di partizione sintetica, ad esempio, CustomerId + OrderDate Usare quando nessun singolo campo ha cardinalità elevata e corrisponde ai criteri di query. Ideale per carichi di lavoro con elevato utilizzo di scrittura in cui i dati devono essere distribuiti uniformemente tra partizioni fisiche, ad esempio molti ordini effettuati nella stessa data. Consente di distribuire i dati in modo uniforme tra le partizioni, riducendo le partizioni ad accesso frequente, ad esempio la distribuzione degli ordini tramite CustomerId e OrderDate. Distribuisce le scritture tra più partizioni e migliora la velocità effettiva. Le query che filtrano solo in base a un campo, ad esempio solo CustomerId, potrebbero causare query tra partizioni. Le query tra partizioni possono comportare un maggiore consumo di UR (addebito aggiuntivo di 2-3 UR/s per ogni partizione fisica esistente) e una latenza aggiuntiva.
Chiave di partizione gerarchica (HPK), ad esempio CustomerId/OrderId, StoreId/ProductId Usare quando è necessario il partizionamento a più livelli per supportare set di dati su larga scala. Ideale quando le query filtrano in base al primo e al secondo livello della gerarchia. Consente di evitare il limite di 20 GB creando più livelli di partizionamento. Esecuzione efficiente di query su entrambi i livelli gerarchici, ad esempio filtrando prima in base a CustomerID, quindi in base a OrderID. Riduce al minimo le query tra partizioni per le query destinate al livello superiore, ad esempio il recupero di tutti i dati da un CustomerID specifico. Richiede un'attenta pianificazione per garantire che la chiave di primo livello abbia una cardinalità elevata e sia inclusa nella maggior parte delle query. Più complesso da gestire rispetto a una normale chiave di partizione. Se le query non sono allineate alla gerarchia (ad esempio filtrando solo in base a OrderID quando CustomerID è il primo livello), le prestazioni delle query potrebbero diminuire.
Indice secondario globale (GSI) - Anteprima ( ad esempio, l'origine usa CustomerId, GSI usa OrderId) Usare quando non è possibile trovare una singola chiave di partizione che funziona per tutti i modelli di query. Ideale per i carichi di lavoro che devono eseguire query in base a più proprietà indipendenti in modo efficiente e hanno un numero elevato di partizioni fisiche. Elimina le query tra partizioni quando si usa la chiave di partizione GSI. Consente più modelli di query sugli stessi dati con sincronizzazione automatica dal contenitore di origine. Isolamento delle prestazioni tra carichi di lavoro. Ogni GSI ha costi aggiuntivi di archiviazione e UR. I dati in GSI sono infine coerenti con il contenitore di origine.

Chiavi di partizione per contenitori con elevato utilizzo di lettura

Per la maggior parte dei contenitori, i criteri precedenti sono tutto ciò da tenere in considerazione nella selezione una chiave di partizione. Per contenitori di grandi dimensioni di lettura, tuttavia, potrebbe essere necessario scegliere una chiave di partizione che venga visualizzata di frequente come filtro nelle query. Includendo la chiave di partizione del predicato del filtro, le query possono essere instradate in modo efficiente solo alle partizioni fisiche rilevanti.

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

Tuttavia, se il contenitore è piccolo, probabilmente le partizioni fisiche non sono sufficienti a incidere 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 il contenitore può crescere includendo più partizioni fisiche, è necessario assicurarsi di selezionare una chiave di partizione che riduca al minimo le query tra partizioni. Se si verifica uno degli scenari seguenti, il contenitore richiede più partizioni fisiche:

  • Per il contenitore è stato eseguito il provisioning di oltre 30.000 UR

  • Il contenitore archivia più di 100 GB di dati

Indici secondari globali per le query tra partizioni

Se l'applicazione deve eseguire query sui dati usando più proprietà diverse in modo efficiente, gli indici secondari globali (anteprima) offrono un'alternativa all'uso di una strategia di chiave di partizione per il set di dati. Gli indici secondari globali sono contenitori aggiuntivi con chiavi di partizione diverse, sincronizzati automaticamente con i dati del contenitore di origine.

Considerare gli indici secondari globali quando:

  • Sono disponibili più modelli di query che non possono essere soddisfatti da una singola strategia di chiave di partizione
  • La modifica della chiave di partizione esistente potrebbe comportare un'interruzione
  • È necessario isolare i carichi di lavoro analitici o di ricerca dalle operazioni transazionali

Gli indici secondari globali consentono di evitare query tra partizioni archiviando gli stessi dati con chiavi di partizione diverse ottimizzate per modelli di query specifici. Questo approccio può ridurre significativamente il consumo di UR e migliorare le prestazioni delle query per gli scenari in cui l'ottimizzazione della chiave di partizione da sola non è sufficiente.

Usare l'ID elemento come chiave di partizione

Note

Questa sezione riguarda principalmente l'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, sarà probabilmente una scelta ottimale per la chiave di partizione. Un esempio di tale proprietà è l'ID elemento. Per contenitori di piccole dimensioni o contenitori di qualsiasi dimensione ma con scrittura elevata, l'ID elemento (/id ) è naturalmente un'ottima scelta per la chiave di partizione.

L'ID elemento della proprietà di sistema esiste in ogni elemento nel contenitore. Potrebbero essere presenti altre proprietà che rappresentano un ID logico dell'elemento. In molti casi, questi identificatori univoci sono anche ottime scelte di chiave di partizione per le stesse ragioni dell'ID elemento.

L'ID elemento è un'ottima scelta per la chiave di partizione, per i motivi seguenti:

  • È disponibile un'ampia gamma di valori possibili (un ID elemento univoco per elemento).
  • Poiché è presente un ID elemento univoco per ogni elemento, l'ID elemento sarà efficace per bilanciare uniformemente l’utilizzo delle UR e l'archiviazione dei dati.
  • È possibile eseguire facilmente ed efficacemente la lettura di punti, poiché si conoscerà sempre la chiave di partizione di un elemento se si conosce il relativo ID elemento.

Quando si seleziona l'ID elemento come chiave di partizione, tenere presenti le avvertenze seguenti:

  • Se l'ID elemento è la chiave di partizione, diventa un identificatore univoco nell'intero contenitore. Non è possibile creare elementi con identificatori duplicati.
  • Se si dispone di un contenitore con un numero elevato di letture con molte partizioni fisiche, le query saranno più efficienti se hanno un filtro di uguaglianza con l'ID elemento.
  • Non è possibile eseguire stored procedure o trigger destinati a più partizioni logiche.

Contenuti correlati

  • Last updated on