Condividi tramite

Ridistribuire la velocità effettiva tra partizioni (anteprima)

  • Articolo

SI APPLICA A: NoSQL MongoDB

Per impostazione predefinita, Azure Cosmos DB distribuisce la velocità effettiva di cui è stato effettuato provisioning di un database o di un contenitore in modo uniforme in tutte le partizioni fisiche. Tuttavia, potrebbero verificarsi alcuni scenari in cui a causa di un'asimmetria del carico di lavoro o della scelta della chiave di partizione, alcune partizioni logiche (e quindi fisiche) richiedono una velocità effettiva maggiore rispetto ad altre. In questi scenari, Azure Cosmos DB consente di ridistribuire la velocità effettiva di cui è stato effettuato il provisioning tra partizioni fisiche. La ridistribuzione della velocità effettiva tra le partizioni consente di ottenere prestazioni migliori senza dover configurare la velocità effettiva complessiva in base alla partizione con il carico di lavoro più elevato.

La funzionalità di ridistribuzione della velocità effettiva si applica ai database e ai contenitori usando la velocità effettiva di cui è stato effettuato il provisioning (manuale e scalabilità automatica) e non si applica ai contenitori serverless. È possibile modificare la velocità effettiva per ogni partizione fisica usando i comandi di Azure Cosmos DB PowerShell o dell'interfaccia della riga di comando di Azure.

Quando usare questa funzionalità

In generale, l'utilizzo di questa funzionalità è consigliato per gli scenari in cui sono soddisfatte entrambe le condizioni seguenti:

  • Si riscontra costantemente una percentuale di risposte superiore all'1-5% con errori 429
  • C'è una partizione ad accesso frequente coerente e prevedibile

Se non vengono visualizzate 429 risposte e la latenza end-to-end è accettabile, non è necessaria alcuna azione per riconfigurare le UR/sec per partizione. Se si dispone di un carico di lavoro con traffico coerente con picchi occasionali imprevedibili in tutte le partizioni, è consigliabile usare la scalabilità automatica e la capacità burst (anteprima). La scalabilità automatica e la capacità burst garantiscono la possibilità di soddisfare i requisiti di velocità effettiva. Se è presente una quantità ridotta di UR/sec per partizione, è anche possibile usare il merge di partizione (anteprima) per ridurre il numero di partizioni e assicurarsi una quantità maggiore di UR/sec per partizione per la stessa velocità effettiva totale di cui è stato effettuato il provisioning.

Scenario di esempio

Si supponga di avere un carico di lavoro che tiene traccia delle transazioni che si svolgono nei negozi al dettaglio. Poiché la maggior parte delle query viene effettuata per StoreId, si sceglie un partizionamento in base a StoreId. Tuttavia, nel corso del tempo, si noterà che alcuni negozi registrano più attività rispetto ad altri e richiedono una maggiore velocità effettiva per gestire i carichi di lavoro. Si osserva una limitazione della frequenza (429) per le richieste relative a tali StoreId e la percentuale complessiva di risposte 429 risposte è maggiore dell'1-5%. Nel frattempo, altri negozi sono meno attivi e richiedono una minore velocità effettiva. Verrà quindi illustrato come ridistribuire la velocità effettiva per ottenere prestazioni migliori.

Passaggio 1: Identificare le partizioni fisiche che richiedono una maggiore velocità effettiva

Esistono due modi per identificare se è presente una partizione ad accesso frequente.

Opzione 1: Usare le metriche di Monitoraggio di Azure

Per verificare la presenza di una partizione ad accesso frequente, passare a Informazioni dettagliate>Velocità effettiva>Consumo UR normalizzato (%) per PartitionKeyRangeID. Filtrare in base a un database e a un contenitore specifico.

Ogni PartitionKeyRangeId è mappato a una partizione fisica. Cercare un PartitionKeyRangeId con un consumo di UR normalizzato più elevato rispetto ad altri. Ad esempio, un valore è costantemente al 100%, ma altri sono al 30% o meno. Un modello come questo può indicare una partizione ad accesso frequente.

Screenshot del grafico Normalized UR Consumption by PartitionKeyRangeId con una partizione ad accesso frequente.

Opzione 2: Usare i log di diagnostica

È possibile usare le informazioni di CDBPartitionKeyRUConsumption nei log di diagnostica per ottenere altre informazioni sulle chiavi di partizione logica (e sulle partizioni fisiche corrispondenti) che utilizzano la maggior parte delle UR/sec con una granularità a livello di secondo. Si noti che le query di esempio usano 24 ore solo a scopo illustrativo. È consigliabile usare almeno sette giorni di cronologia per comprendere il modello.

Trovare la partizione fisica (PartitionKeyRangeId) che utilizza la maggior parte delle UR/sec nel tempo

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hr)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| summarize sum(RequestCharge) by bin(TimeGenerated, 1s), PartitionKeyRangeId
| render timechart

Per una partizione fisica specifica, trovare le prime 10 chiavi di partizione logiche che utilizzano la maggior parte delle UR/sec in ogni ora

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hour)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| where PartitionKeyRangeId == 0 // Replace with PartitionKeyRangeId 
| summarize sum(RequestCharge) by bin(TimeGenerated, 1hour), PartitionKey
| order by sum_RequestCharge desc | take 10

Passaggio 2: Determinare le UR/sec di destinazione per ogni partizione fisica

Determinare le UR/sec correnti per ogni partizione fisica

Prima di tutto, determinare le UR/sec correnti per ogni partizione fisica. È possibile usare la nuova metrica PhysicalPartitionThroughput di Monitoraggio di Azure e suddividerla in base alla dimensione PhysicalPartitionId per visualizzare il numero di UR/sec presenti in ogni partizione fisica.

In alternativa, se non è stata modificata la velocità effettiva per partizione in precedenza, è possibile usare la formula: Current RU/s per partition = Total RU/s / Number of physical partitions

Seguire le indicazioni riportate nell'articolo Procedure consigliate per il dimensionamento della velocità effettiva con provisioning (UR/sec) per determinare il numero di partizioni fisiche.

È anche possibile usare i comandi di PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput e Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput per leggere le UR/sec correnti in ogni partizione fisica.

Usare Install-Module per installare il modulo Az.CosmosDB con funzionalità non definitive abilitate.

$parameters = @{
    Name = "Az.CosmosDB"
    AllowPrerelease = $true
    Force = $true
}
Install-Module @parameters

Usare il comando Get-AzCosmosDBSqlContainerPerPartitionThroughput o Get-AzCosmosDBSqlDatabasePerPartitionThroughput per leggere le UR/sec correnti in ogni partizione fisica.


// Container with dedicated RU/s
$somePartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -AllPartitions

// Database with shared RU/s
$somePartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -AllPartitions

Determinare le UR/sec per la partizione di destinazione

A questo punto, è necessario decidere il numero di UR/sec da assegnare alle partizioni fisiche ad accesso più frequente. Questo set specifica le partizioni di destinazione. Il numero massimo di UR/s che le partizioni fisiche possono contenere è 10.000 UR/sec.

L'approccio corretto dipende dai requisiti del carico di lavoro. Gli approcci generali includono:

  • Aumentando le UR/sec di un valore percentuale, misurare la frequenza di risposte 429 e ripetere la procedura fino a quando non si raggiunge la velocità effettiva desiderata.
    • Se non si è certi della percentuale corretta, è possibile iniziare con il 10% per essere prudenti.
    • Se si sa già che questa partizione fisica richiede la maggior parte della velocità effettiva del carico di lavoro, è possibile iniziare raddoppiando le UR/sec o aumentandole fino al valore massimo di 10.000 UR/sec, a seconda del valore più basso.
  • Aumento del numero di UR/sec a Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • Questo approccio tenta di stimare il consumo di UR/sec "reale" se le richieste non fossero state limitate.

Determinare il numero di UR/sec per la partizione di origine

Infine, si decide il numero di UR/sec che si vuole mantenere nelle altre partizioni fisiche. Questa selezione determinerà le partizioni da cui la partizione fisica di destinazione acquisisce la velocità effettiva.

Nelle API di PowerShell è necessario specificare almeno una partizione di origine da cui ridistribuire le UR/sec. È anche possibile specificare una velocità effettiva minima personalizzata per ogni partizione fisica dopo la ridistribuzione. Se questo valore non è specificato, per impostazione predefinita Azure Cosmos DB garantirà che ogni partizione fisica abbia almeno 100 UR/sec dopo la ridistribuzione. È consigliabile specificare in modo esplicito la velocità effettiva minima.

L'approccio corretto dipende dai requisiti del carico di lavoro. Gli approcci generali includono:

  • Acquisire le UR/sec in modo equo da tutte le partizioni di origine (funziona meglio quando sono presenti <= 10 partizioni)
    • Calcolare la quantità di cui è necessario eseguire l'offset per ogni partizione fisica di origine. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • Assegnare la velocità effettiva minima per ogni partizione di origine = Current RU/s of source partition - offset
  • Acquisire le UR/sec dalle partizioni meno attive
    • Usare le metriche di Monitoraggio di Azure e i log di diagnostica per determinare quali partizioni fisiche presentano il volume di traffico/richieste minimo
    • Calcolare la quantità di cui è necessario eseguire l'offset per ogni partizione fisica di origine. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • Assegnare la velocità effettiva minima per ogni partizione di origine = Current RU/s of source partition - offset

Passaggio 3: Modificare a livello di codice la velocità effettiva tra le partizioni

È possibile usare il comando Update-AzCosmosDBSqlContainerPerPartitionThroughput di PowerShell per ridistribuire la velocità effettiva.

Per comprendere l'esempio seguente, si supponga di avere un contenitore con 6.000 UR/sec totali (6.000 UR/sec manuali o 6.000 UR/sec di scalabilità automatica) e 3 partizioni fisiche. In base all'analisi, si vuole un layout con:

  • Partizione fisica 0: 1000 UR/sec
  • Partizione fisica 1: 4000 UR/sec
  • Partizione fisica 2: 1000 UR/sec

Le partizioni 0 e 2 vengono specificate come partizioni di origine e si indica che dopo la ridistribuzione devono avere un numero di 1.000 UR/sec. La partizione 1 è la partizione di destinazione, che deve avere 4.000 UR/sec.

Usare Update-AzCosmosDBSqlContainerPerPartitionThroughput per i contenitori con UR/sec dedicate o il comando Update-AzCosmosDBSqlDatabasePerPartitionThroughput per i database con UR/sec condivise per ridistribuire la velocità effettiva tra partizioni fisiche. Nei database con velocità effettiva condivisa, gli ID delle partizioni fisiche sono rappresentati da una stringa GUID.

$SourcePhysicalPartitionObjects =  @()
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "0" -Throughput 1000
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "2" -Throughput 1000

$TargetPhysicalPartitionObjects =  @()
$TargetPhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "1" -Throughput 4000

// Container with dedicated RU/s
Update-AzCosmosDBSqlContainerPerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -Name "<cosmos-container-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

// Database with shared RU/s
Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

Dopo aver completato la ridistribuzione, è possibile verificare la modifica visualizzando la metrica PhysicalPartitionThroughput in Monitoraggio di Azure. Dividere per la dimensione PhysicalPartitionId per verificare il numero di UR/sec disponibili per ogni partizione fisica.

Se necessario, è anche possibile reimpostare le UR/sec per ogni partizione fisica in modo che le UR/sec del contenitore vengano distribuite uniformemente in tutte le partizioni fisiche.

Usare il comando Update-AzCosmosDBSqlContainerPerPartitionThroughput per i contenitori con UR/sec dedicate o il comando Update-AzCosmosDBSqlDatabasePerPartitionThroughput per i database con UR/sec condivise con il parametro -EqualDistributionPolicy per distribuire le UR/sec in modo uniforme in tutte le partizioni fisiche.


// Container with dedicated RU/s
$resetPartitionsDedicatedRUContainer = Update-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -EqualDistributionPolicy

// Database with dedicated RU/s
$resetPartitionsSharedThroughputDatabase = Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -EqualDistributionPolicy

Passaggio 4: Verificare e monitorare il consumo di UR/sec

Dopo aver completato la ridistribuzione, è possibile verificare la modifica visualizzando la metrica PhysicalPartitionThroughput in Monitoraggio di Azure. Dividere per la dimensione PhysicalPartitionId per verificare il numero di UR/sec disponibili per ogni partizione fisica.

È consigliabile monitorare la frequenza complessiva di risposte 429 e il consumo di UR/sec. Per altre informazioni, tornare al Passaggio 1 per verificare se sono state raggiunte le prestazioni previste.

Dopo le modifiche, supponendo che il carico di lavoro complessivo non sia cambiato, è probabile che sia le partizioni fisiche di destinazione che quelle di origine abbiano un consumo di UR normalizzato rispetto a quello precedente. Un consumo di UR normalizzato più elevato è il comportamento previsto. In pratica, è stato allocato un numero di UR/sec più vicino a quello che ogni partizione deve effettivamente utilizzare, quindi un consumo più elevato di UR normalizzate significa che ogni partizione sta utilizzando completamente le UR/sec allocate. Si dovrebbe anche riscontrare una frequenza complessiva inferiore di eccezioni 429, perché le partizioni ad accesso frequente dispongono di un maggior numero di UR/sec per gestire le richieste.

Limiti

Criteri di idoneità per l'anteprima

Per usare l'anteprima, l'account Azure Cosmos DB deve soddisfare tutti i criteri seguenti:

  • L'account Azure Cosmos DB usa l'API for NoSQL o l'API for MongoDB.
    • Se si usa l'API for MongoDB, la versione deve essere >= 3.6.
  • L'account Azure Cosmos DB usa la velocità effettiva con provisioning (manuale o con scalabilità automatica). La distribuzione della velocità effettiva tra le partizioni non si applica agli account serverless.

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

Passaggi successivi

Informazioni su come usare la velocità effettiva con provisioning con gli articoli seguenti: