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

Question

Oferecemos uma plataforma para clipes de vídeo e áudio, fotos e vetores-grafics. Começamos com o MySQL como back -end do banco de dados e incluímos recentemente MongoDB Para armazenar todas as meta-informações dos arquivos, porque o MongoDB se encaixa melhor nos requisitos. Por exemplo: as fotos podem ter Exif Informações, vídeos podem ter faixas de áudio, onde queremos armazenar a meta-informação de, também. Vídeos e vetor-Graphics 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 fornecerá um fórum para nossos usuários. A pergunta que agora surge é: use o banco de dados MySQL, que seria uma boa opção para armazenar fóruns e postos de fórum etc. ou usar o MongoDB para isso também?

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

Answer 1

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

O MongoDB não é uma loja de chave/valor, é um pouco mais. Definitivamente, também não é um RDBMS. Não usei o MongoDB na produção, mas usei um pequeno aplicativo de teste e é uma peça de kit muito legal. Parece ser muito performante e tem, ou terá em breve, a tolerância a falhas e o toque automático (também conhecido como escalará). Eu acho que Mongo pode ser a coisa mais próxima de uma substituição do RDBMS que eu já vi até agora. Não funcionará para todos os conjuntos de dados e padrões de acesso, mas foi criado para o seu material típico do CRUD. Armazenar o que é essencialmente um enorme hash e ser capaz de selecionar em qualquer uma dessas teclas é para o que a maioria das pessoas usa um banco de dados relacional. Se o seu banco de dados for 3NF e você não fizer nenhuma junção (você está apenas selecionando um monte de mesas e juntando todos os objetos, também conhecido como o que a maioria das pessoas faz em um aplicativo da web), o MongoDB provavelmente chutará a bunda para você.

Então, na conclusão:

O verdadeiro a apontar é que, se você está sendo impedido de fazer algo super incrível porque não pode escolher um banco de dados, está fazendo errado. Se você conhece o MySQL, basta usá -lo. Otimize quando você realmente precisar. Use -o como AK/V Store, use -o como um RDBMS, mas, pelo amor de Deus, construa seu aplicativo assassino! Nada disso será importante para a maioria dos aplicativos. O Facebook ainda usa muito o MySQL. A Wikipedia usa muito o MySQL. FriendFeed usa MySQL, muito. O NOSQL é uma ótima ferramenta, mas certamente não será sua vantagem competitiva, não vai deixar seu aplicativo quente e, acima de tudo, seus usuários não se importarão com isso.

Em que vou construir meu próximo aplicativo? Provavelmente Postgres. Vou usar o nosql? Pode ser. Eu também posso usar Hadoop e Hive. Eu posso manter tudo em arquivos planos. 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 armazenamento em cache, provavelmente usarei Tokyo Tyrant. Se eu precisar de acidez, não usarei NoSQL. Se eu precisar de uma tonelada de contadores, usarei Redis. Se eu precisar de transações, usarei o PostGres. Se eu tiver uma tonelada de um único tipo de documentos, provavelmente usarei Mongo. Se eu precisar escrever 1 bilhão de objetos por dia, provavelmente usaria Voldemort. Se eu precisar de pesquisa completa de texto, provavelmente usaria o Solr. Se eu precisar de pesquisas completas de texto de dados voláteis, provavelmente usaria Sphinx.

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

Link alternativo para o artigo

Answer 2

Depois de 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 ingressar em dados de diferentes tabelas/coleções, algo que um RDBMS faria por você automaticamente.
2. Seus recursos de consulta com o NOSQL são drasticamente aleijados. O MongoDB pode ser a coisa mais próxima do SQL, mas ainda está extremamente para trá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 aproveitar apenas um índice. E o MongoDB é provavelmente um dos bancos de dados NOSQL mais flexíveis. Em muitos cenários, isso significa mais ida e volta ao servidor para encontrar registros relacionados. E então você inicia dados de desnormalização - 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á (pensou por alguns com desempenho ruim) restrições de chaves estrangeiras para garantir que seus dados sejam consistentes. Garanto que isso acabará por criar inconsistências de dados no 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.

Answer 3

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 no formato do documento. Esses rdbms altenativos chamaram Nosql lojas de dados (MongoDB, Couchdb, Voldemort) são muito úteis para aplicativos que escalam massivamente e requerem acesso de dados mais rápido dessas lojas de big data.

E a implementação desses bancos de dados é mais simples que o RDBMS regular. Como estes são objetos binários simples com valor-chave ou de documento diretamente serializados no disco. Esses lojas de dados não aplicam o Propriedades ácidas, e qualquer Esquemas. Isso não fornece nenhum transação habilidades. Portanto, isso pode escalar grande e podemos obter acesso mais rápido (leitura e gravação).

Mas, por outro lado, o RDBM aplica ácido e esquemas em dados. Se você quiser trabalhar com dados estruturados, poderá seguir em frente com o RDBM.

Eu escolheria Mysql para criar Fóruns Para esse tipo de coisa. Porque isso não vai escalar grande. E este é um aplicativo muito simples (comum) que tem relações estruturadas entre os dados.

Answer 4

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

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

Answer 5

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

Answer 6

Quem precisa de fóruns distribuídos e fragmentados? Talvez o Facebook, mas, a menos que você esteja criando um competidor do Facebook, basta usar o MySQL, o PostGres ou o que quer que esteja mais confortável. Se você quiser experimentar o MongoDB, ok, mas não espere que faça mágica por você. Ele terá suas peculiaridades e maldade geral, assim como todo o resto, como tenho certeza de que você já descobriu se realmente já está trabalhando nisso.

Claro, o MongoDB pode ser empolgado e parecer fácil na superfície, mas você terá problemas que os produtos mais maduros já superaram. Não seja atraído com tanta facilidade, mas espere até que "nosql" amadureça ou morra.

Pessoalmente, acho que "nosql" murchará e morre da fragmentação, pois não há padrões definidos (quase por definição). Portanto, não vou apostar pessoalmente em nenhum projeto de longo prazo.

A única coisa que pode salvar "NoSQL" no meu livro é se ele pode se integrar perfeitamente ao rubi ou em idiomas similares e tornar o idioma "persistente", quase sem despesas gerais em codificação e design. Isso pode acontecer, mas vou esperar até então, não agora, e precisa ser mais maduro, é claro.

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

Answer 7

Eu já vi muitas empresas usando o MongoDB para análises em tempo real dos logs de aplicativos. Sua frequência de esquema realmente se encaixa nos registros de aplicativos, onde o esquema de registro tende a mudar o tempo a tempo. Além disso, é Coleção Capped O recurso é útil porque purga automaticamente dados antigos para manter os dados ajustados na memória.

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

Answer 8

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

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

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

Answer 9

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

Answer 10

Como dito anteriormente, você pode escolher entre muitas opções, dê uma olhada em todas essas opções:http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

O que eu sugiro é encontrar sua melhor combinação: MySQL + Memcache é realmente ótimo se você precisar de ácido e deseja se juntar a algumas tabelas MongoDB + Redis é perfeito para a loja de documentos neo4j é perfeita para o banco de dados de gráficos

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