Perguntas frequentes sobre o Azure Cosmos DB for Apache Cassandra

APLICA-SE AO: Cassandra

Quais são as principais diferenças entre o Azure Cosmos DB for Cassandra e o Apache Cassandra?

Aqui estão algumas das principais diferenças entre a API para o serviço Cassandra e o Apache Cassandra:

  • O Apache Cassandra recomenda o limite de 100 MB no tamanho das chaves de partição. A API para Cassandra para o Azure Cosmos DB permite até 20 GB por partição.
  • No Apache Cassandra, é possível desabilitar as confirmações duráveis. Você pode pular a escrita no log de commit e ir diretamente para a estrutura de dados em memória. Isso poderá levar à perda de dados se o nó falhar antes que as estruturas de dados em memória sejam liberadas para SSTables no disco. O Azure Cosmos DB sempre faz confirmações duráveis para evitar a perda de dados.
  • O Apache Cassandra pode ter desempenho ruim com cargas de trabalho que envolvem muitas substituições ou exclusões. O motivo é que a carga de trabalho de leitura precisa ignorar as marcas de exclusão para buscar os dados mais recentes. Na API para Cassandra, as leituras não têm redução de desempenho quando a carga de trabalho tem muitas substituições ou exclusões.
  • Em cargas de trabalho com muitas substituições, é necessário realizar compactação para mesclar o SSTables no disco. (A mesclagem é necessária porque as gravações do Apache Cassandra são acrescentadas somente. Várias atualizações são armazenadas como entradas da SSTable individuais que precisam ser mescladas periodicamente.) Essa situação também pode prejudicar o desempenho da leitura durante a compactação. Esse impacto no desempenho não ocorre na API para Cassandra porque ela não implementa a compactação.
  • É possível definir o fator de replicação como 1 no Apache Cassandra. No entanto, isso levará à baixa disponibilidade se o único nó com os dados ficar inativo. Isso não é um problema com a API para Cassandra no Azure Cosmos DB porque sempre há um fator de replicação de 4 (quorum de 3).
  • A adição ou remoção de nós no Apache Cassandra requer intervenção manual, bem como alto uso de CPU no nó novo enquanto os nós anteriores transferem os intervalos de token para ele. Essa situação é a mesma quando você encerra um nó. No entanto, a API para Cassandra é escalada horizontalmente sem problemas observados no serviço ou aplicativo.
  • Não é necessário definir num_tokens em cada nó do cluster como no Apache Cassandra. O Azure Cosmos DB gerencia totalmente nós e intervalos de token.
  • A API para Cassandra é totalmente gerenciada. Você não precisa dos comandos, como reparo e descomissionamento, que são usados no Apache Cassandra.

A API para Cassandra dá suporte para qual versão do protocolo?

A API do Cassandra para Azure Cosmos DB dá suporte ao Cassandra Query Language (CQL) m versão 3.x. A compatibilidade com o CQL da API é baseada no repositório público do Apache Cassandra no GitHub. Se você tiver comentários sobre o suporte de outros protocolos, envie um email para askcosmosdbcassandra@microsoft.com.

Por que é necessário escolher uma taxa de transferência para uma tabela?

O Azure Cosmos DB define a taxa de transferência padrão para o contêiner com base em onde você cria a tabela: portal do Azure ou CQL.

O Azure Cosmos DB fornece garantias de desempenho e latência com limites superiores nas operações. Essas garantias são possíveis quando o mecanismo pode impor a governança nas operações do locatário. Configurar a taxa de transferência assegura que você obtenha taxa de transferência e latência garantidas, pois a plataforma reserva essa capacidade e garante o sucesso da operação. Você pode alterar a taxa de transferência de maneira flexível para se beneficiar da sazonalidade de seu aplicativo e reduzir custos.

O conceito de taxa de transferência é explicado no artigo Unidades de solicitação no Azure Cosmos DB. A taxa de transferência de uma tabela é distribuída igualmente entre as partições físicas subjacentes.

Qual é a taxa de transferência de uma tabela criada por meio de CQL?

O Azure Cosmos DB usa unidades de solicitação por segundo (RU/s) como moeda para indicar a taxa de transferência. As tabelas criadas por meio de CQL têm 400 RU por padrão. Você pode alterar a RU no portal do Azure.

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

O que acontece quando a taxa de transferência é usada?

O Azure Cosmos DB fornece garantias de desempenho e latência com limites superiores nas operações. Essas garantias são possíveis quando o mecanismo pode impor a governança nas operações do locatário. Configurar a taxa de transferência assegura que você obtenha taxa de transferência e latência garantidas, pois a plataforma reserva essa capacidade e garante o sucesso da operação.

Quando você ultrapassa essa capacidade, a mensagem de erro abaixo é exibida, indicando que a capacidade foi consumida:

0x1001 Sobrecarregado: a solicitação não pode ser processada porque "A taxa de solicitação é grande"

É essencial ver quais operações e respectivos volumes causam esse problema. Você pode ter uma ideia da capacidade consumida que excede a capacidade provisionada com as métricas no portal do Azure. Em seguida, você precisa garantir que a capacidade seja consumida de maneira quase igual entre todas as partições subjacentes. Quando uma partição consome mais da taxa de transferência, está ocorrendo distorção da carga de trabalho.

Há uma métrica disponível para mostrar como a taxa de transferência é usada ao longo de horas, dias e por sete dias, nas partições ou no todo. Para obter mais informações, consulte Como monitorar e depurar com métricas no Azure Cosmos DB.

Logs de diagnóstico são explicados no artigo Logs de diagnóstico do Azure Cosmos DB.

A chave primária mapeia para o conceito de chave de partição do Azure Cosmos DB?

Sim, a chave de partição é usada para colocar a entidade na localização correta. No Azure Cosmos DB, ela é usada para localizar a partição lógica correta que é armazenada em uma partição física. O conceito de particionamento também é explicado no artigo Partição e escala no Azure Cosmos DB. A questão essencial aqui é que uma partição lógica não deve exceder o limite de 20 GB.

O que acontece quando recebo a notificação de que uma partição está cheia?

O Azure Cosmos DB é um sistema baseado em SLA (Contrato de Nível de Serviço). Ele tem escala ilimitada com garantias de latência, taxa de transferência, disponibilidade e consistência. O armazenamento ilimitado baseia-se na expansão horizontal de dados usando o particionamento como o conceito chave. O conceito de particionamento também é explicado no artigo Partição e escala no Azure Cosmos DB.

Você deve observar o limite de 20 GB no número de entidades ou itens por partição lógica. Para garantir que seu aplicativo dimensiona bem, recomendamos que você não crie uma partição ativa armazenando todas as informações em uma partição e consultando-a. Esse erro poderá apenas surgir se os dados forem distorcidos: ou seja, muitos dados para uma chave de partição (mais do que 20 GB). Você pode localizar a distribuição de dados usando o portal de armazenamento. Uma forma de consertar esse erro é recriar a tabela e escolher um primário granular (chave de partição), que permita uma melhor distribuição de dados.

É possível usar a API para Cassandra como um armazenamento de valor de chave com milhões ou bilhões de chaves de partição?

O Azure Cosmos DB pode armazenar dados ilimitados expandindo o armazenamento. O armazenamento é independente da taxa de transferência. Sim, sempre há a opção de usar a API para Cassandra para armazenar e recuperar chaves e valores especificando a chave de partição/primária correta. Essas chaves individuais têm uma partição lógica própria e permanecem acima da partição física sem problemas.

É possível criar mais de uma tabela com a API para Cassandra?

Sim, é possível criar mais de uma tabela com a API para Cassandra. Cada uma dessas tabelas é tratada como unidade de taxa de transferência e armazenamento.

É possível criar mais de uma tabela sucessivamente?

O Azure Cosmos DB é um sistema de recursos administrado para atividades de plano de dados e controle. Os contêineres, como coleções e tabelas, são entidades de runtime provisionadas para uma determinada capacidade de taxa de transferência. A criação dos contêineres em sucessão rápida não é uma atividade esperada e pode ser limitada. Se você tiver testes que removem ou criam tabelas imediatamente, tente espaçá-los.

Qual é o número máximo de tabelas que podem ser criadas?

Não há limite físico à quantidade de tabelas. Caso você precise criar muitas tabelas além do número usual de dezenas ou centenas (com tamanho total estável acima de 10 TB de dados), envie um email para askcosmosdbcassandra@microsoft.com.

Qual é a quantidade máxima de keyspaces que pode ser criada?

Não há limite físico ao número de keyspaces porque eles são contêineres de metadados. Se você tiver muitos keyspaces, envie um email para askcosmosdbcassandra@microsoft.com.

Posso trazer muitos dados depois de começar de uma tabela normal?

Sim. Contanto que a distribuição das partições seja uniforme, a capacidade de armazenamento é gerenciada automaticamente e aumenta à medida que mais dados são enviados por push. Portanto, você pode importar com confiança a quantidade de dados que precisar sem o gerenciamento e provisionamento de nós e muito mais. No entanto, se você estiver antecipando um crescimento imediato de dados numerosos, faz mais sentido provisionar diretamente para a taxa de transferência prevista do que começar mais baixo e aumentá-la imediatamente.

É possível usar configurações de arquivo YAML para configurar o comportamento da API?

A API para Cassandra para o Azure Cosmos DB oferece compatibilidade em nível de protocolo para executar operações. Ela oculta a complexidade de gerenciamento, monitoramento e configuração. Como desenvolvedor/usuário, você não precisa se preocupar com a disponibilidade, marcas de exclusão, cache de chaves, cache de linhas, filtro de bloom e uma variedade de outras configurações. A API para Cassandra se concentra em proporcionar o desempenho necessário de leitura e gravação sem a sobrecarga de configuração e gerenciamento.

A API para Cassandra dará suporte para comandos de adição de nó, status do cluster e status do nó?

A API para Cassandra simplifica o planejamento da capacidade e a resposta às demandas de elasticidade para taxa de transferência e armazenamento. Com o Azure Cosmos DB, você provisiona a taxa de transferência de que precisa. Depois é possível escalar e reduzir verticalmente quantas vezes você quiser por dia sem se preocupar com adição, exclusão ou gerenciamento de nós. Você não precisa usar ferramentas para gerenciamento de nó e cluster.

O que acontece com várias definições de configuração para a criação de keyspaces como simples/rede?

O Azure Cosmos DB oferece distribuição global imediata por motivos de baixa latência e disponibilidade. Você não precisa instalar réplicas ou outras coisas. As gravações são sempre confirmadas por quorum de maneira duradoura em qualquer região na qual você grava com garantias de desempenho.

O que acontece com as diferentes configurações para metadados de tabela?

O Azure Cosmos DB garante o desempenho de leituras, gravações e taxa de transferência. Portanto, você não precisa se preocupar em alterar acidentalmente um dos parâmetros de configuração. Essas configurações incluem filtro de bloom, armazenamento em cache, chance de reparo de leitura, gc_grace e memtable_flush_period de compactação.

Há suporte para o TTL (Tempo de Vida) para tabelas Cassandra?

Sim, há suporte para TTL.

Como posso monitorar a infraestrutura em conjunto com a taxa de transferência?

O Azure Cosmos DB é um serviço de plataforma que ajuda a aumentar a produtividade e não se preocupar com o gerenciamento e monitoramento da infraestrutura. Por exemplo, não é necessário monitorar status do nó, status de réplica, gc e parâmetros de sistema operacional mais cedo com diversas ferramentas. Você precisa cuidar da taxa de transferência que está disponível na métrica do portal para saber se há ou não restrição e aumentar ou diminuir a taxa de transferência. Você pode:

Quais SDKs de cliente podem trabalhar com a API para Cassandra?

Os drivers de cliente do SDK do Apache Cassandra que usam CQLv3 foram usados para programas clientes. Se houver outros drivers que você use ou se você estiver enfrentando problemas, envie um email para askcosmosdbcassandra@microsoft.com.

Há suporte para chave de partição de composição?

Sim, é possível usar a sintaxe regular para criar chaves de partição de composição.

É possível usar o sstableloader para carregamento de dados?

Não, não há suporte para sstableloader.

É possível emparelhar um cluster do Apache Cassandra local à API para Cassandra?

Agora, o Azure Cosmos DB tem uma experiência otimizada para o ambiente em nuvem sem a sobrecarga de operações. Se você precisar de emparelhamento, envie um email para askcosmosdbcassandra@microsoft.com com uma descrição do seu cenário. Estamos trabalhando em uma oferta para emparelhar o cluster local ou de nuvem do Cassandra à API para Cassandra para o Azure Cosmos DB.

A API para Cassandra realiza backups completos?

O Azure Cosmos DB realiza dois backups completos gratuitos em intervalos de quatro horas em todas as APIs. Portanto, você não precisa configurar uma agenda de backup.

Você pode gerenciar a retenção e a frequência de backup por conta própria.

Se quiser restaurar pelo backup, envie um e-mail para askcosmosdbcassandra@microsoft.com ou abra um caso de suporte. As informações sobre a funcionalidade de backup são fornecidas no artigo Backup e restauração online automáticos com o Azure Cosmos DB.

Como uma conta da API para Cassandra lida com o failover caso uma região fique inativa?

A API para Cassandra pega emprestado da plataforma distribuída globalmente do Azure Cosmos DB. Para que seu aplicativo tolere o tempo de inatividade do datacenter, habilite pelo menos mais uma região para a conta no portal do Azure. Veja mais informações em Alta disponibilidade com o Azure Cosmos DB.

Você pode adicionar quantas regiões quiser para a conta e controlar para onde ela pode fazer o failover fornecendo uma prioridade de failover. Para usar o banco de dados, você precisa fornecer um aplicativo lá também. Quando você fizer isso, os clientes não terão o tempo de inatividade.

A API para Cassandra indexa todos os atributos de uma entidade por padrão?

Não. O API para Cassandra dá suporte a índices secundários, que se comportam de maneira semelhante à do Apache Cassandra. A API não indexa todos os atributos por padrão.

Posso usar o novo SDK da API para Cassandra localmente com o emulador?

Sim, há suporte para isso. Veja mais detalhes sobre a habilitação do recurso no artigo Usar o emulador do Azure Cosmos DB para desenvolvimento e teste locais.

Como faço para migrar dados de clusters do Apache Cassandra para o Azure Cosmos DB?

Você pode ler sobre as opções de migração no tutorial Migrar seus dados para a conta da API para Cassandra no Azure Cosmos DB.