Partilhar via

Como se adaptar ao Azure Cosmos DB para Apache Cassandra se você estiver vindo do Apache Cassandra

  • Artigo

APLICA-SE A: Cassandra

O Azure Cosmos DB para Apache Cassandra fornece compatibilidade de protocolo de conexão com SDKs e ferramentas existentes do Cassandra. Você pode executar aplicativos projetados para se conectar ao Apache Cassandra usando a API para Cassandra com alterações mínimas.

Quando você usa a API para Cassandra, é importante estar ciente das diferenças entre o Apache Cassandra e o Azure Cosmos DB. Se você estiver familiarizado com o Apache Cassandra nativo, este artigo pode ajudá-lo a começar a usar o Azure Cosmos DB para Apache Cassandra.

Suporte de funcionalidades

A API para Cassandra suporta um grande número de recursos do Apache Cassandra. Algumas funcionalidades não são suportadas ou têm limitações. Antes de migrar, certifique-se de que os recursos do Azure Cosmos DB para Apache Cassandra de que você precisa são suportados.

Replicação

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

Embora você possa se comunicar com a API para Cassandra por meio do protocolo binário CQL (Cassandra Query Language) v4 wire protocol, o Azure Cosmos DB implementa seu próprio protocolo de replicação interna. Você não pode usar o protocolo de fofoca Cassandra para migração ou replicação ao vivo. Para obter mais informações, consulte Migração ao vivo do Apache Cassandra para a API do Cassandra usando gravações duplas.

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

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

Ao usar a API para Cassandra, você não precisa fazer alterações substanciais de código em aplicativos existentes que executam o Apache Cassandra. Recomendamos algumas abordagens e definições de configuração para a API para Cassandra no Azure Cosmos DB. Revise a API de postagem do blog para recomendações Cassandra para Java.

Amostras de código

A API para Cassandra foi projetada para funcionar com o código do aplicativo existente. Se você encontrar erros relacionados à conectividade, use os exemplos de início rápido como ponto de partida para descobrir pequenas alterações de configuração que talvez seja necessário fazer no código existente.

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

Você também pode usar exemplos para Java Spring Boot (driver v3) e Java Spring Boot (driver v4).

Armazenamento

A API para Cassandra é apoiada pelo 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 nos requisitos de armazenamento entre o Apache Cassandra nativo e o Azure Cosmos DB é mais percetível em tamanhos de linha pequenos. Em alguns casos, a diferença pode ser compensada porque o Azure Cosmos DB não implementa compactação ou lápides. Este fator depende significativamente da carga de trabalho. Se você não tiver certeza sobre os requisitos de armazenamento, recomendamos que você primeiro crie uma prova de conceito.

Implementações em múltiplas regiões

O Apache Cassandra nativo é um sistema multi-mestre por padrão. O Apache Cassandra não tem uma opção para mestre único com replicação de várias regiões apenas 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 único ponto de falha. No entanto, o Azure Cosmos DB fornece a capacidade pronta para configurar regiões de mestre único ou multimestre para gravações.

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

Nota

Uma forte consistência entre regiões e um RPO (Recovery Point Objetive, 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. Você pode configurar o Azure Cosmos DB para uma forte consistência entre regiões em uma única configuração de região de gravação. No entanto, como no Apache Cassandra nativo, não é possível configurar uma conta do Azure Cosmos DB configurada com várias regiões de gravação para uma consistência forte. Um sistema distribuído não pode fornecer um RPO de zero e um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de zero.

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

Unidades de pedidos

Uma das principais diferenças entre executar um cluster Apache Cassandra nativo e provisionar uma conta do Azure Cosmos DB é 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 multilocatário. A capacidade é expressa usando uma única métrica normalizada chamada unidades de solicitação. Cada pedido enviado para a base de dados tem um custo unitário de pedido (custo RU). Cada solicitação pode ser perfilada para determinar seu custo.

A vantagem de usar unidades de solicitação como métrica é que a capacidade do banco de dados pode ser provisionada deterministicamente para desempenho e eficiência altamente previsíveis. Depois de traçar 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 necessária para provisionar. O desafio dessa forma de capacidade de provisionamento é que você precisa ter uma compreensão sólida das características de taxa de transferência de sua carga de trabalho.

Recomendamos vivamente que defina o perfil dos seus pedidos. Use essas informações para ajudá-lo a estimar o número de unidades de solicitação que você precisará provisionar. Aqui estão alguns artigos que podem ajudá-lo a fazer a estimativa:

Modelos de provisionamento de capacidade

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

Em geral, as cargas de trabalho de estado estacionário que têm 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 dormê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, são as que mais se beneficiam do modo de dimensionamento automático. Recomendamos que você revise os seguintes artigos para obter uma compreensão clara do melhor modelo de capacidade para suas necessidades de taxa de transferência:

Criação de partições

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 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 percetível quando um modelo de dados existente tem uma inclinação significativa na taxa de transferência.

Tome medidas para garantir que o design da chave de partição resulte em uma distribuição relativamente uniforme de solicitações. Para obter mais informações sobre como o particionamento lógico e físico funciona e os limites da capacidade de taxa de transferência por partição, consulte Particionamento no Azure Cosmos DB para Apache Cassandra.

Dimensionamento

No Apache Cassandra nativo, aumentar a capacidade e a escala envolve adicionar novos nós a um cluster e garantir que os nós sejam adicionados corretamente ao anel Cassandra. No Azure Cosmos DB, a adição de nós é transparente e automática. O dimensionamento é uma função de quantas unidades de solicitação são provisionadas para seu espaço de chave ou tabela. O dimensionamento em máquinas físicas 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, consulte Particionamento no Azure Cosmos DB para Apache Cassandra.

Rate limiting (Limitação de taxa)

Um desafio do provisionamento de unidades de solicitação, especialmente se você estiver usando a taxa de transferência provisionada, é o limite de taxa. O Azure Cosmos DB retorna erros de taxa limitada se os clientes consumirem mais recursos do que a quantidade provisionada. A API para Cassandra no Azure Cosmos DB traduz essas exceções em erros sobrecarregados no protocolo nativo Cassandra. Para obter informações sobre como evitar a limitação de taxa em seu aplicativo, consulte Evitar erros de limitação de taxa para operações do Azure Cosmos DB para Apache Cassandra.

Conector do Apache Spark

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

Resolver problemas comuns

Para obter soluções para problemas comuns, consulte Solucionar problemas comuns no Azure Cosmos DB para Apache Cassandra.

Próximos passos