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 Azure Cosmos DB è l'unità di scalabilità per velocità effettiva e archiviazione. Un contenitore è partizionato orizzontalmente tra 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 per 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) per 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 usa una velocità effettiva superiore rispetto a quella allocata alla partizione logica sottostante, è possibile che le operazioni risultino limitate in termini di velocità. L'evento noto come partizione ad accesso frequente si verifica quando una partizione logica riceve un numero di richieste sproporzionato rispetto ad altri valori delle chiavi 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. È importante accertarsi anche che la chiave di partizione scelta distribuisca uniformemente lo spazio di archiviazione e il volume delle richieste. Per altre informazioni sul partizionamento, vedere l'articolo Partizionamento e ridimensionamento orizzontale in Azure Cosmos DB.

È consigliabile configurare la velocità effettiva al livello di granularità del contenitore per 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:

Physical partition that hosts one or more logical partitions of a container

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 fra tutti i contenitori (detti contenitori di database condivisi) nel database, Un'eccezione è rappresentata dal caso in cui sia stata specificata una velocità effettiva con provisioning su contenitori specifici del 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 Effettuare il provisioning della velocità effettiva 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 di 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 può paragonare la velocità effettiva con provisioning configurata nel database di Azure Cosmos DB a un equivalente logico (ma più conveniente e flessibile) 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 nel database fino a 25 contenitori con almeno 400 UR/sec. La velocità effettiva con provisioning con scalabilità automatica supporta fino a 25 contenitori in un database con almeno 1000 UR/sec per la scalabilità automatica (con 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 il proprio 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:

Physical partition that hosts one or more logical partitions that belong to different containers

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 standard (manuale) in un database di Azure Cosmos DB e in un contenitore:

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

  • 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.

    Setting the throughput at the container-level

  • 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, MongoDB e Cassandra semplificano l'esecuzione di questo processo.

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

Dopo aver creato un contenitore o un database di Azure Cosmos DB, è 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 oppure con i seguenti SDK:

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

Il numero minimo di UR/s effettivo può variare a seconda della configurazione dell'account. Per altre informazioni, vedere Domande frequenti sulla scalabilità automatica.

Modifica della velocità effettiva con provisioning

È possibile ridimensionare la velocità effettiva con provisioning di un contenitore o di un database nel portale di Azure oppure con i seguenti SDK:

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

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

Per altre informazioni, vedere l'articolo Procedure consigliate per il dimensionamento del provisioning di velocità effettiva (UR/s).

Nota

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

È possibile controllare lo stato di avanzamento dell'operazione di 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 allocata (UR/sec) e dell'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 Fino a 25 contenitori senza limite minimo di UR/sec per contenitore. 400 Scalabilità automatica tra 100 e 1000 UR/sec. Fino a 25 contenitori senza limite minimo di UR/sec per contenitore. Scalabilità automatica tra 100 e 1000 UR/sec.
Numero minimo di UR/sec per contenitore -- 400 -- Scalabilità automatica 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. Nessun limite Nessun limite Nessun limite
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