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

NoSQL bancos de dados desistir de uma enorme quantidade de funcionalidades que um banco de dados SQL dá a você por sua natureza.

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

bancos de dados noSQL não têm tudo isso. Se você precisar dessas coisas, você precisa fazê-lo sozinho, mas se você não precisar dele (e há muitos aplicativos que não o fazem), então rapaz, por favor, você está com sorte. O banco de dados não precisa fazer todas essas operações complexas e travar em grande parte do conjunto de dados, então é muito fácil particionar a coisa em vários servidores / discos / o que quer que seja e fazer com que funcione muito rápido.

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

Escalável deve ser dividido em seus componentes:

• Read scaling = manipular volumes maiores de operações de leitura
• Gravar escala = lidar com volumes mais altos de operações de gravação

Bancos de dados compatíveis com ACID (como os RDBMSs tradicionais) podem escalar leituras. Eles não são inerentemente menos eficientes que os bancos de dados NoSQL porque os (possíveis) gargalos de desempenho são introduzidos por coisas que o NoSQL (às vezes) não possui (como junções e restrições) que você pode optar por não usar. Os RDBMSs SQL em cluster podem dimensionar as leituras introduzindo nós adicionais no cluster. Existem restrições sobre até que ponto as operações de leitura podem ser dimensionadas, mas são impostas pela dificuldade de aumentar as gravações à medida que você introduz mais nós no cluster.

Escrever escalonamento é onde as coisas ficam complicadas. Existem várias restrições impostas pelo princípio ACID que você não vê em arquiteturas eventualmente consistentes (BASE):

• A atomicidade significa que as transações devem ser concluídas ou falhadas como um todo, portanto, muita contabilidade deve ser feita nos bastidores para garantir isso.
• 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 faz com que um cluster RDBMS tradicional seja difícil de dimensionar.
• 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 para o disco.

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

• Eliminar atomicidade permite reduzir a duração das tabelas (conjuntos de dados) bloqueadas. Exemplo: MongoDB, CouchDB.
• Eliminar consistência permite dimensionar as gravações nos nós do cluster. Exemplos: riak, cassandra.
• A diminuição da durabilidade permite responder a comandos de gravação sem precisar descarregar no disco. Exemplos: memcache, redis.

Os bancos de dados NoSQL geralmente seguem o modelo BASE em vez do modelo ACID. Eles desistem dos requisitos A, C e / ou D e, em troca, melhoram a escalabilidade. Alguns, como Cassandra, permitem que você opte pelas garantias do ACID quando precisar deles. 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 as consultas em que os requisitos do ACID são relaxados. É por isso que os bancos de dados BASE são todos NoSQL.

Nota pessoal: um último ponto que gostaria de fazer é que a 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 corretamente normalizado com índices apropriados. Como comprovado por este mesmo site (desenvolvido pelo MS SQL Server), os RDBMS podem escalar para altas cargas de trabalho, se você usá-los adequadamente. As pessoas que não entendem como otimizar os RDBMS devem ficar longe do NoSQL, porque não entendem quais riscos estão assumindo com seus dados.

No IBM developerWorks: Forneça escalabilidade de dados em nível de nuvem com o NoSQL bases de dados

Escalabilidade é o sistema que deve ser capaz de suportar bancos de dados muito grandes com taxas de solicitação muito altas em 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 de nível de chamada (em contraste com um SQL ligação).
• Suporte para modelos de consistência mais fracos que as transações do ACID em RDBMS mais tradicional.
• Uso eficiente de índices distribuídos e RAM para armazenamento de dados.
• A capacidade de definir dinamicamente novos atributos ou esquemas de dados.

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

Em geral, sistemas de gerenciamento de bancos de dados relacionais têm sido considerados como 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 sucesso um grande mercado e soluções em diferentes domínios de negócios.

A necessidade cada vez maior de escalabilidade e novos requisitos de aplicativos criaram novos desafios para o RDBMS tradicional, incluindo alguma insatisfação com essa abordagem única em todos os aplicativos de escala da web. A resposta para isso tem sido 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 aplicações web, corporativas e de computação em nuvem têm requisitos diferentes de seus bancos de dados - nem todos os aplicativos exigem consistência de dados rígida, por exemplo.

Outro exemplo: para sites de alto 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, até mesmo a menor interrupção pode ter consequências financeiras significativas e afetar a confiança do cliente.

Em DBA.SE: O que significa escalonamento horizontal?

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

O escalonamento horizontal é usado quando você tem a capacidade de executar várias instâncias em servidores simultaneamente. Normalmente, é muito mais difícil ir de 1 servidor para 2 servidores, então é ir de 2 a 5, 10, 50, etc.

Depois de abordar os problemas de execução de instâncias paralelas, você pode tirar proveito de ambientes como o Amazon EC2, o Cloud Service da Rackspace, o GoGrid, etc, pois pode aumentar e diminuir instâncias com base na demanda, reduzindo a necessidade de pagar para energia do servidor que 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.

É 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 dos DBAs experientes.

Os bancos de dados NoSQL permitem que os programadores experientes, que estão bem cientes das condições de corrida e operações atômicas, deixem passar uma grande quantidade de processamento necessária apenas em uma pequena porcentagem do código atual da aplicação web. Os bancos de dados NoSQL certamente têm operações atômicas e a maioria dos requisitos transacionais presentes nos bancos de dados SQL também podem ser obtidos em 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, portanto, em códigos mais rápidos com a maior probabilidade de corrupção de dados por programadores não sazonados.

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 de desenvolvimento e o desempenho são muito importantes. É provável que o software financeiro e corporativo retenha sua herança de SQL, porque o desempenho do hardware é relativamente barato, eles têm DBAs experientes disponíveis e o risco aumentado causado por programadores não sazonados não é palatável.