por que os bancos de dados noSQL são mais escaláveis ​​que o SQL?

Recentemente, li muito sobre DBMSs noSQL. Entendo o teorema da CAP , regras ACID , regras BASE e a teoria básica. Mas não encontrou nenhum recurso sobre por que o noSQL é escalonável com mais facilidade que o RDBMS (por exemplo, no caso de um sistema que requer muitos servidores de banco de dados)?

Eu acho que manter restrições e chaves estrangeiras custa recursos e, quando um DBMS é distribuído, é muito mais complicado. Mas espero que haja muito mais que isso.

Alguém pode explicar como o noSQL / SQL afeta a escalabilidade?

Os bancos de dados noSQL oferecem uma enorme quantidade de funcionalidades que um banco de dados SQL oferece por sua natureza.

Coisas como imposição automática da integridade referencial, transações, etc. Essas são coisas muito úteis para alguns problemas e requerem algumas técnicas interessantes para serem dimensionadas fora de um único servidor (pense no que acontece se você precisar bloquear duas tabelas para uma transação atômica e eles estão em servidores diferentes!).

Os bancos de dados noSQL não têm tudo isso. Se você precisar dessas coisas, precisará fazê-lo por conta própria, mas se não precisar (e existem muitas aplicações que não precisam), então, rapaz, como estás com sorte. O banco de dados não precisa executar todas essas operações complexas e travar grande parte do conjunto de dados; portanto, é muito fácil particionar a coisa entre muitos servidores / discos / o que quer que seja e fazer com que funcione muito rápido.

Não é sobre NoSQL vs SQL, é sobre BASE vs ACID.

O escalável deve ser dividido em seus constituintes:

• Escala de leitura = manipula volumes mais altos de operações de leitura
• Escala de gravação = manipula volumes mais altos de operações de gravação

Os bancos de dados compatíveis com ACID (como os RDBMS tradicionais) podem escalar leituras. Eles não são inerentemente menos eficientes do que os bancos de dados NoSQL porque os (possíveis) gargalos de desempenho são introduzidos por coisas que o NoSQL (às vezes) carece (como junções e restrições de onde) que você pode optar por não usar. Os RDBMSs SQL em cluster podem escalar leituras introduzindo nós adicionais no cluster. Existem restrições quanto ao alcance das operações de leitura, mas elas são impostas pela dificuldade de aumentar as gravações à medida que você introduz mais nós no cluster.

A escala de gravação é onde as coisas ficam peludas. Existem várias restrições impostas pelo princípio ACID que você não vê nas arquiteturas eventualmente consistentes (BASE):

• Atomicidade significa que as transações devem ser concluídas ou falhar como um todo; portanto, muita contabilidade deve ser feita nos bastidores para garantir isso.
• As restrições de consistência significam que todos os nós no cluster devem ser idênticos. Se você gravar em um nó, essa gravação deverá ser copiada para todos os outros nós antes de retornar uma resposta ao cliente. Isso dificulta o dimensionamento de um cluster RDBMS tradicional.
• As restrições de durabilidade significam que, para nunca perder uma gravação, você deve garantir que, antes que uma resposta seja retornada ao cliente, a gravação tenha sido liberada no disco.

Para expandir as operações de gravação ou o número de nós em um cluster além de um certo ponto, é necessário relaxar alguns dos requisitos do ACID:

• Eliminar o Atomicity permite reduzir a duração de bloqueio de tabelas (conjuntos de dados). Exemplo: MongoDB, CouchDB.
• A eliminação da consistência permite aumentar as gravações nos nós do cluster. Exemplos: riak, cassandra.
• Soltar a durabilidade permite responder a comandos de gravação sem liberar para o disco. Exemplos: memcache, redis.

Os bancos de dados NoSQL geralmente seguem o modelo BASE em vez do modelo ACID. Desistem dos requisitos A, C e / ou D e, em troca, melhoram a escalabilidade. Alguns, como Cassandra, permitem que você aceite as garantias do ACID quando precisar delas. No entanto, nem todos os bancos de dados NoSQL são mais escaláveis ​​o tempo todo.

A API do SQL não possui um mecanismo para descrever consultas em que os requisitos do ACID são flexíveis. É por isso que os bancos de dados BASE são todos NoSQL.

Nota pessoal: um ponto final que gostaria de destacar é que, na maioria dos casos em que o NoSQL está sendo usado atualmente para melhorar o desempenho, uma solução seria possível em um RDBMS adequado, usando um esquema normalizado corretamente com índices adequados. Conforme comprovado por este site (desenvolvido pelo MS SQL Server), os RDBMSs podem ser escalados para altas cargas de trabalho, se você usá-las adequadamente. As pessoas que não entendem como otimizar os RDBMSs devem ficar longe do NoSQL, porque não entendem os riscos que estão correndo com seus dados.

Atualização (17/09/2019):

O cenário dos bancos de dados evoluiu desde a publicação desta resposta. Embora ainda exista a dicotomia entre o mundo RDBMS ACID e o mundo NoSQL BASE, a linha se tornou mais confusa. Os bancos de dados NoSQL adicionaram recursos do mundo RDBMS, como APIs SQL e suporte a transações. Agora, existem até bancos de dados que prometem SQL, ACID e redimensionamento de gravação, como o Google Cloud Spanner, YugabyteDB ou CockroachDB. Normalmente, o diabo está nos detalhes, mas para a maioria dos propósitos estes são "suficientemente ACIDOS". Para aprofundar a tecnologia de banco de dados e como ela evoluiu, você pode dar uma olhada neste deck de slides (as notas do slide têm a explicação que o acompanha).

É verdade que os bancos de dados NoSQL (MongoDB, Redis, Riak, Memcached, etc.) não mantêm restrições de chave estrangeira, e as operações atômicas devem ser especificadas mais explicitamente. Também é verdade que os bancos de dados SQL (SQL Server, Oracle, PostgreSQL etc.) podem ser dimensionados para lidar com requisitos de desempenho muito grandes por DBAs experientes.

Os bancos de dados NoSQL permitem que programadores experientes, que estão cientes das condições de corrida e operações atômicas, renunciem a uma grande quantidade de processamento necessária apenas em uma pequena porcentagem do código de aplicativos da web atual. Os bancos de dados NoSQL certamente possuem operações atômicas e quase todos os requisitos transacionais presentes nos bancos de dados SQL também podem ser obtidos nos bancos de dados NoSQL. A diferença é o nível de abstração. Os bancos de dados NoSQL removem os níveis mais altos de abstração e entregam essa capacidade ao programador de aplicativos, resultando em um código mais rápido em geral, com maior probabilidade de corrupção de dados por programadores não sazonais.

Como resultado, é muito mais provável que os bancos de dados NoSQL sejam cada vez mais usados ​​no espaço de aplicativos da web, onde o tempo e o desempenho do desenvolvimento são muito importantes. É provável que os softwares financeiros e corporativos mantenham sua herança SQL, porque o desempenho do hardware é relativamente barato, eles possuem DBAs disponíveis e o aumento do risco causado por programadores não temperados não é agradável.

No IBM developerWorks: Forneça escalabilidade de dados no nível da nuvem com bancos de dados NoSQL

Escalabilidade é o sistema que deve suportar bancos de dados muito grandes com taxas de solicitação muito altas e com latência muito baixa.

Os sistemas NoSQL têm vários recursos de design em comum:

• A capacidade de dimensionar horizontalmente a taxa de transferência em muitos servidores.
• Uma interface ou protocolo simples em nível de chamada (em contraste com uma ligação SQL).
• Suporte para modelos de consistência mais fraca que as transações ACID na maioria dos RDBMS tradicionais.
• Uso eficiente de índices distribuídos e RAM para armazenamento de dados.
• A capacidade de definir dinamicamente novos atributos ou esquema de dados.

Por que os bancos de dados relacionais podem não ser ideais para o Scaling

Em geral, os sistemas de gerenciamento de banco de dados relacional têm sido considerados uma "solução única para persistência e recuperação de dados" por décadas. Eles amadureceram após extensos esforços de pesquisa e desenvolvimento e criaram com muito sucesso um grande mercado e soluções em diferentes domínios de negócios.

A crescente necessidade de escalabilidade e novos requisitos de aplicativos criaram novos desafios para o RDBMS tradicional, incluindo alguma insatisfação com essa abordagem de tamanho único em alguns aplicativos de escala da Web. A resposta para isso foi uma nova geração de software de banco de dados de baixo custo e alto desempenho, projetado para desafiar o domínio dos sistemas de gerenciamento de banco de dados relacional. Uma grande razão para o movimento NoSQL é que diferentes implementações de aplicativos da Web, corporativos e de computação em nuvem têm requisitos diferentes de seus bancos de dados - nem todo aplicativo exige consistência rígida de dados, por exemplo.

Outro exemplo: para sites de grande volume como eBay, Amazon, Twitter ou Facebook, escalabilidade e alta disponibilidade são requisitos essenciais que não podem ser comprometidos. Para essas aplicações, mesmo a menor interrupção pode ter consequências financeiras significativas e afetar a confiança do cliente.

Mais no DBA.SE: o que significa escala horizontal?

O dimensionamento horizontal é essencialmente construído em vez de aumentado. Você não compra um servidor maior e transfere toda a sua carga para ele; em vez disso, compra mais de 1 servidor adicional e distribui sua carga entre eles.

A escala horizontal é usada quando você tem a capacidade de executar várias instâncias nos servidores simultaneamente. Normalmente, é muito mais difícil ir de 1 servidor para 2 servidores, depois é de 2 para 5, 10, 50, etc.

Depois de resolver os problemas de execução de instâncias paralelas, você pode tirar grande proveito de ambientes como Amazon EC2, Cloud Service da Rackspace, GoGrid etc., pois pode ativar e desativar instâncias com base na demanda, reduzindo a necessidade de pagar pela energia do servidor você não está usando apenas para cobrir essas cargas de pico.

Bancos de dados relacionais são um dos itens mais difíceis de executar leitura / gravação completa em paralelo.