Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
SI APPLICA A: NoSQL
MongoDB
Cassandra
Gremlin
Tabella
In Azure Cosmos DB è possibile configurare la velocità effettiva standard (manuale) o scalabile automaticamente sui database e contenitori. La velocità effettiva con provisioning a scalabilità automatica in Azure Cosmos DB consente di ridimensionare la velocità effettiva (UR/sec) del database o del contenitore automaticamente e immediatamente.
La velocità effettiva con provisioning a scalabilità automatica è particolarmente adatta per carichi di lavoro cruciali con modelli di traffico variabili o imprevedibili e che richiedono contratti di servizio per prestazioni elevate e scalabilità. La scalabilità automatica per impostazione predefinita ridimensiona i carichi di lavoro in base all'area e alla partizione più attive. Per i carichi di lavoro non univoci con modelli di carico di lavoro diversi tra aree e partizioni, questa scalabilità può causare scale-up non necessarie. Il ridimensionamento dinamico o la scalabilità automatica dinamica è un potenziamento della scalabilità automatica configurata ovunque, che aiuta a ridimensionare tali carichi di lavoro non uniformi in modo indipendente in base all'utilizzo, a livello di regione e di partizione. Il ridimensionamento dinamico consente di risparmiare costi se si verificano spesso partizioni ad accesso frequente e/o con più aree.
Vantaggi della scalabilità automatica
I database e i contenitori di Azure Cosmos DB configurati con la velocità effettiva con provisioning a scalabilità automatica offrono i vantaggi seguenti:
Semplicità: la scalabilità automatica elimina la complessità della gestione di RU/s tramite script personalizzati o attraverso la capacità di ridimensionamento manuale.
Scalabilità: i database e i contenitori ridimensionano automaticamente la velocità effettiva con provisioning in base alle esigenze. senza interruzioni delle connessioni client, delle applicazioni e dei contratti di servizio di Azure Cosmos DB.
Convenienza: la scalabilità automatica consente di ottimizzare l'utilizzo di UR/sec e i costi grazie alla riduzione quando non in uso. Si paga solo per le risorse necessarie per i carichi di lavoro su base oraria. Se di tutte le ore in un mese imposti una scalabilità automatica con un valore massimo UR/s (Tmax) e utilizzi l'intero Tmax per il 66% delle ore o meno, puoi risparmiare con la scalabilità automatica. Oltre al ridimensionamento dinamico, l'aggiunta di un'area secondaria per la disponibilità elevata è più conveniente perché ogni area e partizione viene ridimensionata in modo indipendente in base all'utilizzo effettivo. Per altre informazioni, vedere l'articolo Come scegliere tra la velocità effettiva con provisioning standard (manuale) e la velocità effettiva con provisioning a scalabilità automatica.
Disponibilità elevata: i database e i contenitori che usano la scalabilità automatica usano lo stesso back-end di Azure Cosmos DB distribuito a livello globale, a tolleranza di errore e a disponibilità elevata per garantire la durabilità e un'elevata disponibilità dei dati.
Casi d'uso di scalabilità automatica
I casi d'uso di scalabilità automatica includono:
Carichi di lavoro variabili o imprevedibili: quando i carichi di lavoro hanno picchi di utilizzo variabili o imprevedibili, la scalabilità automatica consente di aumentare o ridurre automaticamente la capacità in base all'utilizzo. Gli esempi includono i siti Web di vendita al dettaglio con modelli di traffico diversi a seconda della stagionalità, i carichi di lavoro IoT con picchi in diversi momenti della giornata, le applicazioni line-of-business per le quali i picchi si verificano alcune volte al mese o all'anno e così via. Con la scalabilità automatica non è più necessario eseguire manualmente il provisioning per la capacità massima o media.
Nuove applicazioni: se si sta sviluppando una nuova applicazione e non si è certi della velocità effettiva (UR/sec) necessaria, la scalabilità automatica semplifica le operazioni iniziali. È possibile iniziare con un punto di ingresso per la scalabilità automatica di 100 - 1000 UR/sec, monitorare l'utilizzo e stabilire qual è il valore UR/sec corretto nel tempo.
Applicazioni usate raramente: se si dispone di un'applicazione, che viene usata solo per alcune ore diverse volte al giorno, alla settimana o al mese, ad esempio un sito di applicazione/Web/blog a basso volume. La scalabilità automatica regola la capacità per gestire i picchi di utilizzo e riduce la capacità quando terminano.
Carichi di lavoro di sviluppo e test: se l'utente o il suo team usa i database e i contenitori di Azure Cosmos DB durante le ore di lavoro, ma non ne ha bisogno nelle ore notturne o nei fine settimana, la scalabilità automatica consente di risparmiare sui costi riducendo la capacità al minimo quando non è in uso.
Carichi di lavoro e query di produzione pianificati: se hai una serie di richieste, operazioni o query programmate da eseguire durante i periodi di inattività, puoi farlo facilmente con la scalabilità automatica. Quando è necessario eseguire il carico di lavoro, la velocità effettiva viene automaticamente ridimensionata in base al valore necessario e si riduce in un secondo momento.
La creazione di una soluzione personalizzata a questi problemi non solo richiede una quantità di tempo enorme, ma introduce anche complessità nella configurazione o nel codice dell'applicazione. La scalabilità automatica consente di gestire con facilità gli scenari precedenti ed elimina la necessità di procedure personalizzate o manuali di ridimensionamento della capacità.
Casi d'uso di scalabilità dinamica
I casi d'uso del ridimensionamento dinamico includono:
- Carichi di lavoro del database con un'area primaria con traffico elevato e un'area passiva secondaria per il ripristino di emergenza.
- Con il ridimensionamento dinamico, il raggiungimento della disponibilità elevata con più aree è più conveniente. L'area secondaria viene ridimensionata in modo indipendente e automatico durante l'inattività. L'area secondaria si espande automaticamente quando diventa attiva e mentre gestisce il traffico di scrittura replicato dall'area primaria.
- Carichi di lavoro di database in più aree.
- Questi carichi di lavoro spesso osservano una distribuzione irregolare delle richieste tra regioni a causa della crescita naturale del traffico e delle flessioni durante il giorno. Ad esempio, un database potrebbe essere attivo durante l'orario di ufficio in fusi orari distribuiti a livello globale.
Funzionamento della velocità effettiva con provisioning a scalabilità automatica
Quando si configurano i contenitori e i database con la scalabilità automatica, è necessario specificare la velocità effettiva massima Tmax
richiesta. Azure Cosmos DB ridimensiona la velocità effettiva T
come 0.1*Tmax <= T <= Tmax
. Se ad esempio si imposta la velocità effettiva massima su 20.000 UR/sec, la velocità effettiva viene ridimensionata tra 2000 e 20.000 UR/sec. Poiché il ridimensionamento è automatico e istantaneo, in qualsiasi momento è possibile usare fino al valore Tmax
provisionato senza alcun ritardo.
Ogni ora viene addebitata la velocità effettiva più elevata T
a cui il sistema è stato ridimensionato entro tale ora. Quando il ridimensionamento dinamico è abilitato, il ridimensionamento si basa sull'utilizzo di UR/sec in ogni partizione fisica e in ogni area. Poiché ogni partizione e area vengono ridimensionate in modo indipendente, ciò può comportare risparmi sui costi per i carichi di lavoro non univoci, in quanto vengono evitate le istanze di scalabilità non necessarie.
Il punto di ingresso per la velocità effettiva massima a scalabilità automatica Tmax
inizia a 1000 UR/sec, che si ridimensiona tra 100 e 1000 UR/sec. È possibile impostare Tmax
con incrementi di 1000 UR/sec e modificare il valore in qualsiasi momento.
Ad esempio, se si dispone di una raccolta con 1000 UR/sec e 2 partizioni, ogni partizione può arrivare fino a 500 UR/sec. Per un'ora di attività, l'utilizzo sarà simile al seguente:
Regione | Partizione | Capacità di trasmissione | Utilizzo | Note |
---|---|---|---|---|
Scrittura | P1 | <= 500 UR/sec | 100% | 500 UR/sec costituite da 50 UR/sec usate per le operazioni di scrittura e 450 UR/sec per le operazioni di lettura. |
Scrittura | P2 | <= 200 UR/sec | 40 % | 200 UR/sec costituite da tutte le operazioni di lettura. |
Leggi | P1 | <= 150 UR/sec | 30% | 150 UR/sec costituite da 50 UR/sec utilizzate per le scritture replicate dall'area di scrittura. 100 UR/sec vengono usate per le operazioni di lettura in questa area. |
Leggi | P2 | <= 50 UR/sec | 10% |
Senza ridimensionamento dinamico, tutte le partizioni vengono ridimensionate in modo uniforme in base alla partizione più trafficata. In questo esempio, poiché la partizione più ad accesso frequente ha un utilizzo del 100%, tutte le partizioni nelle aree di scrittura e di lettura vengono ridimensionate a 1000 UR/sec, rendendo il numero totale di UR/sec ridimensionato a 2000 UR/sec.
Con il ridimensionamento dinamico, poiché ogni partizione e velocità effettiva dell'area viene ridimensionata in modo indipendente, il totale di UR/sec è pari a 900 UR/sec, che riflette meglio il modello di traffico effettivo e riduce i costi.
Abilitazione della scalabilità automatica sulle risorse esistenti
Usare il portale di Azure, l'interfaccia della riga di comando o PowerShell per abilitare la scalabilità automatica in un database o un contenitore esistente. In qualsiasi momento è possibile passare dalla velocità effettiva con provisioning a scalabilità automatica alla velocità effettiva con provisioning standard (manuale) e viceversa. Per altre informazioni, vedere questa documentazione.
Limiti di archiviazione e velocità effettiva per la scalabilità automatica
Per qualsiasi valore di Tmax
, il database o il contenitore può archiviare un totale di 0.1 * Tmax GB
. Raggiunta questa quantità di spazio di archiviazione, il valore massimo di UR/sec verrà aumentato automaticamente in base al nuovo valore di archiviazione, senza alcun impatto sull'applicazione.
Se ad esempio si inizia con un numero massimo di UR/sec pari a 50.000 (con scalabilità compresa tra 5000 e 50.000 UR/sec), è possibile archiviare fino a 5000 GB di dati. Se si superano i 5000 GB, ad esempio se ora l'archiviazione è pari a 6000 GB, il nuovo numero massimo di UR/s diventa 60.000 UR/s, con scalabilità compresa tra 6000 e 60.000 UR/s.
Quando si usa la velocità effettiva a livello di database con scalabilità automatica, è possibile fare in modo che i primi 25 contenitori condividano un numero massimo di UR/sec di scalabilità automatica pari a 1000 (con scalabilità compresa tra 100 e 1000 UR/sec), purché non si superino 100 GB di spazio di archiviazione. Per altre informazioni, vedere questa documentazione.
Abilitazione del ridimensionamento dinamico
Il ridimensionamento dinamico è abilitato per impostazione predefinita per tutti gli account Azure Cosmos DB creati dopo il 25 settembre 2024. I clienti che desiderano abilitare questa funzionalità per gli account meno recenti possono farlo a livello di codice tramite l'API Rest di Azure PowerShell/CLI o dal riquadro delle funzionalità di portale di Azure, come illustrato di seguito:
Nel portale di Azure passare all'account Azure Cosmos DB.
Passare alla pagina Funzionalità.
Individuare e abilitare la funzionalità Scalabilità automatica dinamica (scalabilità automatica per area e per partizione).
Importante
La funzionalità è abilitata a livello di account e verrà applicata automaticamente ai contenitori a scalabilità automatica e ai database con velocità effettiva a scalabilità automatica condivisa all'interno dell'account. L'abilitazione di questa funzionalità non influisce sulle risorse nell'account che utilizzano la velocità manuale. Per sfruttare il dimensionamento dinamico, le risorse manuali dovranno essere modificate per la scalabilità automatica. L'abilitazione di questa funzionalità non ha alcun impatto sul tempo di inattività o sulle prestazioni. Questa funzionalità non è applicabile per gli account serverless. Questa funzionalità è supportata in tutti i cloud.
Monitorare le metriche
È possibile usare le metriche seguenti per monitorare la scalabilità automatica e il ridimensionamento dinamico:
Nome della metrica | Definizione | Uso delle metriche |
---|---|---|
Velocità effettiva sottoposta a provisioning | Mostra il numero di UR/sec aggregato più alto ridimensionato all'ora e rappresenta il totale di UR/sec ridimensionato per l'ora. | È possibile usare la metrica Provisioned Throughput per visualizzare le UR/sec fatturate ogni ora. Con la scalabilità automatica, la fatturazione avviene in base alla partizione più utilizzata per ogni ora e questo criterio viene applicato a tutte le partizioni e regioni. Con la scalabilità automatica dinamica, viene addebitato il numero di RU/s aggregato più alto ridimensionato ogni ora a livello di ciascuna partizione e area. |
Consumo UR normalizzato | Questa metrica rappresenta il rapporto tra UR/sec utilizzate e UR/sec di cui è stato effettuato il provisioning a ogni livello di partizione e area. | Usare questa metrica per determinare se la velocità effettiva massima a scalabilità automatica è stata sottoposta a un provisioning insufficiente o eccessivo. Se il valore della metrica è costantemente 100% e l'applicazione visualizza la limitazione della velocità (codice errore 429), potrebbero essere necessarie più UR/sec. Al contrario, se questo valore della metrica è basso e non esiste alcuna limitazione della velocità, potrebbe esserci spazio per ottimizzare e ridurre le UR/sec. Informazioni su come interpretare ed eseguire il debug di errori di limitazione della frequenza del codice 429. La metrica Normalized RU Consumption riflette le UR/sec usate nell'area secondaria a causa del traffico di replica di scrittura dal database primario, oltre a qualsiasi traffico di lettura sul database secondario. |
UR a scalabilità automatica | Mostra la velocità effettiva con provisioning scalata dinamicamente a livello di partizione e di area solo per gli account con abilitazione alla scalabilità automatica dinamica. | Usare questa metrica per vedere in che modo le partizioni in ogni area vengono ridimensionate in modo indipendente in base al relativo utilizzo. Usare le metriche di Monitoraggio di Azure - Autoscaled RU per analizzare il modo in cui viene applicata la nuova scalabilità automatica tra partizioni e aree. Filtrare in base all'account e al contenitore di database desiderati, quindi filtrare o dividere in base alla metrica Physical PartitionID. Questa metrica mostra tutte le partizioni nelle varie aree. |
Importante
È consigliabile usare la funzionalità di scalabilità dinamica nativa di Azure Cosmos DB per gestire la capacità. Tuttavia, se necessario, è possibile usare la metrica Normalized UR Consumption in Monitoraggio di Azure per prendere decisioni di ridimensionamento a livello di codice. Altri approcci, ad esempio l'uso della chiamata ReadThroughputAsync() negli SDK di Azure Cosmos DB per ottenere ProvisionedThroughput o l'uso di ProvisionedThroughput in Monitoraggio di Azure non sono consigliati e causeranno risultati imprecisi. Queste metriche rappresentano la velocità effettiva fatturata con un ritardo e non devono essere usate per le decisioni di ridimensionamento.
Confronto tra contenitori configurati con velocità effettiva manuale e a scalabilità automatica
Per informazioni dettagliate, vedere la documentazione su come scegliere tra la velocità effettiva standard (manuale) e quella a scalabilità automatica.
Contenitori con velocità effettiva standard (manuale) | Contenitori con capacità di scalabilità automatizzata | |
---|---|---|
Capacità erogata (RU/s) | Con provisioning manuale. | Ridimensionamento automatico e istantaneo in base ai modelli di utilizzo del carico di lavoro. |
Limitazione della frequenza delle richieste/operazioni (429) | Può succedere se il consumo supera la capacità provisionata. | Non si verifica se il consumo di UR/sec rientra nell'intervallo impostato per la velocità effettiva a scalabilità automatica. |
Pianificazione della capacità | È necessario eseguire la pianificazione della capacità e impostare la velocità effettiva esatta necessaria. | Il sistema provvede automaticamente alla pianificazione della capacità e alla gestione della capacità. |
Prezzi | Si paga per le UR/sec con provisioning manuale per ora, usando la tariffa oraria delle UR/sec standard (manuale). | Si paga ogni ora per i valori massimi di UR/sec raggiunti dal sistema entro l'ora. Per gli account con singola area di scrittura, si paga per le UR/sec usate su base oraria, applicando la tariffa oraria delle UR/sec di scalabilità automatica. Per gli account con più aree di scrittura, non sono previsti costi aggiuntivi per la scalabilità automatica. Si paga per la velocità effettiva usata su base oraria applicando la stessa tariffa oraria delle UR/sec per scritture in più aree. |
Ideale per tipi di carico di lavoro | Carichi di lavoro prevedibili e stabili | Carichi di lavoro imprevedibili e variabili |
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 utilizzare uno script dell'interfaccia della riga di comando di Azure per eseguire la migrazione di ogni risorsa di velocità effettiva in una sottoscrizione di Azure alla scalabilità automatica.
Passaggi successivi
- Vedere le domande frequenti sulla scalabilità automatica.
- Scopri come scegliere tra la larghezza di banda manuale e quella a scalabilità automatica.
- Informazioni su come effettuare il provisioning della velocità effettiva a scalabilità automatica in un database o un contenitore di Azure Cosmos DB.
- Altre informazioni sul partizionamento in Azure Cosmos DB.
- 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 conoscete solo il numero di vCore e i server nel cluster di database esistente, leggete le informazioni sulla stima delle unità di richiesta con 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