Come scegliere tra la velocità effettiva con provisioning standard (manuale) e la velocità effettiva con provisioning a scalabilità automatica

Articolo
06/01/2023

SI APPLICA A: Nosql Mongodb Cassandra Gremlin Tabella

Azure Cosmos DB supporta due tipi o offerte di velocità effettiva con provisioning: standard (manuale) e a scalabilità automatica. Entrambi i tipi di velocità effettiva sono adatti per carichi di lavoro cruciali che richiedono scalabilità e prestazioni elevate e sono supportati dagli stessi contratti di servizio Azure Cosmos DB in merito a velocità effettiva, disponibilità, latenza e coerenza.

Questo articolo descrive come scegliere tra la velocità effettiva con provisioning standard (manuale) e la velocità effettiva con provisioning a scalabilità automatica per un carico di lavoro.

Panoramica dei tipi di velocità effettiva con provisioning

Prima di illustrare la differenza tra standard (manuale) e a scalabilità automatica, è importante comprendere il ruolo della velocità effettiva con provisioning in Azure Cosmos DB.

Quando si usa la velocità effettiva con provisioning, si imposta la velocità effettiva, misurata in unità richiesta al secondo (UR/s), necessaria per il carico di lavoro in corso. Il servizio effettua quindi il provisioning della capacità necessaria per supportare i requisiti di velocità effettiva. Ogni operazione di database eseguita sul servizio, ad esempio letture, scritture e query, userà una determinata quantità di unità richiesta (UR). Altre informazioni sulle unità richiesta.

La tabella seguente illustra un confronto generale tra standard (manuale) e a scalabilità automatica.

Descrizione	Standard (manuale)	Autoscale
Ideale per	Carichi di lavoro con traffico stabile o prevedibile	Carichi di lavoro con traffico variabile o imprevedibile. Vedere i casi d'uso di scalabilità automatica.
Funzionamento	Viene effettuato il provisioning di una quantità di UR/s `T` statiche nel tempo, a meno che non vengano modificate manualmente. Ogni secondo, è possibile usare una velocità effettiva fino a `T` UR/s. Se, ad esempio, si imposta il parametro Standard (manuale) su 400 UR/s, la velocità effettiva resterà pari a 400 UR/s.	È possibile impostare la quantità massima di UR/s `Tmax` che non si vuole venga superata dal sistema. Il sistema ridimensiona automaticamente la velocità effettiva `T` in modo che `0.1* Tmax <= T <= Tmax`. Se, ad esempio, si imposta una scalabilità automatica massima di 4000 UR/s, il sistema rispetterà una scalabilità compresa tra 400 e 4000 UR/s.
Scenari di utilizzo	Quando si preferisce gestire manualmente la capacità di velocità effettiva (UR/s) e impostare autonomamente il valore di scalabilità. In presenza di un uso elevato e coerente di UR/s con provisioning. Se per tutte le ore di un mese si imposta un valore di UR/s con provisioning `T` e si usa la quantità massima per il 66% delle ore o più, si stima che si risparmi scegliendo la velocità effettiva con provisioning standard (manuale). Questa supposizione si basa sul confronto tra l'impostazione di `T` in modalità standard (manuale) e l'impostazione della stessa quantità `Tmax` in modalità scalabilità automatica.	Quando si preferisce che Azure Cosmos DB gestisca la scalabilità e la capacità della velocità effettiva (UR/s), in base all'utilizzo. In presenza di un uso di UR/s variabile o difficile da stimare. Se per tutte le ore di un mese si imposta un valore di UR/s con scalabilità automatica massima di `Tmax` e la quantità massima `Tmax` viene usata per meno del 66% delle ore, si stima che si risparmi scegliendo la scalabilità automatica. Questa supposizione si basa sul confronto tra l'impostazione della velocità effettiva a scalabilità automatica `Tmax` e l'impostazione della stessa quantità `T` in modalità standard (manuale).
Modello di fatturazione	Per le UR/s con provisioning, la fatturazione viene eseguita su base oraria, indipendentemente dal numero di UR utilizzate. Esempio: Provisioning di 400 UR/s Ora 1: nessuna richiesta Ora 2: richieste per un valore di 400 UR/s Per entrambe le ore 1 e 2, verranno fatturate 400 UR/s alla tariffa standard (manuale).	La fatturazione viene eseguita su base oraria, per il più elevato numero di UR/s a cui il sistema è giunto nel corso dell'ora. Esempio: Provisioning con scalabilità automatica massima di UR/s pari a 4000 UR/s (con scalabilità compresa tra 400 e 4000 UR/s) Ora 1: il sistema raggiunge il valore massimo di 3500 UR/s Ora 2: il sistema raggiunge il valore minimo di 400 UR/s (sempre il 10% di `Tmax`), a causa di assenza di utilizzo Verranno addebitate 3500 UR/s nell'ora 1 e 400 UR/s nell'ora 2 alla tariffa della velocità effettiva con provisioning a scalabilità automatica. La velocità di scalabilità automatica per UR/s è 1,5 * tariffa standard (manuale).
Cosa accade se si supera la quantità di UR/s con provisioning	Il numero di UR/s rimane statico alla quantità sottoposta a provisioning. Per eventuali richieste che consumano un numero di UR al secondo superiore alla quantità di cui è stato effettuato il provisioning viene forzata una limitazione della velocità, con una risposta che suggerisce un tempo di attesa prima di riprovare. Se necessario, è possibile aumentare o diminuire manualmente il numero di UR/s.	Il sistema aumenta il numero di UR/s fino alla quantità massima di UR con scalabilità automatica. Per eventuali richieste che consumano un numero di UR al secondo superiore alla quantità massima con scalabilità automatica precedentemente impostata, viene forzata una limitazione della velocità, con una risposta che suggerisce un tempo di attesa prima di riprovare.

Panoramica sui modelli di traffico

Nuove applicazioni

Se si sta compilando una nuova applicazione e non si conosce ancora il modello di traffico, è possibile iniziare dal punto di ingresso di UR/s (o numero minimo di UR/s) per evitare l'overprovisioning nella fase iniziale. Se invece si ha un'applicazione di piccole dimensioni che non richiede una particolare scalabilità, è preferibile effettuare il provisioning solo del numero minimo di UR/s (punto di ingresso) per ottimizzare i costi. Per le piccole applicazioni con un traffico previsto ridotto, è anche possibile considerare la modalità di capacità serverless .

Se si prevede di usare standard (manuale) o scalabilità automatica, ecco cosa si dovrebbe considerare:

Se si seleziona la velocità effettiva con provisioning standard (manuale) al punto di ingresso di 400 UR/s, non sarà possibile usare più di 400 UR/s, a meno che non si modifichi manualmente la velocità effettiva. Verranno quindi addebitate 400 UR/s alla tariffa oraria della velocità effettiva con provisioning standard (manuale).

Se si effettua il provisioning della velocità effettiva di scalabilità automatica con 4000 UR/s, la risorsa verrà ridimensionata tra 400 e 4000 UR/s. Poiché la tariffa di fatturazione della velocità effettiva a scalabilità automatica per UR/s è pari a 1,5 volte la tariffa standard (manuale), per le ore in cui il sistema è rimasto al punto di ingresso di 400 UR/s, l'importo della fattura sarebbe superiore rispetto a quello che risulterebbe impostando manualmente il provisioning a 400 UR/s. Con la scalabilità automatica, tuttavia, se in un momento qualsiasi si verifica un picco di traffico dell'applicazione, è possibile usare fino a 4000 UR/s senza che sia necessario alcun intervento da parte dell'utente. In generale, quindi, è consigliabile prendere in considerazione il vantaggio di poter usare in qualsiasi momento il numero massimo di UR/s con una tariffa pari ad appena 1,5 volte la tariffa standard.

Per stimare i requisiti di velocità effettiva, usare lo strumento di calcolo della capacità di Azure Cosmos DB.

Applicazioni esistenti

Se si ha un'applicazione esistente per cui è stata applicata la velocità effettiva con provisioning standard (manuale), è possibile usare le metriche di Monitoraggio di Azure per determinare se il modello di traffico in uso è adatto alla scalabilità automatica.

Per prima cosa, individuare la metrica di utilizzo delle unità richiesta normalizzate del database o del contenitore. L'utilizzo normalizzato è una misura della capacità attualmente in uso della velocità effettiva con provisioning (manuale). Più il numero si avvicina al 100%, maggiore sarà la quantità di UR/s con provisioning interamente usati. Altre informazioni sulle metriche.

Determinare quindi il modo in cui l'utilizzo normalizzato varia nel tempo. Trovare l'utilizzo normalizzato più elevato per ogni ora. Calcolare quindi l'utilizzo normalizzato medio in tutte le ore. Se si nota che l'utilizzo normalizzato è inferiore al 66%, provare ad abilitare la scalabilità automatica nel database o nel contenitore. Al contrario, se l'utilizzo medio è superiore al 66%, è consigliabile mantenere la velocità effettiva sottoposta a provisioning standard (manuale).

Suggerimento

Se l'account è configurato per l'uso di scritture su più aree e ha più di un'area, la frequenza per 100 UR/s è uguale sia per la scalabilità manuale che per la scalabilità automatica. Ciò significa che l'abilitazione della scalabilità automatica non comporta costi aggiuntivi indipendentemente dall'utilizzo. Di conseguenza, è sempre consigliabile usare la scalabilità automatica con operazioni di scrittura su più aree quando si dispone di più aree, per sfruttare i risparmi derivanti dal pagamento solo per le scalabilità dell'applicazione a. Se si dispone di scritture su più aree e un'area, usare l'utilizzo medio per determinare se la scalabilità automatica comporterà risparmi sui costi.

Esempio

Esaminiamo due carichi di lavoro di esempio diversi e analizziamo se sono adatti per la velocità effettiva manuale o di scalabilità automatica. Per illustrare l'approccio generale, verranno analizzate tre ore di cronologia per determinare la differenza di costo tra l'uso manuale e la scalabilità automatica. Per i carichi di lavoro di produzione, è consigliabile usare da 7 a 30 giorni di cronologia (o più tempo, se disponibile) per stabilire un modello di utilizzo delle UR/s.

Nota

Tutti gli esempi illustrati in questa documentazione si basano sul prezzo per un account Azure Cosmos DB distribuito in un'area non governativa negli Stati Uniti. I prezzi e il calcolo variano a seconda dell'area usata, vedere la pagina dei prezzi di Azure Cosmos DB per le informazioni sui prezzi più recenti.

Presupposti:

Si supponga di avere attualmente una velocità effettiva manuale di 30.000 UR/s.
L'area è configurata con scritture in un'area singola, con un'area. Se si disponesse di più aree, si moltiplica il costo orario per il numero di aree.
Usare le tariffe dei prezzi pubblici per la velocità effettiva manuale ($ 0,008 USD per 100 UR/sec all'ora) e la velocità effettiva di scalabilità automatica ($ 0,012 USD per 100 UR/sec all'ora) in account di scrittura a singola area. Per informazioni dettagliate, vedere la pagina dei prezzi .

Esempio 1: Carico di lavoro variabile (scelta consigliata per la scalabilità automatica)

In primo luogo, si esamina il consumo normalizzato di UR. Questo carico di lavoro ha traffico variabile, con un consumo di UR normalizzato compreso tra il 6% e il 100%. Ci sono picchi occasionali al 100% difficili da prevedere, ma molte ore con un utilizzo ridotto.

Carico di lavoro con traffico variabile : consumo normalizzato di UR tra il 6% e il 100% per tutte le ore

Confrontare il costo del provisioning della velocità effettiva manuale di 30.000 UR/s rispetto all'impostazione del numero massimo di UR/sec con scalabilità automatica a 30.000 (scalabilità compresa tra 3000 e 30.000 UR/sec).

A questo punto, analizziamo la cronologia. Si supponga di avere l'utilizzo descritto nella tabella seguente. L'utilizzo medio tra queste tre ore è del 39%. Poiché il consumo di UR normalizzato è inferiore al 66%, si risparmia usando la scalabilità automatica.

Si noti che nell'ora 1, quando è presente un utilizzo del 6%, la scalabilità automatica fattura UR/sec per il 10% del numero massimo di UR/sec, ovvero il valore minimo per ora. Anche se il costo della scalabilità automatica può essere superiore alla velocità effettiva manuale in determinate ore, purché l'utilizzo medio sia inferiore al 66% per tutte le ore, la scalabilità automatica sarà più economica complessivamente.

Periodo di tempo	Utilizzo	Ur/sec di scalabilità automatica fatturata	Opzione 1: Manuale 30.000 UR/sec	Opzione 2: Scalabilità automatica tra 3000 e 30.000 UR/sec
Ora 1	6%	3000	30.000 * 0,008 / 100 = $ 2,40	3000 * 0,012 / 100 = $ 0,36
Ora 2	100%	30.000	30.000 * 0,008 / 100 = $ 2,40	30.000 * 0,012 / 100 = $ 3,60
Ora 3	11%	3300	30.000 * 0,008 / 100 = $ 2,40	3300 * 0,012 / 100 = $ 0,40
Totale			$ 7,20	$ 4,36 (risparmio del 39%)

Esempio 2: Carico di lavoro stabile (velocità effettiva manuale consigliata)

Questo carico di lavoro ha un traffico costante, con un consumo normalizzato di UR compreso tra il 72% e il 100%. Con provisioning di 30.000 UR/sec, ciò significa che stiamo consumando da 21.600 a 30.000 UR/sec.

Carico di lavoro con traffico costante: consumo normalizzato di UR tra il 72% e il 100% per tutte le ore

Si supponga di avere la cronologia di utilizzo come descritto nella tabella. L'utilizzo medio tra queste tre ore è pari all'88%. Poiché il consumo di UR normalizzato raggiunge un valore superiore al 66%, si risparmia usando la velocità effettiva manuale.

In generale, se l'utilizzo medio per tutte le 730 ore in un mese è maggiore del 66%, si salverà usando la velocità effettiva manuale.

Periodo di tempo	Utilizzo	Ur/sec di scalabilità automatica fatturata	Opzione 1: Manuale 30.000 UR/sec	Opzione 2: Scalabilità automatica tra 3000 e 30.000 UR/sec
Ora 1	72%	21,600	30.000 * 0,008 / 100 = $ 2,40	21600 * 0,012 / 100 = $ 2,59
Ora 2	93%	28.000	30.000 * 0,008 / 100 = $ 2,40	28.000 * 0,012 / 100 = $ 3,36
Ora 3	100%	30.000	30.000 * 0,008 / 100 = $ 2,40	30.000 * 0,012 / 100 = $ 3,60
Totale			$ 7,20	$9,55

Suggerimento

Con la velocità effettiva standard (manuale) impostata, è possibile usare la metrica di utilizzo normalizzato per stimare le UR/s effettive che sarebbe possibile usare se si passasse alla scalabilità automatica. Moltiplicare l'utilizzo normalizzato in un punto nel tempo per il numero di UR/s con provisioning standard (manuale). Se, ad esempio, è stato effettuato il provisioning di 5000 UR/s e l'utilizzo normalizzato è pari al 90%, il consumo di UR/s sarà pari a 0,9 * 5000 = 4500 UR/s. Se si nota che il modello di traffico è variabile, ma si è al di sopra o al di sotto del limite di provisioning, è possibile abilitare la scalabilità automatica e quindi modificare di conseguenza il numero massimo di UR/s con scalabilità automatica.

Come calcolare l'utilizzo medio

La scalabilità automatica fattura il numero massimo di UR/sec ridimensionato in un'ora. Quando si analizza il consumo normalizzato di UR nel tempo, è importante usare l'utilizzo più elevato all'ora durante il calcolo della media.

Per calcolare la media dell'utilizzo più elevato in tutte le ore:

Impostare Aggregazione sulla metrica Utilizzo UR noramlized su Max.
Selezionare La granularità dell'ora su 1 ora.
Passare a Opzioni grafico.
Selezionare l'opzione grafico a barre.
In Condividi selezionare l'opzione Scarica in Excel . Dal foglio di calcolo generato calcolare l'utilizzo medio per tutte le ore.

Per visualizzare il consumo normalizzato di UR per ora, 1) Selezionare la granularità del tempo a 1 ora; 2) Modificare le impostazioni del grafico; 3) Selezionare l'opzione grafico a barre; 4) In Condividi selezionare l'opzione Scarica in Excel per calcolare la media in tutte le ore.

Misurare e monitorare l'utilizzo

Dopo aver scelto il tipo di velocità effettiva, è necessario monitorare l'applicazione a lungo termine e apportare eventuali modifiche in base alle esigenze.

Se si sceglie la scalabilità automatica, usare Monitoraggio di Azure per visualizzare il numero massimo di UR/s con provisioning a scalabilità automatica (velocità effettiva massima a scalabilità automatica) e il numero di UR/s a cui si trova attualmente il sistema (velocità effettiva con provisioning). Di seguito è riportato un esempio di carico di lavoro variabile o imprevedibile per il quale viene usata la scalabilità automatica. Se non è presente traffico, il sistema ridimensiona il numero di UR/s alla quantità minima del 10% rispetto al numero massimo di UR/s, che in questo caso sono, rispettivamente, 5000 UR/s e 50.000 UR/s.

Esempio di carico di lavoro con scalabilità automatica, con numero massimo di UR/sec con scalabilità automatica pari a 50.000 UR/sec e velocità effettiva compresa tra 5000 e 50.000 UR/sec