Condividi tramite

Evitare errori di limitazione della frequenza per le operazioni di Azure Cosmos DB for Apache Cassandra

  • Articolo

SI APPLICA A: Cassandra

Il costo di tutte le operazioni di database viene normalizzato da Azure Cosmos DB ed è espresso in termini di unità richiesta (UR). Un'unità richiesta è una valuta basata sulle prestazioni determinata in base all'astrazione delle risorse di sistema, ad esempio CPU, operazioni di I/O al secondo e memoria, necessarie per eseguire le operazioni di database supportate da Azure Cosmos DB.

Le operazioni di Azure Cosmos DB for Apache Cassandra possono avere esito negativo con errori di limitazione della frequenza (OverloadedException/429) se superano un limite di velocità effettiva della tabella (UR). Questa operazione può essere gestita sul lato client come descritto qui. Se non è possibile implementare i criteri di retry client per gestire l'errore a causa di un errore di limitazione della frequenza, è possibile usare la funzionalità Retry lato server (SSR) in cui le operazioni che superano il limite di velocità effettiva della tabella verranno ritentate automaticamente dopo un breve ritardo. Si tratta di un'impostazione a livello di account e si applica a tutti gli spazi chiave e le tabelle nell'account.

Usare il portale di Azure

  1. Accedere al portale di Azure.

  2. Passare all'account Azure Cosmos DB for Apache Cassandra.

  3. Passare al riquadro Funzionalità sotto la sezione Impostazioni.

  4. Seleziona Retry lato server.

  5. Fare clic su Abilita per abilitare questa funzionalità per tutte le raccolte nell'account.

Screenshot della funzionalità di ripetizione dei tentativi sul lato server per Azure Cosmos DB per Apache Cassandra

Usare l'interfaccia della riga di comando di Azure

  1. Controllare se SSR è già abilitato per l'account:

    az cosmosdb show --name accountname --resource-group resourcegroupname

  2. Abilitare SSR per tutte le tabelle nell'account del database. Affinché la modifica diventi effettiva potrebbero essere necessari fino a 15 minuti.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra DisableRateLimitingResponses

  3. Il comando seguente Disabilita il retry lato server per tutte le tabelle nell'account di database rimuovendo DisableRateLimitingResponses dall'elenco delle funzionalità. Affinché la modifica diventi effettiva potrebbero essere necessari fino a 15 minuti.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra

Domande frequenti

Come vengono ritentate le richieste?

Le richieste vengono ritentate continuamente (più volte) fino a quando non viene raggiunto un timeout di 60 secondi. Se viene raggiunto il timeout, il client riceverà l'errore di timeout di lettura o scrittura di conseguenza

Quando SSR è la scelta più vantaggiosa?

Il retry lato server (SSR) è particolarmente utile quando si verifica un picco improvviso per una breve durata inferiore a 1 minuto in cui è possibile evitare errori di limitazione. Se il carico di lavoro è aumentato e rimane costantemente al di sopra delle UR specificate, SSR non aiuterà molto. Il suggerimento consiste nell'aumentare le UR in modo appropriato.

Impostazioni lato client suggerite?

Dopo l'abilitazione di SSR, l'app client dovrebbe aumentare il timeout di lettura oltre l'impostazione di ripetizione del server di 60 secondi. Ti consigliamo 90 secondi per star più sicuri.

Driver esempio di codice 3

SocketOptions socketOptions = new SocketOptions()
	.setReadTimeoutMillis(90000);

Driver esempio di codice 4

ProgrammaticDriverConfigLoaderBuilder configBuilder = DriverConfigLoader.programmaticBuilder()
	.withDuration(DefaultDriverOption.REQUEST_TIMEOUT, Duration.ofSeconds(90));

Come è possibile monitorare gli effetti di un retry lato server?

È possibile visualizzare gli errori di limitazione della frequenza (429) ritentati sul lato server nel riquadro Metriche di Azure Cosmos DB. Questi errori non raggiungono il client quando SSR è abilitato, poiché vengono gestiti e ritentati sul lato server.

È possibile cercare voci di log contenenti estimatedDelayFromRateLimitingInMilliseconds nei log delle risorse di Azure Cosmos DB.

Il retry sul lato server influisce sul livello di coerenza?

Il retry lato server non influisce sui livelli di coerenza. Le richieste vengono ritentate sul lato server se viene limitata la loro velocità (errore 429).

Il retry lato server influisce su qualsivoglia tipo di errore che il client potrebbe ricevere?

No, il retry lato server influisce solo sugli errori di limitazione della frequenza (429) ritentandoli sul lato server. Questa funzionalità impedisce di gestire gli errori di limitazione della frequenza nell'applicazione client. Tutti gli altri errori verranno visualizzati nel client.

Passaggi successivi

Per altre informazioni sulla risoluzione degli errori comuni, vedere questo articolo:

Vedere gli articoli seguenti per informazioni sul provisioning della velocità effettiva in Azure Cosmos DB: