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...