Respondendo às perguntas frequentes do Apache Cassandra

Desde que foi desenvolvido em 2007, o Apache Cassandra construiu uma reputação como um armazenamento de dados NoSQL sólido, altamente escalável e confiável usado por algumas das maiores empresas do mundo. Mas também é preciso um certo nível de experiência e conhecimento para trabalhar com Cassandra. Portanto, é compreensível que surjam muitas perguntas ao aprender sobre esse banco de dados de código aberto.

Este artigo aborda algumas das principais perguntas que os desenvolvedores fazem em vários fóruns da comunidade.

Qual é a diferença entre partição, clustering e chaves compostas no Cassandra?

Compreender como a chave primária em bancos de dados de colunas largas é diferente das chaves primárias relacionais é uma etapa crítica para aprender a usar o poder de Cassandra.

Lojas de colunas largas como Cassandra usam a noção de famílias de colunas, um objeto de banco de dados que contém várias colunas de dados relacionados que são usados juntos, semelhante às tabelas de banco de dados relacionais tradicionais. Dentro de uma determinada família de colunas, todos os dados são armazenados linha por linha, de forma que as colunas de uma determinada linha sejam armazenadas juntas, em vez de cada coluna ser armazenada separadamente.

Dito de outra forma, uma família de colunas é um par chave-valor, onde a chave é mapeada para um valor que é um conjunto de colunas. Para fazer uma analogia com bancos de dados relacionais, uma família de colunas é como uma “tabela”, com cada par chave-valor sendo uma “linha”. Para desenvolvedores, as tabelas de colunas largas podem se apresentar como uma tabela de linha e coluna que é familiar e fácil de trabalhar, no código ou por meio de APIs.

Vejamos alguns códigos de exemplo para ajudar a dar vida aos conceitos.

No código acima, temos um keyspace, alguns campos como “cidade”, “sobrenome” e “primeiro nome”. A chave primária está na parte inferior. A propósito, todas as tabelas no Cassandra devem incluir pelo menos uma chave de partição. No exemplo destacado pela imagem acima, iremos particionar por “cidade”.

Qualquer outra coisa que segue é uma coluna de cluster. Observe os parênteses ao redor de “cidade” — isso indica que esta é a chave de partição. Usamos os parênteses para indicar qual é a chave de partição, caso sua chave de partição seja composta e tenha mais de uma coluna. Então fica claro quais colunas são para chaves primárias e quais são colunas de agrupamento.

O principal objetivo da chave primária é garantir que uma linha seja única. Ele também pode conter zero ou mais colunas de agrupamento, que podem controlar a classificação. Mas a chave primária também pode ser “composta” ou “composta”, o que significa que possui duas ou mais colunas.

A chave de partição é usada para particionar nossas linhas e possui uma ou mais colunas.

Como o Cassandra encontra o nó que contém os dados que desejo?

Algumas pessoas parecem pensar que os clientes do driver apenas enviam dados para um nó aleatório. Mas há realmente uma maneira não aleatória de seu driver escolher um nó para conversar. Este nó é chamado de nó coordenador. É normalmente escolhido porque é o mais próximo.

As solicitações do cliente podem ser enviadas para qualquer nó — e primeiro elas são enviadas para os nós que seu driver conhece. Mas uma vez que o software do driver se conecta e entende a topologia do seu cluster, ele pode mudar para um coordenador mais próximo. Confira o projeto de ecossistema de código aberto Stargate para saber como computação e armazenamento podem ser separados para escalabilidade.

Os nós em um cluster Cassandra de software livre trocam informações de topologia entre si usando o protocolo gossip. O fofoqueiro é executado a cada segundo e garante que todos os nós sejam mantidos atualizados com os dados de qualquer informante que você tenha configurado. O snitch rastreia a quais centros de dados e racks cada nó pertence. Dessa forma, o nó coordenador também possui dados sobre quais nós são responsáveis por cada faixa de token.

Você pode ver essas informações executando uma ferramenta de nó “anel” na linha de comando, embora se estiver usando nós virtuais ou “vnodes”, será um pouco mais complicado verificar como dados em todos os 256 nós virtuais (o padrão quantidade) piscará rapidamente na tela.

Em K8ssandra.io , esse comportamento é mais nativo do Kubernetes e o Etcd é usado em vez do protocolo Gossip para propagar metadados de cluster, bem como atualizações de esquema seguras.

Como funcionam os índices secundários no Cassandra?

A indexação é bastante sutil. Isso ajuda a entender os componentes internos do banco de dados. Como essa consulta funcionaria internamente no Cassandra? Dê uma olhada neste código de exemplo:

Como essa consulta funcionaria internamente no Cassandra?

Essencialmente, todos os dados da partição com ID de escopo igual a 35 e ID de formulário igual a 78005 seriam retornados e, em seguida, seriam filtrados pelo índice de ID do link de registro. Ele procurará ou a entrada de ID de índice de registro para 9897 e tentará corresponder às entradas que correspondem às linhas retornadas onde ID de escopo é igual a 35 e ID de formulário é igual a 78005. A interseção das linhas para as chaves de partição e as chaves de índice serão retornadas .

Você pode perguntar se uma coluna de alta cardinalidade, como o índice de ID do link de registro, afetaria o desempenho da consulta para isso. Índices de alta cardinalidade criam essencialmente uma linha para quase cada entrada na tabela principal. O desempenho pode ser afetado porque Cassandra é projetado para leituras sequenciais para resultados de consulta. Uma consulta de índice basicamente força o Cassandra a realizar leituras aleatórias à medida que a cardinalidade do seu índice aumenta, assim como o tempo que leva para encontrar o valor consultado.

Então, Cassandra tocaria em todos os nós da consulta acima? Não, ele deve tocar apenas em um nó responsável por esse ID de escopo igual a 35 e esse ID de formulário igual a 78005 partição. Os índices, da mesma forma, são armazenados localmente e contêm apenas entradas válidas para o nó local.

Qual é a diferença entre Cassandra e DataStax Astra DB?

Cassandra é um banco de dados NoSQL de software livre que alimenta os aplicativos distribuídos que você provavelmente usa todos os dias, em grande escala. No entanto, cabe a você e sua equipe se autogerenciar.

O Astra DB , por outro lado, é um banco de dados como serviço sem servidor. É um serviço de nuvem totalmente gerenciado e com dimensionamento automático criado no Cassandra e executado em um provedor de nuvem pública de sua escolha.

Com a adição do gateway de API de dados de código aberto Stargate , o Cassandra e o Astra DB atendem a cargas de trabalho NoSQL de documento, colunar e valor-chave. E com o Astra DB, o Stargate é configurado automaticamente para você.

Quer saber mais sobre Cassandra? Junte-se a nós no Cassandra Forward , um evento digital gratuito em 14 de março!