Ao
se pensar em um banco de dados a primeira coisa que um desenvolvedor
de software pensa é em realizar buscas, queries, realizar a
normalização. Mesmo depois de tanto tempo com várias discussões
com NOSQL, muitas pessoas ainda acreditam que o NOSQL, mas vale
lembrar que muitas coisas mudaram no mundo do desenvolvimento de
software e isso inclui os bancos de dados, existem muitas soluções
além da convencional para armazenar informações. O objetivo desse
artigo é discutir é ajudar aquelas pessoas que pretendem ao
utilizam o Cassandra em pouco tempo fornecendo algumas dicas.
Saber
quando utilizar a tecnologia: Antes de escolher uma tecnologia é
muito importante entender bem o seu problema e em seguida entender o
motivo no qual a tecnologia escolhida será útil em seu projeto. Com
o Cassandra não é diferente, ele é um banco NOSQL é interessante
seu uso quando se precisa de uma alta disponibilidade e tolerância a
falhas (seria o A e o P no teorema do CAP). 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: Uma coisa muito comum das pessoas ao
aprender uma nova tecnologia é tentar realizar relações com a
técnologia já conhecida, o problema é que em alguns casos os estudantes ultrapassam o estudo e tentam simular o SQL dentro do
Cassandra. O Cassandra 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 (O erro ficará oculto com uma massa
pequena, mas quando for para produção com uma grande massa o erro
será desastroso).
Não
existe normalização no Cassandra: Um erro muito comum dentro do
Cassandra é tentar realizar a normalização. Como já dito
anteriormente o Cassandra foi feito em cima de outro 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, dessa forma não repeti-la.
Atualmente o armazenamento está ficando cada vez mais barato e o
desafio mudou: É lidar, por exemplo, com um número de requisição
cada vez maior (milhões, talvez bilhões).
Hierarquia
dentro do Cassandra: A hierarquia dos bancos relacionais segue o
seguinte fluxo: banco, tabela e coluna. No Cassandra acontece de
forma semelhante no topo temos o KeySpace, família de colunas, e a
coluna, esse por sua vez é composto por um bloco com três
informações: O nome do tampo, o valor do campo 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 coluna ao mesmo tempo. Para saber
qual versão é a mais recente ele utiliza o timestamp existente no
campo, acontece que quando um campo é inserido, ele recebe o timestamp
do momento que foi inserido.
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 se
criar um keyspace setta o fator de réplica, que 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 defina 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 de 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 coluna contendo as duas tabelas, mesmo
que existam duas possas que tenham o mesmo endereço, replicando o endereço.
Busque
informações pela chave: O uso de um campo auto-increment como
chave no Banco de dados deve ser evitado. 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-lo como índice, mas se deve evitar 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, se um registro não tiver o
campo “telefone”, por exemplo, ele de fato não existirá, diferente do
banco relacional em que a coluna existe para todos os registros com o
valor null.
Não
existe Constraints: O constraints muito utilizado para regras dos
seus dados não existem dentro do Cassandra, pode parecer estranho
para alguns, mas atualmente tal recurso não 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”, ou seja, as regras já estão dentro do seu
software. Outro exemplo, caso se insira, utilizando um insert, a
mesma informação duas vezes, vai funcionar normalmente já que a
informação é apenas colocada lá, 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
preprocessada em uma família de colunas, muito semelhante as view
materializadas nos bancos relacionais. Esse recurso é muito
utilizado, é muito comum se ter várias famílias de colunas como
estas, o ideal é que sua modelagem seja feita de acordo com sua
busca. No caso do sistema de temperatura se pode ter uma família de
colunas para média por dia, mês e ano, para acompanhar o histórico
de temperatura de 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 1 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, o CQL. Com ele é possível 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 se pode usar o DataStax DevCenter que
possui sua interface baseada no eclipse.
Coleções
muitos grandes: Um recurso que entrou recentemente no banco é o
uso de três coleções: o list (uma lista de informações), o set
(uma lsita sem valor duplicado), e um map (um dicionário de dados,
possui um valor para uma chave correspondente). Esse recurso é muito
interessante e é importante utilizado, mas tome cuidado para que
essas coleções não sejam muito grandes. O interessante é que ela
no geral não ultrapassagem 260KB ou 75KB.
Acompanhe
seus nós: É interessante acompanhar a performance, topologia do
seu datacenter. Na configuração o recomendado é que o commitlog e
o sstable estejam em discos diferentes e que esses discos sejam SSDs.
Outra dica importante é ter cuidado com o tamanho do heap na maioria
dos casos o padrão resolverá (é feito um calculo 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.
Concluindo,
nesse pequeno artigo foi demonstrado algumas dicas inicias para os
usuários do Cassandra, demonstrando que é muito comum tentar
simular o SQL dentro do Cassandra, tenderá a ter consequências
desastrosas.
Links:
Nenhum comentário:
Postar um comentário