Condividi tramite

Domande frequenti sulla distribuzione della velocità effettiva tra partizioni in Azure Cosmos DB (anteprima)

SI APPLICA A: NoSQL MongoDB

La funzionalità di ridistribuzione della velocità effettiva di Azure Cosmos DB consente di ridistribuire la velocità effettiva di cui è stato effettuato il provisioning tra partizioni fisiche. Questo articolo risponde alle domande frequenti sulla ridistribuzione della velocità effettiva tra partizioni in Azure Cosmos DB.

Con quali risorse è possibile usare questa funzionalità?

La funzionalità è supportata solo per gli account SQL e API for MongoDB. È supportata per database e contenitori/raccolte di velocità effettiva condivisa con velocità effettiva dedicata (manuale o scalabilità automatica). La funzionalità non si applica agli account serverless.

Come si esegue la registrazione alla funzionalità di anteprima?

Non è necessario eseguire la registrazione all'anteprima. Per usare la funzionalità, è sufficiente utilizzare i comandi pertinenti in Azure PowerShell o nell'interfaccia della riga di comando di Azure per ridistribuire la velocità effettiva tra le partizioni fisiche delle risorse.

Quale versione della funzionalità di Azure Cosmos DB in Azure PowerShell e nell'interfaccia della riga di comando di Azure supporta questa funzionalità?

La possibilità di ridistribuire UR/sec tra partizioni fisiche è supportata solo nella versione di anteprima di Azure PowerShell (versione 2.0.2-preview o successiva)[https://www.powershellgallery.com/packages/Az.CosmosDB/2.0.2-preview] e nella versione di anteprima più recente dell'interfaccia della riga di comando di Azure.

Qual è il numero massimo di partizioni fisiche che è possibile modificare in una richiesta?

  • Il numero massimo di partizioni di origine e fisiche che possono essere incluse in una singola richiesta è 20 ciascuna.
  • È necessario fornire almeno una partizione di origine e una fisica di destinazione in ogni richiesta. Le partizioni di origine devono avere UR/sec a sufficienza per ridistribuire le partizioni di destinazione.
  • Il numero di UR/sec desiderate per ogni partizione fisica di destinazione non può superare le 10.000 UR/sec o il totale di UR/sec della risorsa complessiva. Se le UR/sec desiderate sono maggiori di quelle della risorsa complessiva, è necessario aumentare le UR/sec complessive prima di procedere alla loro ridistribuzione.

Esiste un limite alla frequenza di chiamate che si possono effettuare per ridistribuire la velocità effettiva tra le partizioni?

È possibile effettuare un massimo di cinque richieste al minuto per la ridistribuzione della velocità effettiva tra le partizioni.

Cosa accade alla distribuzione di UR/sec quando se ne modifica il numero complessivo?

  • Se si riducono le UR/sec, ogni partizione fisica ottiene la frazione equivalente delle nuove UR/sec (current throughput fraction * new RU/s). Si supponga, ad esempio, di avere una raccolta con 6000 UR/sec e 3 partizioni fisiche. È possibile ridurle fino a 3.000 UR/sec.

    Prima della riduzione (6000 UR/sec) Dopo la riduzione (3000 UR/sec) Frazione delle UR/sec totali
    P0: 1000 UR/sec P0: 500 UR/sec 1/6
    P1: 4000 UR/sec P1: 2000 UR/sec 2/3
    P2: 1000 UR/sec P2: 500 UR/sec 1/6

  • Se si aumentano le UR/sec, ogni partizione fisica avrà UR/sec = MIN(current throughput fraction * new RU/s, 10,000 RU/s). Su una partizione fisica non si può mai superare il limite di 10.000 UR/sec.

    Si supponga, ad esempio, di avere una raccolta con 6000 UR/sec e 3 partizioni fisiche. Si aumentano fino a 12.000 UR/sec:

    Prima dell'aumento (6000 UR/sec) Dopo l'aumento (12.000 UR/sec) Frazione delle UR/sec totali
    P0: 1000 UR/sec P0: 2000 UR/sec 1/6
    P1: 4000 UR/sec P1: 8000 UR/sec 2/3
    P2: 1000 UR/sec P2: 2000 UR/sec 1/6

Perché viene visualizzata una discrepanza tra le UR/sec complessive nel contenitore e la somma delle UR/sec in tutte le partizioni fisiche?

  • Questa discrepanza può verificarsi quando si aumentano le UR/sec complessive per ogni singola partizione, perché (current RU/s per partition * new container RU/s)/(old container RU/s) è maggiore di 10.000 UR/sec. Questa discrepanza si verifica quando si attiva una divisione della partizione aumentando le UR/sec oltre currentNumberOfPartitions * 10,000 RU/s o aumentando le UR/sec senza attivare una divisione della partizione.

  • È consigliabile ridistribuire equamente la velocità effettiva dopo l'aumento. In caso contrario, potrebbe non essere possibile usare tutte le UR/sec di cui è stato effettuato il provisioning (anche se vengono fatturate).

  • Per verificare se questo scenario si applica alla risorsa, usare le metriche di Monitoraggio di Azure. Confrontare il valore della metrica ProvisionedThroughput (quando si usa la velocità effettiva manuale) o AutoscaleMaxThroughput (quando si usa la scalabilità automatica) con il valore della metrica PhysicalPartitionThroughput. Se il valore di PhysicalPartitionThroughput è inferiore al rispettivo ProvisionedThroughput o AutoscaleMaxThroughput, prima della ridistribuzione reimpostare le UR/sec su una distribuzione equa, altrimenti ridurre la velocità effettiva della risorsa al valore di PhysicalPartitionThroughput.

    Si supponga, ad esempio, di avere una raccolta con 6000 UR/sec e 3 partizioni fisiche. È possibile aumentarle fino a 24.000 UR/sec. Dopo l'aumento, la velocità effettiva totale su tutte le partizioni è di sole 18.000 UR/sec. Questa distribuzione significa che, sebbene vengano fatturate 24.000 UR/sec, è possibile ottenere solo 18.000 UR/sec di velocità effettiva. Ogni partizione ottiene 8.000 UR/sec, dal momento che vengono ridistribuite equamente ed è possibile ridistribuirle nuovamente secondo necessità. Si può inoltre scegliere di ridurre le UR/sec complessive a 18.000.

    Prima dell'aumento (6000 UR/sec) Dopo l'aumento a 24.000 UR/sec (UR/sec effettive = 18.000 UR/sec) Frazione delle UR/sec totali
    P0: 1000 UR/sec P0: 4000 UR/sec 1/6
    P1: 4000 UR/sec P1: 10.000 UR/sec (la partizione non può superare le 10.000 UR/sec) 2/3
    P2: 1000 UR/sec P2: 4000 UR/sec 1/6