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

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?

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

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.

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.

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.

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)

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).

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.

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.

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.

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!