Ridimensionare in modo elastico un account Azure Cosmos DB for Apache Cassandra

  • Articolo

SI APPLICA A: Cassandra

Sono disponibili diverse opzioni per esplorare la natura elastica di Azure Cosmos DB for Apache Cassandra. Per comprendere come scalare in modo efficace in Azure Cosmos DB, è importante comprendere come effettuare il provisioning della quantità corretta di unità richiesta (UR/sec) per tenere conto delle esigenze di prestazioni del sistema. Per altre informazioni sulle unità richiesta, vedere l'articolo Unità richiesta.

Per l'API per Cassandra, è possibile recuperare l'addebito delle unità richiesta per le singole query usando gli SDK .NET e Java. Questa operazione è utile per determinare la quantità di UR/s di cui è necessario eseguire il provisioning nel servizio.

Utilizzo delle unità richiesta da parte delle operazioni di database

Gestione della limitazione della frequenza (429 errori)

Azure Cosmos DB restituirà errori di limitazione della frequenza (429) se i client utilizzano più risorse (UR/s) rispetto al valore di cui è stato effettuato il provisioning. L'API per Cassandra in Azure Cosmos DB converte queste eccezioni in errori di overload per il protocollo nativo di Cassandra.

Se il sistema non è sensibile alla latenza, potrebbe essere sufficiente gestire la limitazione della velocità effettiva usando i tentativi. Vedere esempi di codice Java per versione 3 e versione 4 dei driver Java Apache Cassandra per informazioni su come gestire la limitazione della frequenza in modo trasparente. Questi esempi implementano una versione personalizzata dei criteri di ripetizione di Cassandra predefiniti in Java. È anche possibile usare l'estensione Spark per gestire la limitazione della frequenza. Quando si usa Spark, assicurarsi di seguire le indicazioni fornite su Ottimizzazione della configurazione della velocità effettiva del connettore Spark.

Gestire la scalabilità

Se è necessario ridurre al minimo la latenza, esiste una gamma di opzioni per la gestione della scalabilità e il provisioning della velocità effettiva (UR) nell'API per Cassandra:

Nelle sezioni seguenti vengono descritti i vantaggi e gli svantaggi di ogni approccio. È quindi possibile scegliere la strategia migliore per bilanciare le esigenze di scalabilità del sistema, il costo complessivo e le esigenze di efficienza per la propria soluzione.

Usare il portale di Azure

È possibile dimensionare le risorse nell'account Azure Cosmos DB for Apache Cassandra usando il portale di Azure. Per altre informazioni, vedere l'articolo sulla provisioning della velocità effettiva nei contenitori e nei database. In questo articolo vengono illustrati i vantaggi relativi all'impostazione della velocità effettiva a livello di database o contenitore nel portale di Azure. I termini "database" e "contenitore" indicati in questi articoli vengono mappati rispettivamente a "keyspace" e "tabella" per l'API per Cassandra.

Il vantaggio di questo metodo è che si tratta di un modo semplice per gestire la capacità della velocità effettiva nel database. Tuttavia, lo svantaggio è che, in molti casi, l'approccio alla scalabilità può richiedere che determinati livelli di automazione siano sia economici che ad alte prestazioni. Le sezioni successive illustrano gli scenari e i metodi pertinenti.

Usare il piano di controllo

L'API di Azure Cosmos DB per Cassandra consente di regolare la velocità effettiva a livello di codice usando le varie funzionalità del piano di controllo. Per informazioni ed esempi, vedere gli articoli Azure Resource Manager, PowerShell e Interfaccia della riga di comando di Azure.

Il vantaggio di questo metodo è che è possibile automatizzare l'aumento o la riduzione delle risorse in base a un timer per tenere conto di picchi di attività o periodi di minore attività. Vedere l'esempio qui per informazioni su ottenere questo risultato usando Funzioni di Azure e PowerShell.

Uno svantaggio di questo approccio può essere dovuto al fatto che non è possibile rispondere a esigenze di scalabilità mutevoli non prevedibili in tempo reale. Al contrario, potrebbe essere necessario sfruttare il contesto dell'applicazione nel sistema, a livello di client/SDK, o usando la scalabilità automatica.

Usare query CQL con un SDK specifico

È possibile dimensionare il sistema in modo dinamico con il codice eseguendo i comandi CQL ALTER per il database o il contenitore specificato.

Il vantaggio di questo approccio è che consente di rispondere in modo dinamico alle esigenze di scalabilità e in modo personalizzato per l'applicazione. Con questo approccio è comunque possibile sfruttare i costi e le tariffe standard di UR/s. Se le esigenze di scalabilità del sistema sono prevedibili (circa il 70% o più), l'uso dell'SDK con CQL può essere un metodo più conveniente per il dimensionamento automatico rispetto all'uso della scalabilità automatica. Lo svantaggio di questo approccio è che può essere piuttosto complesso implementare nuovi tentativi mentre la limitazione della frequenza può aumentare la latenza.

Usare la velocità effettiva con provisioning a scalabilità automatica

Oltre alla modalità standard (manuale) o a livello di codice per il provisioning della velocità effettiva, è anche possibile configurare i contenitori di Azure Cosmos DB nella velocità effettiva con provisioning a scalabilità automatica. La scalabilità automatica verrà automaticamente dimensionata in base alle esigenze di consumo entro gli intervalli di UR specificati senza compromettere i contratti di servizio. Per altre informazioni, vedere l'articolo Creare contenitori e database di Azure Cosmos DB in scalabilità automatica.

Il vantaggio di questo approccio è che è il modo più semplice per gestire le esigenze di scalabilità nel sistema. Non applica la limitazione della frequenza all'interno degli intervalli di UR configurati. Lo svantaggio è che, se le esigenze di dimensionamento nel sistema sono prevedibili, la scalabilità automatica può essere un modo meno conveniente per gestire le esigenze di scalabilità rispetto all'uso del piano di controllo o degli approcci a livello di SDK indicati in precedenza.

Per impostare o modificare la velocità effettiva massima (UR) per la scalabilità automatica usando CQL, usare il comando seguente (sostituendo il nome keyspace/tabella di conseguenza):

# to set max throughput (RUs) for autoscale at keyspace level:
create keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at keyspace level:
alter keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=4000;

# to set max throughput (RUs) for autoscale at table level:
create table <keyspace name>.<table name> (pk int PRIMARY KEY, ck int) WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at table level:
alter table <keyspace name>.<table name> WITH cosmosdb_autoscale_max_throughput=4000;

Passaggi successivi