Como se adaptar ao Azure Cosmos DB para Apache Cassandra se for proveniente do Apache Cassandra

  • Artigo

APLICA-SE A: Cassandra

O Azure Cosmos DB para Apache Cassandra fornece compatibilidade com protocolos com fios com os SDKs e ferramentas existentes do Cassandra. Pode executar aplicações concebidas para ligar ao Apache Cassandra com a API para Cassandra com alterações mínimas.

Quando utiliza a API para Cassandra, é importante ter em atenção as diferenças entre o Apache Cassandra e o Azure Cosmos DB. Se estiver familiarizado com o Apache Cassandra nativo, este artigo pode ajudá-lo a começar a utilizar o Azure Cosmos DB para o Apache Cassandra.

Suporte de funcionalidades

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

Replicação

Quando planeia replicação, é importante analisar a migração e a consistência.

Embora possa comunicar com a API para Cassandra através do protocolo de fios v4 do protocolo de rede v4 da Linguagem de Consulta Cassandra (CQL), o Azure Cosmos DB implementa o seu próprio protocolo de replicação interna. Não pode utilizar o protocolo de fofocas para Cassandra para migração ou replicação em direto. Para obter mais informações, veja Live-migrate from Apache Cassandra to the API for Cassandra by using dual writes (Migrar em direto do Apache Cassandra para a API para Cassandra através de escritas duplas).

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

Embora as abordagens à consistência da replicação no Apache Cassandra e no Azure Cosmos DB sejam semelhantes, é importante compreender como são diferentes. Um documento de mapeamento compara as abordagens do Apache Cassandra e do Azure Cosmos DB com a consistência da replicação. No entanto, recomendamos vivamente que reveja especificamente as definições de consistência do Azure Cosmos DB ou veja um breve guia de vídeo para compreender as definições de consistência na plataforma do Azure Cosmos DB.

Quando utiliza a API para Cassandra, não precisa de fazer alterações de código substanciais às aplicações existentes que executam o Apache Cassandra. Recomendamos algumas abordagens e definições de configuração para a API para Cassandra no Azure Cosmos DB. Reveja a publicação de blogue API para recomendações do Cassandra para Java.

Exemplos de código

A API para Cassandra foi concebida para funcionar com o código da aplicação existente. Se encontrar erros relacionados com a conectividade, utilize os exemplos de início rápido como ponto de partida para detetar pequenas alterações de configuração que poderá ter de fazer no código existente.

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

Também pode utilizar exemplos para Java Spring Boot (controlador v3) e Java Spring Boot (controlador v4).

Armazenamento

A API para Cassandra é suportada pelo Azure Cosmos DB, que é um motor de base de dados NoSQL orientado para documentos. O Azure Cosmos DB mantém metadados, o que pode resultar numa alteração na quantidade de armazenamento físico necessário 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 notá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 não tiver a certeza sobre os requisitos de armazenamento, recomendamos que crie primeiro uma prova de conceito.

Implementações em múltiplas regiões

O Apache Cassandra nativo é um sistema multimestre por predefinição. O Apache Cassandra não tem uma opção para um único modelo global com replicação de várias regiões apenas para leituras. O conceito de ativação pós-falha ao nível da aplicação para outra região para escritas é redundante no Apache Cassandra. Todos os nós são independentes e não existe um único ponto de falha. No entanto, o Azure Cosmos DB fornece a capacidade de configurar regiões de modelo único ou multimestre para escritas.

Uma vantagem de ter uma região de mestre único para escritas é evitar cenários de conflito entre regiões. Dá-lhe a opção de manter uma consistência forte em várias regiões, mantendo um nível de elevada disponibilidade.

Nota

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

Para obter mais informações, veja Política de balanceamento de carga no nosso blogue recomendações da API para Cassandra para Java. Além disso, veja Cenários de ativação pós-falha no nosso exemplo de código oficial para o controlador Java v4 para Cassandra.

Unidades de pedidos

Uma das principais diferenças entre a execução de um cluster nativo do Apache Cassandra e o aprovisionamento de uma conta do Azure Cosmos DB é a forma como a capacidade da base de dados é aprovisionada. Nas bases de dados tradicionais, a capacidade é expressa em termos de núcleos de CPU, RAM e IOPS. O Azure Cosmos DB é uma base de dados de plataforma como serviço multi-inquilino. A capacidade é expressa através de uma única métrica normalizada chamada unidades de pedido. Cada pedido enviado para a base de dados tem um custo unitário de pedido (custo de RU). Cada pedido pode ser perfilado para determinar o respetivo custo.

A vantagem de utilizar unidades de pedido como métrica é que a capacidade da base de dados pode ser aprovisionada deterministicamente para um desempenho e eficiência altamente previsíveis. Depois de criar o perfil do custo de cada pedido, pode utilizar unidades de pedido para associar diretamente o número de pedidos enviados à base de dados com a capacidade que precisa de aprovisionar. O desafio desta forma de aprovisionar capacidade é ter uma compreensão sólida das características de débito da sua carga de trabalho.

Recomendamos vivamente que faça o perfil dos seus pedidos. Utilize essas informações para o ajudar a estimar o número de unidades de pedido que terá de aprovisionar. Eis alguns artigos que podem ajudá-lo a fazer a estimativa:

Modelos de aprovisionamento de capacidade

No aprovisionamento de bases de dados tradicionais, é aprovisionada antecipadamente uma capacidade fixa para processar o débito previsto. O Azure Cosmos DB oferece um modelo baseado na capacidade denominado débito aprovisionado. Como serviço multi-inquilino, o Azure Cosmos DB também oferece modelos baseados no consumo no modo de dimensionamento automático e no modo sem servidor . A medida em que uma carga de trabalho pode beneficiar de qualquer um destes modelos de aprovisionamento baseados no consumo depende da previsibilidade do débito para a carga de trabalho.

Em geral, as cargas de trabalho de estado estável que têm um débito previsível beneficiam mais do débito aprovisionado. As cargas de trabalho que têm grandes períodos de dormência beneficiam do modo sem servidor. As cargas de trabalho que têm um nível contínuo de débito mínimo, mas com picos imprevisíveis, beneficiam mais do modo de dimensionamento automático. Recomendamos que reveja os seguintes artigos para obter uma compreensão clara do melhor modelo de capacidade para as suas necessidades de débito:

Criação de partições

A criação de partições no Azure Cosmos DB é semelhante à criação de partições no Apache Cassandra. Uma das principais diferenças é que o Azure Cosmos DB está mais otimizado para dimensionamento horizontal. No Azure Cosmos DB, são colocados limites na quantidade de capacidade de débito vertical disponível em qualquer partição física. O efeito desta otimização é mais percetível quando um modelo de dados existente tem uma distorção de débito significativa.

Tome medidas para garantir que a estrutura da chave de partição resulta numa distribuição relativamente uniforme dos pedidos. Para obter mais informações sobre como funcionam as partições lógicas e físicas e os limites da capacidade de débito por partição, veja Criação de partições no Azure Cosmos DB para Apache Cassandra.

Dimensionamento

No Apache Cassandra nativo, aumentar a capacidade e o dimensionamento envolve adicionar novos nós a um cluster e garantir que os nós são adicionados corretamente ao anel do Cassandra. No Azure Cosmos DB, adicionar nós é transparente e automático. O dimensionamento é uma função de quantas unidades de pedido são aprovisionadas para o seu espaço de chaves ou tabela. O dimensionamento em máquinas físicas ocorre quando o armazenamento físico ou o débito necessário atinge os limites permitidos para uma partição lógica ou física. Para obter mais informações, veja Criação de partições no Azure Cosmos DB para Apache Cassandra.

Rate limiting (Limitação de taxa)

Um desafio do aprovisionamento de unidades de pedido, especialmente se estiver a utilizar o débito aprovisionado, é a limitação de taxa. O Azure Cosmos DB devolve erros de taxa limitada se os clientes consumirem mais recursos do que o montante aprovisionado. A API para Cassandra no Azure Cosmos DB traduz estas exceções para erros sobrecarregados no protocolo nativo do Cassandra. Para obter informações sobre como evitar a limitação de taxas na sua aplicação, veja Evitar erros de limitação de taxa para as operações do Azure Cosmos DB para o Apache Cassandra.

Conector do Apache Spark

Muitos utilizadores do Apache Cassandra utilizam o conector para Cassandra do Apache Spark para consultar os respetivos dados relativamente a necessidades analíticas e de movimento de dados. Pode ligar à API para Cassandra da mesma forma e com o mesmo conector. Antes de se ligar à API para Cassandra, veja Ligar ao Azure Cosmos DB para Apache Cassandra a partir do Spark. Em particular, veja a secção Otimizar a configuração do débito do conector spark.

Resolver problemas comuns

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

Passos seguintes