Particionamento no Azure Cosmos DB for Apache Cassandra

  • Artigo

APLICA-SE A: Cassandra

Este artigo descreve como o particionamento funciona no Azure Cosmos DB for Apache Cassandra.

A API para Cassandra usa o particionamento para dimensionar as tabelas individuais em um keyspace para atender às necessidades de desempenho do seu aplicativo. As partições são formadas com base no valor de uma chave de partição associada a cada registro em uma tabela. Todos os registros em uma partição têm o mesmo valor de chave de partição. O Azure Cosmos DB gerencia de maneira transparente e automática o posicionamento de partições lógicas em partições físicas para atender com eficiência as necessidades de escalabilidade e desempenho do contêiner. À medida que os requisitos de taxa de transferência e armazenamento de um aplicativo aumentam, o Azure Cosmos DB move e equilibra os dados em um número maior de computadores físicos.

Da perspectiva do desenvolvedor, o particionamento se comporta da mesma forma para o Azure Cosmos DB for Apache Cassandra que no Apache Cassandra nativo. No entanto, há algumas diferenças nos bastidores.

Diferenças entre o Apache Cassandra e o Azure Cosmos DB

No Azure Cosmos DB, cada computador em que as partições são armazenadas é chamado de partição física. A partição física é semelhante a uma máquina virtual; uma unidade de computação dedicada ou um conjunto de recursos físicos. Cada partição armazenada nessa unidade de computação é chamada de partição lógica no Azure Cosmos DB. Se você já estiver familiarizado com o Apache Cassandra, poderá considerar as partições lógicas da mesma forma que considera partições normais no Cassandra.

O Apache Cassandra recomenda um limite de 100 MB no tamanho de dados que podem ser armazenados em uma partição. A API para Cassandra do Azure Cosmos DB permite até 20 GB por partição lógica e até 30 GB de dados por partição física. No Azure Cosmos DB, diferentemente do Apache Cassandra, a capacidade de computação disponível na partição física é expressa usando uma só métrica chamada unidades de solicitação, o que permite que você considere sua carga de trabalho em termos de solicitações (leituras ou gravações) por segundo, em vez de núcleos, memória ou IOPS. Isso pode tornar o planejamento da capacidade mais direto depois que você entende o custo de cada solicitação. Cada partição física pode ter até 10.000 RUs de computação disponíveis. Você pode aprender mais sobre as opções de escalabilidade lendo nosso artigo sobre escala elástica na API para Cassandra.

No Azure Cosmos DB, cada partição física consiste em um conjunto de réplicas com pelo menos quatro réplicas por partição. Isso é diferente do Apache Cassandra, em que é possível definir um fator de replicação de 1. No entanto, isso levará à baixa disponibilidade se o único nó com os dados ficar inativo. Na API para Cassandra, sempre há um fator de replicação de 4 (quorum de 3). O Azure Cosmos DB gerencia automaticamente conjuntos de réplicas, enquanto eles precisam ser mantidos usando várias ferramentas no Apache Cassandra.

O Apache Cassandra tem um conceito de tokens, que são hashes de chaves de partição. Os tokens são baseados em um hash murmur3 de 64 bytes, com valores variando de -2^63 a -2^63 - 1. Esse intervalo é conhecido como "token ring" no Apache Cassandra. O token ring é distribuído em intervalos de token, e esses intervalos são divididos entre os nós presentes em um cluster nativo do Apache Cassandra. O particionamento para Azure Cosmos DB é implementado de maneira semelhante, exceto pelo fato de que ele usa um algoritmo de hash diferente e tem um token ring interno maior. No entanto, externamente, expomos o mesmo intervalo de token que o Apache Cassandra, ou seja,-2^63 a-2^63-1.

Chave primária

Todas as tabelas na API para Cassandra devem ter um primary key definido. A sintaxe de uma chave primária é mostrada abaixo:

column_name cql_type_definition PRIMARY KEY

Suponha que queiramos criar uma tabela de usuário, que armazena mensagens para usuários diferentes:

CREATE TABLE uprofile.user ( 
   id UUID PRIMARY KEY, 
   user text,  
   message text);

Neste design, definimos o campo id como a chave primária. A chave primária funciona como o identificador para o registro na tabela e também é usada como a chave de partição no Azure Cosmos DB. Se a chave primária for definida no modo descrito anteriormente, haverá apenas um registro em cada partição. Isso resultará em uma distribuição perfeitamente horizontal e escalonável durante a gravação de dados no banco de dados e é ideal para casos de uso de pesquisa de valor de chave. O aplicativo deve fornecer a chave primária sempre que estiver lendo dados da tabela para maximizar o desempenho de leitura.

partições

Chave primária composta

O Apache Cassandra também tem um conceito de compound keys. Um primary key composto consiste em mais de uma coluna; a primeira coluna é o partition key e todas as colunas adicionais são as clustering keys. A sintaxe de uma compound primary key é mostrada abaixo:

PRIMARY KEY (partition_key_column_name, clustering_column_name [, ...])

Suponha que queiramos alterar o design acima e tornar possível recuperar mensagens com eficiência para um determinado usuário:

CREATE TABLE uprofile.user (
   user text,  
   id int, 
   message text, 
   PRIMARY KEY (user, id));

Neste design, agora estamos definindo user como a chave de partição e id como a chave de clustering. Você pode definir quantas chaves de clustering desejar, mas cada valor (ou uma combinação de valores) para a chave de clustering deve ser exclusivo para fazer com que vários registros sejam adicionados à mesma partição, por exemplo:

insert into uprofile.user (user, id, message) values ('theo', 1, 'hello');
insert into uprofile.user (user, id, message) values ('theo', 2, 'hello again');

Quando os dados são retornados, eles são classificados pela chave de clustering, conforme esperado no Apache Cassandra:

Captura de tela que mostra os dados retornados que são classificados pela chave de clustering.

Aviso

Ao consultar dados em uma tabela que tenha uma chave primária composta, se você quiser filtrar a chave de partição e outros campos não indexados, além da chave de clustering, adicione explicitamente um índice secundário à chave de partição:

CREATE INDEX ON uprofile.user (user);

Por padrão, o Azure Cosmos DB for Apache Cassandra não aplica índices a chaves de partição. Nesse cenário, no entanto, o índice pode melhorar significativamente o desempenho da consulta. Veja nosso artigo sobre indexação secundária para saber mais.

Com os dados modelados dessa forma, vários registros podem ser atribuídos a cada partição, agrupados por usuário. Assim, podemos emitir uma consulta que é roteada com eficiência pelo partition key (neste caso, user) para obter todas as mensagens para um determinado usuário.

Diagrama que mostra como vários registros podem ser atribuídos a cada partição, agrupados por usuário.

Chave de partição composta

As chaves de partição compostas funcionam essencialmente da mesma forma que as chaves compostas, exceto que você pode especificar várias colunas como uma chave de partição composta. A sintaxe das chaves de partição compostas é mostrada abaixo:

PRIMARY KEY (
   (partition_key_column_name[, ...]), 
    clustering_column_name [, ...]);

Por exemplo, você pode ter o seguinte, em que a combinação exclusiva de firstname e lastname formaria a chave de partição, e id é a chave de clustering:

CREATE TABLE uprofile.user ( 
   firstname text, 
   lastname text,
   id int,  
   message text, 
   PRIMARY KEY ((firstname, lastname), id) );

Próximas etapas