Por que o NoSQL é mais rápido que o SQL?

Existem muitas soluções NoSQL por aí, cada uma com seus pontos strongs e fracos, portanto, o que se segue deve ser tomado com um pouco de sal.

Mas, essencialmente, o que muitos bancos de dados NoSQL fazem é confiar na desnormalização e tentar otimizar o caso desnormalizado. Por exemplo, digamos que você esteja lendo uma postagem de blog junto com seus comentários em um banco de dados orientado a documentos. Muitas vezes, os comentários serão salvos junto com a postagem em si. Isso significa que será mais rápido recuperar todos eles juntos, pois eles são armazenados no mesmo local e você não precisa realizar uma associação.

Claro, você pode fazer o mesmo no SQL, e a desnormalização é uma prática comum quando se precisa de desempenho. É só que muitas soluções NoSQL são projetadas desde o início para serem sempre usadas dessa maneira. Você então obtém as compensações usuais: por exemplo, adicionar um comentário no exemplo acima será mais lento porque você precisa salvar o documento inteiro com ele. E depois de desnormalizar, você precisa cuidar para preservar a integridade dos dados em seu aplicativo.

Além disso, em muitas soluções NoSQL, é impossível fazer junções arbitrárias, portanto, consultas arbitrárias. Alguns bancos de dados, como o CouchDB, exigem que você pense antes das consultas necessárias e prepare-as dentro do banco de dados.

Em suma, tudo se resume a esperar um esquema desnormalizado e a otimizar as leituras para essa situação, e isso funciona bem para dados que não são altamente relacionais e que exigem muito mais leituras do que gravações.

O que você está perdendo no NoSQL é que o NoSQl não pode ser comparado ao SQL de forma alguma. NoSQL é o nome de todas as tecnologias de persistência que não são SQL. DBs de documentos, bancos de dados de valores-chave, bancos de dados de eventos são todos NoSQL. Eles são todos diferentes em quase todos os aspectos, seja estrutura de dados salvos, consulta, desempenho e ferramentas disponíveis.

Então, se alguém lhe fizer tal pergunta na entrevista, esta deve ser a resposta.

Bancos de dados 'NoSQL' (ou mais precisamente: não-relacionais) abrem mão de alguns recursos dos bancos de dados tradicionais em termos de velocidade, mas mais importante para escalabilidade horizontal.

Os recursos ausentes dependem do produto concreto, em geral, as propriedades ACID completas ou até mesmo as operações de junção não são suportadas. Esse é o preço para o aumento do desempenho.

Você está certo, seria um absurdo afirmar isso em uma declaração geral. Qual é provavelmente o ponto inteiro; em vez de uma única resposta, o entrevistador provavelmente espera que você responda com perguntas para ajudá-lo a descobrir qual é o contexto do problema (que tipo de dados, quanto dele, em qual ambiente operacional etc.), a solução particular do NoSQL. . Eles tentarão descobrir como você analisa os problemas e, ao longo do caminho, ter uma ideia do quanto você sabe sobre as diferentes soluções que estão por aí.

Os bancos de dados NoSQL normalmente só fazem sentido se você projetar seus dados em torno deles.

Se você pretende simplesmente usá-los como um substituto do RDBMS, poderá obter menos desempenho do que mais, especialmente se não tiver orçamento suficiente para pagar servidores com grandes quantidades de RAM.

Veja este artigo que compara o uso do espaço em disco do MySQL com o do MongoDB: link

Qual banco de dados NoSQL? Qual banco de dados SQL? Se alguém lhe disser que o NoSQL é mais rápido que o SQL, então você deve se afastar. Ou melhor ainda, assista a este vídeo:

link

Eu não vou dizer que metade das coisas reclamadas sobre o NoSQL estão erradas, mas eu vou dizer que há muito fanboys do NoSQL por aí de pessoas que realmente não entendem isso muito bem.

O SQL tem seus limites (é claro), mas também é uma tecnologia muito madura, que é bem compreendida e tem um grande grupo de desenvolvedores que entende como usá-lo bem. Eu não posso dizer o mesmo para todas as formas de NoSQL.

NoSql suportado por bancos de dados orientados por colunas onde RDBMS é banco de dados orientado a linha ... E por exemplo, temos uma tabela Employee com Nome, Idade, Salery, Address, EmployeeId etc ... colocamos a mesma tabela no MySql (suporte RDBMS ) e HBase (suporte NoSQL). Se um cliente / cliente escrever uma consulta para obter os detalhes médios de Idade ou Salário dos registros dos funcionários da 1Lakh ... o que acontece?

No RDBMS, ele contorna cada linha e coleta o valor e soma & dividir por resultante. Quando se trata de banco de dados Columnar não precisa se preocupar com todas as iterações de uma lakh linha. Mas lide com apenas uma linha, que é mais rápida de calcular. Então, dessa forma, às vezes o NoSQL é mais rápido que o SQL. Este caso NoSQL não se importa com reclamações ACID valem a pena!

Esqueça a teoria em torno de bancos de dados .... o ponto depois de entender suas consultas, você pode salvar dados em bancos de dados nosql de uma maneira exata em que eles são realmente usados em sua aplicação ....

Por exemplo, veja este exemplo, você tem um modelo de cliente com muitos pedidos e muitos itens associados a cada pedido, então eles também têm muitos itens salvos para compras posteriores ... se você for uma grande loja de comércio eletrônico com digamos 10 milhões clientes e 50 milhões de pedidos. E esse cliente efetua login em seu painel que exibe esses dados exatos, quanto trabalho um banco de dados SQL precisará fazer para localizar o cliente, ingressar nos pedidos e em cada item de linha e itens salvos. Em um banco de dados sql, todos esses dados provavelmente precisarão ser associados de alguma forma ... ou vc pode criar uma coleção no banco de dados ur chamada usercache e salvar esses dados exatamente como você os utiliza na vida real. Então, isso pode ser uma única consulta em um único campo [id] para recuperar todos esses dados. Além disso, o banco de dados nosql não precisa enviar a consulta para todos os 40 servidores de banco de dados para recuperar as informações que realmente contêm os dados.

Assim, um banco de dados sql pode consultar um único campo de Id tão rápido, se não mais rápido que o nosql? Sim, mas um banco de dados sql pode retornar todos os dados que você precisa consultando uma tabela e um campo? Não, a menos que você faça algo como salvar os dados no Json dentro de um campo de texto grande. Mas agora que os dados não podem ser consultados para uso futuro em potencial.