Partizionamento orizzontale per la scalabilità orizzontale in Azure Cosmos DB for MongoDB vCore
Azure Cosmos DB for MongoDB vCore supporta il partizionamento orizzontale per distribuire dati e traffico in modo orizzontale. I documenti all'interno di una raccolta sono suddivisi in blocchi denominati partizioni logiche.
Il partizionamento orizzontale viene definito singolarmente per ogni raccolta usando una chiave di partizione designata dalla struttura del documento della raccolta. I dati vengono quindi inseriti in blocchi con ogni blocco corrispondente a una partizione logica. I documenti per ogni valore univoco della proprietà della chiave di partizione si trovano nella stessa partizione logica.
Per ogni documento inserito in una raccolta partizionata, il valore della proprietà della chiave di partizione viene sottoposto a hash per calcolare la partizione logica designata. L'onuso di inserire la partizione logica e di distribuire tutte le partizioni logiche all'interno del cluster vengono astratte dall'utente e completamente gestite dal servizio.
Partizioni logiche
Tutti i documenti contenenti lo stesso valore per la chiave di partizione appartengono alla stessa partizione logica.
Si consideri, ad esempio, una raccolta denominata Employees con la struttura del documento seguente.
Questa tabella mostra un mapping dei valori delle chiavi di partizione alle partizioni logiche.
| ID documento | Valore della chiave della cassetta postale shard | Cassetta postale shard logica |
|---|---|---|
| "12345" | "Steve Smith" | Partizione 1 |
| "23456" | "Jane Doe" | Partizione 2 |
| "34567" | "Steve Smith" | Partizione 1 |
| "45678" | "Michael Smith" | Partizione 3 |
| "56789" | "Jane Doe" | Partizione 2 |
Non esistono limiti al numero di partizioni logiche per una raccolta. Una raccolta può avere tutte le partizioni logiche dei documenti con un valore univoco per la proprietà della chiave di partizione in ogni documento.
Non sono previsti limiti alle dimensioni di una singola partizione logica.
Inoltre, il servizio non limita le transazioni all'ambito di una partizione logica. Il servizio basato su vCore per Azure Cosmos DB for MongoDB supporta transazioni di lettura e scrittura applicabili tra più partizioni logiche e tra più partizioni fisiche nel cluster.
Partizioni fisiche
Le partizioni fisiche sono i computer e i dischi sottostanti responsabili della persistenza dei dati e dell'esecuzione delle transazioni di database. A differenza delle partizioni logiche, il servizio gestisce le partizioni fisiche sotto le quinte.
Il numero di partizioni fisiche viene definito quando viene creato un cluster. I cluster a partizione singola hanno una partizione fisica interamente responsabile delle transazioni di archiviazione e database del cluster. I cluster con più partizioni distribuiscono i dati e il volume delle transazioni tra le partizioni fisiche del cluster.
Mapping di partizioni logiche a partizioni fisiche
Quando vengono aggiunte nuove partizioni logiche, il cluster aggiorna facilmente il mapping di partizioni logiche a partizioni fisiche. Analogamente, l'assegnazione dello spazio indirizzi a ogni partizione fisica viene modificata man mano che vengono aggiunte nuove partizioni fisiche al cluster dopo la quale le partizioni logiche vengono bilanciate nuovamente nel cluster.
L'intervallo hash usato per eseguire il mapping di partizioni logiche e fisiche viene distribuito uniformemente tra le partizioni fisiche nel cluster. Ogni partizione fisica è proprietaria di un bucket di dimensioni uniformi dell'intervallo hash. Per ogni documento scritto, il valore della proprietà della chiave di partizione viene sottoposto a hash e il valore hash determina il mapping del documento alla partizione fisica sottostante. Internamente, diverse partizioni logiche eseguono il mapping a una singola partizione fisica. Inoltre, le partizioni logiche non vengono mai suddivise tra partizioni fisiche e tutti i documenti per una partizione logica eseguono il mapping solo a una partizione fisica.
Basandosi sull'esempio precedente usando un cluster con due partizioni fisiche, questa tabella mostra un mapping di esempio di documenti a partizioni fisiche.
| ID documento | Valore della chiave della cassetta postale shard | Cassetta postale shard logica | Partizione fisica |
|---|---|---|---|
| "12345" | "Steve Smith" | Partizione 1 | Cassetta postale shard fisica 1 |
| "23456" | "Jane Doe" | Partizione 2 | Cassetta postale shard fisica 2 |
| "34567" | "Steve Smith" | Partizione 1 | Cassetta postale shard fisica 1 |
| "45678" | "Michael Smith" | Partizione 3 | Cassetta postale shard fisica 1 |
| "56789" | "Jane Doe" | Partizione 2 | Cassetta postale shard fisica 2 |
Capacità delle partizioni fisiche
Il livello del cluster selezionato quando viene effettuato il provisioning del cluster determina la capacità di CPU e memoria di una partizione fisica. Analogamente, lo SKU di archiviazione determina la capacità di archiviazione e IOPS di una partizione fisica. I livelli di cluster più grandi offrono una maggiore potenza di calcolo e una maggiore memoria, mentre i dischi di archiviazione di dimensioni maggiori offrono più spazio di archiviazione e operazioni di I/O al secondo. Leggere carichi di lavoro pesanti traggono vantaggio da un livello cluster di dimensioni maggiori, mentre i carichi di lavoro pesanti traggono vantaggio da uno SKU di archiviazione più grande. Il livello del cluster può essere ridimensionato verso l'alto e il basso dopo la creazione del cluster in base alle esigenze mutevoli dell'applicazione.
In un cluster con più partizioni, la capacità di ogni partizione fisica è la stessa. L'aumento del livello del cluster o dello SKU di archiviazione non modifica il posizionamento delle partizioni logiche nelle partizioni fisiche. Dopo un'operazione di aumento delle prestazioni, il numero di partizioni fisiche rimane invariato, evitando così la necessità di bilanciare nuovamente i dati nel cluster.
La capacità di calcolo, memoria, archiviazione e operazioni di I/O al secondo della partizione fisica determina le risorse disponibili per le partizioni logiche. Le chiavi di partizione che non dispongono di una distribuzione uniforme di volumi di archiviazione e richieste possono causare un utilizzo non uniforme di archiviazione e velocità effettiva all'interno del cluster. Le partizioni ad accesso frequente possono causare l'uso non uniforme delle partizioni fisiche, con conseguente velocità effettiva e prestazioni imprevedibili. I cluster partizionati richiedono quindi un'attenta pianificazione iniziale per garantire che le prestazioni rimangano coerenti man mano che i requisiti dell'applicazione cambiano nel tempo.
Set di repliche
Ogni cassetta postale shard 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 nella cassetta postale shard fisica durevoli, altamente disponibili e coerenti. Ogni replica che costituisce la partizione fisica eredita l'archiviazione e la capacità di calcolo della partizione fisica. Azure Cosmos DB for MongoDB vCore gestisce automaticamente i set di repliche.
Procedure consigliate per il partizionamento orizzontale dei dati
Il partizionamento orizzontale in Azure Cosmos DB for MongoDB vCore non è necessario a meno che i volumi di archiviazione e transazione della raccolta non superino la capacità di una singola partizione fisica. Ad esempio, il servizio fornisce dischi da 32 TB per partizione. Se una raccolta richiede più di 32 TB, deve essere partizionata.
Non è necessario partizionare ogni raccolta in un cluster con più partizioni fisiche. Le raccolte partizionate e non partizionate possono coesistere nello stesso cluster. Il servizio distribuisce in modo ottimale le raccolte all'interno del cluster per usare in modo uniforme le risorse di calcolo e archiviazione del cluster nel modo più uniforme possibile.
Per le applicazioni con un numero elevato di operazioni di lettura, è necessario selezionare la chiave di partizione in base ai criteri di query più frequenti. Il filtro di query più comunemente usato per una raccolta deve essere scelto come chiave di partizione per ottimizzare la percentuale più elevata di transazioni di database localizzando la ricerca in una singola partizione fisica.
Per le applicazioni con un numero elevato di operazioni di scrittura che favoriscono le prestazioni di scrittura rispetto alle letture, è necessario scegliere una chiave di partizione per distribuire uniformemente i dati tra le partizioni fisiche. Le chiavi di partizione con la cardinalità più elevata offrono la migliore opportunità di distribuire in modo uniforme il più possibile.
Per ottenere prestazioni ottimali, le dimensioni di archiviazione di una partizione logica devono essere inferiori a 4 TB.
Per ottenere prestazioni ottimali, le partizioni logiche devono essere distribuite uniformemente nell'archiviazione e nel volume delle richieste tra le partizioni fisiche del cluster.
Come partizionare una raccolta
Si consideri il documento seguente all'interno del database 'cosmicworks' e della raccolta 'employee'
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Nell'esempio seguente viene partizionata la raccolta di dipendenti all'interno del database cosmicworks nella proprietà firstName.
use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})
La raccolta può anche essere partizionata usando un comando admin:
use cosmicworks;
db.adminCommand({
"shardCollection": "cosmicworks.employee",
"key": {"firstName": "hashed"}
})
Anche se non è ideale modificare la chiave di partizione dopo che la raccolta è cresciuta significativamente nel volume di archiviazione, è possibile usare il comando reshardCollection per modificare la chiave di partizione.
use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})
La raccolta può anche essere partizionata tramite un comando admin:
use cosmicworks;
db.adminCommand({
"reshardCollection": "cosmicworks.employee",
"key": {"lastName": "hashed"}
})
Come procedura consigliata, è necessario creare un indice nella proprietà della chiave di partizione.
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
blocking: true
})