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

La scalabilità automatica o la velocità effettiva con provisioning con scalabilità automatica è il nome aggiornato per la funzionalità di Azure Cosmos DB chiamata in precedenza autopilot. Nella versione corrente della scalabilità automatica sono state aggiunte nuove funzionalità, tra cui il supporto a livello di codice e la possibilità di impostare UR/sec personalizzate.

Le risorse create nel modello di livello precedente sono supportate automaticamente nel nuovo modello di UR/sec personalizzato per la 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/sec e 4.000 UR/sec, il database o il contenitore mostra ora un numero massimo di UR/sec di 4.000 UR/sec, che viene ridimensionato tra 400 UR/sec e 4.000 UR/sec. È quindi possibile modificare il valore massimo di UR/sec 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/sec inferiore a 1.000 UR/sec (scalabilità compresa tra 100 UR/sec e 1.000 UR/sec). È anche possibile impostare un intervallo di scalabilità di 200 UR/sec su 2.000 UR/s o 300 UR/s su 3.000 UR/sec. In precedenza, il punto di ingresso era da 400 UR/sec a 4.000 UR/sec.

È 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/sec.

Con la scalabilità automatica, il sistema ridimensiona la velocità effettiva (UR/sec) T verso l'alto o T verso il basso nell'intervallo di 0,1 × Tmax in base al Tmax 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 il numero massimo di UR/sec di scalabilità automatica di cui è stato effettuato il provisioning e la velocità effettiva corrente (UR/sec) su cui viene ridimensionato il sistema.

Ogni ora viene addebitata la velocità effettiva T più elevata a cui il sistema è stato ridimensionato entro quell'ora. Se la risorsa non aveva richieste durante l'ora o non è stata ridimensionata oltre 0,1 × Tmax, viene addebitato il valore 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 velocità di scalabilità automatica per 100 UR/sec è 1,5 volte la 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. Ad esempio, se il numero massimo di UR/sec del sistema è stato ridimensionato in un'ora è pari a 6.000 UR/sec, vengono fatturati 60 × 1,5 = 90 unità del contatore per quell'ora.

Negli account con più aree di scrittura, la velocità di scalabilità automatica per 100 UR/sec corrisponde alla frequenza per la velocità effettiva standard (manuale) con provisioning di più aree di scrittura. La fattura mostra il contatore delle aree multiple di scrittura esistente. Poiché le tariffe sono le stesse, se si usa la scalabilità automatica, viene visualizzata la stessa quantità di per la velocità effettiva standard.

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

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ì. Il numero massimo di UR/sec è disponibile in ogni area aggiunta all'account Azure Cosmos DB.

Informazioni su Come abilitare la scalabilità automatica.

Sì. È anche possibile passare dalla velocità effettiva con provisioning standard (manuale) alla scalabilità automatica. 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, non è possibile usare gli SDK client di Azure Cosmos DB o un modello di Azure Resource Manager per eseguire la migrazione tra velocità effettiva con provisioning manuale e scalabilità automatica. Tuttavia, è possibile usare gli SDK client o un modello di Azure Resource Manager per creare nuove risorse di scalabilità automatica e modificare il numero massimo di UR/sec 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 di UR/s iniziale in base alle impostazioni correnti della velocità effettiva e all'archiviazione. Durante questo passaggio, non viene accettato alcun valore ur/s fornito dall'utente. Dopo aver completato l'aggiornamento, è quindi possibile modificare le UR/sec in modo da supportare il carico di lavoro.

Eseguire la migrazione dalla velocità effettiva con provisioning standard (manuale) alla scalabilità automatica

Per un contenitore, usare la formula seguente per stimare il numero massimo di UR/sec di scalabilità automatica iniziale:

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

Il numero massimo effettivo di UR/sec di scalabilità automatica iniziale può 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/sec di scalabilità automatica iniziale è 10.000 UR/sec, che può essere ridimensionato tra 1.000 UR/s e 10.000 UR/sec.

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

Eseguire la migrazione dalla scalabilità automatica alla velocità effettiva con provisioning standard (manuale)

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

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

Sì. Per abilitare la scalabilità automatica a livello di codice 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 nuovo contenitore che usa la 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 l'opzione Provision throughput (Provision throughput ).

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

La scalabilità automatica non ha alcun effetto sul livello di coerenza di un database.

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

Il limite di archiviazione in GB per ogni UR/sec massima è il numero massimo di UR/sec del database o del contenitore diviso per 10. Ad esempio, se il numero massimo di UR/sec è 20.000 UR/sec, la risorsa può supportare 2.000 GB di spazio di archiviazione.

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

Se viene superato il limite di archiviazione associato alla velocità effettiva massima del database o del contenitore, Azure Cosmos DB aumenta automaticamente la velocità effettiva massima al numero massimo di UR/sec successivo che può supportare tale livello di archiviazione.

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

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

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

Quando si invia una richiesta per aumentare il numero massimo di UR/sec Tmax, a seconda del numero massimo di UR/sec selezionato, il servizio effettua il provisioning di più risorse per supportare le UR/sec massime più elevate. In questo caso, il carico di lavoro e le operazioni esistenti non sono interessati. Il sistema continua a ridimensionare il database o il contenitore tra il × Tmax 0.1 precedente e Tmax fino a quando non è pronto il nuovo intervallo di scalabilità Tmax_new di 0,1 ×.Tmax_new

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

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

Esempio 2: è disponibile un contenitore di scalabilità automatica con un numero massimo di UR/sec pari a 100.000 UR/s e 100 GB di spazio di archiviazione. A questo momento, è possibile ridimensionare fino a 150.000 UR/sec (scalabilità compresa tra 15.000 UR/sec e 150.000 UR/sec). Il valore minimo minimo che è ora possibile impostare il numero massimo di UR/sec su è MAX(1,000, 150,000 / 10, 100 × 10) = 15.000 UR/sec (scalabilità compresa tra 1.500 UR/sec e 15.000 UR/sec).

Per un database con velocità effettiva condivisa, quando si riduce il numero massimo di UR/sec, il valore minimo su cui è possibile impostarlo viene 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 valore massimo di 1.000 UR/sec.

Queste formule ed esempi si applicano al numero minimo di UR/sec di scalabilità automatica che è possibile impostare. Sono separati dal × Tmax 0,1 all'intervallo Tmax a cui il sistema viene ridimensionato automaticamente. Indipendentemente dalle UR/sec massime, il sistema viene sempre ridimensionato tra 0,1 × Tmax e Tmax.

Le operazioni TTL (Time to Live) non influiscono sul ridimensionamento delle UR/sec nella scalabilità automatica. Tutte le UR utilizzate a causa della durata (TTL) non fanno parte delle UR/sec fatturate del contenitore di scalabilità automatica.

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

• Ora 1: T=0: il contenitore non ha utilizzo (nessuna richiesta TTL o 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 in 1 secondo. Vengono usate 200 UR di durata (TTL). Le UR/sec fatturabili sono ancora pari a 1.000 UR/sec. Indipendentemente dal momento in cui si verificano le eliminazioni TTL, non influiscono sulla logica di scalabilità automatica.

Quando si seleziona per la prima volta il numero massimo di UR/sec, Azure Cosmos DB effettua il provisioning dividendo il numero massimo di UR/sec per 10.000 UR/s per ottenere 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 suddivide automaticamente le partizioni per aggiungere altre partizioni fisiche per gestire l'aumento dell'archiviazione. Se l'archiviazione supera il limite associato, Azure Cosmos DB aumenta il numero massimo di UR/sec.

Il numero massimo di UR/sec del database o del contenitore viene diviso uniformemente in tutte le partizioni fisiche. La velocità effettiva totale che qualsiasi singola partizione fisica può ridimensionare è il numero massimo di UR/sec del database o del contenitore diviso per il numero di partizioni fisiche.

Se le UR/sec complessive utilizzate superano il numero massimo di UR/sec del database o del contenitore, le richieste che superano il numero massimo di UR/sec vengono limitate e restituiscono uno stato di codice 429. Le richieste che comportano un utilizzo normalizzato superiore al 100% vengono limitate. L'utilizzo normalizzato viene definito come il massimo dell'utilizzo di UR/sec in tutte le partizioni fisiche.

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

Sì. È possibile visualizzare gli errori di codice 429 in due scenari.

In primo luogo, quando le UR/sec complessive utilizzate superano il numero massimo di UR/sec 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.

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

La visualizzazione degli 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/sec 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/sec normalizzate.

Passaggi successivi

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