Introduzione alla velocità effettiva con provisioning in Azure Cosmos DB

  • Articolo

SI APPLICA A: Nosql Mongodb Cassandra Gremlin Tabella

Azure Cosmos DB consente di impostare la velocità effettiva con provisioning su database e contenitori. Esistono due tipi di velocità effettiva con provisioning: standard (manuale) o con scalabilità automatica. Questo articolo offre una panoramica del funzionamento della velocità effettiva con provisioning.

Un database Azure Cosmos DB è un'unità di gestione per un set di contenitori. Un database è costituito da un set di contenitori indipendenti dallo schema. Un contenitore di Azure Cosmos DB è l'unità di scalabilità sia per la velocità effettiva che per l'archiviazione. Un contenitore viene partizionato orizzontalmente in un set di computer all'interno di un'area di Azure e viene distribuito in tutte le aree di Azure associate all'account Azure Cosmos DB.

Con Azure Cosmos DB è possibile effettuare il provisioning della velocità effettiva a due livelli di granularità:

  • Contenitore Azure Cosmos DB
  • Database di Azure Cosmos DB

Configurare la velocità effettiva in un contenitore

La velocità effettiva di cui è stato effettuato il provisioning in un contenitore di Azure Cosmos DB è riservata esclusivamente a tale contenitore. Il contenitore riceve sempre la velocità effettiva con provisioning. La velocità effettiva con provisioning in un contenitore è supportata finanziariamente da contratti di servizio. Per informazioni su come configurare la velocità effettiva standard (manuale) in un contenitore, vedere Effettuare il provisioning della velocità effettiva in un contenitore di Azure Cosmos DB. Per informazioni su come configurare la velocità effettiva con scalabilità automatica in un contenitore, vedere Effettuare il provisioning della velocità effettiva con scalabilità automatica.

La configurazione della velocità effettiva con provisioning in un contenitore è l'opzione più diffusa. È possibile ridimensionare in modo elastico la velocità effettiva per un contenitore effettuando il provisioning di una quantità di velocità effettiva tramite le unità richiesta (UR).

La velocità effettiva di cui viene effettuato il provisioning per un contenitore viene distribuita uniformemente tra le partizioni fisiche e, presupponendo una chiave di partizione efficace che distribuisca equamente le partizioni logiche tra le partizioni fisiche, la velocità effettiva viene distribuita in modo uniforme anche fra tutte le partizioni logiche del contenitore. Non è possibile specificare in modo selettivo la velocità effettiva per le partizioni logiche. Poiché una o più partizioni logiche di un contenitore sono ospitate da una partizione fisica, le partizioni fisiche appartengono esclusivamente al contenitore e supportano la velocità effettiva di cui è stato effettuato il provisioning nel contenitore.

Se il carico di lavoro in esecuzione in una partizione logica utilizza più della velocità effettiva allocata alla partizione fisica sottostante, è possibile che le operazioni siano limitate a velocità. Ciò che è noto come partizione ad accesso frequente si verifica quando una partizione logica ha richieste in modo sproporzionato rispetto ad altri valori di chiave di partizione.

Quando si verifica una limitazione di velocità, è possibile aumentare la velocità effettiva di cui è stato effettuato il provisioning per l'intero contenitore o ripetere le operazioni. È anche necessario assicurarsi di scegliere una chiave di partizione che distribuisca in modo uniforme l'archiviazione e il volume delle richieste. Per altre informazioni sul partizionamento, vedere Partizionamento e scalabilità orizzontale in Azure Cosmos DB.

È consigliabile configurare la velocità effettiva con la granularità del contenitore quando si vogliono ottenere prestazioni prevedibili per il contenitore.

L'immagine seguente mostra in che modo una partizione fisica ospita una o più partizioni logiche di un contenitore:

Partizione fisica che ospita una o più partizioni logiche di un contenitore

Configurare la velocità effettiva in un database

Quando si effettua il provisioning della velocità effettiva in un database di Azure Cosmos DB, la velocità effettiva viene condivisa tra tutti i contenitori (denominati contenitori di database condivisi) nel database. a meno che non sia stata specificata una velocità effettiva con provisioning in contenitori specifici nel database. La condivisione della velocità effettiva con provisioning a livello del database tra i relativi contenitori è analoga all'hosting di un database in un cluster di computer. Poiché tutti i contenitori all'interno di un database condividono le risorse disponibili in un computer, naturalmente non si ottengono prestazioni prevedibili in un contenitore specifico. Per informazioni su come configurare la velocità effettiva con provisioning in un database, vedere Configurare la velocità effettiva con provisioning in un database di Azure Cosmos DB. Per informazioni su come configurare la velocità effettiva con scalabilità automatica in un database, vedere Effettuare il provisioning della velocità effettiva con scalabilità automatica.

Dato che tutti i contenitori all'interno del database condividono la velocità effettiva di cui è stato effettuato il provisioning, Azure Cosmos DB non garantisce alcuna velocità effettiva prevedibile per un determinato contenitore nel database. La porzione della velocità effettiva che può essere ricevuta da uno specifico contenitore dipende dai fattori seguenti:

  • Numero di contenitori.
  • Scelta delle chiavi di partizione per vari contenitori.
  • Distribuzione del carico di lavoro tra varie partizioni logiche dei contenitori.

È consigliabile configurare la velocità effettiva in un database se si intende condividere la velocità effettiva tra più contenitori, ma non si vuole riservarla a uno specifico contenitore.

Di seguito sono riportati alcuni esempi in cui è preferibile effettuare il provisioning della velocità effettiva a livello di database:

  • La condivisione della velocità effettiva con provisioning di un database in un set di contenitori è utile per un'applicazione multi-tenant. Ogni utente può essere rappresentato da un contenitore azure Cosmos DB distinto.

  • La condivisione della velocità effettiva con provisioning di un database in un set di contenitori è utile quando si esegue la migrazione in Azure Cosmos DB di un database NoSQL, come MongoDB o Cassandra, ospitato in un cluster di macchine virtuali o in server fisici locali. Si pensi alla velocità effettiva con provisioning configurata nel database Azure Cosmos DB come equivalente logico, ma più conveniente ed elastico, a quella della capacità di calcolo del cluster MongoDB o Cassandra.

Tutti i contenitori creati all'interno di un database con velocità effettiva con provisioning devono essere creati con una chiave di partizione. In uno specifico momento, la velocità effettiva allocata a un contenitore all'interno di un database viene distribuita fra tutte le partizioni logiche di tale contenitore. In presenza di contenitori che condividono la velocità effettiva con provisioning configurata in un database, non è possibile applicare in modo selettivo la velocità effettiva a un contenitore o una partizione logica specifica.

Se il carico di lavoro in una partizione logica utilizza un livello di velocità effettiva superiore rispetto a quello allocato a una specifica partizione logica, le operazioni risulteranno limitate in termini di velocità. Quando si verifica una limitazione di velocità, è possibile aumentare la velocità effettiva per l'intero database o ripetere le operazioni. Per altre informazioni sul partizionamento, vedere Partizioni logiche.

I contenitori in un database con velocità effettiva condivisa condividono tale velocità (UR) allocata nel database. Con la velocità effettiva con provisioning standard (manuale) è possibile avere fino a 25 contenitori con almeno 400 UR/sec nel database. Con la velocità effettiva con provisioning con scalabilità automatica, è possibile avere fino a 25 contenitori in un database con scalabilità automatica minima di 1000 UR/sec (scalabilità compresa tra 100 e 1000 UR/sec).

Nota

A febbraio 2020 è stata introdotta una modifica che consente di avere un massimo di 25 contenitori in un database con velocità effettiva condivisa, migliorando così la condivisione della velocità effettiva tra i contenitori. Dopo i primi 25 contenitori, è possibile aggiungere altri contenitori al database solo se la relativa velocità effettiva con provisioning è dedicata, ossia separata dalla velocità effettiva condivisa del database.
Se l'account Azure Cosmos DB contiene già un database con velocità effettiva condivisa con >=25 contenitori, l'account e tutti gli altri account nella stessa sottoscrizione di Azure sono esenti da questa modifica. Per inviare feedback o domande, contattare il supporto tecnico.

Se i carichi di lavoro comportano l'eliminazione e la ricreazione di tutte le raccolte di un database, è consigliabile eliminare il database vuoto e ricrearne uno nuovo prima di creare le raccolte. L'immagine seguente mostra in che modo una partizione fisica può ospitare una o più partizioni logiche che appartengono a contenitori diversi all'interno di un database:

Partizione fisica che ospita una o più partizioni logiche che appartengono a contenitori diversi

Configurare la velocità effettiva in un database e in un contenitore

È possibile combinare i due modelli, effettuando il provisioning della velocità effettiva sia nel database che nel contenitore. L'esempio seguente illustra come effettuare il provisioning della velocità effettiva con provisioning standard (manuale) in un database di Azure Cosmos DB e in un contenitore:

  • È possibile creare un database di Azure Cosmos DB denominato Z con velocità effettiva con provisioning standard (manuale) di UR "K".

  • Creare quindi cinque contenitori denominati A, B, C, D ed E all'interno del database. Quando si crea il contenitore B, abilitare l'opzione Provision dedicated throughput for this container (Effettua il provisioning di velocità effettiva dedicata per questo contenitore) e configurare in modo esplicito "P" UR di velocità effettiva con provisioning in questo contenitore. È possibile configurare la velocità effettiva condivisa e dedicata solo durante la creazione del database e del contenitore.

    Impostazione della velocità effettiva a livello di contenitore

  • La velocità effettiva di "K" UR è condivisa tra i quattro contenitori A, C, D ed E. La quantità esatta di velocità effettiva disponibile per A, C, D o E varia. Non sono previsti contratti di servizio per la velocità effettiva di ogni singolo contenitore.

  • Il contenitore B ha la garanzia di ottenere sempre la velocità effettiva di "P" UR ed è supportato da contratti di servizio.

Nota

Un contenitore con velocità effettiva con provisioning non può essere convertito in un contenitore di database condiviso. Viceversa, un contenitore di database condiviso non può essere convertito in un contenitore con velocità effettiva dedicata. Sarà necessario spostare i dati in un contenitore con l'impostazione di velocità effettiva desiderata. I processi di copia del contenitore per le API NoSQL e Cassandra sono utili per questo processo.

Aggiornare la velocità effettiva in un database o in un contenitore

Dopo aver creato un contenitore azure Cosmos DB o un database, è possibile aggiornare la velocità effettiva con provisioning. La velocità effettiva massima con provisioning che è possibile configurare nel database o nel contenitore non è soggetta ad alcun limite.

Velocità effettiva con provisioning corrente

È possibile recuperare la velocità effettiva con provisioning di un contenitore o di un database nel portale di Azure o usando gli SDK:

La risposta di questi metodi contiene anche la velocità effettiva minima con provisioning per il contenitore o il database:

Il numero minimo di UR/s effettivo può variare a seconda della configurazione dell'account, ma in genere quello massimo è:

  • 400 UR/sec
  • Archiviazione corrente in GB * 1 UR/sec
  • Numero massimo di UR/sec con provisioning mai presente nel database o nel contenitore/100

Modifica della velocità effettiva con provisioning

È possibile ridimensionare la velocità effettiva con provisioning di un contenitore o di un database tramite il portale di Azure o usando gli SDK:

Se si riduce la velocità effettiva con provisioning, sarà possibile farlo fino al minimo.

Se si aumenta la velocità effettiva con provisioning, la maggior parte del tempo, l'operazione è istantanea. Esistono tuttavia casi in cui l'operazione può richiedere più tempo a causa delle attività di sistema per effettuare il provisioning delle risorse necessarie. In questo caso, un tentativo di modificare la velocità effettiva con provisioning mentre questa operazione è in corso restituirà una risposta HTTP 423 con un messaggio di errore che spiega che è in corso un'altra operazione di ridimensionamento.

Per altre informazioni, vedere l'articolo Procedure consigliate per il ridimensionamento della velocità effettiva con provisioning (UR/sec).

Nota

Se si prevede un carico di lavoro di inserimento molto grande che richiederà un notevole aumento della velocità effettiva con provisioning, tenere presente che l'operazione di ridimensionamento non ha contratto di servizio e, come indicato nel paragrafo precedente, può richiedere molto tempo quando l'aumento è elevato. È possibile pianificare in anticipo e avviare il ridimensionamento prima dell'avvio del carico di lavoro e usare i metodi seguenti per controllare lo stato di avanzamento.

È possibile controllare lo stato di avanzamento del ridimensionamento a livello di codice leggendo la velocità effettiva con provisioning corrente e usando:

È possibile usare le metriche di Monitoraggio di Azure per visualizzare la cronologia della velocità effettiva con provisioning (UR/sec) e l'archiviazione in una risorsa.

Confronto tra modelli

Questa tabella mostra un confronto tra il provisioning della velocità effettiva standard (manuale) in un database e in un contenitore.

Parametro Provisioning della velocità effettiva standard (manuale) in un database Provisioning della velocità effettiva standard (manuale) in un contenitore Provisioning della velocità effettiva con scalabilità automatica in un database Provisioning della velocità effettiva con scalabilità automatica in un contenitore
Punto di ingresso (numero minimo di UR/sec) 400 UR/sec Può avere fino a 25 contenitori senza UR/sec minimo per ogni contenitore. 400 Scalabilità automatica compresa tra 100 e 1000 UR/sec. Può avere fino a 25 contenitori senza UR/sec minimo per ogni contenitore. Scalabilità automatica compresa tra 100 e 1000 UR/sec.
Numero minimo di UR/sec per contenitore -- 400 -- Scalabilità automatica compresa tra 100 e 1000 UR/sec
UR massime Illimitate, nel database. Illimitate, nel contenitore. Illimitate, nel database. Illimitate, nel contenitore.
UR assegnate o disponibili per un contenitore specifico Nessuna garanzia. Le UR assegnate a un determinato contenitore dipendono dalle proprietà. Le proprietà possono essere, a scelta, le chiavi di partizione dei contenitori che condividono la velocità effettiva, la distribuzione del carico di lavoro e il numero di contenitori. Tutte le UR configurate nel contenitore sono riservate esclusivamente per il contenitore. Nessuna garanzia. Le UR assegnate a un determinato contenitore dipendono dalle proprietà. Le proprietà possono essere, a scelta, le chiavi di partizione dei contenitori che condividono la velocità effettiva, la distribuzione del carico di lavoro e il numero di contenitori. Tutte le UR configurate nel contenitore sono riservate esclusivamente per il contenitore.
Archiviazione massima per un contenitore Senza limiti. Nessuna limitazione Nessuna limitazione Nessuna limitazione
Velocità effettiva massima per partizione logica di un contenitore 10.000 UR/sec 10.000 UR/sec 10.000 UR/sec 10.000 UR/sec
Spazio di archiviazione massimo (data + indice) per partizione logica di un contenitore 20 GB 20 GB 20 GB 20 GB

Passaggi successivi