Imagine-se diante do seguinte problema e você precisando resolvê-lo: criar uma grande aplicação Web, com milhares de acesso concorrentes, lidando com terabytes de dados e recursos transacionais. Várias questões vêem a mente, tais como tecnologia, recursos de servidores, banco de dados, mecanismos sofisticados que precisarão ser construídos e etc. Se você for um bom arquiteto já vai querer saber sobre os requisitos não funcionais, de performance principalmente, mas vamos parar por aqui.
Provavelmente, atender as necessidades funcionais desta grande aplicação será o menor dos problemas. O “bicho pega” no volume de informação que será preciso manipular e ter acesso. Se você utilizar um banco de dados relacional e não se preocupar com mecanismos elaborados, o acesso a informação pode tornar-se o gargalo da sua aplicação, ou pode tornar-se difícil de encontrá-la e escalar.
Com muito esforço você pensa e com consegue adaptar o seu banco de dados relacional para atender a sua aplicação, e ele se adapta perfeitamente a várias realidades, a prova disso é a maturidade e o uso que demos a eles ao longo de todos esses anos. Mas veja que para isso é preciso muito esforço.
Existe hoje um movimento de tecnologias que prometem minimizar o esforço para manter e construir uma infra-estrutura de armazenamento de grandes volumes distribuídos. Chama-se NoSQL. O termo refere-se ao armazenamento de dados que não seja relacional. A solução de banco de dados NoSQL é baseada pares de chave/valor e vai muito além do que só isso.
Alguns projetos que seguem essa linha:
Voldemort
Cassandra
Dynamite
HBase
Hypertable
CouchDB
MongoDB
Talvez você possa considerar o uso deste estilo de armazenamento quando estiver diante do problema citado acima. E veja que esta tecnologia está intimamente ligada ao conceito de cloud computing.
Imagine-se diante do seguinte problema e você precisando resolvê-lo: criar uma grande aplicação Web, com milhares de acesso concorrentes, lidando com terabytes de dados e recursos transacionais. Várias questões vêem a mente, tais como tecnologia, recursos de servidores, banco de dados, mecanismos sofisticados que precisarão ser construídos e etc. Se você for um bom arquiteto já vai querer saber sobre os requisitos não funcionais, de performance principalmente, mas vamos parar por aqui.
Provavelmente, atender as necessidades funcionais desta grande aplicação será o menor dos problemas. O “bicho pega” no volume de informação que será preciso manipular e ter acesso. Se você utilizar um banco de dados relacional e não se preocupar com mecanismos elaborados, distribuição, o acesso a informação pode tornar-se o gargalo da sua aplicação, ou pode tornar-se difícil de encontrá-la e escalar.
Com muito esforço você pensa e consegue adaptar o seu banco de dados relacional para atender a sua aplicação, e ele se adapta perfeitamente a várias realidades, a prova disso é a maturidade e o uso que demos a eles ao longo de todos esses anos. Mas veja que para isso é preciso muito esforço.
Existe hoje um movimento de tecnologias que prometem minimizar o esforço para manter e construir uma infra-estrutura de armazenamento de grandes volumes distribuídos. Chama-se NoSQL. O termo refere-se ao armazenamento de dados que não seja relacional. A solução de banco de dados NoSQL é baseada pares de chave/valor, mas vai muito além do que só isso.
Alguns projetos que seguem essa linha NoSQL:
Talvez você possa considerar o uso deste estilo de armazenamento quando estiver diante do problema citado acima.
Rec6 
Del.icio.us 
BlogBlogs 
Technorati 
LinkTo 
Na onda do cloud computing, surgem serviços simples e bem legais. Particularmente, acredito que estes tipos de oferta ajudam muito a validar tecnicamente o conceito de cloud computing, compartilhando dados menos críticos (claro que existem exceções, como o 
