Condividi tramite

Contenitori di traffico di dati in Azure Cosmos DB (anteprima)

SI APPLICA A: NoSQL

Quando più carichi di lavoro condividono lo stesso contenitore di Azure Cosmos DB, la contesa delle risorse può causare limitazioni, aumento della latenza e potenziale impatto aziendale. Per affrontare questo problema, Cosmos DB consente di allocare bucket di throughput, garantendo un migliore isolamento e una governance più efficace dell'utilizzo delle risorse per diversi carichi di lavoro.

Casi d'uso comuni

  • Carichi di lavoro multi-tenant gestiti da fornitori di software indipendenti (ISV)
  • Esecuzione in blocco nei processi ETL
  • Processi di inserimento e migrazione dei dati
  • Esecuzione delle procedure memorizzate
  • Elaborazione del feed di modifiche

Come funzionano i bucket di velocità effettiva

I bucket di velocità effettiva consentono di gestire l'utilizzo delle risorse per i carichi di lavoro che condividono un contenitore Cosmos DB limitando la velocità effettiva massima che può essere usata da un bucket. Tuttavia, la velocità effettiva non è riservata per alcun bucket, ma rimane condivisa tra tutti i carichi di lavoro.

  • Ogni bucket ha una percentuale di velocità effettiva massima, che limita la frazione della velocità effettiva massima del contenitore che può consumare.
  • Le richieste assegnate a un bucket possono consumare la larghezza di banda solo fino a questo limite.
  • Se il bucket supera il limite configurato, le richieste successive vengono limitate.
  • Questo meccanismo consente di evitare conflitti di risorse, assicurandosi che nessun singolo carico di lavoro consuma una velocità effettiva eccessiva e influisca su altri utenti.

Annotazioni

Le richieste non assegnate a un bucket consumeranno la velocità effettiva dal contenitore senza restrizioni.

Come iniziare

Per abilitare i bucket velocità effettiva, passare alla sezione Funzionalità di anteprima nella pagina Sottoscrizione nel portale di Azure. Cercare la funzionalità Bucket velocità effettiva e registrarsi per l'anteprima. Dopo l'approvazione della registrazione, potrebbero essere necessarie fino a un'ora per abilitare i bucket velocità effettiva in tutti gli account all'interno della sottoscrizione. Dopo l'abilitazione, è possibile creare bucket di velocità effettiva per i contenitori di Cosmos DB.

Configurazione dei bucket di velocità effettiva

Per configurare i bucket di velocità effettiva nel portale di Azure:

  1. Aprire Esplora dati e passare al riquadro Scale &Settings del contenitore.
  2. Individuare la scheda Bucket di velocità effettiva.
  3. Abilitare il bucket di velocità effettiva desiderato cambiando il suo stato da "Inattivo" a "Attivo".
  4. Impostare la percentuale di velocità effettiva massima desiderata per i bucket abilitati (fino a cinque bucket per contenitore).

Requisiti minimi per la versione dell'SDK

Uso di bucket di velocità effettiva nelle richieste SDK

Per assegnare una richiesta a un bucket specifico, usare RequestOptions nell'SDK.

using Microsoft.Azure.Cosmos;

string itemId = "<id>";
PartitionKey partitionKey = new PartitionKey("<pkey>");

// Define request options with Throughput Bucket 1 for read operation
ItemRequestOptions readRequestOptions = new ItemRequestOptions{ThroughputBucket = 1};

// Send read request using Bucket ID 1
ItemResponse<Product> readResponse = await container.ReadItemAsync<Product>(
    itemId,
    partitionKey,
    readRequestOptions);

Product product = readResponse.Resource;

// Define request options with Throughput Bucket 2 for update operation
ItemRequestOptions updateRequestOptions = new ItemRequestOptions{ThroughputBucket = 2};

// Send update request using Bucket ID 2
ItemResponse<Product> updateResponse = await container.ReplaceItemAsync(
    product,
    itemId,
    partitionKey,
    updateRequestOptions);

Per applicare un bucket di velocità effettiva a tutte le richieste da un'applicazione client, usare ClientOptions nell'SDK.

using Microsoft.Azure.Cosmos;
using Azure.Identity;

var credential = new DefaultAzureCredential();

// Create CosmosClient with Bulk Execution and Throughput Bucket 1
CosmosClient cosmosClient = new CosmosClientBuilder("<endpointUri>", credential)
    .WithBulkExecution(true)   // Enable bulk execution
    .WithThroughputBucket(1)   // Assign throughput bucket 1 to all requests
    .Build();

// Get container reference
Container container = cosmosClient.GetContainer("<DatabaseId>", "<ContainerId>");

// Prepare bulk operations
List<Task> tasks = new List<Task>();
for (int i = 1; i <= 10; i++)
{
    var item = new
    {
        id = Guid.NewGuid().ToString(),
        partitionKey = $"pkey-{i}",
        name = $"Item-{i}",
        timestamp = DateTime.UtcNow
    };

    tasks.Add(container.CreateItemAsync(item, new PartitionKey(item.partitionKey)));
}

// Execute bulk insertions with throughput bucket 1
await Task.WhenAll(tasks);

//Read item with throughput bucket 1
ItemResponse<Product> response = await container.ReadItemAsync<Product>(partitionKey: new PartitionKey("pkey1"), id: "id1");

Annotazioni

Se l'esecuzione bulk è abilitata, non è possibile assegnare un bucket di velocità effettiva a una singola richiesta usando RequestOptions.

Comportamento del bucket in Esplora Dati

  • Se bucket 1 è configurato, tutte le richieste di Esplora dati usano questo bucket e rispettano i limiti di velocità effettiva.
  • Se bucket 1 non è configurato, le richieste usano la velocità effettiva disponibile completa del contenitore.

Monitoraggio dei bucket di velocità effettiva

È possibile tenere traccia dell'utilizzo del bucket nel portale di Azure:

  • Totale richieste (anteprima): visualizzare il numero di richieste per bucket dividendo la metrica per ThroughputBucket.

  • Unità di richieste totali (anteprima): monitorare il consumo di UR/sec per bucket dividendo la metrica per ThroughputBucket.

Limitazioni

  • Non supportato per i contenitori in un database con velocità effettiva condivisa.
  • Non disponibile per gli account Cosmos DB serverless.
  • Le richieste assegnate a un bucket non possono usare la capacità burst.

Passaggi successivi

  • Last updated on