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

  • Si applica a: ✅ Apache Cassandra

SI APPLICA A: Cassandra

Importante

Si sta cercando una soluzione di database per scenari su larga scala con un contratto di servizio di disponibilità 99.999%, scalabilità automatica immediata e failover automatico in più aree? Prendere in considerazione Azure Cosmos DB per NoSQL.

Si sta cercando di eseguire la migrazione di un'applicazione Apache Cassandra esistente? Prendere in considerazione Azure Istanza gestita per Apache 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. Accedi al portale di Azure.

  2. Vai all'account Azure Cosmos DB per Apache Cassandra.

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

  4. Seleziona Ritenta lato server.

  5. Selezionare 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 il 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ù o più volte) fino a quando non viene raggiunto un timeout di 60 secondi. Se viene raggiunto il timeout, il client riceve di conseguenza l'errore di timeout di lettura o di scrittura.

Quando SSR è la scelta più vantaggiosa?

Il riavvio 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 throttling. 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 estendere il timeout di lettura oltre il limite 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 passano al client quando SSR è abilitato, perché vengono gestiti e ritentati sul lato server.

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

Il retry lato server compromette il mio livello di coerenza?

Il nuovo tentativo lato server non influisce sui livelli di coerenza. Le richieste vengono ritentate sul lato server se sono limitate alla frequenza (Errore 429).

Il tentativo di nuovo dal lato server influisce su qualsiasi 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à ti evita di dover gestire gli errori di limitazione della frequenza nell'applicazione client. Tutti gli altri errori passano al client.

Passaggi successivi

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

Per apprendere informazioni sul provisioning del throughput in Azure Cosmos DB, vedere gli articoli seguenti:

  • Last updated on