O seguinte problema apareceu durante execução do Cassandra em minha máquina Fedora Core 13:
[root@caravela apache-cassandra-0.7.0]# bin/cassandra [root@caravela apache-cassandra-0.7.0]# Error occurred during initialization of VM The size of the object heap + VM data exceeds the maximum representable size
Após experimentar com dezenas de valores para o heap size da VM através de
export JVM_OPTS=”-Xmx512M”
desistí e fui atrás do script de inicialização do cassandra. Notei que ele configura o ambiente de execução através do script:
conf/cassandra-env.sh
Editei este arquivo, reduzindo o tamanho da heap para um Gigabyte, descomentando da linha
MAX_HEAP_SIZE=”1G”
E pronto!
bin/cassandra -f e Cassandra está online!
Cassandra é um sistema de banco de dados distribuido baseado no modelo BigTable do Google e no sistema de armazenamento Dynamo, da Amazon.com. Foi desenvolvido internamente no Facebook, empresa que contribuiu o sistema de volta para a comunidade Open Source através da fundação Apache. O projeto tornou-se “top level” na Apache e hoje é utilizado por dezenas de gigantes online, entre eles o Reddit, Digg e o próprio Facebook.
O principal diferencial do Cassandra para bancos de dados relacioais como MySQL, PgSQL, Oracle e DB2 está no fato dele não utilizar a linguagem SQL para modelar, alterar e recuperar dados. É o que vem sendo chamado “banco de dados NoSQL”.
Sua principal função é garantir fácil distribuição de dados e de carga no servidor. Apenas acrescentando máquinas e inicializando o Cassandra com algumas configurações básicas, é possível criar um cluster de banco de dados distribuido. De fato, a configuração necessária para criar um cluster é mínima, conforme veremos em artigos futuros. Após criar um cluster, basta acessar, inserir ou modificar dados em qualquer instância da rede e, eventualmente, os dados serão replicados para todos os outros participantes do cluster. Há um pequeno delay nessa sincronização, por isso o Cassandra é uma base de dados distribuida e “eventualmente consistente”.
Refiro-me ao projeto Cassandra, ao banco de dados Cassandra e, em geral, ao sistema Cassandra. A Cassandra, da mitologia Grega, não é citada neste artigo!
Provavelmente, sim. Cassandra é escrito em Java e deverá funcionar, com mínimas adaptações, em qualquer sistema operacional que possua uma VM.
Acesse a página do Cassandra no portal Apache, baixe a última versão disponível no quadro de download.
Basta extrair o pacote em um diretório qualquer e rodar bin/cassandra -f. Recomendo a opção -f para inciantes, de modo que o processo permaneça no console e o log seja mostrado na tela.
Assim que apertar ENTER, o Cassandra estará rodando na máquina local(cluster de uma máquina só). Utilize os exemplos em Cassandra CLI para criar e ler seus primeiros dados no banco.
Dados inseridos, alterados ou removidos em qualquer das instâncias Cassandra no cluster são eventualmente replicados para todos os outros. Em determinados pontos no tempo todos os nodes estarão sincronizados, e a base de dados então estará consistente. O termo “eventualmente consistente” realça o fato da replicação para uma grande quantidade de nodos exigir uma estratégia de replicação, e um tempo mínimo para executar essa estratégia.
O termo “NoSQL” foi recentemente cunhado para designar os bancos de dados que não utilizam a linguagem SQL em sua administração e na manipulação de dados.
Sim. Migrações para sistemas NoSQL em geral, não apenas para o Cassandra, tem se revelado extremamente trabalhosas. O recente caso da reformulação do portal Digg.com é um exemplo relevante disso. Após ser relançado, o Digg.com enfrentou incontáveis problemas com a nova base de dados e permaneceu bastante tempo instável, sendo considerado, um enorme fracasso devido à enorme perda de usuários para o Reddit.
Sistemas devem ser arquitetados para utilizar bases NoSQL, em especial levando em consideração a ausência de schema formal de dados e lembrando sempre das limitações de bases de dados do tipo chave -> valor(mongoDB, memcacheDB e Cassandra, por exemplo).
Cassandra não utiliza SQL, pode possuir diversas instâncias de dados em uma só linha(quebrando o modelo relacional) e possui apenas um tipo de dados: binário. Tudo que é armazenado em um banco Cassandra deve ser serializado e armazenado como uma cadeia de bytes. Tanto as chaves, quanto os valores de dados, são apenas cadeias de bytes. O tratamento de campos especializados como horas, datas, identities e relações entre chaves em geral deve ser feito em nível de aplicação.
Não há views, triggers e stored procedures no Cassandra, o usuário deve programar a lógica completa da aplicação. O Cassandra é apenas um “data store”. Sendo baseado em modelo de chave->valor, é possível utilizar o Cassandra como banco relacional, desde que o desenvolvedor crie a lógica de negócios de modo que só exista um valor por linha(o que Cassandra permite quebrar) e tenha controle de suas próprias chaves primárias e externas. Ou seja, ao pé da letra, Cassandra não fornece mecanismos relacionais.
Cassandra deve ser empregado onde seja exigida replicação em massa de dados(clusters com inúmeros nodes), sites com pesada carga encima do banco de dados e uma tendência a mais leitures que escritas, pois a inserção de dados no Cassandra é uma operação lenta e computacionalmente custosa, devido ao armazenamento ordenado de dados.
O Cassandra tem sido empregado na WWW devido à sua natureza distribuida, permitindo acrescentar dezenas, centenas, de máquinas a um portal, e a carga é automaticamente distribuida entre os componentes do cluster que se forma automaticamente(com mínima configuração).
Conforme já foi citado, o processo de inserção de dados no Cassandra é bastante lento, devido à forma como os dados são armazenados, sempre em ordem. Não há implementações nativas do Cassandra, ele é um banco totalmente escrito em Java e necessita de uma máquina virtual para sua execução.
Atualmente na versão 0.7, Cassandra vem mudando com frequência. Aplicações que exijam um banco mais estável devem aguardar futuras versões, pós 1.0, para migrar. Sites como Facebook e Reddit, apesar de muito acessados, não oferecem qualquer garantia de integridade dos dados enviados por usuários. Fotos podem se perder do Facebook, noticias podem desaparecer do Reddit, sem qualquer risco jurídico para esses portais. Empresas como bancos e hospitais, e aplicações que exigem maior maturidade de seus sistemas de bancos de dados, devem aguardar desenvolvimentos futuros. Vale ressaltar que o Cassandra é muito estável para sua idade, porém ainda é muito “verde” quando comparado a sistemas como IBM DB2 e Oracle.
O Cassandra é um banco que já nasce com o apoio de gigantes da WWW. A performance no Reddit e no Digg.com demonstram que o banco está pronto para grandes demandas de carga. Apesar de um pouco imaturo, o sistema Cassandra tem tudo para tornar-se o banco NoSQL mais popular no futuro próximo. O fato de ser um projeto Top Level na Fundação Apache confere credibilidade ao mesmo, e nos permite pressupor o desenvolvimento ativo do código fonte.
Com a adoção em populares portais WWW, a comunidade criada em torno do Cassandra cresce rapidamente, tornando o suporte técnico via comunidade cada vez mais acessível. Com o crescimento na base de usuários, falhas e bugs são encontrados e corrigidos com maior agilidade.
Vale a pena estudar o modelo de dados Cassandra pois este banco tem tudo para tornar-se muito popular no futuro. As tecnologias Google e Amazon.com utilizadas no Cassandra vieram para ficar, portanto é um aprendizado que não será desperdiçado.
Há pouco material sobre o Cassandra em Português, portanto os links relacionados são praticamente todos em Inglês.
Home Page na Apache
Tipos de Dados no Cassandra
Introdução ao Modelo de Dados Cassandra
Mais um tutorial sobre o modelo de dados Cassandra