Come scegliere tra la velocità effettiva con provisioning standard (manuale) e la velocità effettiva con provisioning a scalabilità automatica
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. |
Quando usarlo | 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 | La fatturazione viene effettuata su base oraria per il provisioning delle unità richieste al secondo, indipendentemente dal numero di unità richieste usate. Esempio: 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: Tmax ), a causa di assenza di utilizzoVerranno 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 applicazioni di piccole dimensioni con un traffico previsto basso, per la capacità è anche possibile prendere in considerazione la modalità serverless.
Se si prevede di usare la scalabilità automatica o standard (manuale), è consigliabile considerare quanto segue:
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 invece si seleziona la velocità effettiva con provisioning a scalabilità automatica pari a 4000 UR/s, la risorsa verrà ridimensionata su un valore compreso 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.
Determinare quindi il modo in cui l'utilizzo normalizzato varia nel tempo. Trovare l'uso normalizzato più elevato per ogni ora. Calcolare quindi l'uso normalizzato medio tra 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 operazioni di scrittura in più aree e dispone di più di un'area, la tariffa per 100 UR/sec è la stessa per la scalabilità sia manuale che automatica. Ciò significa che l'abilitazione della scalabilità automatica non comporta costi aggiuntivi indipendentemente dall'uso. Di conseguenza, è sempre consigliabile usare la scalabilità automatica con operazioni di scrittura in più aree quando si dispone di più aree, per sfruttare il risparmio derivante dal pagamento solo delle UR/s a cui l'applicazione viene ridimensionata. In presenza di operazioni di scrittura in più aree e in un'area, usare l'utilizzo medio per determinare se la scalabilità automatica comporterà un risparmio sui costi.
Esempi
Verranno ora esaminati due diversi carichi di lavoro di esempio e si analizzerà se sono adatti per la velocità effettiva manuale o a scalabilità automatica. Per illustrare l'approccio generale, verranno analizzate tre ore nella cronologia per determinare la differenza di costo tra l'uso della scalabilità manuale e automatica. Per i carichi di lavoro di produzione, è consigliabile usare da 7 a 30 giorni della cronologia (o più, se disponibile) per stabilire un modello di uso di UR/sec.
Nota
Tutti gli esempi illustrati in questo documento si basano sul prezzo di un account Azure Cosmos DB distribuito in un'area non governativa negli Stati Uniti. I prezzi e i calcoli variano a seconda dell'area in uso. Per le informazioni più aggiornate sui prezzi, vedere la pagina dei prezzi di Azure Cosmos DB.
Presupposti:
- Si supponga di avere attualmente una velocità effettiva con scalabilità manuale pari a 30.000 UR/sec.
- L'area è configurata con operazioni di scrittura in una singola area, con un'area. Se si dispone di più aree, si deve moltiplicare il costo orario per il numero di aree.
- Usare le tariffe dei prezzi pubblici per la velocità effettiva con scalabilità manuale (0,008 USD per 100 UR/sec all'ora) e per la velocità effettiva con scalabilità automatica (0,012 USD per 100 UR/sec all'ora) in account con operazioni di scrittura in una singola area. Per informazioni dettagliate, vedere la pagina dei prezzi.
Esempio 1: carico di lavoro variabile (scelta consigliata per la scalabilità automatica)
Prima di tutto esaminare il consumo normalizzato di UR. Questo carico di lavoro ha traffico variabile, con un consumo normalizzato di UR compreso tra il 6% e il 100%. Sono presenti picchi occasionali al 100% difficili da prevedere, ma molte ore sono caratterizzate da un uso ridotto.
Confrontare il costo del provisioning di una velocità effettiva con scalabilità manuale pari a 30.000 UR/sec, rispetto all'impostazione del numero massimo di UR/sec con scalabilità automatica pari a 30.000 (scalabilità compresa tra 3000 e 30.000 UR/sec).
A questo punto, analizzare la cronologia. Si supponga che l'uso sia quello descritto nella tabella seguente. L'uso medio di queste tre ore è del 39%. Poiché la media del consumo di UR normalizzato è inferiore al 66%, si risparmia usando la scalabilità automatica.
Si noti che nell'ora 1, quando l'uso è pari al 6%, la scalabilità automatica fattura il 10% del numero massimo di UR/sec, ovvero il valore minimo all'ora. Anche se il costo della scalabilità automatica può essere superiore alla velocità effettiva con scalabilità manuale in determinate ore, purché l'uso medio sia inferiore al 66% per tutte le ore, complessivamente la scalabilità automatica sarà più conveniente.
Periodo di tempo | Utilizzo | UR/sec con scalabilità automatica fatturati | Opzione 1: 30.000 UR/sec con scalabilità manuale | Opzione 2: 3.000 - 30.000 UR/sec con scalabilità automatica |
---|---|---|---|---|
Ora 1 | %6 | 3000 | 30.000 * 0,008 / 100 = 2,40 USD | 3.000 * 0,012 / 100 = 0,36 USD |
Ora 2 | 100% | 30.000 | 30.000 * 0,008 / 100 = 2,40 USD | 30.000 * 0,012 / 100 = 3,60 USD |
Ora 3 | 11% | 3300 | 30.000 * 0,008 / 100 = 2,40 USD | 3.300 * 0,012 / 100 = 0,40 USD |
Totali | 7,20 USD | 4,36 USD (risparmio del 39%) |
Esempio 2: carico di lavoro costante (scelta consigliata per una velocità effettiva con scalabilità manuale)
Questo carico di lavoro ha traffico costante, con un consumo normalizzato di UR compreso tra il 72% e il 100%. Con il provisioning di 30.000 UR/s, ciò significa che vengono consumate tra 21.600 e 30.000 UR/sec.
Confrontare il costo del provisioning di una velocità effettiva con scalabilità manuale pari a 30.000 UR/sec, rispetto all'impostazione del numero massimo di UR/sec con scalabilità automatica pari a 30.000 (scalabilità compresa tra 3000 e 30.000 UR/sec).
Si supponga che la cronologia dell'uso sia quella descritta nella tabella seguente. L'uso medio di queste tre ore è dell'88%. Poiché la media del consumo di UR normalizzato è inferiore al 66%, si risparmia usando una velocità effettiva con scalabilità manuale.
In generale, se l'uso medio per tutte le 730 ore in un mese è maggiore del 66%, si risparmierà usando una velocità effettiva con scalabilità manuale.
Periodo di tempo | Utilizzo | UR/sec con scalabilità automatica fatturati | Opzione 1: 30.000 UR/sec con scalabilità manuale | Opzione 2: 3.000 - 30.000 UR/sec con scalabilità automatica |
---|---|---|---|---|
Ora 1 | 72% | 21.600 | 30.000 * 0,008 / 100 = 2,40 USD | 21.600 * 0,012 / 100 = 2,59 USD |
Ora 2 | 93% | 28.000 | 30.000 * 0,008 / 100 = 2,40 USD | 28.000 * 0,012 / 100 = 3,36 USD |
Ora 3 | 100% | 30.000 | 30.000 * 0,008 / 100 = 2,40 USD | 30.000 * 0,012 / 100 = 3,60 USD |
Totali | 7,20 USD | 9,55 USD |
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'uso medio
La scalabilità automatica fattura il valore più elevato di UR/s ridimensionate in un'ora. Quando si analizza il consumo normalizzato di UR nel tempo, è importante impiegare l'uso più elevato all'ora quando si calcola la media.
Per calcolare la media dell'uso più elevato in tutte le ore:
- Nella metrica Consumo UR normalizzato, impostare Aggregazione su Max.
- Impostare Granularità temporale su un'ora.
- Passare a Opzioni grafico.
- Selezionare l'opzione Grafico a barre.
- In Condividi selezionare l'opzione Scarica in Excel. Nel foglio di calcolo generato calcolare l'uso medio per 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).
L'esempio seguente fa riferimento a un carico di lavoro variabile o imprevedibile che usa 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, 5.000 UR/s e 50.000 UR/s.
Eseguire la migrazione della velocità effettiva con provisioning standard alla scalabilità automatica
Gli utenti che vogliono eseguire la migrazione di un numero elevato di risorse dalla velocità effettiva con provisioning standard alla scalabilità automatica possono usare uno script dell'interfaccia della riga di comando di Azure, che eseguirà la migrazione di ogni risorsa di velocità effettiva in una sottoscrizione di Azure alla scalabilità automatica. Per altri dettagli, vedere Convertire in scalabilità automatica.
Passaggi successivi
- Usare il calcolatore UR per stimare la velocità effettiva per i nuovi carichi di lavoro.
- Usare Monitoraggio di Azure per monitorare i carichi di lavoro esistenti.
- Informazioni su come effettuare il provisioning della velocità effettiva con scalabilità automatica in un database o un contenitore Azure Cosmos DB.
- Vedere le domande frequenti sulla scalabilità automatica.
- Si sta tentando di pianificare la capacità per una migrazione ad Azure Cosmos DB? È possibile usare le informazioni del cluster di database esistente per la pianificazione della capacità.
- Se si conosce solo il numero di vcore e server nel cluster di database esistente, leggere le informazioni sulla stima delle unità richieste usando vCore o vCPU
- Se si conosce la frequenza delle richieste tipiche per il carico di lavoro corrente del database, leggere le informazioni sulla stima delle unità richieste con lo strumento di pianificazione della capacità di Azure Cosmos DB