Quando alguém usaria o MongoDB (ou similar) em um DBMS relacional?

Estou um pouco confuso sobre toda a coisa NoSQL e tal. Quando você escolheria usar algo como MongoDB em vez de algo como Oracle ou MySQL? Eu realmente não entendo a "diferença" quanto ao uso entre eles.

Pelo que entendi, os bancos de dados do tipo NoSQL não pretendem substituir RDBMSes, mas o que exatamente eles devem fazer?

Eu usei o CouchDB antes em três projetos de animais de estimação.

• Um sistema de micro blog.
• Para salvar informações para uma pequena anotação no aplicativo que eu criei.
• Um aplicativo de brainstorming de uso geral.

A principal razão pela qual eu escolhi isso em vez de algo como MSSQL ou MySQL é a flexibilidade que você obtém ao usá-lo. Nenhum esquema rígido. Se três meses depois da linha, você precisa de uma determinada tabela para ter um campo extra, e isso e aquilo, basta alterá-la e ela se ondula a partir daí.

Usei o Beginning CouchDB do Apress para aprender como usá-lo.

Por exemplo, o CouchDB usa o json para se comunicar de / para o banco de dados. Se seu idioma puder POST dados, você pode usá-lo para se comunicar com o banco de dados.

Leia também: Por que devo usar o banco de dados baseado em documento em vez do banco de dados relacional? no StackOverflow

Desculpe adicionar outra resposta, mas nenhuma das respostas aqui é muito satisfatória. Essa resposta é específica para o MongoDB (em oposição à grande variedade de outras opções de armazenamento de dados disponíveis, que não são bancos de dados relacionais).

Prós:

• O MongoDB possui uma latência menor por consulta e gasta menos tempo de CPU por consulta, porque está fazendo muito menos trabalho (por exemplo, sem junções, transações). Como resultado, ele pode lidar com uma carga maior em termos de consultas por segundo e, portanto, é frequentemente usado se você tiver um número maciço de usuários.
• O MongoDB é mais fácil de fragmentar (usar em um cluster) porque não precisa se preocupar com transações e consistência.
• O MongoDB tem uma velocidade de gravação mais rápida, porque não precisa se preocupar com transações ou reversões (e, portanto, não precisa se preocupar com o bloqueio).
• O MongoDB não possui um esquema , caso você tenha um caso de uso especial que possa tirar proveito disso.

Contras:

• O MongoDB não suporta transações . É assim que ele obtém a maioria de seus benefícios.
• Em geral, o MongoDB cria mais trabalho (por exemplo, mais custo de CPU) para o servidor cliente . Por exemplo, para unir dados, é necessário emitir várias consultas e fazer a junção no cliente.
• Mesmo aqui em 2017, há menos suporte a ferramentas para o MongoDB do que para bancos de dados relacionais simplesmente porque é mais recente. Também há menos especialistas em MongoDB do que seus colegas relacionais.

Pontos frequentemente incompreendidos:

• O MongoDB e os bancos de dados relacionais oferecem suporte à indexação. O desempenho da consulta é semelhante em termos de execução de consultas grandes .
• O MongoDB não remove a necessidade de migrações ou, mais especificamente, atualizando os dados existentes à medida que o esquema evolui. Por exemplo: Se você possui um aplicativo que depende de uma tabela de usuários para conter determinados dados e modifica essa tabela para conter dados diferentes (digamos que você adicione um campo de imagem do perfil), ainda precisará:
  • Escreva seu aplicativo para manipular objetos para os quais essa propriedade é indefinida OU
  • Escreva uma migração única para inserir um valor padrão para esta propriedade OU
  • Escreva o código para fornecer um valor padrão no momento da consulta, se este campo não estiver presente OU
  • Manipule o campo ausente de alguma outra maneira

Para roubar descaradamente o Renesis (na verdade, estou fazendo esta resposta CW):

Usando RDBMSs em vez de outros tipos:

• Leia a idéia do "NoSQL" e outros tipos de banco de dados:
  • NoSQL: Se ao menos fosse assim tão fácil
  • (acima está linkado de) Quando usar o MongoDB ou outros sistemas de banco de dados orientados a documentos? ^{atualmente excluído no SO} ( mais )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Quando usar o CouchDB vs RDBMS
• Os RDBMS fazem uso pesado de indexação para desempenho. Em bancos de dados muito grandes, isso pode afetar negativamente o desempenho ou até reduzir o número ideal de linhas por DB / Shard, exigindo mais hardware
• Não é o ideal se você estiver armazenando uma quantidade enorme de dados, mas lendo com menos frequência
• Se você não possui muitos relacionamentos externos, os bancos de dados relacionais podem não ser ideais (armazenamento de documentos)

Quando seus dados não são relacionais, pode haver grandes benefícios no uso de bancos de dados NoSQL, como desempenho e escalabilidade (dependendo das circunstâncias, é claro). Alguns padrões de design como o CQRS facilitam muito o aproveitamento de dados não relacionais em áreas que convencionalmente exigiriam o uso exclusivo de um banco de dados SQL.

É comum usar bancos de dados como o mongo para dados em cache. Por exemplo, se você precisar gerar um relatório, poderá fazer uma consulta SQL complicada que une e agrega um monte de dados em tempo real, ou pode apenas buscar um único documento json do banco de dados mongo que já tem tudo o que precisa para gerar o relatório. Isso torna a leitura de dados realmente fácil (e rápido!), Mas pode tornar a gravação de dados bastante complicada (é aqui que o CQRS entra).

Bancos de dados como o MongoDB são ótimos quando você geralmente sabe onde estão seus dados (em vez de precisar escrever várias consultas complicadas). Com o Mongo, os dados "relacionados" são aninhados nos dados pai ou possuem chaves primárias / estrangeiras. Isso é ótimo se, por exemplo, você tiver Postagens e Comentários; geralmente, você não exibirá comentários fora do contexto de uma postagem; portanto, faz sentido que os comentários sejam contidos em uma postagem (dessa forma, você obtém todos os comentários da postagem sem precisar consultar uma tabela separada).

O MongoDB não possui esquema. Isso significa que será necessário qualquer estrutura de dados que você lançar nela, na maior parte.

Por outro lado, se você precisar usar funções agregadas e sentir a necessidade de consultar dados de maneiras complexas que não podem ser alcançadas por meio de incorporações ou relações simples no Mongo, é quando você sabe que é hora de usar um RDBMS como MySQL ou PostgreSQL.

O MongoDB não pretende substituir o SQL. Ele simplesmente atende a diferentes necessidades, e o MongoDB e um RDBMS podem ser usados ​​em conjunto. Na minha opinião, o MongoDB não é tudo o que é necessário se você não precisar que seus dados sejam flexíveis ou incorporados a um documento pai. O desenvolvimento com o MongoDB é muito divertido, porque há muito menos etapas envolvidas na instalação e execução de um projeto (digamos no Rails). Precisa fazer uma alteração? Sem problemas. Basta adicionar um atributo ao seu modelo. Feito.

Não posso falar em muitos outros bancos de dados NoSQL, embora saiba que eles geralmente são projetados de maneira semelhante para atender a uma necessidade específica que não pode ser atendida por um RDBMS. Alguns residem inteiramente na memória ou podem ser fragmentados ou redimensionados com muita facilidade. Tenho certeza de que o Cassandra foi projetado para continuar operando sem perda de dados se um nó cair. O Redis é basicamente um armazenamento de valores-chave que reside na memória (com gravações periódicas em disco para persistência), mas também tem a capacidade de armazenar tipos de dados como conjuntos e classificá-los.

A grande vitória é quando você deseja compartilhar dados ou ter bancos de dados multimestres. Você pode compartilhar dados no MySQL, mas isso se torna um grande problema. Se você estiver fazendo muitas gravações, geralmente é útil compartilhar os dados em vários servidores, o problema é que, se você deseja ter uma consistência referencial forte ao fazer isso, pode ser muito difícil, se não impossível, procurar o teorema do CAP.

Os bancos de dados SQL têm uma consistência muito boa, mas o suporte ao particionamento é muito ruim; os bancos de dados NoSQL tendem a seguir o outro caminho. Fácil de particionar, mas geralmente o que é chamado de consistência eventual. Se você estiver criando um site de mensagens aceitável, provavelmente um banco não está bem.

A vantagem é que agora existem vários modelos de como armazenar dados, para que você possa escolher como implementar as coisas, enquanto antes tudo o que você tinha eram bancos de dados SQL.

A SE Radio teve alguns bons episódios sobre esse assunto.

O MongoDB funciona bem quando você escreve muitos dados e quando suas necessidades de consulta não são muito complicadas. Portanto, o MongoDB é um bom ajuste quando você está implementando o CQRS com Event Sourcing no lado do Comando - ou seja, seu armazenamento de eventos é um banco de dados do MongoDB.

No lado da consulta, ainda usamos um banco de dados SQL Server com visualizações e WCF Data Services na parte superior, devido à sua flexibilidade. Acho que na maioria dos casos você realmente precisará do poder de um banco de dados relacional para consultas.

A diferença imediata e fundamental entre o MongoDB e um RDBMS é o modelo de dados subjacente. Um banco de dados relacional estrutura dados em tabelas e linhas, enquanto o MongoDB estrutura dados em coleções de documentos JSON. JSON é um formato de dados legível por humanos e autoexplicativo. Originalmente projetado para trocas leves entre navegador e servidor, tornou-se amplamente aceito para muitos tipos de aplicativos.

Os documentos JSON são particularmente úteis para gerenciamento de dados por vários motivos. Um documento JSON é composto por um conjunto de campos que são eles próprios pares de valores-chave. Isso significa que cada documento JSON carrega seu próprio design de esquema legível por humanos aonde quer que vá, permitindo que os documentos se movam facilmente entre o banco de dados e os aplicativos clientes sem perder seu significado.

JSON também é um formato de dados natural para uso na camada de aplicativo. O JSON suporta uma estrutura de dados mais rica e flexível do que as tabelas compostas de colunas e linhas. Além de suportar tipos de campos como número, sequência, booleano etc., os campos JSON podem ser matrizes ou subobjetos aninhados. Isso significa que podemos representar um conjunto de relações sofisticadas que são uma representação mais próxima dos objetos com os quais nossos aplicativos trabalham. O uso de documentos JSON em nosso banco de dados significa que não precisamos de um mapeador relacional de objetos entre nosso banco de dados e os aplicativos que ele serve. Podemos manter nossos dados da forma correta

Se seus dados precisam de muitas consultas, uma solução NoSQL não é boa e, quando você precisa de suporte transacional (ACID), um NoSql não é o mais adequado. Acho que o NoSQL brilha quando você tem muitas leituras que precisam ser rápidas e quando a estrutura é um tanto ad-hoc, você recupera por documento ou por estrutura de página, algo assim. Porém, muitas soluções NoSQL melhoram muito rapidamente, de modo que talvez haja falhas em breve. De qualquer forma, acho que os bancos de dados relacionais ainda são um bom ajuste para a maioria dos aplicativos.