Scegliere una chiave di partizione
Si ricordi che i dati nei documenti JSON sono archiviati nei database di Azure Cosmos DB all'interno di contenitori che sono a loro volta distribuiti in partizioni fisiche e dove i dati sono indirizzati alla partizione fisica appropriata in base al valore di una chiave di partizione.
La chiave di partizione è una proprietà necessaria del documento, che garantisce che i documenti con lo stesso valore della chiave di partizione siano indirizzati e archiviati in una specifica partizione fisica. Una partizione fisica supporta una quantità fissa di spazio di archiviazione e di velocità effettiva (UR/s) con un limite massimo. Azure Cosmos DB distribuisce automaticamente le partizioni logiche sulle partizioni fisiche disponibili, usando ancora una volta il valore della chiave di partizione per farlo in modo prevedibile.
In questa unità verranno acquisite altre informazioni sulle partizioni logiche e su come evitare le partizioni ad accesso frequente. Queste informazioni consentono di scegliere la chiave di partizione appropriata per i dati dei clienti nello scenario.
In Azure Cosmos DB si aumentano lo spazio di archiviazione e la velocità effettiva aggiungendo più partizioni fisiche per accedere ai dati e archiviarli. La dimensione massima dello spazio di archiviazione di una partizione fisica è 50 GB e la velocità effettiva massima è 10.000 UR/sec.
Partizioni logiche in Azure Cosmos DB
Una partizione logica è un'astrazione sopra le partizioni fisiche sottostanti. È possibile archiviare più partizioni logiche all'interno di una singola partizione fisica. Un contenitore può avere un numero illimitato di partizioni logiche. Le singole partizioni logiche vengono spostate in nuove partizioni fisiche man mano che aumentano le dimensioni per garantire un utilizzo e una crescita ottimali dello spazio di archiviazione. Lo spostamento delle partizioni logiche come unità garantisce che tutti i documenti al suo interno si trovino nella stessa partizione fisica. La dimensione massima per una partizione logica è 20 GB. L'uso di una chiave di partizione con cardinalità elevata consente di evitare questo limite di 20 GB distribuendo i dati su un numero maggiore di partizioni logiche. È anche possibile usare delle chiavi di partizione gerarchica che organizzano i valori delle chiavi di partizione in una gerarchia per evitare questo limite. Queste sono trattate in un altro percorso di apprendimento.
Una chiave di partizione consente di instradare i dati per una partizione logica. Si tratta di una proprietà presente all'interno di ogni documento nel contenitore che instrada i dati. Un contenitore è un'altra astrazione per tutti i dati archiviati con la stessa chiave di partizione. La chiave di partizione viene definita quando si crea un contenitore.
Nell'esempio seguente il contenitore ha la chiave di partizione /username.
Evitare le partizioni ad accesso frequente
Quando si modellano i dati per Azure Cosmos DB, è fondamentale che la chiave di partizione scelta restituisca una distribuzione uniforme di dati e richieste in entrambe le partizioni logiche e, per estensione, le partizioni fisiche nel contenitore. Questo è particolarmente vero quando i contenitori diventano più grandi e hanno un numero crescente di partizioni fisiche.
Se non si testa la progettazione del database in fase di caricamento durante lo sviluppo, una scelta inadeguata per la chiave di partizione potrebbe non essere evidente finché l'applicazione non è in produzione e non sono già stati scritti dati significativi.
Se i dati non sono partizionati correttamente, si possono avere partizioni ad accesso frequente. Le partizioni ad accesso frequente impediscono al carico di lavoro dell'applicazione di ridimensionarsi e possono verificarsi sia per la risorsa di archiviazione che per la velocità effettiva.
Partizioni ad accesso frequente e risorse di archiviazione
Una partizione ad accesso frequente relativa all'archiviazione si verifica quando si usa una chiave di partizione che genera criteri di archiviazione estremamente asimmetrici. Si consideri ad esempio un'applicazione multi-tenant che utilizza TenantId come chiave di partizione con sei tenant: da A a F. I tenant B, C, E ed F hanno dimensioni molto contenute, il tenant D contiene un numero di dati leggermente superiore. Il tenant A è tuttavia di grandi dimensioni e raggiunge rapidamente il limite di 20 GB per la partizione. In questo scenario è necessario selezionare una chiave di partizione diversa che ripartirà l'archiviazione tra più partizioni logiche.
Partizioni ad accesso frequente e velocità effettiva
La velocità effettiva può essere influenzata negativamente dalle partizioni ad accesso frequente quando la maggior parte o tutte le richieste sono destinate alla stessa partizione logica.
È importante comprendere i criteri di accesso per l'applicazione per assicurarsi che le richieste vengano distribuite nel modo più uniforme possibile tra i valori delle chiavi di partizione. Quando viene sottoposta a provisioning per un contenitore in Azure Cosmos DB, la velocità effettiva viene allocata in modo uniforme in tutte le partizioni fisiche all'interno di un contenitore.
Ad esempio, se si usa un contenitore con 30.000 UR/sec, questo carico di lavoro viene distribuito tra le tre partizioni fisiche per gli stessi sei tenant indicati in precedenza. Ogni partizione fisica riceve quindi 10.000 RU/sec. Se il tenant D usa tutte le 10.000 UR/sec, la sua velocità sarà limitata perché non è in grado di usare la velocità effettiva allocata alle altre partizioni. Ciò si traduce in prestazioni scarse per i tenant C e D, lasciando la capacità di calcolo inutilizzata nelle altre partizioni fisiche e nei tenant rimanenti. In definitiva, questa chiave di partizione comporta una progettazione di database dove il carico di lavoro dell'applicazione è privo di scalabilità.
Quando i dati e le richieste vengono distribuiti in modo uniforme, il database può crescere in modo da usare completamente sia le risorse di archiviazione che la velocità effettiva. Il risultato sarà la migliore prestazione possibile con la massima efficienza. In breve, la progettazione del database verrà dimensionata.
Valutare il peso delle operazioni di lettura e di scrittura
Quando si sceglie una chiave di partizione, è anche necessario valutare se i dati richiedono numerose operazioni di lettura o di scrittura. È consigliabile cercare di distribuire le richieste con intensa attività di scrittura con una chiave di partizione con cardinalità elevata.
Per i carichi di lavoro con intensa attività di lettura, è necessario garantire che le query vengano elaborate da una o da un numero limitato di partizioni includendo nelle query una clausola WHERE con un filtro di uguaglianza sulla chiave di partizione o un operatore IN su un subset di valori della chiave di partizione.
Per gli scenari in cui il carico di lavoro dell'applicazione richiede numerose operazioni sia di scrittura che di lettura esiste una soluzione. Questo argomento verrà trattato nel modulo successivo.
La figura seguente illustra un contenitore partizionato in base al nome utente. Questa query userà solo un'unica partizione logica, quindi le prestazioni saranno sempre soddisfacenti.
Una query che filtra in base a un'altra proprietà, ad esempio favoriteColor, effettuerebbe il "fan-out" di tutte le partizioni nel contenitore. Questa operazione è nota anche come query tra partizioni. Una query di questo tipo funzionerà come previsto se il contenitore è di piccole dimensioni e occupa una sola partizione. Quando tuttavia il contenitore cresce e il numero di partizioni fisiche aumenta, la query diventa più lenta e costosa perché deve controllare ogni partizione per ottenere i risultati, indipendentemente dal fatto che la partizione fisica contenga o meno i dati relativi alla query.
Scegliere una chiave di partizione per i clienti
Ora che si è compreso il partizionamento in Azure Cosmos DB, è possibile scegliere una chiave di partizione per i dati dei clienti. Come illustrato in precedenza, vengono eseguite tre operazioni sui clienti: creare un cliente, aggiornare un cliente e recuperare un cliente. In questo caso, il cliente verrà recuperato in base all'ID. Poiché questa operazione sarà chiamata più spesso, ha senso che l'ID del cliente sia la chiave di partizione del contenitore.
In questo caso ci si potrebbe preoccupare del fatto che usare l'ID come chiave di partizione significa avere un numero di partizioni logiche pari a quello dei clienti, con ogni partizione logica che contiene un solo documento. Questo significa che per milioni di clienti si avranno milioni di partizioni logiche.
Ma è assolutamente accettabile. Le partizioni logiche sono un concetto virtuale e non esiste alcun limite al numero di partizioni logiche che si possono avere. Azure Cosmos DB collocherà più partizioni logiche nella stessa partizione fisica. Man mano che il numero o le dimensioni delle partizioni logiche aumentano, se necessario Cosmos DB le sposta in nuove partizioni fisiche.