Domande frequenti sulla velocità effettiva con provisioning a scalabilità automatica in Azure Cosmos DB

La scalabilità automatica o la velocità effettiva con provisioning a scalabilità automatica ridimensiona i carichi di lavoro in base all'area e alla partizione più attive. Al contrario, la scalabilità automatica dinamica consente alle aree e alle partizioni dei carichi di lavoro di ridimensionarsi in modo indipendente in base all'utilizzo. La scalabilità automatica dinamica è consigliabile per tutti i clienti che pianificano l'uso della scalabilità automatica.

È possibile usare il modello di Resource Manager con versione API 2023-11-15-preview o la versione successiva dell’anteprima per impostare la proprietà enablePerRegionPerPartitionAutoscale su true. È possibile visualizzare questa proprietà nella visualizzazione JSON usando la versione di anteprima 2023-11-15-preview o una versione di anteprima successiva. È anche possibile usare PowerShell o l'interfaccia della riga di comando di Azure.

// Add Azure Cosmos DB extension 2.0.6-preview for PowerShell
Install-Module -Name Az.CosmosDB -RequiredVersion 2.0.6-preview -AllowPrerelease -AllowClobber -Force

// update the account using this command to enable or disable the property
Update-AzCosmosDBAccount -EnablePerRegionPerPartitionAutoscale $true -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"

// Run this command to see the enablement or disablement status:
Get-AzCosmosDBAccount -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"

// Add Azure Cosmos DB extension for CLI
az extension add --name cosmosdb-preview --allow-preview true

// update the account using this command to enable or disable the property
az cosmosdb update --enable-prpp-autoscale true --name '<cosmos-account-name>' --resource-group '<resource-group-name>'

// Run this command to see the enablement or disablement status:
az cosmosdb show --name '<cosmos-account-name>' --resource-group '<resource-group-name>'

Le risorse create nel modello di livello precedente sono supportate automaticamente nel nuovo modello di UR/s personalizzato con scalabilità automatica. Il limite superiore del livello diventa il nuovo numero massimo di UR/s, che ha come risultato lo stesso intervallo di scalabilità.

Ad esempio, se in precedenza è stato selezionato il livello con scalabilità compresa tra 400 UR/s e 4.000 UR/s, il database o il contenitore mostra ora un numero massimo di UR/s di 4.000 UR/s, che viene ridimensionato tra 400 UR/s e 4.000 UR/s. Sarà quindi possibile modificare il numero massimo di UR/s in un valore personalizzato in base al carico di lavoro.

A partire da aprile 2022, è possibile impostare la scalabilità automatica con un numero massimo di UR/s inferiore a 1.000 UR/s (viene ridimensionato tra 100 UR/sc e 1.000 UR/s). È anche possibile impostare un intervallo di scalabilità compreso tra 200 UR/s e 2.000 UR/s o 300 UR/s e 3.000 UR/s. In precedenza, il punto di ingresso era da 400 UR/s a 4.000 UR/s.

È consigliabile usare questa configurazione per i carichi di lavoro con requisiti di velocità effettiva ridotti, ma che potrebbero comunque raggiungere il numero massimo di UR/s.

Con la scalabilità automatica, il sistema ridimensiona la velocità effettiva (UR/s) T verso l’alto o T verso il basso entro l'intervallo da 0,1 × Tmax a Tmax in base al traffico in ingresso. Poiché il ridimensionamento è automatico e istantaneo, in qualsiasi momento è possibile utilizzare fino al valore Tmax di cui è stato effettuato il provisioning senza alcun ritardo.

Usare le metriche di Monitoraggio di Azure per monitorare sia il numero massimo di UR/s di scalabilità automatica di cui è stato effettuato il provisioning che la velocità effettiva corrente (UR/s) a cui il sistema è dimensionato.

Ogni ora viene addebitata la velocità effettiva più elevata T a cui il sistema è stato ridimensionato entro quell’ora. Se la risorsa non ha ricevuto richieste nel corso di tale ora o se non è stata ridimensionata oltre 0,1 × Tmax, viene addebitato il minimo di 0,1 × Tmax. Per informazioni dettagliate, vedere la pagina dei prezzi di Azure Cosmos DB.

Negli account di area a scrittura singola, la tariffa della scalabilità automatica per 100 UR/s è pari a 1,5 volte la tariffa della velocità effettiva con provisioning standard (manuale). La fattura mostra il contatore della velocità effettiva con provisioning standard esistente. La quantità di questo contatore viene moltiplicata per 1,5. Se, ad esempio, il numero massimo di UR/s del sistema è stato ridimensionato a 6,000 UR/s nel corso di un'ora, per tale ora vengono addebitate 60 × 1,5 = 90 unità del contatore.

Negli account che hanno più aree di scrittura, la tariffa della scalabilità automatica per 100 UR/s è uguale alla tariffa della velocità effettiva dell'area di scrittura con provisioning standard (manuale). La fattura mostra il contatore delle aree di scrittura multiple esistente. Poiché le tariffe sono le stesse, se si usa la scalabilità automatica viene visualizzata la stessa quantità come per la velocità effettiva standard.

Sì. Con la capacità riservata per gli account con aree di scrittura singole, lo sconto relativo alla prenotazione per le risorse di scalabilità automatica viene applicato all'utilizzo del contatore con un rapporto di 1,5 volte rispetto al rapporto dell'area specifica. Ad esempio, se si vuole usare la capacità riservata per coprire 10.000 UR/s di scalabilità automatica, è necessario pianificare l'acquisto di 15.000 UR/s di capacità riservata complessiva.

La capacità riservata dell'area di scrittura multipla funziona allo stesso modo per la velocità effettiva con scalabilità automatica e per la velocità effettiva con provisioning standard (manuale). Per altre informazioni, vedere Capacità riservata di Azure Cosmos DB.

Sì. Nel livello gratuito è possibile usare la velocità effettiva di scalabilità automatica in un database o in un contenitore. Altre informazioni sul funzionamento della fatturazione del livello gratuito con la scalabilità automatica.

Sì. La scalabilità automatica è supportata per tutte le API: NoSQL, Gremlin, Table, Cassandra e MongoDB.

Sì. L’UR/s massimo è disponibile in ogni area aggiunta all'account Azure Cosmos DB.

Informazioni su Come abilitare la scalabilità automatica.

Sì. È anche possibile passare da velocità effettiva con scalabilità automatica a velocità effettiva con provisioning standard (manuale) e viceversa. Attualmente, per tutte le API, è possibile usare il portale di Azure, l'interfaccia della riga di comando di Azure o PowerShell per eseguire queste operazioni. Per impostazione predefinita, per eseguire la migrazione tra velocità effettiva con provisioning manuale e scalabilità automatica, non è possibile usare gli SDK client di Azure Cosmos DB o un modello di Azure Resource Manager. Tuttavia, è gli SDK client o un modello di Azure Resource Manager possono essere usati per creare nuove risorse di scalabilità automatica e modificare il numero massimo di UR/s in una risorsa di scalabilità automatica esistente.

Dal punto di vista concettuale, il cambiamento del tipo di velocità effettiva è un processo in due fasi. Prima si invia la richiesta di modifica delle impostazioni della velocità effettiva per l'uso della scalabilità automatica o del provisioning manuale. In entrambi i casi, il sistema determina e imposta automaticamente un valore UR/s iniziale, in base alle impostazioni della velocità effettiva e alla risorsa di archiviazione correnti. Durante questo passaggio, non viene accettato alcun valore UR/s indicato dall'utente. Al completamento dell’aggiornamento, sarà possibile modificare il numero di UR/s per adattarlo al carico di lavoro.

Migrare dalla velocità effettiva con provisioning standard (manuale) alla velocità effettiva con scalabilità automatica

Per un contenitore, la formula seguente consente di stimare il numero massimo di UR/s di scalabilità automatica iniziale:

MAX(1,000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB × 10) arrotondato al migliaio di UR/s più vicino.

Il numero massimo di UR/s effettivo iniziale per la scalabilità automatica potrebbe variare a seconda della configurazione dell'account.

Esempio 1: è disponibile un contenitore con una velocità effettiva con provisioning manuale di 10.000 UR/s e 25 GB di spazio di archiviazione. Quando si abilita la scalabilità automatica, il numero massimo di UR/s di scalabilità automatica iniziale è 10.000 UR/s, che può essere ridimensionato tra 1.000 UR/s e 10.000 UR/s.

Esempio 2: è disponibile un contenitore con una velocità effettiva con provisioning manuale di 50.000 UR/s e 25.000 GB di spazio di archiviazione. Quando si abilita la scalabilità automatica, il numero massimo di UR/s di scalabilità automatica iniziale è 250.000 UR/s, che può essere ridimensionato tra 25.000 UR/s e 250.000 UR/s.

Migrare dalla velocità effettiva con scalabilità automatica alla velocità effettiva con provisioning standard (manuale)

La velocità effettiva con provisioning manuale iniziale è uguale al numero massimo di UR/s della scalabilità automatica corrente.

Esempio: si dispone di un database o di un contenitore con scalabilità automatica che dispone di un numero massimo di UR/s pari a 20.000 UR/s (viene ridimensionato tra 2.000 UR/s e 20.000 UR/s). Quando si esegue l'aggiornamento per l'uso della velocità effettiva con provisioning manuale, la velocità effettiva iniziale è di 20.000 UR/s.

Nel caso in cui sia necessario eseguire la migrazione di un numero elevato di risorse per la velocità effettiva, prendere in considerazione l'uso di questo script dell'interfaccia della riga di comando di Azure - Converti in scalabilità automatica.

Sì. Per abilitare in modo programmatico la scalabilità automatica in un database o un contenitore esistente, è possibile usare l'interfaccia della riga di comando di Azure o PowerShell.

Per creare un nuovo database o un contenitore con scalabilità automatica, è possibile usare l'interfaccia della riga di comando di Azure, PowerShell o un modello di Azure Resource Manager.

Sì. Per abilitare la scalabilità automatica per un database con velocità effettiva condivisa, quando si crea il database, selezionare scalabilità automatica e quindi l'opzione Effettuare il provisioning della velocità effettiva.

In un database con velocità effettiva condivisa Azure Cosmos DB applica un massimo di 25 contenitori. Il numero massimo si applica ai database con scalabilità automatica o velocità effettiva standard (manuale).

La scalabilità automatica non produce effetti sul livello di coerenza di un database.

Per altre informazioni, vedere l'articolo relativo ai livelli di coerenza.

Il limite della risorsa di archiviazione in GB per ogni UR/s massimo è il numero massimo di UR/s del database o del contenitore diviso per 10. Se ad esempio il numero massimo di UR/s è 20.000, la risorsa può supportare 2.000 GB di spazio di archiviazione.

Per le opzioni di UR/s massimo e di risorse di archiviazione disponibili, vedere Effettuare il provisioning dei limiti di scalabilità automatica della velocità effettiva.

Se il limite di archiviazione associato alla velocità effettiva massima del database o del contenitore viene superato, Azure Cosmos DB aumenta automaticamente la velocità effettiva massima al numero di UR/s più alto successivo che può supportare quel livello di archiviazione corrente.

Per uno scenario di esempio, se si inizia con un numero massimo di UR/s pari a 50.000 UR/s (viene ridimensionato tra 5.000 UR/s e 50.000 UR/s), è possibile archiviare fino a 5.000 GB di dati. Se le dimensioni di archiviazione aumentano a 5.001 GB, la risorsa di archiviazione è ora di 6.000 GB e il nuovo numero massimo di UR/s è 60.000 UR/s (viene ridimensionato tra 6.000 UR/s e 60.000 UR/s).

Sì. Per altre informazioni, vedere Come effettuare il provisioning della velocità effettiva a scalabilità automatica.

Quando si modifica il numero massimo di UR/s, a seconda del valore richiesto, l'operazione asincrona potrebbe richiedere da 4 a 6 ore. Altre informazioni.

Quando si invia una richiesta di aumento del numero massimo di UR/s Tmax, a seconda del numero massimo di UR/s selezionato, il servizio effettua il provisioning di una quantità maggiore di risorse per supportare il numero massimo di UR/s più alto. Durante questa operazione, il carico di lavoro e le operazioni esistenti non ne vengono interessate. Il sistema continua a ridimensionare il database o il contenitore tra il 0,1 × Tmax precedente e Tmax fino a quando non sarà pronto il nuovo intervallo di scalabilità da 0,1 × Tmax_new a Tmax_new.

Quando si riduce il numero massimo di UR/s, il valore minimo che è possibile impostare è MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10), arrotondato al migliaio di UR/s più vicino.

Esempio 1: è disponibile un contenitore di scalabilità automatica con un numero massimo di UR/s pari a 20.000 UR/s (viene ridimensionato tra 2.000 UR/s e 20.000 UR/s) e 1.500 GB di risorsa di archiviazione. Il valore minimo più basso su cui è possibile impostare il numero massimo di UR/s è MAX(1,000, 20,000 / 10, 1,500 × 10) = 15.000 UR/s (viene ridimensionato tra 1.500 UR/s e 15.000 UR/s).

Esempio 2: è disponibile un contenitore di scalabilità automatica con un numero massimo di UR/s pari a 100.000 UR/s e 100 GB di risorsa di archiviazione. Ora è possibile ridimensionare fino a 150.000 UR/s (viene ridimensionato tra 15.000 UR/s e 150.000 UR/s). Il valore minimo più basso su cui è ora possibile impostare il numero massimo di UR/s è MAX(1,000, 150,000 / 10, 100 × 10) = 15.000 UR/s (viene ridimensionato tra 1.500 UR/s e 15.000 UR/s).

Per un database con velocità effettiva condivisa, quando si riduce il numero massimo di UR/s, il valore minimo che è possibile impostare è MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10, 1,000 + (MAX(Container count - 25, 0) × 1,000)), arrotondato al migliaio di UR/s più vicino.

Queste formule ed esempi si applicano al numero massimo di UR/s di scalabilità automatica minima che è possibile impostare. Sono separati dall’intervallo compreso tra 0,1 × Tmax e Tmax al quale il sistema viene ridimensionato automaticamente. Indipendentemente dal numero massimo di UR/s, il sistema viene sempre ridimensionato tra 0,1 × Tmax e Tmax.

Le operazioni TTL (Time to Live) non influiscono sul ridimensionamento di UR/s nella scalabilità automatica. Tutte le UR/s che sono state utilizzate per operazioni TTL non rientrano tra le UR/s fatturate per il contenitore con scalabilità automatica.

Ad esempio, per un contenitore di scalabilità automatica da 400 UR/s a 4.000 UR/s:

• Ora 1: T=0: il contenitore non ha utilizzo (nessuna richiesta TTL o di carico di lavoro). Le UR/s fatturabili sono 400.
• Ora 1: T=1: TTL è abilitato.
• Ora 1: T=2: il contenitore inizia a ottenere le richieste. Le richieste utilizzano 1.000 UR/s in 1 secondo. Vengono usate TTL da 200 UR/s. Le UR/s fatturabili sono comunque 1.000. Indipendentemente dal momento in cui avvengono le eliminazioni TTL, non influiscono sulla logica del ridimensionamento automatico.

Quando si seleziona per la prima volta il numero massimo di UR/s, Azure Cosmos DB effettua il provisioning dividendo il numero massimo di UR/s per 10.000 UR/s, e in questo modo ottiene il numero di partizioni fisiche necessarie. Ogni partizione fisica può supportare fino a 10.000 UR/s e 50 GB di spazio di archiviazione. Con l'aumentare delle dimensioni di archiviazione, Azure Cosmos DB divide automaticamente le partizioni per aggiungere altre partizioni fisiche per gestire l'aumento della risorsa di archiviazione. Se l'archiviazione supera il limite associato, Azure Cosmos DB aumenta il numero massimo di UR/s.

Il numero massimo di UR/s del database o del contenitore viene diviso uniformemente tra tutte le partizioni fisiche. La velocità effettiva totale alla quale può scalare qualsiasi singola partizione fisica è il numero massimo di UR/s del database o del contenitore diviso per il numero di partizioni fisiche.

Se il numero di UR/s utilizzate complessivamente supera il numero massimo di UR/s del database o del contenitore, le richieste che superano il numero massimo di UR/s vengono limitate e restituiscono un codice di stato 429. Le richieste che comportano un utilizzo normalizzato superiore al 100% vengono limitate. L'utilizzo normalizzato è definito come l'utilizzo massimo delle UR/s tra tutte le partizioni fisiche.

Ad esempio, la velocità effettiva massima è di 20.000 UR/s e sono presenti due partizioni fisiche, P_1 e P_2. Ogni partizione è in grado di ridimensionare fino a 10.000 UR/s. In un secondo dato, se P_1 ha usato 6.000 UR/s e P_2 ha usato 8.000 UR/s, l'utilizzo normalizzato è MAX(6,000 RU / 10,000 RU, 8,000 RU / 10,000 RU) = 0,8.

Sì. Gli errori con codice 429 vengono visualizzati in due casi.

Nel primo scenario, se le UR/s utilizzate superano il numero massimo di UR/s del database o del contenitore, il servizio limita le richieste di conseguenza.

In secondo luogo, se un valore di chiave di partizione logica ha un numero sproporzionato di richieste rispetto ad altri valori di chiave di partizione, ad esempio in una partizione ad accesso frequente, la partizione fisica sottostante potrebbe superare il budget di UR/s. Come procedura consigliata, per evitare partizioni con accesso frequente, scegliere una chiave di partizione adeguata che comporti una distribuzione uniforme sia dello spazio di archiviazione che della velocità effettiva.

Se ad esempio si seleziona l'opzione di velocità effettiva massima di 20.000 UR/s e si hanno 200 GB di spazio di archiviazione, se si dispone di quattro partizioni fisiche, ciascuna può essere ridimensionata automaticamente fino a 5.000 UR/s. Se una partizione ad accesso frequente si trova in una chiave di partizione logica specifica, gli errori di codice 429 saranno visualizzati quando la partizione fisica sottostante in cui si trova, supera i 5.000 UR/s o l'utilizzo normalizzato del 100%.

Il visualizzare gli errori di codice 429 quando si usa la scalabilità automatica non indica necessariamente un problema con il database o il contenitore. In genere per un carico di lavoro di produzione, se tra il 1% e il 5% delle richieste presenta errori di codice 429 e la latenza end-to-end è accettabile, gli errori sono un segno integro che le UR/s vengono usate completamente. Non è necessaria alcuna azione.

Informazioni su come interpretare ed eseguire il debug di errori di limitazione della frequenza del codice 429.

Sì. Per altre informazioni, vedere Monitorare le UR/s normalizzate.

Passaggi successivi

• Informazioni su come abilitare la scalabilità automatica in un database o in un contenitore di Azure Cosmos DB.
• Informazioni sui vantaggi del provisioning della velocità effettiva usando la scalabilità automatica.
• Altre informazioni sulle partizioni logiche e fisiche.