Costuma-se repetir que o problema do Big Data é que os bancos de dados relacionais não podem ser dimensionados para processar os enormes volumes de dados que agora estão sendo criados.
Mas quais são essas limitações de escalabilidade às quais as soluções de Big Data, como o Hadoop, não estão vinculadas? Por que o fragmento Oracle RAC ou MySQL ou MPP RDBMS como Teradata (etc.) não consegue essas proezas?
Estou interessado nas limitações técnicas - estou ciente de que os custos financeiros de clustering RDBMS podem ser proibitivos.
A MS acabou de ter uma palestra sobre tecnologia na Holanda, onde discutiram algumas dessas coisas. Começa devagar, mas entra na essência do Hadoop por volta dos 20 minutos.
A essência disso é que "depende". Se você tiver um conjunto de dados organizado de maneira sensata (pelo menos um pouco) fácil de particionar que (pelo menos um pouco) seja homogêneo, deve ser bastante fácil escalar para esses altos volumes de dados com um RDBMS, dependendo do que você está fazendo .
Hadoop e MR parecem ser mais voltados para situações em que você é forçado a grandes varreduras distribuídas de dados, especialmente quando esses dados não são necessariamente tão homogêneos ou estruturados quanto os que encontramos no mundo RDBMS.
A quais limitações as soluções de Big Data não estão vinculadas? Para mim, a maior limitação a que eles não estão sujeitos é ter que fazer um esquema rígido com antecedência. Com as soluções de Big Data, você coloca grandes quantidades de dados na "caixa" agora e adiciona lógica às suas consultas posteriormente para lidar com a falta de homogeneidade dos dados. Do ponto de vista do desenvolvedor, a compensação é a facilidade de implementação e flexibilidade no front-end do projeto, versus complexidade na consulta e consistência de dados menos imediata.
O pioneiro e pesquisador de banco de dados Michael Stonebraker co-escreveu um artigo que discute as limitações das arquiteturas de banco de dados tradicionais. Geralmente, eles escalam com hardware mais caro, mas têm dificuldade em escalar com hardware mais comum em paralelo e são limitados pela arquitetura de software herdada que foi projetada para uma era mais antiga. Ele afirma que a era do BigData exige várias novas arquiteturas de banco de dados que aproveitam a infraestrutura moderna e otimizam para uma determinada carga de trabalho. Exemplos disso são o projeto C-store, que levou ao banco de dados comercial Vertica Systems, e o projeto H-store que levou ao VoltDB, um banco de dados OLTP SQL em memória projetado para cargas de trabalho de BigData de alta velocidade. (Divulgação completa, eu trabalho para VoltDB).
Você pode achar este webinar interessante sobre este tópico. Ele responde a alguns dos mitos que surgiram com o sucesso dos bancos de dados NoSQL. Basicamente, ele afirma que o SQL não era o problema, não deveria ser necessário abrir mão dos recursos tradicionais do banco de dados, como consistência, para obter desempenho.
Não é inteiramente verdade que o RDBMS não pode escalar. No entanto, a verdade parcial na declaração depende da arquitetura. Na lista que você deu, o Oracle RAC é diferente do resto (MySQL fragmentado e Teradata). A principal diferença é o disco compartilhado versus as arquiteturas sem compartilhamento.
As arquiteturas de disco compartilhado, como o Oracle RAC, sofrem com o dimensionamento porque, em algum momento ou outro, todas as máquinas em execução devem sincronizar em alguma parte dos dados. Por exemplo, o gerenciador de bloqueio global é um assassino. Você pode continuar ajustando-o até certo ponto, mas acabará batendo em uma parede. Se você não puder adicionar máquinas facilmente, deverá ter menos máquinas, mas superpoderosas, que podem queimar seu bolso. No caso de arquiteturas sem compartilhamento (ou dados fragmentados), cada máquina se apropria de alguns dados. Não precisa sincronizar com outras máquinas se quiser atualizar alguns dados.
Em seguida, vem a geração de bancos de dados NoSQL. Eu os trataria como um subconjunto de bancos de dados RDBMS tradicionais. Nem todos os aplicativos neste mundo precisarão de todas as funcionalidades oferecidas pelo RDBMS. Se eu quiser usar o banco de dados como cache, não me importaria com a durabilidade. Pode ser que, em alguns casos, eu também não me importe com a consistência. Se toda a minha pesquisa de dados for baseada em uma chave, não preciso de suporte para consultas de intervalo. Posso não precisar de índices secundários. Não preciso de toda a camada de processamento/otimização de consultas que todos os bancos de dados tradicionais possuem.