Quais são as diferenças entre o NoSQL e um RDBMS tradicional?


71

Quais são as diferenças entre o NoSQL e um RDBMS tradicional?

Nos últimos meses, o NoSQL foi mencionado com frequência nas notícias técnicas. Quais são os recursos mais significativos em relação a um RDBMS tradicional? Em que nível (físico, lógico) as diferenças ocorrem?

Onde estão os melhores lugares para usar o NoSQL? Por quê?

Respostas:


61

NoSQL significa "Não apenas SQL" e geralmente significa que o banco de dados não é um banco de dados relacional, que tem sido muito popular nas últimas décadas.

A razão pela qual o NoSQL tem sido tão popular nos últimos anos é principalmente porque, quando um banco de dados relacional cresce em um servidor, não é mais tão fácil de usar. Em outras palavras, eles não se expandem muito bem em um sistema distribuído. Todos os grandes sites que você mencionou Google, Yahoo, Facebook e Amazon (eu não sei muito sobre o Digg) têm muitos dados e os armazenam em sistemas distribuídos por vários motivos. Pode ser que os dados não se ajustem em um servidor ou haja requisitos para alta disponibilidade .

Teorema da CAP

As propriedades de um sistema distribuído podem ser descritas pelo teorema do CAP . Das três propriedades, você só pode ter no máximo duas:

  • C OERÊNCIA
  • Uma disponibilidade
  • tolerância à criação de rede P

O Amazon Dynamo usa a Eventual Consistency para se aproximar e obter as três propriedades. Vale a pena ler o artigo Dynamo: armazenamento de valores-chave altamente disponível da Amazon ao aprender sobre os bancos de dados NoSQL e sistemas distribuídos. O Amazon Dynamo possui as propriedades A e P.

O Google adota uma abordagem diferente com o BigTable , que possui as propriedades C e A.

Outros bancos de dados NoSQL

Como escrevi no começo, existem muitos outros tipos de bancos de dados NoSQL, projetados para diferentes requisitos. Por exemplo, bancos de dados gráficos como o Neo4j , bancos de dados de documentos como CouchDB e bancos de dados de modelos / objetos como o OrientDB .

Finalmente, gostaria de dizer que os bancos de dados relacionais permanecerão populares. Eles são muito flexíveis e sustentáveis. Mas eles nem sempre são a melhor escolha.


11
Resposta boa e exaustiva.
TML

NoSQL NÃO significa não relacional, apenas significa algo diferente de um SQL DBMS.
Nvogel

11
Parece que, na recente O'Reilly Strata Conference, Mark Madsen cunhou uma nova interpretação do "NoSQL" em sua história de bancos de dados em notação para substituir o "Not Only SQL". Agora é: "Não, SQL" ;-)
Lukas Eder

6
"Não apenas" foi um retrofit, o movimento NoSQL inicial foi violentamente contra bancos de dados relacionais. Então eles atingiram o mundo real.
Gaius

22

NoSQL é um termo muito amplo e geralmente é referido como significando "Não apenas SQL". O termo está caindo em desuso na comunidade que não é RDBMS.

Você verá que o banco de dados NoSQL tem poucas características comuns. Eles podem ser divididos em algumas categorias:

  • armazenamentos de chave / valor
  • Bancos de dados inspirados em Bigtable (com base no documento do Google Bigtable)
  • Bancos de dados inspirados no Dynamo
  • bancos de dados distribuídos
  • bancos de dados de documentos

Essa é uma pergunta enorme, mas é bastante bem respondida nesta pesquisa de bancos de dados distribuídos .

Para uma resposta curta:

Os bancos de dados NoSQL podem dispensar várias partes do ACID para obter outros benefícios - tolerância da partição, desempenho, distribuição de carga ou escala linear com a adição de novo hardware.

Quanto a quando usá-los - isso depende inteiramente das necessidades do seu aplicativo.


12

O NoSQL é um tipo de banco de dados que não possui um esquema fixo, como um RDBMS tradicional. Com os bancos de dados NoSQL, o esquema é definido pelo desenvolvedor em tempo de execução. Eles não escrevem instruções SQL normais no banco de dados, mas usam uma API para obter os dados necessários. Os bancos de dados NoSQL geralmente podem ser dimensionados em diferentes servidores físicos facilmente, sem precisar saber em qual servidor os dados que você está procurando estão.

No entanto, existem algumas vantagens para toda essa flexibilidade: os bancos de dados NoSQL são bastante carentes em comparação com os sistemas RDBMS como SQL Server, Oracle, DB2, MySQL, etc. Não há Service Broker, log de transações, pacotes ETL etc.

NoSQL não é algo novo. Realmente existe há 50-60 anos. Naquela época, era chamado COBOL. A mesma idéia exata, apenas um grupo diferente surgiu com ela.


3
O ponto 1 está incorreto para muitos bancos de dados NoSQL (todos?), A menos que você tenha explicitamente informado ao banco de dados que não se importa se as gravações tiverem êxito. Por exemplo, qualquer banco de dados suportado pelo Hadoop gravará os dados em três locais, como o inferno ou o mar. Por padrão, o Cassandra gravará em três locais e reconhecerá a gravação como bem-sucedida quando duas tiverem êxito.
Jeremiah Peschka

3
Como ele lida com a simultaneidade ao fazer essas atualizações? Existe uma transação de tipo distribuído entre eles ou a gravação foi ACK previamente e os servidores lidam com o restante em segundo plano?
mrdenny

A simultaneidade depende inteiramente da implementação. Riak usa relógios de vetor para garantir a simultaneidade e, no caso de gravações conflitantes, eles podem ser retornados ao aplicativo de chamada para resolução. Outros usam as últimas vitórias de gravação.
Jeremiah Peschka

No que diz respeito ao reconhecimento de gravação - na maioria dos casos, as gravações não são confirmadas até que o SO reconheça a gravação. Você pode até solicitar o reconhecimento de gravações duráveis, o que significa que os bits são realmente liberados no disco em vez de estarem no buffer do SO. O MongoDB reconhece gravações na memória por padrão, mas pode ser configurado para exigir o reconhecimento da gravação no disco. A replicação é tratada de maneira diferente com cada produto. Com o Hadoop, o cliente grava no servidor A, que grava em B, que grava em C. Quando C responde, a gravação é concluída e o cliente recebe uma gravação em branco.
Jeremiah Peschka

Nesse caso, estou corrigido. Eu removi a declaração incorreta. Eu FUBAR alguma outra coisa?
mrdenny

6

A dispensação básica da configuração relacional, das chaves primárias e estrangeiras e da sobrecarga adicional envolvida na manutenção da segurança das transações, geralmente proporciona aumentos extremos no desempenho. No entanto, isso não é exclusivo dos novos bancos de dados / datastores, como por exemplo, o MySQL foi ajustado para executar em "níveis NoSQL" ignorando as camadas.

Em resumo, muitas vezes você pode obter um desempenho impressionante se estiver bem em correr o risco de possivelmente perder dados. A maioria dos sistemas NoSQL faz isso. Por exemplo, o MongoDB encena as alterações de dados a serem gravadas quando for conveniente. Os dados em si são seguros e transacionais, mas mantidos em armazenamento volátil (memória). Se você perder energia, não poderá ter 100% de certeza de que não perdeu dados ou de que não possui dados corrompidos.

É uma troca entre segurança e desempenho.


5

Um bom lugar para começar é a entrada da Wikipedia . Basicamente, em vez de relacionar dados em uma tabela para outra, você armazena as coisas como pares de valores-chave e não há esquema do banco de dados, eles são tratados no código.

Alguns sites usam o NoSQL e os servidores RDBMS típicos simultaneamente, mas para armazenar dados diferentes. Então você não precisa escolher um ou outro.


O fato de que a maior parte desta pergunta pode ser respondida pelo WP me faz esfregar o queixo enquanto contemplo as respostas aqui. Eu acho que é um pouco demais "questão de preenchimento", mas isso é realmente tudo o que temos agora.
jcolebrand

11
A observação importante aqui é que evitar o suporte a relações (chave estrangeira) na infraestrutura de banco de dados / servidor alivia o banco de dados / servidores da sobrecarga de gerenciamento de carga e bloqueio de manter a integridade referencial. A conseqüência disso, o trade-off, é que a integridade referencial, a consistência e as outras preocupações com o ACID são enviadas aos aplicativos. Muitos aplicativos se beneficiam com isso, em vez de serem limitados por ele. (Alguns aplicativos precisam ser inseridos no modelo cliente / servidor).
Jim Dennis

0

Eu trabalhei muito no banco de dados MongoDB NoSQL e Oracle.

Esquema

O banco de dados SQL possui seu próprio esquema predefinido para armazenar dados estruturados.

No banco de dados NoSQL, não há esquema predefinido, aqui o esquema é o elemento mais dinâmico com base nos elementos de dados.

Escalabilidade

Os bancos de dados SQL são escaláveis ​​verticalmente, o que significa que, se quisermos escalar o banco de dados SQL, precisamos dar um impulso ao hardware no qual o sistema DBMS está instalado. É aqui que às vezes vale a limitação da escalabilidade.

Os bancos de dados NoSQL são escaláveis ​​horizontalmente, ou seja, se quisermos escalá-lo, precisamos adicionar mais nós e criar uma rede de distribuição com base em nossa própria necessidade e energia necessária. É assim que eles reduzem a carga no banco de dados

Recuperação de dados

Em bancos de dados baseados em SQL, para definir e manipular dados, podemos usar o SQL (Structured Query Language), que é muito poderoso atualmente.

Em termos de banco de dados NoSQL, as consultas se concentram na coleta e nos documentos. Às vezes, é chamado UnQL (Unstructured Query Language). Isso ainda está na fase de evolução, portanto varia de fornecedor para fornecedor do banco de dados NoSQL.

Para saber mais sobre as principais diferenças, meu blog: Diferença entre banco de dados SQL e NoSQL

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.