O Cassandra é um banco de dados noSQL de arquitetura distribuída e seu armazenamento é configurável (híbrido). Desenvolvido na plataforma Java, possui API para as linguagens Ruby, Perl, Scala,Python e PHP.

Seu projeto foi iniciado pela equipe do Facebook e atualmente é mantido pelo Apache. Tem como seus principais cases de sucesso o Twitter, Facebook e o Digg.

Além disso, o Cassandra usa o modelo família de colunas, composto por keystore, supercoluna e coluna, como mostra a Figura 1.

Figura 1. Família de colunas

Os tipos de valores que possam ser inseridos nas colunas são:

  • BytesType: tipo simples pelo valor de byte. Nenhuma validação é executada;
  • AsciiType: parecido com o BytesType, mas confirma que a entrada pode ser analisado como US-ASCII;
  • UTF8Type: uma string codificada como UTF8;
  • LongType: um longo de 64bit;
  • LexicalUUIDType: um UUID de 128 bits, em comparação léxica (por valor byte);
  • TimeUUIDType: a versão 1 UUID de 128 bits, comparados por timestamp.

Nível de Consistência do Cassandra

Para garantir tolerância a falhas, os dados no Cassandra precisam ser replicados. O campo timestamp funciona como uma bússola verificando o campo mais atual entre as réplicas. De uma maneira geral, o comportamento de leitura e escrita do Cassandra pode ser definida por apenas três itens:

  • ONE(1) - Na escrita garante que o dado foi escrito em um commit loge, uma tabela de memória de, ao menos, uma réplica antes de responder ao cliente. Na leitura, o dado será retornado a partir do primeiro nó, onde a chave buscada foi encontrada. Essa prática pode resultar em dados antigos sendo retornados, porém, como cada leitura gera uma verificação de consistência em background, consultas subsequentes retornarão o valor correto do dado;
  • QUORUM(Q) - Na escrita garante que o dado foi escrito em N/2+1 réplicas. Na leitura retorna o valor mais recente lido de N/2+1 réplicas. As réplicas restantes são sincronizadas em background;
  • ALL(N) - Garante que operações de leitura e escrita envolverão todas as réplicas. Assim, qualquer nó que não responda às consultas fará as operações falharem.

As Tabela 1 e 2 demonstram os níveis de consistência de escrita e leitura, respectivamente.

Nível

Comportamento

ANY

Garantir que a gravação foi escrita para, pelo menos, 1 nó, incluindoosdestinatários.

ONE

Garantir que a gravação foi escrita a, pelo menos, 1 log de réplica cometer e tabela de memória antes de responder ao cliente.

QUORUM

Garantirque a gravação foi escrita para N / 2 + 1 réplicas antes deresponder ao cliente.

LOCAL_QUORUM

Garantir que a gravação foi escrita para / 2 + 1 nós dentro do datacenter local (requer NetworkTopologyStrategy)

EACH_QUORUM

Garantirque a gravação foi escrita para / 2 + 1 nós em cada datacenter (requer NetworkTopologyStrategy)

ALL

Garantirque a escrita é para todas as réplicas N antes de responder ao cliente. Qualquer réplica responder irá falhar aoperação.

Tabela 1. Escrita

Nível

Comportamento

ANY

Não suportado. Você provavelmente vai querer uma vez.

ONE

Retornaráo registro retornado pela primeira réplica para responder. Averificação de consistência é sempre feita em um thread em segundo plano para corrigir os problemas de consistência quandoConsistencyLevel.ONE é usado. Isto significa que chamadassubsequentes terão dados corretos mesmo que a leitura inicial seja um antigo valor. (Isso é chamado ReadRepair)

QUORUM

Irá consultar todas as réplicas e retornar o registro com o timestamp mais recente, desde que tenha pelo menos a maioria de réplicas (N/ 2 + 1) relatados. Novamente, as réplicas restantes serão verificadas em segundo plano.

LOCAL_QUORUM

Retorna o registro com o timestamp mais recente, desde que a maioria das réplicas dentro do datacenter locais tenham respondido.

EACH_QUORUM

Retorna o registro com o timestamp mais recente, desde que a maioria dasréplicas dentro de cada datacenter tenham respondido.

ALL

Irá consultar todas as réplicas e retornar o registro com o timestampmais recente, uma vez que todas as réplicas tenham respondido. Qualquer réplica que responder irá falhar a operação.

Tabela 2. Ler

Apresentado um pouco sobre o Cassandra, agora iniciaremos o processo de instalação e configuração dele.

Para iniciar, baixe-o no site do projeto - http://cassandra.apache.org/. Em seguida, basta descompactar e dar o seguinte comando dentro da pasta descompactada:

bin/cassandra -f

Figura 2. Instalação

O resultado da execução vemos na Figura 2.

Para executar o cliente dentro da pasta descompactada, execute o seguinte comando:

bin/cassandra-cli -host localhost 

Veremos a execução do mesmo na Figura 3.

Figura 3. Execução do cliente.

Referências:

  • Java Magazine nº 86 Introdução ao noSQL
  • http://escalabilidade.com/2010/03/08/introducao-ao-nosql-parte-i/
  • http://cassandra.apache.org/
  • http://horasdeocionerd.blogspot.com/2011/02/consistencia-dos-dados-no-cassandra.html