Quando usar o MongoDB ou outros sistemas de banco de dados orientados a documentos? [fechadas]

516

Oferecemos uma plataforma para clipes de vídeo e áudio, fotos e gráficos vetoriais. Começamos com o MySQL como back-end do banco de dados e incluímos recentemente o MongoDB para armazenar todas as meta-informações dos arquivos, porque o MongoDB se adapta melhor aos requisitos. Por exemplo: as fotos podem ter informações Exif , os vídeos podem ter trilhas de áudio nas quais também queremos armazenar as meta-informações. Vídeos e gráficos vetoriais não compartilham nenhuma meta-informação comum etc., então eu sei que o MongoDB é perfeito para armazenar esses dados não estruturados e mantê-los pesquisáveis.

No entanto, continuamos desenvolvendo nossa plataforma e adicionando recursos. Agora, uma das próximas etapas será fornecer um fórum para nossos usuários. A questão que surge agora é: use o banco de dados MySQL, que seria uma boa opção para armazenar fóruns e postagens em fóruns, etc. ou use o MongoDB para isso também?

Portanto, a questão é: quando usar o MongoDB e quando usar um RDBMS. O que você usaria, mongoDB ou MySQL, se você tivesse a escolha e por que a aceitaria?

aurora
fonte
12
Não sei por que isso é marcado como baseado em opiniões, quando claramente não é. Há uma resposta clara ou errada aqui.
Spencer #

Respostas:

659

No NoSQL: se fosse assim tão fácil , o autor escreve sobre o MongoDB:

O MongoDB não é um armazenamento de chave / valor, é um pouco mais. Definitivamente, também não é um RDBMS. Não usei o MongoDB na produção, mas usei um pouco para criar um aplicativo de teste e é um kit muito legal. Parece ter um bom desempenho e possui, ou terá em breve, tolerância a falhas e compartilhamento automático (também conhecido como dimensionamento). Acho que o Mongo pode ser a coisa mais próxima de uma substituição do RDBMS que eu vi até agora. Não funcionará para todos os conjuntos de dados e padrões de acesso, mas foi criado para o seu material CRUD típico. Armazenar o que é essencialmente um enorme hash e poder selecionar qualquer uma dessas chaves é para o que a maioria das pessoas usa um banco de dados relacional.Se o seu banco de dados é 3NF e você não faz nenhuma junção (você está apenas selecionando um monte de tabelas e juntando todos os objetos, também conhecido como o que a maioria das pessoas faz em um aplicativo da web), o MongoDB provavelmente seria bom para você.

Então, na conclusão:

O verdadeiro ponto a ser destacado é que, se você está impedindo de criar algo super impressionante porque não pode escolher um banco de dados, está fazendo errado. Se você conhece o mysql, use-o. Otimize quando você realmente precisar. Use-o como uma loja ak / v, use-o como um rdbms, mas, pelo amor de Deus, crie seu aplicativo matador! Nada disso importa para a maioria dos aplicativos. O Facebook ainda usa muito o MySQL. A Wikipedia usa muito o MySQL. O FriendFeed usa muito o MySQL. O NoSQL é uma ótima ferramenta, mas certamente não será sua vantagem competitiva, não aquecerá seu aplicativo e, acima de tudo, seus usuários não se importarão com nada disso.

No que eu vou construir meu próximo aplicativo? Provavelmente Postgres. Vou usar o NoSQL? Talvez. Eu também poderia usar o Hadoop e o Hive. Eu posso manter tudo em arquivos simples. Talvez eu comece a invadir o Maglev. Vou usar o que for melhor para o trabalho. Se eu precisar de relatórios, não usarei nenhum NoSQL. Se eu precisar de cache, provavelmente usarei o Tokyo Tyrant. Se eu precisar do ACIDity, não usarei o NoSQL. Se eu precisar de uma tonelada de balcões, usarei Redis. Se eu precisar de transações, usarei o Postgres. Se eu tiver uma tonelada de um único tipo de documento, provavelmente usarei o Mongo. Se eu precisar escrever 1 bilhão de objetos por dia, provavelmente usaria o Voldemort. Se eu precisar de pesquisa de texto completo, provavelmente usaria o Solr. Se eu precisar de uma pesquisa de texto completo de dados voláteis, provavelmente usaria o Sphinx.

Gosto deste artigo, acho muito informativo, fornece uma boa visão geral do cenário e do hype do NoSQL. Mas, e essa é a parte mais importante, é realmente útil fazer as perguntas certas quando se trata de escolher entre RDBMS e NoSQL. Vale a pena ler IMHO.

Link alternativo para o artigo

Pascal Thivent
fonte
4
obrigado, é realmente um artigo muito interessante.
aurora
48
@iddqd ROFL! Cara, isso foi hilário. "Se você é estúpido o suficiente para ignorar totalmente a confiabilidade apenas para obter benchmarks, sugiro que você direcione seus dados para /dev/nullque sejam muito rápidos" : D
Pascal Thivent
3
Obrigado pela resposta atenta ao hype.
deamon
2
Espero que BJ Clark não opte por usar todas essas tecnologias no mesmo projeto. Isso seria um pouco de uma curva de aprendizado.
Adam Monsen
186

Após dois anos usando o MongoDb para um aplicativo social, testemunhei o que realmente significa viver sem um SQL RDBMS.

  1. Você acaba escrevendo trabalhos para fazer coisas como juntar dados de diferentes tabelas / coleções, algo que um RDBMS faria automaticamente por você.
  2. Seus recursos de consulta com o NoSQL são drasticamente prejudicados. O MongoDb pode ser a coisa mais próxima do SQL, mas ainda está muito atrás. Confie em mim. As consultas SQL são super intuitivas, flexíveis e poderosas. As consultas do MongoDb não são.
  3. As consultas do MongoDb podem recuperar dados de apenas uma coleção e tirar proveito de apenas um índice. E o MongoDb é provavelmente um dos bancos de dados NoSQL mais flexíveis. Em muitos cenários, isso significa mais viagens de ida e volta ao servidor para encontrar registros relacionados. E então você começa a desnormalizar os dados - o que significa trabalhos em segundo plano.
  4. O fato de não ser um banco de dados relacional significa que você não terá (acredita-se que alguns tenham mau desempenho) restrições de chave estrangeira para garantir que seus dados sejam consistentes. Garanto que isso acabará criando inconsistências de dados em seu banco de dados. Esteja preparado. Provavelmente, você começará a escrever processos ou verificações para manter seu banco de dados consistente, o que provavelmente não terá um desempenho melhor do que permitir que o RDBMS faça isso por você.
  5. Esqueça estruturas maduras como o hibernate.

Acredito que 98% de todos os projetos provavelmente são muito melhores com um SQL RDBMS típico do que com o NoSQL.

Marquez
fonte
10
pensamentos interessantes ...
luigi7up
3
Por outro lado, os recursos de consulta e as junções que você descreve não devem ser um problema: se você usa o MongoDB, ainda precisa fazer algum trabalho para projetar suas coleções e quais dados serão inseridos para que você não precise de problemas complexos. JOINs e assim por diante. De qualquer forma, os bancos de dados não são um gargalo e existem soluções alternativas como o Memcache para alguns casos de uso. Porém, se começar do zero, você pode achar que projetar e usar o MongoDB é mais simples e rápido (como desenvolvedor trabalhando com código de objeto, não preciso de um ORM). Claro que você tem que escrever alguns scripts, mas na verdade não é tão difícil e você reutilizar o código
Aki
1
A maioria das pessoas não usa bancos de dados NoSQL para o caso de uso muito específico para o qual foram criados, reinventando tantas rodas posteriormente. O debate NoSQL vs. SQL mostra que muitas pessoas experimentam o uso do NoSQL como se estivessem voltando 20 a 30 anos no tempo pré-codd, pré-relacional e pré-SQL . Ou, como Michael Stonebraker coloca: "O que vai, volta e volta"
Lukas Eder
1
O item 3, "e aproveite apenas um índice", ainda é válido hoje? Estou entrando no MongoDB agora e parece que li e vi até agora que ele pode suportar vários índices?
Jeach 18/01/14
1
@Each: Não, # 3 não é mais verdade. O MongoDB 2.6 introduziu a interseção do índice .
Rob Garrison
26

para armazenar esses dados não estruturados

Como você disse, o MongoDB é mais adequado para armazenar dados não estruturados. E isso pode organizar seus dados em formato de documento. Esses altenativos do RDBMS, denominados repositórios de dados NoSQL ( MongoDB , CouchDB , Voldemort ), são muito úteis para aplicativos que escalam maciçamente e exigem acesso mais rápido a dados desses armazenamentos de big data.

E a implementação desses bancos de dados é mais simples que o RDBMS comum. Como esses são objetos binários simples, com valor de chave ou estilo de documento, serializados diretamente em disco. Esses armazenamentos de dados não impõem as propriedades ACID e nenhum esquema . Isso não fornece nenhuma habilidade de transação . Portanto, isso pode ser grande e podemos obter acesso mais rápido (leitura e gravação).

Mas, por outro lado, o RDBM aplica ACID e esquemas nos dados. Se você deseja trabalhar com dados estruturados, pode prosseguir com o RDBM.

Eu escolheria o MySQL para criar fóruns para esse tipo de coisa. Porque isso não vai crescer muito. E esta é uma aplicação muito simples (comum) que estruturou relações entre os dados.

RameshVel
fonte
10
"Eu escolheria o mysql para criar coisas como fóruns." Mesmo? Eu acho que coisas como fóruns seriam muito mais fáceis de escrever usando um banco de dados orientado a documentos do que um relacional (se você estivesse escrevendo do zero). Se você não precisar especificamente dos recursos de um RDBMS, diria que vá com o MongoDB ou um banco de dados semelhante para facilitar o uso e a escala.
Sasha Chedygov 01/11/2009
2
O CouchDB possui suporte a ACID. couchdb.apache.org/docs/overview.html
Sonia
De 2018: MongoDB tem suporte ACID bem
Nepoxx
10

Observe que o Mongo essencialmente armazena JSON. Se seu aplicativo está lidando com muitos objetos JS (com aninhamento) e você deseja persistir esses objetos, há um argumento muito forte para usar o Mongo. Isso torna suas camadas DAL e MVC ultrafinas, porque elas não estão descompactando todas as propriedades do objeto JS e tentando ajustá-las à força em uma estrutura (esquema) na qual elas não se encaixam naturalmente.

Temos um sistema que possui vários objetos JS complexos em seu coração e amamos o Mongo porque podemos persistir em tudo muito, muito facilmente. Nossos objetos também são bastante amorfos e não estruturados, e Mongo absorve essa complicação sem pestanejar. Temos uma camada de relatório personalizada que decifra os dados amorfos para consumo humano, e que não foi tão difícil de desenvolver.

Journeyman
fonte
7

Eu diria que use um RDBMS se você precisar de transações complexas. Caso contrário, eu usaria o MongoDB - mais flexível para trabalhar e você sabe que ele pode ser dimensionado quando necessário. (Mas sou tendencioso - trabalho no projeto MongoDB)

mdirolf
fonte
7
Transações complexas não funcionam no MongoDB, mas funcionam em outros bancos de dados NoSQL, como o MarkLogic (também sou tendencioso desde que administro a comunidade de desenvolvedores do MarkLogic).
Eric Bloch
Obrigado pela dica do MarkLogic - eu não sabia disso.
Aurora
Eu gostaria de ouvir de mdirolf sobre isso. Por que o MongoDB optou por não implementar transações?
Aki
7

Quem precisa de fóruns distribuídos e fragmentados? Talvez o Facebook, mas a menos que você esteja criando um concorrente no Facebook, use o Mysql, o Postgres ou o que você quiser. Se você quiser experimentar o MongoDB, ok, mas não espere que ele faça mágica para você. Ele terá suas peculiaridades e desagradabilidade geral, assim como tudo o mais, como tenho certeza de que você já descobriu se já está trabalhando nisso.

Certamente, o MongoDB pode ser sensacional e parecer fácil na superfície, mas você terá problemas que produtos mais maduros já superaram. Não seja atraído com tanta facilidade, mas espere até o "nosql" amadurecer ou morrer.

Pessoalmente, acho que o "nosql" vai murchar e morrer de fragmentação, pois não há padrões estabelecidos (quase por definição). Portanto, não vou apostar pessoalmente em projetos de longo prazo.

A única coisa que pode salvar "nosql" no meu livro é se ele pode se integrar perfeitamente ao Ruby ou a idiomas semelhantes e tornar o idioma "persistente", quase sem sobrecarga na codificação e no design. Isso pode acontecer, mas vou esperar até lá, não agora, e precisa ser mais maduro, é claro.

Btw, por que você está criando um fórum a partir do zero? Existem muitos fóruns de código aberto que podem ser ajustados para atender à maioria dos requisitos, a menos que você realmente esteja criando a próxima geração de fóruns (o que duvido).

Fred
fonte
5
obrigado pela sua resposta. integrar um fórum é uma bagunça - já fizemos isso e decidimos não seguir esse caminho novamente: não precisamos de milhares de recursos, mas de uma integração completa em nosso software.
Aurora
4

Eu já vi muitas empresas usando o MongoDB para análises em tempo real a partir dos logs do aplicativo. Sua ausência de esquema realmente se encaixa nos logs de aplicativos, onde o esquema de registros tende a mudar de tempos em tempos. Além disso, seu recurso Capped Collection é útil porque limpa automaticamente os dados antigos para manter os dados ajustados na memória.

Essa é uma área em que realmente acho que o MongoDB se encaixa, mas o MySQL / PostgreSQL é mais recomendado em geral. Existem muitas documentações e recursos para desenvolvedores na Web, assim como sua funcionalidade e robustez.

Kazuki Ohta
fonte
4

A 2 principal razão pela qual você pode preferir o Mongo é

  • Flexibilidade no design do esquema (armazenamento de documentos do tipo JSON).
  • Escalabilidade - basta adicionar nós e ele pode ser dimensionado horizontalmente muito bem.

É adequado para aplicativos de big data. RDBMS não é bom para big data.

Sushant Gupta
fonte
3

Você sabe, todo esse material sobre as junções e as 'transações complexas' - mas foi o próprio Monty que, há muitos anos, explicou a "necessidade" de COMMIT / ROLLBACK, dizendo que 'tudo o que é feito nas classes lógicas (e não o banco de dados) de qualquer maneira '- então é a mesma coisa novamente. O que é necessário é um mecanismo de armazenamento / recuperação de dados estúpido, mas incrivelmente organizado e rápido, para 99% do que os aplicativos da web fazem.

FYA
fonte
Obrigado, você está levantando um ponto interessante aqui. Eu realmente estaria interessado na explicação de Monty, porque não tenho certeza de quão complexas são as reversões de atualizações em várias tabelas na lógica pura do aplicativo - não tenho certeza, se isso é realmente possível?
Aurora
Também não tenho certeza da melhor maneira. Sempre rastreamos tudo o que foi feito no banco de dados e, em seguida, permitimos ou desfazemos no nível do aplicativo, no código. Nunca confiamos em transações, em nenhum lugar, nunca. Os documentos do Mongo sugerem o uso de metadados para rastrear quais partes da transação reversível ocorreram, em que estado está a transação, caso ela quebre e precise ser revertida. O engraçado é que já tínhamos feito isso o tempo todo com o MySQL e outros. Não é muito mais trabalho e mantém o foco no que está acontecendo, quando, onde e por que, em vez de no boxe preto.
FYA 25/11
Há uma observação sobre isso no site da 10gen em algum lugar ... mencionando como os campos de 'intertravamento' ou 'catracas' são usados ​​manualmente para indicar o status de um processo de várias etapas. Parece-me que, se você ampliar o mecanismo do MySQL, a "transação em bloco" ainda se expandirá para uma série de etapas, não importa o quê; é só que os intertravamentos ou catracas são feitos de uma maneira muito menor e mais rápida do que rastrear manualmente nos campos do banco de dados.
FYA
Ainda precisamos encontrar uma boa maneira de limitar o daemon MongoDB - ele consome quase toda a RAM disponível para armazenamento de índice e dados na memória, embora produz memória rapidamente quando outros procs precisam. Ainda assim, seria bom ter um 'use_max_memory' ou alguns outros limites facilmente definíveis para garantir que o MongoDB não fuja e envie o servidor para troca de swap (vimos isso várias vezes, mesmo na versão mais recente). Pelo menos o MySQL aceita todos os tipos de limites definíveis e dicas de operação.
FYA
Não está diretamente relacionado, mas meio que: estávamos usando o memcached, mas desistimos dele por causa do fiasco do driver PHP ainda não resolvido do Memcache / Memcached. Usamos o MongoDB como uma chave rápida e temporária: val store (pela qual funcionou muito bem!) Até descobrir o quão rápido e fácil é o apc_store (). Se acharmos que a APC está se enchendo de crud temporário (vs PHP pré-compilado armazenado) que costumávamos stach no memcached, reverteremos para o MongoDB para armazenamento key: val.
FYA
1

Como dito anteriormente, você pode escolher entre várias opções, consulte todas essas opções: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

O que eu sugiro é encontrar a melhor combinação: MySQL + Memcache é realmente ótimo se você precisar de ACID e quiser juntar-se a algumas tabelas. MongoDB + Redis é perfeito para armazenamento de documentos Neo4J é perfeito para banco de dados de gráficos

O que faço: começo com o MySQl + Memcache porque estou acostumado, depois começo a usar outras estruturas de banco de dados. Em um único projeto, você pode combinar MySQL e MongoDB, por exemplo!

Adrien Hadj-Salah
fonte
O MySQL + memcached fornecerá consistência eventual. Que eu não considero ACID em um contexto RDMB.
R. van Twisk