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


17

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.

Respostas:


15

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.


Obrigado Dave, você está me aproximando do que estou tentando descobrir. Você diz que o Hadoop é voltado para situações com grandes verificações distribuídas - se alguns / muitos RDBMS 'têm soluções em cluster (RAC, shards, MPP, etc), por que eles também não podem fazer isso? O que torna inviável para um RDBMS classificar 10 trilhões de registros em 16 horas como um cluster Hadoop muito grande pode? veja aqui
Jeremy Beard

2
Nada torna inviável que um cluster RDBMS execute esse tipo de trabalho, e você pode configurar um RDBMS para expandir para fazer esse tipo de coisa. O problema com um RDBMS é que, para fazer isso, você precisa ter muito cuidado com a estrutura de seu esquema e partições para que funcione. As arquiteturas de Big Data vencem quando seus dados não são estruturados o suficiente para serem particionados e otimizados com facilidade ou eficácia em um RDBMS.
21812 Dave

1
Designers de banco de dados incompetentes dificultam o dimensionamento dos bancos de dados relacionais. Muitas empresas acham que os desenvolvedores de aplicativos podem criar bancos de dados (ou pior usar o ORMS para fazer o design) quando precisam contratar desenvolvedores de bancos de dados competentes desde o início. A segunda pessoa que você contrata para um projeto que envolve dados deve ser o desenvolvedor do banco de dados.
HLGEM

3
@HLGEM: Minha resposta a isso é "meh". Os desenvolvedores mais eficazes serão os que entenderão os dois lados da pilha - a ideia de que existe um bom "desenvolvedor de aplicativos" que trabalha com um RDBMS o tempo todo sem saber como funciona é uma falácia . Da mesma forma, a idéia de que existe um bom "desenvolvedor de banco de dados" que não entende os ORMs ou o lado do aplicativo também é, na OMI, uma falácia.
Dave Markle

6

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.


6
Para se qualificar como divulgação completa, você provavelmente também deve mencionar que seu co-fundador e CTO Michael Stonebraker também foi co-arquiteto de todos os seus exemplos. E esse suporte ao SQL do VoltDB é um subconjunto embaraçosamente pequeno .
Daniel Lyons

5

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.