Desenvolvido inicialmente pelo
Facebook como open source em 2008, cujo objetivo foi ampliar o universo de instalação MySQL, o
Cassandra exerce com excelência a função de repositório de dados. Leve e desenvolvido na plataforma Java, ele não apresenta a sobrecarga de recurso do banco de dados convencionais. Atualmente o projeto é baseado na tecnologia emergente
NoSQL e encontra-se incubado pela Fundação Apache.
Com poucos minutos de pesquisa na internet, é possível encontrar testes realizados por diversos segmentos demonstrando confiabilidade, escalabilidade e fácil gerenciamento. Atualmente o
Twitter apresenta uma massa crítica e pesada baseada no seu monstruoso crescimento atrelado a escala temporal, sendo assim, este cenário é um excelente "caso de sucesso" para o
Apache Cassandra.
Instalei o projeto Apache Cassandra e veremos na próxima página, passo-a-passo como fazê-lo sem trauma algum. NoSQL conta com sua maior aplicação atual: 100 terabytes de dados e 150 servidores (uma base consideravelmente grande). Diversas APIs de acesso proporcionam o seu uso de forma muito simples (Ruby, Perl, Scala, Python, PHP e Java).
O Digg usa o Cassandra, o Facebook (desenvolvedor original) e agora o Twitter. Isto demonstra que a desnormalização de dados não é um problema onde geralmente leva-se em conta ao custo do espaço em disco. O vasto campo do NoSQL está gerando grandes interesses, e as sua técnicas estão colocando em evidências os bancos de dados NoSQL.
O texto a seguir foi extraído do post do blog globalcoder e ilustra bem o atual polêmico cenário:
"Escalabilidade é um tema bastante complexo e armazenamento e processamento de grandes volumes de dados são focos de pesquisas que estão bem aquecidas hoje em dia. Um dos mais ativos movimentos nesta linha está tomando forma, encorpando e sendo batizado. Chama-se NoSQL. Em um livro recém lançado intitulado 'Hadoop: The Definitive Guide' (escrito por Tom White) há uma passagem digna de nota (em uma tradução livre):
Este é o resumo de como a história acerca de escalabilidade no uso de um banco de dados relacional se desenrola. A seguinte lista assume uma aplicação de sucesso, de demanda crescente.
Lançamento ao público inicial:
Cópia da instância MySQL de desenvolvimento para o ambiente de produção, compartilhado e remoto, tendo um esquema de dados bem definido.
A aplicação se torna mais popular; requisições demasiadas de leitura atingindo o banco de dados:
Adiciona-se "memcached" ao sistema para que as requisições mais comuns se mantenham em memória. As leituras ao banco de dados não são mais estritamente ACID; dados armazenados em memória devem ser invalidados por algum mecanismo.
A aplicação continua com crescente demanda; requisições demasiadas de escrita atingindo o banco de dados:
Escala-se verticalmente o MySQL através da atualização de hardware do servidor com 16 núcleos, 128 GB de RAM e bancos de discos rígidos com 15000 RPMs. Oneroso.
Novos recursos implementados no sistema aumentam a complexidade das consultas SQL; agora temos muitos "joins":
Desnormalização dos dados para reduzir "joins" (isto não é o que eles ensinam na escola para DBA).
Demanda da aplicação cresce e derruba o servidor; tudo está muito lento:
Para-se com qualquer processamento no lado do servidor.
Algumas consultas ainda estão lentas:
Cria-se periodicamente "views" materializadas das consultas mais complexas, tenta-se eliminar "joins" na maioria dos casos.
Leituras estão aceitáveis mas escritas estão cada vez mais lentas e lentas:
Elimina-se índices secundários e "triggers"! Sem índices? ...
Quantos de nós estamos envolvidos com sistemas que estão nesta rota? Será mesmo que nossas aplicações nunca atingirão tais níveis?"
Texto extraído de:
http://blog.globalcode.com.br/
Bom, agora chega de blá, blá, blá e partiremos para o que realmente interessa, a mão na massa...