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

48

Recentemente me perguntaram:

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

Eu não concordo com a premissa da pergunta ... é apenas um absurdo para mim pessoalmente. Não vejo nenhum aumento de desempenho usando o NoSQL em vez de SQL. Talvez SQL sobre NoSQL, sim, mas não dessa maneira.

Estou perdendo algo sobre o NoSQL?

performance nosql

— cnd
fonte

3

Se você não consegue ver um aumento no desempenho, é isso que você diz. O fato é que a maioria das soluções NoSQL renuncia a uma (ou mais) propriedades do ACID de um banco de dados relacional e, portanto, faz menos.

— Oded

1

Existem alguns fluxos de trabalho (e estruturas de dados) que não podem ser facilmente mapeados para um banco de dados relacional tradicional ativado por ACID. Para aqueles, você pode ver grandes aumentos de desempenho usando um banco de dados NoSQL. Se, no entanto, você simplesmente pegar um banco de dados SQL existente (bem projetado) e colocá-lo em um banco de dados NoSQL, seu desempenho certamente sofrerá.

— Joachim Sauer

1

A resposta é: foi estabelecido o mais rápido? E mais rápido em quê? Tempo de desenvolvimento? Tempo de leitura? Escreva tempo? Que tipo de gravação? Com o que estamos comparando? Consultas com várias tabelas? Junta-se?

— Rolf

65

Existem muitas soluções NoSQL por aí, cada uma com suas próprias forças e fraquezas, portanto, o seguinte 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. Frequentemente, os comentários serão salvos junto com a própria postagem. 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.

Obviamente, você pode fazer o mesmo no SQL, e a desnormalização é uma prática comum quando se precisa de desempenho. Acontece que muitas soluções NoSQL são projetadas desde o início para serem sempre usadas dessa maneira. Você obtém as vantagens e desvantagens usuais: por exemplo, adicionar um comentário no exemplo acima será mais lento porque você precisará salvar o documento inteiro. E depois de desnormalizar, você deve 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 as prepare dentro do banco de dados.

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

— Andrea
fonte

4

A propósito, isso pode ser realizado com uma visão materializada simples ou uma camada de cache, enquanto ainda se beneficia de toda a qualidade do SQL. Qualquer coisa adequadamente modelada é relacional, e a duplicação de dados lógicos não é uma solução (a visualização mat. É uma duplicação, mas não uma duplicação lógica, porque é simplesmente uma imagem de outra coisa).

— Morg.

Como eu disse na resposta, pode-se fazer o mesmo no SQL; é que, quando isso se torna a regra, e não a exceção, os bancos de dados NoSQL geralmente são mais rápidos e mais naturais de usar. Em teoria, o SQL é o melhor modelo que se pode usar, mas quando os dados crescem acima de um determinado tamanho, eles simplesmente não conseguem acomodar alguns modelos e a duplicação de dados se torna mais rápida e fácil de raciocinar.

— Andrea

3

Isso é besteira. O modelo relacional abrange tudo o que você pode criar no NoSQL e muito mais. A única vantagem do NoSQL é que uma abordagem simples e inconsistente ao dimensionamento é incorporada e fácil de usar. Não tem nada a ver com SQL e tudo a ver com não se importar com as propriedades do ACID. Você pode ter trabalhos de sincronização entre nós SQL independentes que terão exatamente as mesmas (péssimas) propriedades de dimensionamento e consistência que os repositórios NoSQL possuem. A diferença é que os nós SQL também podem ter consistência, se você optar por isso.

— Morg.

1

E se você tiver 5.000.000.000 de linhas de dados e desejar obter o comentário de todos eles por alguma condição. Não seria mais rápido se você tivesse um índice no campo de comentário da tabela com SQL? A indexação de texto completo melhoraria ainda mais isso.

— Jwize 23/12

@morg - "O modelo relacional abrange tudo o que você pode criar no NoSQL e muito mais." Não, realmente não. Existem muitos exemplos de tipos de dados que são tão ruins para o modelo relacional que forçar os dados a ele resulta em enorme ineficiência. Exemplo: um jogo online tem uma facilidade para armazenar o inventário dos jogadores. Os jogadores têm um conjunto finito de slots numerados, cada um dos quais pode armazenar um ou mais itens de um tipo específico. Há cerca de 50 tipos diferentes de produto, cada um dos quais tem 4-6 atributos associados, com alguma sobreposição, por isso há cerca de 80 atributos possíveis ...

— Jules

27

O que está faltando no NoSQL é que o NoSQl não pode ser comparado ao SQL de nenhuma maneira. NoSQL é o nome de todas as tecnologias de persistência que não são SQL. DBs de documentos, DBs de valor-chave e DBs de eventos são todos NoSQL. Eles são todos diferentes em quase todos os aspectos, seja a estrutura de dados salvos, consultas, desempenho e ferramentas disponíveis.

Portanto, se alguém lhe fizer essa pergunta na entrevista, essa deve ser a resposta.

— Eufórico
fonte

4

Se existe um recurso matador do NoSQL, eu diria que é a escalabilidade. É por isso que o Facebook e o Google o usam. Por causa do volume gigantesco de dados. NoSQL: quando você precisa lidar com enormes quantidades de dados.

— Pieter B

16

Os bancos de dados 'NoSQL' (ou mais precisamente: não relacionais) renunciam a alguns recursos dos bancos de dados tradicionais por velocidade, mas mais importante por escalabilidade horizontal.

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

— Karl
fonte

1

Descrever o NoSQL como não relacional não é mais preciso. Existem outros bancos de dados não relacionais antigos que não se enquadram na categoria NoSQL. NoSQL significa muito mais do que apenas não-relacionais. Leia isto para obter mais informações: martinfowler.com/bliki/NosqlDefinition.html

— eddyP23:

8

Você está certo, seria um absurdo afirmar isso em uma declaração geral. Qual é provavelmente o ponto todo; 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 deles, em que ambiente operacional etc.), a solução NoSQL específica . Eles tentarão descobrir como você analisa os problemas e, ao longo do caminho, terão uma idéia do quanto você sabe sobre as diferentes soluções existentes.

— Eelco
fonte

Sim, é uma afirmação geral e, se aceitamos que seja verdade, a resposta para a pergunta é: depende.

— Rolf

5

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 em vez de mais, especialmente se não tiver orçamento suficiente para pagar por servidores com grandes quantidades de RAM.

Veja este artigo que compara o uso do espaço em disco do MySQL com o do MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

— Clifford
fonte

3

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

http://www.youtube.com/watch?v=b2F-DItXtZs

Não direi que metade das coisas reivindicadas sobre o NoSQL estão erradas, mas direi que há muito fanboyismo no NoSQL por aí de pessoas que realmente não o entendem muito bem.

O SQL tem seus limites (é claro), mas também é uma tecnologia muito madura, que é bem entendida e tem um grande conjunto de desenvolvedores que sabem como usá-la bem. Não posso dizer o mesmo para todas as formas de NoSQL.

— Zachary K
fonte

-2

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

No RDBMS, ele percorre cada linha e coleta o valor e soma e divisão para o resultado. Quando se trata de banco de dados Columnar, não é necessário se preocupar com todas as iterações de uma linha. Mas lide com apenas uma linha que é mais rápida de calcular. Assim, às vezes, o NoSQL é mais rápido que o SQL. Nesse caso, o NoSQL não se importa com reclamações de ACIDs!

— kiran teja avvaru
fonte

2

Corrigi um pouco a formatação, embora não tenha certeza do que você está tentando obter entre os dois. E o ACID também nem sempre é suportado pelo RDBMS.

-3

Esqueça a teoria dos bancos de dados .... o ponto em que você entender suas consultas, poderá salvar os dados nos bancos de dados nosql da maneira exata em que eles são realmente usados em seu aplicativo ....

Por exemplo, considere este exemplo: você tem um modelo de cliente com muitos pedidos e muitos itens associados a cada pedido; eles também têm muitos itens salvos para compras posteriores ... se você é uma grande loja de comércio eletrônico, digamos 10 milhões de clientes e 50 milhões de pedidos. E esse cliente efetua login no painel que exibe esses dados exatos, quanto trabalho um banco de dados sql precisará fazer para encontrar o cliente, juntar os pedidos e cada item de linha e itens salvos. Em um banco de dados sql, todos esses dados provavelmente precisarão se juntar de alguma forma ... ou você pode criar uma coleção em seu banco de dados chamada usercache e salvar esses dados exatamente como você os usa na vida real. Portanto, pode ser realmente uma única consulta em um único campo [id] para recuperar todos esses dados. Além disso, o banco de dados nosql não

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

— Steffan Perry
fonte