Como se adaptar ao Azure Cosmos DB for Apache Cassandra se você for um usuário do Apache Cassandra

  • Artigo

APLICA-SE A: Cassandra

O Azure Cosmos DB for Apache Cassandra fornece compatibilidade do protocolo de transferência com os SDKs e as ferramentas existentes do Cassandra. Você pode executar aplicativos que foram projetados para se conectar ao Apache Cassandra usando a API for Cassandra com alterações mínimas.

Quando você usa a API for Cassandra, é importante estar ciente das diferenças entre o Apache Cassandra e o Azure Cosmos DB. Caso você esteja familiarizado com o Apache Cassandra nativo, este artigo pode ajudar você a começar a usar o Azure Cosmos DB for Apache Cassandra.

Suporte a recursos

A API for Cassandra dá suporte a um grande número de recursos do Apache Cassandra. Alguns recursos não têm suporte ou têm limitações. Antes de migrar, verifique se há suporte para os recursos necessários do Azure Cosmos DB for Apache Cassandra.

Replicação

Ao planejar a replicação, é importante ver a migração e a consistência.

Embora você possa se comunicar com a API for Cassandra por meio do protocolo de transferência Protocolo Binário v4 da CQL (Cassandra Query Language), o Azure Cosmos DB implementa um protocolo de replicação interna próprio. Não é possível usar o protocolo gossip do Cassandra para replicação ou migração dinâmica. Para obter mais informações, confira Migração dinâmica do Apache Cassandra para a API for Cassandra usando gravações duplas.

Para obter mais informações sobre a migração offline, confira Migrar dados do Cassandra para uma conta do Azure Cosmos DB for Apache Cassandra usando o Azure Databricks.

Embora as abordagens de consistência de replicação no Apache Cassandra e no Azure Cosmos DB sejam semelhantes, é importante entender as diferenças entre elas. Um documento de mapeamento compara as abordagens do Apache Cassandra e do Azure Cosmos DB para a consistência da replicação. No entanto, é altamente recomendável que você examine especificamente as configurações de consistência do Azure Cosmos DB ou assista a um breve guia de vídeo para entender as configurações de consistência na plataforma do Azure Cosmos DB.

Quando você usa a API for Cassandra, não precisa fazer alterações substanciais de código nos aplicativos existentes que executam o Apache Cassandra. Recomendamos algumas abordagens e definições de configuração para a API for Cassandra no Azure Cosmos DB. Confira a postagem no blog Recomendações da API for Cassandra para Java.

Exemplos de código

A API for Cassandra foi projetada para funcionar com seu código de aplicativo existente. Ao encontrar algum erro relacionado à conectividade, use os exemplos de início rápido como ponto de partida para descobrir as pequenas alterações de configuração que você pode precisar fazer no código existente.

Além disso, temos exemplos mais aprofundados para drivers Java v3 e Java v4. Esses exemplos de código implementam extensões personalizadas, que, por sua vez, implementam as configurações de cliente recomendadas.

Também é possível usar exemplos para o Java Spring Boot (driver v3) e Java Spring Boot (driver v4).

Armazenamento

A API for Cassandra tem o suporte do Azure Cosmos DB, que é um mecanismo de banco de dados NoSQL orientado a documentos. O Azure Cosmos DB mantém metadados, o que pode resultar em uma alteração na quantidade de armazenamento físico necessária para uma carga de trabalho específica.

A diferença entre os requisitos de armazenamento entre o Apache Cassandra nativo e o Azure Cosmos DB é mais perceptível em tamanhos de linha pequenos. Em alguns casos, a diferença pode ser deslocada porque o Azure Cosmos DB não implementa compactação ou marcas de exclusão. No entanto, esse fator depende significativamente da carga de trabalho. Se não tiver certeza sobre os requisitos de armazenamento, recomendamos que você crie primeiro uma prova de conceito.

Implantações em várias regiões

O Apache Cassandra nativo é um sistema com vários mestres por padrão. O Apache Cassandra não tem uma opção para mestre único com replicação de várias regiões somente para leituras. O conceito de failover no nível do aplicativo para outra região para gravações é redundante no Apache Cassandra. Todos os nós são independentes e não há um ponto único de falha. No entanto, o Azure Cosmos DB permite configurar regiões de mestre único ou de vários mestres para gravações.

Uma vantagem de ter uma região de mestre único para gravações é evitar cenários de conflito entre regiões. Isso oferece a opção de manter uma coerência forte em várias regiões, mantendo um nível de alta disponibilidade.

Observação

A coerência forte entre regiões e um RPO (Objetivo de Ponto de Recuperação) de zero não é possível para o Apache Cassandra nativo porque todos os nós são capazes de servir gravações. É possível configurar o Azure Cosmos DB para coerência forte entre regiões na configuração de região de gravação única. No entanto, como com o Apache Cassandra nativo, não é possível definir uma conta do Azure Cosmos DB configurada com várias regiões de gravação para uma coerência forte. Um sistema distribuído não pode fornecer um RPO de zero e um RTO (Objetivo de Tempo de Recuperação) de zero.

Para saber mais, confira Política de balanceamento de carga em nosso blog de recomendações para a API for Cassandra para Java. Além disso, confira Cenários de failover em nosso exemplo de código oficial para o driver do Cassandra Java v4.

Unidades de solicitação

Uma das principais diferenças entre executar um cluster nativo do Apache Cassandra e provisionar uma conta do Azure Cosmos DB é a maneira como a capacidade do banco de dados é provisionada. Em bancos de dados tradicionais, a capacidade é expressa em termos de núcleos de CPU, RAM e IOPs. O Azure Cosmos DB é um banco de dados de plataforma como serviço com vários locatários. A capacidade é expressa usando uma métrica normalizada chamada unidades de solicitação. Toda solicitação enviada ao banco de dados tem um custo por RU (unidade de solicitação). É possível criar o perfil de cada solicitação para determinar o custo respectivo.

O benefício de usar as unidades de solicitação como uma métrica é que a capacidade do banco de dados pode ser provisionada de modo determinístico para atingir um desempenho e uma eficiência altamente previsíveis. Depois de fazer o perfil do custo de cada solicitação, você pode usar unidades de solicitação para associar diretamente o número de solicitações enviadas ao banco de dados com a capacidade que você precisa provisionar. O desafio dessa forma de provisionamento de capacidade é que você precisa ter uma compreensão mais sólida das características de taxa de transferência de sua carga de trabalho.

É altamente recomendável criar o perfil de suas solicitações. Com a ajuda dessas informações, é possível estimar o número de unidades de solicitação que você precisará provisionar. Aqui estão alguns artigos que podem ajudar você a fazer a estimativa:

Modelos de provisionamento de capacidade

No provisionamento de banco de dados tradicional, uma capacidade fixa é provisionada com antecedência para lidar com a taxa de transferência antecipada. O Azure Cosmos DB oferece um modelo baseado em capacidade conhecido como taxa de transferência provisionada. Como um serviço de vários locatários, o Azure Cosmos DB também oferece modelos baseados em consumo no modo de dimensionamento automático e no modo sem servidor. A extensão em que uma carga de trabalho pode se beneficiar de qualquer um desses modelos de provisionamento baseados em consumo depende da previsibilidade da taxa de transferência para a carga de trabalho.

De modo geral, cargas de trabalho de estado estável com taxa de transferência previsível se beneficiam mais da taxa de transferência provisionada. As cargas de trabalho que têm grandes períodos de latência se beneficiam do modo sem servidor. As cargas de trabalho que têm um nível contínuo de taxa de transferência mínima, mas com picos imprevisíveis, se beneficiam mais do modo de dimensionamento automático. Recomendamos que você examine os seguintes artigos para uma compreensão clara do melhor modelo de capacidade para suas necessidades de taxa de transferência:

Particionamento

O particionamento no Azure Cosmos DB é semelhante ao particionamento no Apache Cassandra. Uma das principais diferenças é que o Azure Cosmos DB é mais otimizado para a escala horizontal. No Azure Cosmos DB, os limites são colocados na quantidade de capacidade de taxa de transferência vertical disponível em qualquer partição física. O efeito dessa otimização é mais perceptível quando há uma distorção significativa da taxa de transferência em um modelo de dados existente.

Tome medidas para garantir que seu design de chave de partição resulte em uma distribuição relativamente uniforme de solicitações. Para saber como os particionamentos lógico e físico funcionam e os limites da capacidade de taxa de transferência por partição, confira Particionamento no Azure Cosmos DB for Apache Cassandra.

Escala

No Apache Cassandra nativo, aumentar a capacidade e a escala envolve adicionar novos nós a um cluster e garantir que eles sejam adicionados corretamente ao anel do Cassandra. No Azure Cosmos DB, a adição de nós é transparente e automática. A escala é uma função de quantas unidades de solicitação são provisionadas para seu keyspace ou tabela. A escala em computadores físicos ocorre quando o armazenamento físico ou a taxa de transferência necessária atinge os limites permitidos para uma partição lógica ou física. Para obter mais informações, confira Particionamento no Azure Cosmos DB for Apache Cassandra.

Limitação de taxa

Um desafio do provisionamento de unidades de solicitação, especialmente se você estiver usando a taxa de transferência provisionada, é a limitação de taxa. O Azure Cosmos DB retornará erros limitados por taxa se os clientes consumirem mais recursos do que o valor provisionado. A API for Cassandra no Azure Cosmos DB converte essas exceções em erros de sobrecarga no protocolo nativo do Cassandra. Para obter informações sobre como evitar a limitação de taxa no seu aplicativo, confira Evitar erros de limitação de taxa para as operações do Azure Cosmos DB for Apache Cassandra.

Conector do Apache Spark

Muitos usuários do Apache Cassandra usam o conector do Cassandra do Apache Spark para consultar dados para necessidades de análise e de movimentação de dados. Você pode se conectar à API for Cassandra da mesma forma, usando o mesmo conector. Antes de se conectar à API for Cassandra, confira Conectar-se ao Azure Cosmos DB for Apache Cassandra por meio do Spark. Em particular, consulte a seção Otimizar configuração de taxa de transferência do conector Spark.

Solução de problemas comuns

Para ver soluções para problemas comuns, confira Solucionar problemas comuns no Azure Cosmos DB for Apache Cassandra.

Próximas etapas