Dimensionar elasticamente uma conta do Azure Cosmos DB para Apache Cassandra

  • Artigo

APLICA-SE A: Cassandra

Existem várias opções para explorar a natureza elástica do Azure Cosmos DB para o Apache Cassandra. Para compreender como dimensionar eficazmente no Azure Cosmos DB, é importante compreender como aprovisionar a quantidade certa de unidades de pedido (RU/s) para ter em conta as exigências de desempenho no seu sistema. Para saber mais sobre as unidades de pedido, veja o artigo unidades de pedido .

Para a API para Cassandra, pode obter o custo da Unidade de Pedido para consultas individuais com os SDKs .NET e Java. Isto é útil para determinar a quantidade de RU/s que terá de aprovisionar no serviço.

As operações de base de dados consomem Unidades de Pedido

Processamento da limitação da taxa (erros 429)

O Azure Cosmos DB devolverá erros de taxa limitada (429) se os clientes consumirem mais recursos (RU/s) do que o montante que aprovisionou. A API para Cassandra no Azure Cosmos DB traduz estas exceções para erros sobrecarregados no protocolo nativo do Cassandra.

Se o seu sistema não for sensível à latência, poderá ser suficiente para lidar com a limitação da taxa de débito através de repetições. Veja Exemplos de código Java para a versão 3 e a versão 4 dos controladores Java do Apache Cassandra para saber como lidar com a limitação de taxa de forma transparente. Estes exemplos implementam uma versão personalizada da política de repetição do Cassandra predefinida em Java. Também pode utilizar a extensão do Spark para lidar com a limitação de taxas. Ao utilizar o Spark, certifique-se de que segue a nossa documentação de orientação sobre Como Otimizar a configuração de débito do conector do Spark.

Gerir o dimensionamento

Se precisar de minimizar a latência, existe um espectro de opções para gerir o débito de dimensionamento e aprovisionamento (RUs) na API para Cassandra:

As secções seguintes explicam as vantagens e desvantagens de cada abordagem. Em seguida, pode decidir sobre a melhor estratégia para equilibrar as necessidades de dimensionamento do seu sistema, o custo global e as necessidades de eficiência para a sua solução.

Utilizar o portal do Azure

Pode dimensionar os recursos na conta do Azure Cosmos DB para Apache Cassandra com portal do Azure. Para saber mais, veja o artigo sobre Aprovisionar débito em contentores e bases de dados. Este artigo explica os benefícios relativos da definição do débito ao nível da base de dados ou do contentor no portal do Azure. Os termos "base de dados" e "contentor" mencionados nestes artigos mapeiam para "keyspace" e "table", respetivamente, para a API para Cassandra.

A vantagem deste método é que é uma forma simples de gerir a capacidade de débito na base de dados. No entanto, a desvantagem é que, em muitos casos, a sua abordagem ao dimensionamento pode exigir que determinados níveis de automatização sejam económicos e de elevado desempenho. As secções seguintes explicam os cenários e métodos relevantes.

Utilizar o plano de controlo

A API do Azure Cosmos DB para Cassandra fornece a capacidade de ajustar o débito através de programação através das nossas várias funcionalidades do plano de controlo. Veja os artigos do Azure Resource Manager, PowerShell e CLI do Azure para obter orientações e exemplos.

A vantagem deste método é que pode automatizar o aumento ou redução vertical dos recursos com base num temporizador para contabilizar a atividade de pico ou períodos de baixa atividade. Veja o nosso exemplo aqui para saber como fazê-lo com o Funções do Azure e o PowerShell.

Uma desvantagem com esta abordagem pode ser o facto de não poder responder às necessidades imprevisíveis de dimensionamento em tempo real. Em vez disso, poderá ter de tirar partido do contexto da aplicação no seu sistema, ao nível do cliente/SDK ou através do Dimensionamento Automático.

Utilizar consultas CQL com um SDK específico

Pode dimensionar o sistema dinamicamente com código ao executar os comandos ALTER do CQL para a base de dados ou contentor especificado.

A vantagem desta abordagem é que lhe permite responder às necessidades de dimensionamento dinamicamente e de forma personalizada que se adequa à sua aplicação. Com esta abordagem, ainda pode tirar partido dos custos e taxas padrão das RU/s. Se as necessidades de dimensionamento do sistema forem maioritariamente previsíveis (cerca de 70% ou mais), a utilização do SDK com o CQL poderá ser um método mais económico de dimensionamento automático do que a utilização do dimensionamento automático. A desvantagem desta abordagem é que pode ser bastante complexo implementar repetições, enquanto a limitação da taxa pode aumentar a latência.

Utilizar o débito aprovisionado de dimensionamento automático

Além do débito padrão (manual) ou programático de aprovisionamento, também pode configurar contentores do Azure Cosmos DB no débito aprovisionado de dimensionamento automático. O dimensionamento automático será dimensionado automaticamente e instantaneamente para as suas necessidades de consumo dentro dos intervalos de RU especificados sem comprometer os SLAs. Para saber mais, veja o artigo Criar contentores e bases de dados do Azure Cosmos DB no dimensionamento automático .

A vantagem desta abordagem é que é a forma mais fácil de gerir as necessidades de dimensionamento no seu sistema. Não aplicará a limitação de taxas dentro dos intervalos de RU configurados. A desvantagem é que, se as necessidades de dimensionamento no seu sistema forem previsíveis, o dimensionamento automático pode ser uma forma menos económica de lidar com as suas necessidades de dimensionamento do que utilizar o plano de controlo personalizado ou abordagens ao nível do SDK mencionadas acima.

Para definir ou alterar o débito máximo (RUs) para o dimensionamento automático com o CQL, utilize o seguinte (substituindo o nome da tabela/espaço de chaves em conformidade):

# 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;

Passos seguintes