Quando um desenvolvedor pensa em um banco de dados imagina como será realizar queries e normalização. O tipo de BD NoSQL oferece uma opção além da convencional para armazenar informações. Por isso, o objetivo desse artigo é ajudar aquelas pessoas que pretendem utilizar o Cassandra, um tipo de banco NoSQL, fornecendo algumas dicas preciosas.
Saber quando utilizar a tecnologia
Antes de escolher uma tecnologia é muito importante entender bem o seu problema e em seguida entender como a tecnologia escolhida será útil em seu projeto. Assim, o Cassandra é um banco NoSQL e interessante quando se precisa de alta disponibilidade e tolerância a falhas. Possui uma escalabilidade linear, ou seja, quanto mais nós em seu datacenter, maior será o número de requisições por segundo.
O Cassandra não é relacional
Tentar simular o SQL dentro do Cassandra não é possível, pois ele foi feito em cima de um outro “paradigma” de persistência, o BASE. É muito importante entender que ao tentar realizar emulações de ACID dentro de um BASE não se conseguirá atingir nenhum dos objetivos.
Não existe normalização no Cassandra
Um erro muito comum é tentar realizar a normalização dentro do Cassandra. Isso não funcionará por conta do paradigma. O fato é que a normalização se tornou muito popular em 1970, quando o armazenamento era muito caro, assim o desafio era conter a informação de forma econômica e não repeti-la. Atualmente o armazenamento está ficando cada vez mais barato e o desafio mudou: agora é lidar, por exemplo, com um número de requisição cada vez maior (na casa dos milhões, talvez bilhões).
Hierarquia dentro do Cassandra
A hierarquia dos bancos relacionais segue esse fluxo: banco, tabela e coluna. No Cassandra acontece de forma semelhante, onde no topo temos o KeySpace, família de colunas e a coluna. Essa, por sua vez, é composta por um bloco com três informações: o nome do campo, o seu valor e o timestamp.
No Cassandra não existe transação
O Cassandra foi feito para trabalhar com uma alta taxa de disponibilidade, desse modo é inviável que exista transação. É possível enviar vários registros em uma mesma família de colunas ao mesmo tempo. Para saber qual versão é a mais recente ele utiliza o timestamp existente no campo, já que no momento que é inserido um campo ele recebe o timestamp daquele momento.
Nível de Consistência
O Cassandra trabalha em cima da replicação da informação para ter sua característica tolerante a falhas. Ao criar um keyspace setta, o fator de réplica é quem define a quantidade de nós na qual a informação será duplicada. Após isso, toda requisição, tanto escrita quanto leitura, é feita em cima do fator de réplica.
Ao enviar uma informação para o Cassandra é importante entender a diferença entre disponibilidade e consistência. Se ao realizar uma requisição for definido uma consistência alta, por exemplo, o ALL - que é o número de fator de réplica definido no momento da criação/alteração do keyspace - o processo só será finalizado quando enviar para todos os nós definido. Diferente de um nível baixo, como o ONE, que enviará a solicitação para apenas um nó, deixando os outros nós prontos para trabalharem em outras requisições, realizando a réplica em background, elevando assim o nível de disponibilidade.
Não existe relacionamento
Uma boa prática para usar o Cassandra é desnormalizando sua base: desse modo, não existem relacionamentos. Se, por exemplo, você tem duas tabelas (pessoa e endereço) em uma relação um para um, no Cassandra o mais correto seria uma família de colunas contendo as duas informações (mesmo que existam duas que tenham o mesmo endereço e replique a informação).
Busque informações pela chave
O uso de um campo auto-increment como chave no Banco de dados deve ser evitado, pois dentro do Cassandra, por padrão, o único campo no qual se pode buscar informações é a chave. Caso você queria adicionar mais campos “buscáveis” basta defini-los como índice, mas isso não é bom por questão de performance. No caso de uma tabela pessoa, a chave poderia ser o cpf ou o nickname.
O único campo obrigatório é a chave
No Cassandra o único campo obrigatório é a chave, desse modo, podem existir registros com 10, 20, 100, ou nenhuma coluna, desde que o mesmo possua uma chave. Os campos são criados por demanda, por exemplo, se um registro não tiver o campo “telefone” o mesmo não existirá, diferentemente de um banco relacional, em que a coluna existe para todos os registros com o valor null.
Não existe Constraints
O constraints, muito utilizados para regras dos seus dados, não existem dentro do Cassandra. Pode parecer estranho para alguns, mas atualmente tal recurso se torna desnecessário. Não é muito comum, por exemplo, colocar para o usuário a mesma mensagem de erro que o banco retornou, como o: “there is no unique constraint matching given keys for referenced table "tec_configurations"” ou “null value in column "pessoa_nome" violates not-null constraint” e sim “nickname já cadastrado” e “campo nome obrigatório”. Outro exemplo é no caso de inserção da mesma informação duas vezes com um insert: vai funcionar normalmente, já que a informação é apenas colocada lá e caso ela já exista, será sobrescrita.
Views materializadas
Em alguns momentos precisamos realizar cálculos em uma aplicação (somatório, média, etc.). Imaginando um sistema que mede a temperatura de uma determinada cidade e os sensores enviam informação a cada milissegundo pode-se deixar essa informação pré-processada em uma família de colunas, muito semelhante as view materializadas nos bancos relacionais. Esse recurso é muito utilizado e é muito comum, mas o ideal é que sua modelagem seja feita de acordo com sua busca. No caso do sistema de temperatura podemos ter uma família de colunas para média por dia, mês e ano, a fim de acompanhar o histórico das temperaturas em uma cidade.
Sua aplicação também precisa escalar
Não adianta ter um banco escalável preparado para receber mil requisições por segundo, se sua aplicação envia apenas ua requisição por segundo. Desse modo é importante entender que sua aplicação também precisa escalar.
Cassandra Query Language
Para facilitar a vida do desenvolvedor existe o Cassandra Query Language (CQL), com o qual podemos criar e modificar estruturas e realizar manipulações de dados de uma maneira mais tranquila e muito mais fácil. O interessante é que esse recurso possui uma sintaxe muito semelhante ao SQL. Para executar e verificar os CQLs usamos o DataStax DevCenter, que possui sua interface baseada no framework Eclipse.
Coleções muitos grandes
Recentemente o banco pode fazer uso de três coleções: o list (uma lista de informações), o set (uma lista sem valor duplicado) e um map (um dicionário de dados que possui um valor para uma chave correspondente). Esse recurso é muito interessante e muito utilizado, mas tome cuidado para que essas coleções não sejam muito grandes. O interessante é que ela não deve ultrapassar dos 260KB.
Acompanhe seus nós
É interessante acompanhar a performance e a topologia do seu datacenter. Na configuração o recomendado é que o commitlog e o sstable estejam em discos diferentes e que esses sejam SSDs. Outra dica importante é ter cuidado com o tamanho do heap, pois na maioria dos casos o padrão resolverá (é feito um cálculo de heap baseado em memória disponível). Caso modifique, o recomendado é que não ultrapasse os 8GB. Uma solução para acompanhar seus nós é o DataStax OpsCenter.
Assim, concluímos esse pequeno artigo em que foram demonstradas algumas dicas inicias para os usuários do Cassandra. É muito comum tentar simular o SQL dentro do Cassandra, mas isso tenderá a ter consequências desastrosas. o do Cassandra, tenderá a ter consequências desastrosas.
Links:
http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
http://www.slideshare.net/mattdennis
