Criação de partições no Azure Cosmos DB para Apache Cassandra

  • Artigo

APLICA-SE A: Cassandra

Este artigo descreve como funciona a criação de partições no Azure Cosmos DB para Apache Cassandra.

A API para Cassandra utiliza a criação de partições para dimensionar as tabelas individuais num espaço de chaves para satisfazer as necessidades de desempenho da sua aplicação. As partições são formadas com base no valor de uma chave de partição que está associada a cada registo numa tabela. Todos os registos numa partição têm o mesmo valor de chave de partição. O Azure Cosmos DB gere de forma transparente e automática a colocação de partições nos recursos físicos para satisfazer eficazmente as necessidades de escalabilidade e desempenho da tabela. À medida que os requisitos de débito e armazenamento de uma aplicação aumentam, o Azure Cosmos DB move e equilibra os dados num maior número de máquinas físicas.

Do ponto de vista do programador, a criação de partições comporta-se da mesma forma para o Azure Cosmos DB para Apache Cassandra, tal como acontece no Apache Cassandra nativo. No entanto, existem algumas diferenças nos bastidores.

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

No Azure Cosmos DB, cada máquina na qual as partições são armazenadas é denominada 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 nesta unidade de computação é referida como uma partição lógica no Azure Cosmos DB. Se já estiver familiarizado com o Apache Cassandra, pode pensar nas partições lógicas da mesma forma que pensa nas partições normais no Cassandra.

O Apache Cassandra recomenda um limite de 100 MB no tamanho de dados que podem ser armazenados numa partição. A API para Cassandra para o 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, ao contrário do Apache Cassandra, a capacidade de computação disponível na partição física é expressa através de uma única métrica denominada unidades de pedido, que lhe permite pensar na sua carga de trabalho em termos de pedidos (leituras ou escritas) por segundo, em vez de núcleos, memória ou IOPS. Isto pode tornar o planeamento de capacidade mais simples, assim que compreender o custo de cada pedido. Cada partição física pode ter até 10 000 RUs de computação disponíveis. Pode saber mais sobre as opções de escalabilidade ao ler o nosso artigo sobre dimensionamento elástico na API para Cassandra.

No Azure Cosmos DB, cada partição física consiste num conjunto de réplicas, também conhecido como conjuntos de réplicas, com pelo menos 4 réplicas por partição. Isto contrasta com o Apache Cassandra, onde é possível definir um fator de replicação de 1. No entanto, isto origina uma baixa disponibilidade se o único nó com os dados ficar inativo. Na API para Cassandra, existe sempre um fator de replicação de 4 (quórum de 3). O Azure Cosmos DB gere automaticamente conjuntos de réplicas, enquanto estes têm de ser mantidos com 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 baseiam-se num hash murmur3 de 64 bytes, com valores que variam entre -2^63 e -2^63 - 1. Normalmente, este intervalo é denominado "token ring" no Apache Cassandra. A cadência de tokens é distribuída em intervalos de tokens e estes intervalos estão divididos entre os nós presentes num cluster nativo do Apache Cassandra. A criação de partições do Azure Cosmos DB é implementada de forma semelhante, exceto que utiliza um algoritmo hash diferente e tem um token ring interno maior. No entanto, vamos expor externamente o mesmo intervalo de tokens que o Apache Cassandra, ou seja, -2^63 a -2^63 - 1.

Chave primária

Todas as tabelas na API para Cassandra têm de ter uma primary key definida. A sintaxe de uma chave primária é apresentada abaixo:

column_name cql_type_definition PRIMARY KEY

Suponha que queremos criar uma tabela de utilizador, que armazena mensagens para diferentes utilizadores:

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

Nesta estrutura, definimos o id campo como a chave primária. A chave primária funciona como o identificador do registo na tabela e também é utilizada como a chave de partição no Azure Cosmos DB. Se a chave primária for definida da forma descrita anteriormente, haverá apenas um único registo em cada partição. Isto resultará numa distribuição perfeitamente horizontal e dimensionável ao escrever dados na base de dados e é ideal para casos de utilização de pesquisa de chave-valor. A aplicação deve fornecer a chave primária sempre que ler 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 composto primary key consiste em mais do que uma coluna; a primeira coluna é a partition key, e todas as colunas adicionais são .clustering keys A sintaxe de um compound primary key é apresentada abaixo:

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

Suponha que queremos alterar a estrutura acima e tornar possível obter mensagens de forma eficiente para um determinado utilizador:

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

Neste design, estamos agora a definir user como a chave de partição e id como a chave de clustering. Pode definir quantas chaves de clustering quiser, mas cada valor (ou uma combinação de valores) para a chave de clustering tem de ser exclusivo para resultar na adição de vários registos à 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 devolvidos, são ordenados pela chave de clustering, conforme esperado no Apache Cassandra:

Captura de ecrã que mostra os dados devolvidos ordenados pela chave de clustering.

Aviso

Ao consultar dados numa tabela que tenha uma chave primária composta, se quiser filtrar a chave de partição e quaisquer outros campos não indexados além da chave de clustering, certifique-se de que adiciona explicitamente um índice secundário na chave de partição:

CREATE INDEX ON uprofile.user (user);

O Azure Cosmos DB para Apache Cassandra não aplica índices a chaves de partição por predefinição e o índice neste cenário pode melhorar significativamente o desempenho das consultas. Veja o nosso artigo sobre indexação secundária para obter mais informações.

Com os dados modelados desta forma, podem ser atribuídos vários registos a cada partição, agrupados por utilizador. Assim, podemos emitir uma consulta que é encaminhada de forma eficiente pelo partition key (neste caso, user) para obter todas as mensagens de um determinado utilizador.

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

Chave de partição composta

As chaves de partição compostas funcionam essencialmente da mesma forma que as chaves compostas, exceto que pode especificar múltiplas colunas como uma chave de partição composta. A sintaxe das chaves de partição compostas é apresentada abaixo:

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

Por exemplo, pode ter o seguinte, em que a combinação exclusiva de e lastname formaria a chave de firstname 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) );

Passos seguintes