Cassandra: Prevendo o Futuro do NoSQL

Quando o Twitter anunciou algumas semanas atrás que não utilizaria o Cassandra para o armazenamento de tweets, houve uma onda de “eu avisei” dos céticos de NoSQL. Mas até onde deve ir essa onda ? Isso de alguma maneira desmerece o esforço envolvido na tecnologia que movimenta o grafo social do Facebook?

SQL RDBMS BBQ

O SQL e os bancos de dados relacionais têm sido a solução padrão para o armazenamento e recuperação de dados por anos a fio. Mas novas aplicações web que estão sendo construídas hoje em dia não necessariamente se encaixam neste velho esquema. Existem novas demandas de bases de dados, e não simplesmente em termos de escalabilidade, mas também em termos de disponibilidade e de imprevisibilidade. Em resposta, algumas novas bases de dados têm sido desenvolvidas e categorizadas como NoSQL.

Embora o nome soe como um repúdio ao SQL, não significa “No SQL.” Significa “not only (não só) SQL,” e oferece uma medida mais orientada e flexível para o gerenciamento de banco de dados.

NoSQL OMG

Em uma grande síntese do movimento NoSQL no blog Heroku, Adam Wiggins nos dá os seguintes exemplos de uso do NoSQL:

Dados estatísticos, frequentemente escritos mas raramente lidos (por exemplo, um contador de hits na web), devem usar um modelo chave/valor como o Redis, ou um modelo de documento como o MongoDB.

Big Data (como estatísticas meteorológicas ou analytics de negócios, Business intelligence) funcionam melhor de uma forma livre, em sistemas distribuídos utilizando Hadoop.

Binários (como MP3s e PDFs) são melhores acomodados em um armazenamento de dados que pode servir diretamente para o navegador do usuário, como a Amazon S3.

Dados transientes (como sessões web, bloqueios, ou estatísticas de curto prazo) devem ser mantidos em um armazenamento de dados transitórios como Memcache.

Se você precisa reproduzir o conjunto de dados em vários locais (como a sincronização de um banco de dados de música entre um aplicativo web e um dispositivo móvel), você vai querer os recursos de replicação do CouchDB.

Aplicativos de alta disponibilidade, onde a minimização da inatividade é fundamental, você encontra uma grande utilidade nos datastores de configuração redundante e clusters automáticos como o Cassandra e o Riak.

Querendo Enganar a Quem?

Em um artigo recente sobre NoSQL no SD Times, o analista da Forrester, Mike Gualtieri, disse que bancos NoSQL “não são um substituto para os banco de dados tradicionais; ele pode extender seus banco de dados SQL. Mas para as principais operações, você ainda precisará de um banco de dados SQL.

Porém, dependendo do grau de integridade necessário para suas operações adicionais, NoSQL pode ser uma ótima maneira de armazenar todos os dados extras.” Esse tipo de abordagem cautelosa – “utilize o NoSQL para dados extras” mas use o SQL para os “dados reais” – é muito comum.

Isso faz com que as pessoas dêem pequenos passos para a implementação do NoSQL. “Não migre seus dados de produção existentes,” sugere Mike, “em vez disso, use um desses datastores novos como uma ferramenta complementar.”

Hoje, a ascensão das redes sociais e da web read/write, juntamente com as tecnologias em nuvem, tem reformulado nossas necessidades e demandas na arquitetura de banco de dados, assim como na recuperação da informação.

Sabemos que a tecnologia dos bancos NoSQL é sólida e fornecerá soluções para resolver algumas destas questões. No entanto, o NoSQL ainda exige uma maturidade maior.

O grau de adoção das tecnologias NoSQL hoje ainda são imprevisíveis, mas uma coisa é certa. Elas vieram para ficar.

0 responses to “Cassandra: Prevendo o Futuro do NoSQL

  1. A unica coisa que falta para o BOOM do NOSQL são as hospedagens comuns oferecerem esses sserviços, mas para isso ainda deverão ser criadas ferramentas mais robustas e profissionais para os mesmos.

  2. A unica coisa que falta para o BOOM do NOSQL são as hospedagens comuns oferecerem esses sserviços, mas para isso ainda deverão ser criadas ferramentas mais robustas e profissionais para os mesmos.

  3. Acho que não. Só pq alguma coisa está disponível, não quer dizer que pessoas vão utilizar. E se não está disponível, estas mesmas pessoas contratam um VPS e instalam o SGBD que preferirem.

    Há um outro problema mais “embaixo”: cultura. Boa parte das empresas/pessoas que trabalham com dev são bem acostumadas com o modelo relacional e não vêem motivos para mudar isso.

    Mais pessoas/empresas trabalhando com grandes quantidades de dados pode ser um fator que leve ao boom.

  4. Acho que não. Só pq alguma coisa está disponível, não quer dizer que pessoas vão utilizar. E se não está disponível, estas mesmas pessoas contratam um VPS e instalam o SGBD que preferirem.

    Há um outro problema mais “embaixo”: cultura. Boa parte das empresas/pessoas que trabalham com dev são bem acostumadas com o modelo relacional e não vêem motivos para mudar isso.

    Mais pessoas/empresas trabalhando com grandes quantidades de dados pode ser um fator que leve ao boom.

  5. Acredito que não vai haver um BOOM da tecnológia NoSQL, provavelmente 90% das aplicações web existentes hoje não tem necessidade de utilizá-la, e esses 10% que necessitam não devem utilizar hospedagens comuns.
    Mas uma coisa é certa, ela está aí pra ficar.

  6. Acredito que não vai haver um BOOM da tecnológia NoSQL, provavelmente 90% das aplicações web existentes hoje não tem necessidade de utilizá-la, e esses 10% que necessitam não devem utilizar hospedagens comuns.
    Mas uma coisa é certa, ela está aí pra ficar.

  7. Acrescentaria mais alguns itens na lista de exemplos de uso do Adam Wiggins:

    – Logs

    – Dados do help desk

    – Logins e autorizações (que em algumas aplicações são consultados em quase todas as telas)

    – Dados usados para data warehouse

    @Suissa

    A EngineYard hospeda o CouchDB.

  8. Acrescentaria mais alguns itens na lista de exemplos de uso do Adam Wiggins:

    – Logs

    – Dados do help desk

    – Logins e autorizações (que em algumas aplicações são consultados em quase todas as telas)

    – Dados usados para data warehouse

    @Suissa

    A EngineYard hospeda o CouchDB.

  9. Interessante, mas ainda falta considerar outros aspectos.

    Primeiro, uma “provocação”- não vi nenhuma menção a filesystems modernos, que são uma excelente opção para determinados tipos de dados, e que no fundo também são um tipo muito específico de “banco de dados” (excelentes para logs e arquivos sequenciais, ou para coleções de objetos binários). E ainda há muito espaço para evolução dos filesystems.

    Outro ponto é que a própria tecnologia de armazenamento ainda tem muito a evoluir. A forma de usar um BD ainda está muito intrinsecamente ligada à forma de armazenamento dos dados. Boa parte das otimizações dos bancos de dados relacionais atuais diz respeito ao acesso a disco – e aí temos muitas novidades, como discos flash de um lado, e protocolos de emulação de acesso a disco via rede, que mudam a forma de otimizar o funcionamento do banco de dados radicalmente. Por outro lado, arquiteturas como CouchDB partem também da premissa de que o armazenamento está associado ao servidor – em um HD interno ou storage montado localmente. Não sei se a premissa de que os dados são armazenados no próprio servidor continuará sendo válida. Acredito que isso possa trazer impacto na forma de desenhar e implementar a próxima geração de banco de dados. O problema é que este impacto é bem difícil de imaginar na situação atual.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *