Dimensionar elasticamente uma conta do Azure Cosmos DB para Apache Cassandra
APLICA-SE A: Cassandra
Há uma variedade de opções para explorar a natureza elástica do Azure Cosmos DB para Apache Cassandra. Para entender como dimensionar efetivamente no Azure Cosmos DB, é importante entender como provisionar a quantidade certa de unidades de solicitação (RU/s) para levar em conta as demandas de desempenho em seu sistema. Para saber mais sobre unidades de solicitação, consulte o artigo Unidades de solicitação.
Para a API para Cassandra, você pode recuperar a cobrança da Unidade de Solicitação para consultas individuais usando os SDKs .NET e Java. Isso é útil para determinar a quantidade de RU/s que você precisará fornecer no serviço.
Limitação da taxa de manipulação (429 erros)
O Azure Cosmos DB retornará erros de taxa limitada (429) se os clientes consumirem mais recursos (RU/s) do que a quantidade que você provisionou. A API para Cassandra no Azure Cosmos DB traduz essas exceções em erros sobrecarregados no protocolo nativo Cassandra.
Se o seu sistema não for sensível à latência, pode ser suficiente lidar com a limitação da taxa de transferência usando tentativas. Consulte Exemplos de código Java para as versões 3 e 4 dos drivers Java Apache Cassandra para saber como lidar com a limitação de taxa de forma transparente. Esses exemplos implementam uma versão personalizada da política padrão de repetição Cassandra em Java. Você também pode usar a extensão Spark para lidar com a limitação de taxa. Ao usar o Spark, certifique-se de seguir nossas orientações sobre como otimizar a configuração da taxa de transferência do conector Spark.
Gerenciar dimensionamento
Se você precisar minimizar a latência, há um espectro de opções para gerenciar a escala e a taxa de transferência de provisionamento (RUs) na API para Cassandra:
- Manualmente usando o portal do Azure
- Programaticamente usando os recursos do plano de controle
- Programaticamente usando comandos CQL com um SDK específico
- Dinamicamente usando o dimensionamento automático
As secções seguintes explicam as vantagens e desvantagens de cada abordagem. Em seguida, você pode decidir sobre a melhor estratégia para equilibrar as necessidades de dimensionamento do seu sistema, o custo geral e as necessidades de eficiência para sua solução.
Utilizar o portal do Azure
Você pode dimensionar os recursos no Azure Cosmos DB para a conta Apache Cassandra usando o portal do Azure. Para saber mais, consulte o artigo sobre Taxa de transferência de provisionamento em contêineres e bancos de dados. Este artigo explica os benefícios relativos da definição da taxa de transferência no nível do banco de dados ou do contêiner no portal do Azure. Os termos "banco de dados" e "contêiner" mencionados nestes artigos são mapeados para "keyspace" e "table", respectivamente, para a API para Cassandra.
A vantagem desse método é que ele é uma maneira simples de gerenciar a capacidade de taxa de transferência no banco de dados. No entanto, a desvantagem é que, em muitos casos, sua abordagem de dimensionamento pode exigir certos níveis de automação para ser econômica e de alto desempenho. As próximas seções 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 a taxa de transferência programaticamente usando nossos vários recursos de plano de controle. Consulte os artigos Azure Resource Manager, PowerShell e Azure CLI para obter orientações e exemplos.
A vantagem desse método é que você pode automatizar o escalonamento para cima ou para baixo de recursos com base em um temporizador para levar em conta a atividade de pico ou períodos de baixa atividade. Dê uma olhada em nosso exemplo aqui para saber como fazer isso usando o Azure Functions e o PowerShell.
Uma desvantagem com essa abordagem pode ser que você não pode responder a necessidades de escala imprevisíveis em tempo real. Em vez disso, talvez seja necessário aproveitar o contexto do aplicativo em seu sistema, no nível do cliente/SDK ou usando o Autoscale.
Usar consultas CQL com um SDK específico
Você pode dimensionar o sistema dinamicamente com código executando os comandos CQL ALTER para determinado banco de dados ou contêiner.
A vantagem dessa abordagem é que ela permite que você responda às necessidades de escala dinamicamente e de uma maneira personalizada que se adapte ao seu aplicativo. Com essa abordagem, você ainda pode aproveitar as taxas e encargos padrão de RU/s. Se as necessidades de escala do seu sistema forem previsíveis (cerca de 70% ou mais), usar o SDK com CQL pode ser um método mais econômico de dimensionamento automático do que usar o dimensionamento automático. A desvantagem dessa abordagem é que pode ser bastante complexo implementar novas tentativas, enquanto a limitação de taxa pode aumentar a latência.
Usar taxa de transferência provisionada em escala automática
Além da taxa de transferência padrão (manual) ou programática de provisionamento, você também pode configurar contêineres do Azure Cosmos DB em taxa de transferência provisionada em escala automática. O dimensionamento automático será dimensionado automática e instantaneamente de acordo com suas necessidades de consumo dentro de intervalos de RU especificados sem comprometer os SLAs. Para saber mais, consulte o artigo Criar contêineres e bancos de dados do Azure Cosmos DB em escala automática.
A vantagem dessa abordagem é que é a maneira mais fácil de gerenciar as necessidades de dimensionamento em seu sistema. Ele não aplicará limitação de taxa dentro dos intervalos de RU configurados. A desvantagem é que, se as necessidades de dimensionamento em seu sistema forem previsíveis, o dimensionamento automático pode ser uma maneira menos econômica de lidar com suas necessidades de dimensionamento do que usar o plano de controle personalizado ou as abordagens de nível SDK mencionadas acima.
Para definir ou alterar a taxa de transferência máxima (RUs) para dimensionamento automático usando CQL, use o seguinte (substituindo o espaço de chave/nome da tabela de acordo):
# 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;
Próximos passos
- Introdução à criação de uma API para a conta Cassandra, banco de dados e uma tabela usando um aplicativo Java