Martelo. É a primeira ferramenta que vem a cabeça quando é necessário pregar alguma coisa. E se ao invés de um prego, você precisar prender uma estaca (sempre útil quando você tem um elefante de estimação), existem martelos ou marretas de diversos tamanhos, mas o mecanismo, a forma básica da ferramenta é a mesma. São todos martelos.
Para quem nunca viu, isto é um martelo
Depois que você resolve muitos problemas com seu martelo, começa a achar que todos os seus problemas podem ser resolvidas a base do martelo. Por exemplo, você pode usar o martelo para enfiar um parafuso em um buraco (não façam isso em casa, crianças). Pode fazer um strike no boliche usando o martelo. Precisa desligar a TV? Martelo.
O banco de dados relacional é o martelo, das últimas décadas, quando se fala em armazenamento de dados. Chegamos em um ponto em que nem se questionava mais essa escolha. Precisamos armazenar um monte de dados e depois consultá-los? Banco de dados. Depois disso era questão de escolher entre Microsoft, Oracle ou opções open source. Se o problema não fosse um prego, bastava dar um jeitinho que ele se tornava um prego. E muitos problemas realmente são pregos.
“E quais problemas não são pregos?”, você me pergunta segurando seu martelo. Eis os principais:
Escalabilidade
Mas hoje vivemos em mundo em que a internet já não é mais novidade. O que significa que aplicações muitas vezes precisam suportar acessos de um número imenso de usuários. O que significa que é necessário armazenar montanhas de dados que crescem em um ritmo muito grande e depois consultar esses mesmos dados sem perder muito tempo. Pense em sistemas como Facebook, ou Amazon, ou LinkedIn, e imagine o sistema virando uma carroça porque o banco de dados se tornou o gargalo. É MUITO dinheiro indo pelo ralo.
Para esses casos, se seu banco de dados velho de guerra não está dando conta de jeito nenhum, você precisa de alguma solução que seja um pouco mais distribuída, para a carga de escritas e leituras de dados ficar distribuída. Você precisa de políticas de lock que sejam mais baratas para sua aplicação, porque cada milissegundo perdido em um sistema desse porte pode se transformar em muitos segundos (ou muitos time-outs).
Para esses casos você pode dar uma olhada em alguns dos bancos de dados de documentos (document databases) e hashmaps distribuídos, como CouchDB, MongoDB, Tokyo Cabinet e Project Voldemort. Também existem os serviços do Google e da Amazon que inspiraram muitos desses projetos, o BigTable e o SimpleDB respectivamente. E se seu maior problema é processar muitos dados, talvez você queira conhecer o HBase, que é um subprojeto do Hadoop, a implementação open source do algoritmo Map-Reduce do Google (também conhecido como a forma mais popular hoje de se dividir um trabalho grande e resolver em paralelo como muitas coisas pequenas). O CouchDB também está implementando um Map-Reduce diretamente em seu banco de dados.
Flexibilidade
Às vezes a estrutura de seus dados não é fixa. Imagine por exemplo que você precise guardar questionarios e suas respostas, e toda hora alguém inventa umas perguntas novas para o seu questionário. Isso é motivo de mau humor para o DBA que toda hora vai criar uma coluna no banco de dados e alterar suas consultas para incluir os novos campos. Esse DBA vai riscar o seu carro. Se quiser se prevenir, você pode dar uma olhada em um dos bancos de dados de documentos de que já falei, como o CouchDB ou o MongoDB, que armazenam os dados como uma entidade que eles chamam de documentos (nada mais que uma coleção de campos e respectivos valores) sem uma estrutura fixa. Na verdade você pode armazenar em uma mesma tabela coisas completamente diferentes, como estatísticas da Fórmula 1 e resumos da novela das 8 (o que não seria muito útil).
Outro caso de uso seria construir um sistema como o Salesforce, que permite que os clientes customizem os dados, adicionando campos que julguem ser úteis para seu negócio. A empresa que vende carros vai querer campos para indicar quais são os opcionais do veículo que estão vendendo. Já o usuário que vende aquelas garrafadas que curam várias doenças, vai querer marcar quais são os males que seu produto vai sanar.
Graças ao meu sistema de CRM, meu market share dobrou no Q3
Estrutura
Dependendo do domínio de sua aplicação, seus dados podem não ter muita cara de tabelas e registros. Não que seja impossível utilizar tabelas e registros para modelar quase tudo, mas pode ser que a natureza desses dados torne um pesadelo tentar modelar as entidades em tabelas. E pior ainda, seu programa levar tanto tempo para te trazer os dados da forma que você precisa que simplesmente inviabilize o projeto.
Imagine que você esteja construindo sua própria rede social, seu Orkut ou algo do tipo. Você acordou com uma vontade muito forte de fazer uma aplicação que descobre quantas pessoas que são amigos de seus amigos, ou amigos de seus amigos de seus amigos e assim por diante, que são fãs do blog TI Simples. Se você é um ninja de SQL já sabe que fazer isso de um golpe só não é viável (a não ser que seu banco de dados tenha alguma extensão ninja de SQL). O problema dessa aplicação é que os relacionamentos entre os dados são a parte mais importante. O que você precisa neste caso é de um banco de dados de grafos (ou banco de dados de redes), como o Neo4j por exemplo.
Precisa construir um datawarehouse para seu sistema de BI? Consultar o banco de dados para retirar informações úteis e que vão ajudar na estratégia da empresa não é algo muito suave de se fazer no mesmo banco de dados que seus sistemas de produção alimentam (por experiência própria, já fui ao cinema enquanto uma consulta rodava, voltei e ainda não havia acabado). A estrutura boa para os dados dos sistemas de entrada de dados em geral não é muito boa para uma consulta mais profunda a esses mesmos dados. No final, você precisa usar produtos de datawarehousing para deixar seus dados no jeito. Ou pode apelar para soluções inovadoras, em que a estrutura física dos dados é otimizada para permitir consultas mais elaboradas, como o Vertica que armazena os dados agrupando-os por coluna (ou seja, os valores para o mesmo campo logicamente próximos, ao contrário de colocar os valores dos campos de cada registro logicamente próximos, como os bancos comuns fazem). Ou armazenamento baseado em valor, fornecido pelo iLuminate, que armazena todos os valores de um mesmo tipo em um mesmo pool evitando valores repetidos (esta abordagem é tão diferente que vale até uma visita ao site do fabricante).
Eu realmente preciso desse trem?
Esses novos bancos de dados surgiram por conta de necessidades que foram aparecendo e que não eram bem respondidas com os produtos existentes. Por serem coisas novas (e legais) começaram a virar moda entre os desenvolvedores, mesmo que muitas dessas bases de dados ainda não estejam em uma fase muito estável. Muito provavelmente, para a maioria dos casos, você pode resolver seus problemas usando o seu banco de dados comum. Pode resolver a escalabilidade utilizando caches de dados, fazendo replicação master-slave ou sharding de seus dados (um servidor com dados de São Paulo e outro com os outros estados por exemplo). Se você precisa de muita flexibilidade nos dados mas não necessariamente precisa realizar consultas usando esses campos, pode por exemplo colocar os dados no banco como XML ou gravá-los em arquivos. Nenhum dos problemas listados acima é novo e dependendo do tamanho do problema e da sua paciência é possível dar um jeito que atenda a sua necessidade.
Mas eu recomendo que comece a dar uma olhada em alguns desses projetos, a maioria deles gratuitos e open source. Verifique se existe uma comunidade ativa de desenvolvedores ao redor do projeto. Faça pequenos testes. A maioria desses projetos abre mão de muitas funcionalidades que existem nos BDs comuns, em troca de alguma vantagem como performance, mas muitos deles estão caminhando para se tornar produtos bastante completos que poderão ser utilizados tranquilamente como seus ancestrais. Com certeza eles não vão acabar com os bancos de dados relacionais (como algumas pessoas estão pensando), mas são ótimas adições à sua caixa de ferramentas. Assim como o martelo.
Se quiser se aprofundar um pouco mais, recomendo este link e mais este, todos em inglês. E visitar os sites dos projetos.
TI SIMPLES 