Quais são as vantagens de usar um banco de dados sem esquema como o MongoDB em comparação com um banco de dados relacional?


95

Estou acostumado a usar bancos de dados relacionais como MySQL ou PostgreSQL e combinados com frameworks MVC como Symfony, RoR ou Django, e acho que funciona muito bem.

Mas ultimamente tenho ouvido muito sobre o MongoDB, que é um banco de dados não relacional ou, para citar a definição oficial ,

um banco de dados escalonável, de alto desempenho, de código aberto, sem esquemas e orientado a documentos.

Estou muito interessado em estar no limite e quero estar ciente de todas as opções que terei para um próximo projeto e escolher as melhores tecnologias que existem.

Em quais casos o uso do MongoDB (ou bancos de dados semelhantes) é melhor do que o uso de bancos de dados relacionais "clássicos"? E quais são as vantagens do MongoDB em relação ao MySQL em geral? Ou pelo menos, por que é tão diferente?

Se você tiver dicas para documentação e / ou exemplos, será de grande ajuda também.

Respostas:


57

Aqui estão algumas das vantagens do MongoDB para construir aplicativos da web:

  1. Um modelo de dados baseado em documento. A unidade básica de armazenamento é análoga a JSON, dicionários Python, hashes Ruby, etc. Esta é uma rica estrutura de dados capaz de conter arrays e outros documentos. Isso significa que você geralmente pode representar em uma única entidade uma construção que exigiria várias tabelas para representar adequadamente em um banco de dados relacional. Isso é especialmente útil se seus dados forem imutáveis.
  2. Capacidade de consulta profunda. O MongoDB oferece suporte a consultas dinâmicas em documentos usando uma linguagem de consulta baseada em documentos que é quase tão poderosa quanto SQL.
  3. Sem migrações de esquema. Como o MongoDB não tem esquema, seu código define seu esquema.
  4. Um caminho claro para a escalabilidade horizontal.

Você precisará ler mais sobre isso e brincar para ter uma ideia melhor. Aqui está uma demonstração online:

http://try.mongodb.org/


3
Aceitei essa resposta, mas veja abaixo as outras boas respostas. @marcgg respondeu com links interessantes, por exemplo.
Guillaume Flandre

Dizer "melhor desempenho" é enganoso; depende do que você está fazendo. O fato de o MongoDB não suportar junções não o torna mais rápido, apenas significa que ele é melhor em operações simples de banco de dados (supostamente, na verdade não vi um benchmark para provar isso). Assim que precisar da funcionalidade que as junções fornecem, seu desempenho com o Mongo cairá drasticamente. Mas se você não precisa de junções ou recursos relacionais, então com certeza, o Mongo pode ter mais desempenho / escalabilidade.
Sasha Chedygov

Obrigado @SashaChedygov. Eu concordo com você. Isso foi muito descuidado da minha parte em 2010 :)
Kyle Banker

@KyleBanker: Não se preocupe, apenas comentando caso alguém veja em 2013 e tenha a ideia errada. :) +1 para a edição.
Sasha Chedygov

O Mongo oferece um caminho muito específico de escalabilidade horizontal, que é útil em cenários específicos ....
AK_

23

As vantagens são inúmeras.

Por exemplo, seu esquema de banco de dados será mais escalável, você não terá que se preocupar com migrações, o código será mais agradável de escrever ... Por exemplo, aqui está um dos códigos do meu modelo:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Adicionar uma chave é apenas adicionar uma linha de código!

Existem também outras vantagens que surgirão no longo prazo, como uma melhor escalabilidade e velocidade.

... Mas tenha em mente que um banco de dados não relacional não é melhor do que um relacional . Se o seu banco de dados tiver muitas relações e normalização, pode fazer pouco sentido usar algo como o MongoDB. É tudo uma questão de encontrar a ferramenta certa para o trabalho.

Para mais coisas para ler, eu recomendo dar uma olhada em " Por que eu acho que o Mongo é para os bancos de dados o que o Rails foi para os Frameworks " ou este post no site do mongodb. Para ficar animado e se você fala francês, dê uma olhada neste artigo que explica como configurar o MongoDB do zero.

Edit: Quase esqueci de falar sobre esse railscast de Ryan . É muito interessante e dá vontade de começar já!


Este railscast parece realmente interessante; vou dar uma olhada nele, espero ter um melhor entendimento de como isso funciona.
Guillaume Flandre

5

A vantagem do esquema sem esquema é que você pode despejar qualquer carga que esteja nele, e ninguém jamais terá qualquer motivo para reclamar ou dizer que estava errado.

Também significa que tudo o que você despeja nele permanece totalmente vazio de significado depois de ter feito isso.

Alguns classificariam isso como uma grande desvantagem, outros não.

O fato de um banco de dados relacional possuir um esquema bem estabelecido, é consequência do fato de ele possuir um conjunto bem estabelecido de predicados extensionais, que são os que nos permitem atribuir significado ao que está registrado no banco de dados, e quais são também um pré-requisito necessário para que o façamos.

Sem um esquema bem estabelecido, sem predicados extensionais e sem precicados extensionais, não há como o usuário extrair qualquer significado do que foi inserido nele.


1
Esta é realmente uma anti-resposta. A maior parte do significado, como a maioria das pessoas o entende, surge de mais do que apenas conceitos relacionais. Na verdade, é mais difícil para a maioria dos desenvolvedores de aplicativos discernir o significado de um esquema altamente normalizado do que para um armazenamento de documentos.
user1020853

1
O significado, segundo a lógica, deriva de proposições. As proposições podem surgir de predicados com lugares livres se e quando esses lugares livres são substituídos por itens de dados reais. Mas esses itens de dados devem vir de uma estrutura. E se existe uma estrutura, existe um esquema. Conseqüentemente, se não há esquema, não há estrutura que possa servir para construir proposições que então dêem origem a significado, exceto colocando o dedo no ar e inventando um. Isso não é anti-nada ou pró-nada, é um fato simples e claro.
Erwin Smout

3
Essa é apenas uma visão de significado e se encaixa apenas em um contexto intelectual bastante restrito (e é filosófico, não lógico). Sua resposta é basicamente "se você não tem um esquema como um banco de dados relacional, então você não tem significado". Isso dificilmente é uma resposta à pergunta original de "quais são as vantagens?" portanto, chamo de anti-resposta. Também não é realmente verdade, a menos que restrinjamos o "significado" a este contexto estreito de onde você está vindo. Há muito espaço para "significado" sem um "esquema bem estabelecido".
user1020853

1
Então, que tal você me mostrar como é a sua visão "mais ampla" do "significado" e como ela pode existir sem os predicados ou proposições da lógica. Observe que meu comentário não mencionou a palavra "relacional" nenhuma vez. A tecnologia de dados pré-relacionais tinha esquemas e, portanto, era adequada para inferir "significado". A tecnologia de pré-banco de dados tinha esquemas e, portanto, era adequada para inferir "significado". Esquema livre não tem esquema (a menos que a parte "livre" seja uma mentira completa) e, portanto, não é adequado para inferir "significado". ...
Erwin Smout

1
... Schema-free força seus usuários a um jogo de adivinhação. E mesmo que esses usuários consigam acertar 90 ou 99% das vezes, ainda é apenas isso, um jogo de adivinhação.
Erwin Smout


3

Minha experiência com Postgres e Mongo após trabalhar com os dois bancos de dados em meus projetos.

Postgres (RDBMS)

O Postgres é recomendado se seus aplicativos futuros tiverem um esquema complicado que precise de muitas junções ou todos os dados tiverem relações ou se houver muita escrita. Postgres é open source, mais rápido, compatível com ACID e usa menos memória em disco, e também tem bom desempenho para armazenamento JSON e inclui serializabilidade completa de transações com 3 níveis de isolamento de transação.

A maior vantagem de ficar com o Postgres é que temos o melhor dos dois mundos. Podemos armazenar dados em JSONB com restrições, consistência e velocidade. Por outro lado, podemos usar todos os recursos SQL para outros tipos de dados. O mecanismo subjacente é muito estável e lida bem com uma boa variedade de volumes de dados. Ele também funciona com sua escolha de hardware e sistema operacional. Postgres fornecendo recursos NoSQL junto com suporte total a transações, armazenando documentos JSON com restrições nos dados dos campos.

Restrições gerais para Postgres

Escalonar Postgres horizontalmente é significativamente mais difícil, mas factível.

As operações de leitura rápida não podem ser totalmente realizadas com o Postgres.

SEM bases de dados SQL

Mongo DB (tigre com fio)

O MongoDB pode vencer o Postgres em dimensão de “escala horizontal”. Armazenar JSON é o que o Mongo é otimizado para fazer. O Mongo armazena seus dados em um formato binário chamado BSONb que é (aproximadamente) apenas uma representação binária de um superconjunto de JSON. O MongoDB armazena objetos exatamente como foram projetados. De acordo com o MongoDB, para aplicativos de gravação intensiva, Mongo diz que o novo mecanismo (Wired Tiger) oferece aos usuários um aumento de até 10 vezes no desempenho de gravação (eu deveria tentar isso), com 80 por cento de redução na utilização do armazenamento, ajudando a reduzir os custos de armazenamento , obter uma maior utilização de hardware.

Restrições gerais do MongoDb

O uso de um mecanismo de armazenamento sem esquema leva ao problema de esquemas implícitos. Esses esquemas não são definidos por nosso mecanismo de armazenamento, mas sim com base no comportamento e nas expectativas do aplicativo.

As tecnologias NoSQL autônomas não atendem aos padrões ACID porque sacrificam proteções de dados críticos em favor do desempenho de alto rendimento para aplicativos não estruturados. Não é difícil aplicar ACID em bancos de dados NoSQL, mas tornaria o banco de dados lento e inflexível até certo ponto. “A maioria das limitações NoSQL foram otimizadas nas versões e lançamentos mais recentes que superaram suas limitações anteriores em grande medida”.


2

É tudo uma questão de compensações. O MongoDB é rápido, mas não é ACID, não possui transações. É melhor que o MySQL em alguns casos de uso e pior em outros.


Por favor, reveja este comentário agora. MongoDb 4.0 agora suporta transações ácidas.
Anant Simran Singh

1

Bellow Lines Written in MongoDB: The Definitive Guide.

Existem vários bons motivos:

  1. Manter diferentes tipos de documentos na mesma coleção pode ser um pesadelo para desenvolvedores e administradores. Os desenvolvedores precisam ter certeza de que cada consulta está retornando apenas documentos de um determinado tipo ou que o código do aplicativo que executa uma consulta pode manipular documentos de diferentes formas. Se estivermos procurando por postagens de blog, é um incômodo eliminar documentos que contêm dados do autor.
  2. É muito mais rápido obter uma lista de coleções do que extrair uma lista dos tipos de uma coleção. Por exemplo, se tivéssemos uma chave de tipo na coleção que dissesse se cada documento era um documento "skim", "inteiro" ou "chunky monkey", seria muito mais lento encontrar esses três valores em uma única coleção do que tem três coleções separadas e consulta por seus nomes
  3. O agrupamento de documentos do mesmo tipo na mesma coleção permite a localização dos dados. Obter várias postagens de blog de uma coleção que contém apenas postagens provavelmente exigirá menos buscas em disco do que obter as mesmas postagens de uma coleção que contém postagens e dados do autor.
  4. Começamos a impor alguma estrutura em nossos documentos quando criamos índices. (Isso é especialmente verdadeiro no caso de índices exclusivos.) Esses índices são definidos por coleção. Colocando apenas documentos de um único tipo na mesma coleção, podemos indexar nossas coleções com mais eficiência

0

Depois de uma questão de bancos de dados com armazenamento textual), dei uma olhada no MongoDB e sistemas semelhantes.
Se bem entendi, eles devem ser mais fáceis de usar e configurar, e muito mais rápidos. Talvez também mais seguro, pois a falta de SQL impede a injeção de SQL ...
Aparentemente, o MongoDB é usado principalmente para aplicativos da web.
Basicamente, e eles próprios afirmam, esses bancos de dados não são adequados para consultas complexas, mineração de dados etc. Mas eles brilham na recuperação rápida de muitos dados simples.


1
Há alguns conceitos errados em sua resposta. Embora o MongoDB não seja vulnerável à injeção de SQL, ele é suscetível à injeção de maneira mais geral. Você pode especificar Javascript arbitrário na cláusula $ where de uma consulta. Além disso, ao contrário de muitas outras opções NoSQL, o MongoDB pode realmente fazer algumas consultas bastante complexas.
Emily

Obrigado pelas precisões. Observe que, como afirmei, é o próprio site MongoDB que emitiu restrições às consultas relacionais. A menos que eu não tenha entendido outra coisa ...
PhiLho

Parece bastante provável que eles tenham dito que o MongoDB não é adequado para consultas relacionais complexas, mas para consultas não relacionais complexas, ele é bastante adequado. Dê uma olhada em mongodb.org/display/DOCS/Advanced+Queries para algumas das coisas legais que você pode fazer.
Emily

0
  1. MongoDB suporta pesquisa por campos, pesquisas de expressão regular. Inclui funções de script java definidas pelo usuário.
  2. O MongoDB pode ser usado como um sistema de arquivos, aproveitando as vantagens dos recursos de balanceamento de carga e replicação de dados em várias máquinas para armazenamento de arquivos.
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.