Creare contenitori e database di Azure Cosmos DB con velocità effettiva con scalabilità automatica
SI APPLICA A: 
NoSQL MongoDB Cassandra Gremlin Tabella
In Azure Cosmos DB è possibile configurare la velocità effettiva standard (manuale) o con provisioning con scalabilità automatica in database e contenitori. La velocità effettiva con provisioning con 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 miglioramento della scalabilità automatica di cui viene eseguito il provisioning in tutto ciò che consente di ridimensionare tali carichi di lavoro non univoci in modo indipendente in base all'utilizzo, a livello di area 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 con scalabilità automatica offrono i vantaggi seguenti:
Semplicità: la scalabilità automatica elimina la complessità della gestione di UR/sec basata su script personalizzati o sulla 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 per tutte le ore di un mese si imposta un valore massimo (Tmax) di UR/s con scalabilità automatica si usa la quantità massima Tmax per il 66% delle ore o meno, la scalabilità automatica consente di risparmiare. 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 il picco di utilizzo e riduce le prestazioni quando è finita.
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 si prevede di eseguire una serie di richieste, operazioni o query pianificate durante i periodi di inattività, la scalabilità automatica può essere molto utile. 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 aumenta automaticamente anche quando diventa attiva e gestisce il traffico di replica di scrittura dall'area primaria.
- Carichi di lavoro di database in più aree.
- Questi carichi di lavoro spesso osservano una distribuzione irregolare delle richieste tra aree a causa della crescita del traffico naturale e delle riduzioni 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 di cui è stato effettuato il provisioning senza alcun ritardo.
Ogni ora viene addebitata la velocità effettiva più elevata T a cui il sistema è stato ridimensionato nel corso dell'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:
| Area | Partizione | Velocità effettiva | 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. |
| Lettura | P1 | <= 150 UR/sec | 30% | 150 UR/sec costituite da 50 UR/sec usate per le scritture replicate dall'area di scrittura. 100 UR/sec vengono usate per le operazioni di lettura in questa area. |
| Lettura | P2 | <= 50 UR/sec | 10% |
Senza scalabilità dinamica, tutte le partizioni vengono ridimensionate in modo uniforme in base alla partizione più frequente. 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. È possibile passare dalla velocità effettiva con provisioning a scalabilità automatica alla velocità effettiva con provisioning standard (manuale) e viceversa in qualsiasi momento. 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, quindi verrà applicata automaticamente a tutti i contenitori con scalabilità automatica e ai database con velocità effettiva condivisa all'interno dell'account. L'abilitazione di questa funzionalità non influisce sulle risorse nell'account che usano la velocità effettiva 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.
Monitoraggio Metriche
È possibile usare le metriche seguenti per monitorare la scalabilità automatica e il ridimensionamento dinamico:
| Nome misurazione | Definizione | Uso delle metriche |
|---|---|---|
| Velocità effettiva con 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, vengono fatturati in base alla partizione più attiva per ogni ora e la stessa viene applicata a tutte le partizioni e le aree. Con la scalabilità automatica dinamica, vengono fatturati i valori massimi di UR/sec aggregati ridimensionati ogni ora a ogni livello di 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 della scalabilità automatica è inferiore o sottoposta a over-provisioning. 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 con scalabilità automatica | Mostra la velocità effettiva con provisioning con dimensionamento dinamico a ogni livello di partizione e area solo per gli account abilitati per la 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. |
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 velocità effettiva a scalabilità automatica | |
|---|---|---|
| Provisioning velocità effettiva (UR/sec) | 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ò verificarsi se il consumo supera la capacità sottoposta a provisioning. | Non si verifica se il consumo di UR/sec rientra nell'intervallo configurato 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 usare uno script dell'interfaccia della riga di comando di Azure per migrare ogni risorsa di velocità effettiva in una sottoscrizione di Azure alla scalabilità automatica. Per altre informazioni, vedere Convertire in scalabilità automatica.
Passaggi successivi
- Vedere le domande frequenti sulla scalabilità automatica.
- Informazioni su come scegliere tra la velocità effettiva manuale e a scalabilità automatica.
- Informazioni su come effettuare il provisioning della velocità effettiva con scalabilità automatica in un database o un contenitore 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 si conosce solo il numero di vCore e server nel cluster di database esistente, leggere le informazioni sulla stima delle unità richieste 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