Por que os bancos de dados relacionais não podem atender às escalas do Big Data?

Costuma-se repetir que o problema do Big Data é que os bancos de dados relacionais não podem ser dimensionados para processar os grandes volumes de dados que estão sendo criados agora.

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 Oracle RAC ou MySQL sharding ou MPP RDBMS como Teradata (etc.) conseguem esses feitos?

Estou interessado nas limitações técnicas - sei que os custos financeiros do clustering de RDBMS podem ser proibitivos.

A MS teve uma conversa sobre tecnologia na Holanda, onde discutiram algumas dessas coisas. Começa lentamente, mas entra na carne do Hadoop por volta dos 20 minutos.

A essência disso é que "depende". Se você tiver um conjunto de dados organizado (pelo menos um pouco) fácil e sensivelmente organizado (pelo menos um pouco) que seja homogêneo, deve ser bastante fácil dimensionar esses volumes de dados altos com um RDBMS, dependendo do que você estiver fazendo .

O Hadoop e o MR parecem estar mais voltados para situações em que você é forçado a realizar grandes verificações distribuídas de dados, especialmente quando esses dados não são necessariamente tão homogêneos ou estruturados quanto o que encontramos no mundo do 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 vinculados é ter que fazer um esquema rígido antes do tempo. Com as soluções de Big Data, você coloca enormes quantidades de dados na "caixa" agora e adiciona lógica às suas consultas posteriormente para lidar com a falta de homogeneidade dos dados. Da perspectiva de um desenvolvedor, o tradeoff é a facilidade de implementação e a flexibilidade no front-end do projeto, versus a complexidade na consulta e a consistência menos imediata dos dados.

O pioneiro e pesquisador de bancos de dados Michael Stonebraker co-escreveu um artigo que discute as limitações das arquiteturas tradicionais de bancos de dados. Geralmente, eles aumentam com hardware mais caro, mas têm dificuldade em expandir com mais hardware 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 requer várias novas arquiteturas de banco de dados que tiram proveito da infraestrutura moderna e otimizam para uma carga de trabalho específica. 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 BigData de alta velocidade. (Divulgação completa, trabalho para o VoltDB).

Você pode achar este webinar interessante sobre esse 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 seria necessário renunciar aos recursos tradicionais do banco de dados, como consistência, para obter desempenho.

Não é inteiramente verdade que o RDBMS não possa ser escalado. No entanto, a verdade parcial na declaração depende da arquitetura. Na lista que você forneceu, o Oracle RAC é diferente do restante (MySQL e Teradata). A principal diferença é o disco compartilhado versus as arquiteturas de nada compartilhado.

As arquiteturas de disco compartilhado, como o Oracle RAC, sofrem com o dimensionamento, porque em algum momento ou em todas as máquinas em execução devem ser sincronizadas em alguma parte dos dados. Por exemplo, o global lock manger é um assassino. Você pode continuar ajustando-o até certo ponto, mas acabará atingindo uma parede. Se você não pode adicionar máquinas facilmente, deve ter menos, mas máquinas super poderosas, que podem queimar seu bolso. No caso de arquiteturas compartilhadas (ou dados fragmentados), cada máquina possui a propriedade de alguns dados. Ele não precisa ser sincronizado com outros máquinas, se quiser atualizar alguns dados.

Depois 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 deste mundo precisarão de todas as funcionalidades oferecidas pelo RDBMS. Se eu quiser usar o banco de dados como cache, não me importo com durabilidade. Pode ser que em alguns casos eu também não me importo com consistência. Se toda a minha pesquisa de dados for baseada em uma chave, não preciso de suporte para consultas de intervalo. Talvez eu não precise de índices secundários. Eu não preciso de toda a camada de processamento / otimização de consulta que todos os bancos de dados tradicionais possuem.