Quando devemos usar o MongoDB?

O MongoDB é um banco de dados NoSQL que eu achei bastante fácil de usar. Recentemente, tive que desenvolver um aplicativo simples que precisava coletar alguns dados usando solicitações HTTP e armazenar alguns resultados após o processamento dos dados, e tentei usar o MongoDB.

Com essa experiência, achei muito mais agradável usar do que os bancos de dados relacionais tradicionais e, como sou desenvolvedor e não DBA, meu trabalho foi bastante simplificado.

Ainda assim, às vezes me sinto inseguro quando devo usar o MongoDB em vez de um banco de dados relacional tradicional, como SQL Server ou MySQL.

Nesse caso, quando podemos usar o MongoDB em vez de bancos de dados relacionais? Existe alguma grande advertência sobre o MongoDB que o torna impróprio para algumas situações?

Basicamente:

• Se você pode representar seus dados na forma de vários documentos, o MongoDB pode ser uma boa opção.

• Se você prefere imaginar seus dados como um monte de tabelas interconectadas, o MongoDB pode não ser uma boa opção.

Aqui estão dois exemplos que eu acho ilustrativos:

• Alguns anos atrás, eu criei um mecanismo de blog. Seu objetivo é hospedar artigos de blog e, para cada artigo, armazenar as diferentes versões, alguns metadados, estatísticas de visitas etc.

  Isso pode ser armazenado como várias tabelas, mas ao tentar construir um modelo, ele cresce muito rapidamente para uma dúzia de tabelas, se não mais. Algumas consultas SQL podem ficar feias com muitos joins, e ... bem, você entendeu.

  O problema aqui é que existe uma coisa central - um artigo de blog - e há todo esse material em torno do artigo, o que o torna adequado para um banco de dados baseado em documentos. Com o MongoDB, a modelagem do banco de dados foi extremamente fácil: uma coleção contém os artigos do blog e uma segunda pequena coleção contém a lista de usuários com permissão para escrever artigos. Cada documento da primeira coleção conteria todas as informações necessárias para exibir um artigo, seria o nome do autor ou as tags.

• Agora imagine um projeto muito diferente. Alguns usuários podem escrever e compartilhar coisas escritas por outros usuários. Na página de um usuário, você esperaria encontrar o que ele escreveu e o que ele compartilhou. Há uma restrição: quando alguém edita o que escreveu no passado, a mudança aparece em todos os lugares onde o texto original foi compartilhado.

  Com uma abordagem baseada em documentos, é difícil encontrar qual seria o documento. Um usuário, talvez? Bem, isso é um bom começo. Um documento de usuário conteria tudo o que esse usuário escreveu. Mas e as coisas que ela compartilhou?

  Uma maneira possível é colocar essas coisas no mesmo documento. O problema dessa abordagem é que, se alguém editar uma entrada, o aplicativo deverá percorrer todos os documentos do usuário no banco de dados para editar todas as ocorrências da entrada antiga. Sem contar a duplicação de dados.

  Uma alternativa seria manter no documento do usuário apenas a lista de entradas que esse usuário compartilhou (com o ID do usuário e da entrada referidos). Mas agora, um problema diferente ocorreria: se um usuário compartilhasse milhares de entradas de milhares de usuários, seria necessário abrir milhares de documentos para obter essas entradas.

  Ou podemos modelar nossa coleção em torno das próprias entradas, cada entrada referente ao seu autor e tendo uma lista de usuários que a compartilharam. Aqui, novamente, os problemas de desempenho podem se tornar visíveis quando você precisar percorrer todos os documentos para mostrar os publicados por um determinado usuário.

  Agora, quantas tabelas você precisaria se estivesse usando um banco de dados relacional? Certo, três. Seria fácil modelar e também fácil de usar.

Cada tecnologia tem suas vantagens.

As vantagens dos bancos de dados relacionais é que o RDBMS faz algumas coisas para você, como:

• Aplicação da integridade referencial (não permitindo a inserção de detalhes da fatura se a fatura à qual ela pertence não existir)
• Evite redundância: as coisas são armazenadas apenas uma vez.
• Consultas complexas podem ser feitas com uma linguagem declarativa (SQL) madura, comprovada pelo tempo e amplamente difundida.

Tudo isso se resume ao fato de que você precisa escrever menos código porque o RDBMS impõe coisas para você.

Além disso, independência de dados: muitas vezes, se você usa estruturas SQL padrão e não específicas de fornecedores, pode migrar seus dados de um RDBMS para outro com o mínimo de problemas, enquanto os bancos de dados NOSQL não são padronizados.

Por outro lado, uma das vantagens dos bancos de dados NOSQL é que eles escalam melhor mantendo o desempenho em milhões de linhas. Eles são mais adequados para armazenamento baseado em documentos, ou seja, dados não estruturados. Mas a maioria dos aplicativos não precisa desses recursos.

Para o seu caso em particular, o MongoDB parece uma boa escolha, mas há muitos cenários (provavelmente a maioria deles) em que não seria a melhor opção.

O MongoDB é mais adequado em cenários que exigem leitura / gravação de muitos dados, sem muita ênfase na segurança das transações (se alguns dados se perdem ocasionalmente em uma falha do servidor, não é grande coisa), esperam escalar muito e não ' realmente tem um esquema estável.

O MongoDB não é adequado para cenários que exigem:

1. Fortes garantias de ACID: O MongoDB permite que dados duplicados sejam armazenados, leituras inconsistentes e até perda de dados. Essas coisas são boas em algumas aplicações, mas não na maioria.
2. Transações com vários objetos: O MongoDB suporta transações ACID, mas apenas para um único objeto / documento. Isso não é suficiente para operações mais complexas, como transferências bancárias, reservas, etc.
3. BI tradicional: existem muitas ferramentas de BI que funcionam bem apenas com o SQL tradicional.
4. SQL: O MongoDB tem uma linguagem de consulta muito específica, enquanto o SQL é muito conhecido por muitas pessoas (pode ser um aspecto importante a ser considerado), pode fazer muitas coisas complexas (enquanto no MongoDB você teria problemas para executar uma simples join) e é transferível em várias implementações.

O MongoDB é mais rápido e permitirá que você obtenha mais desempenho do sistema, eliminando muitas coisas que o RDBMS impõe por padrão, como verificações de integridade (observe que você também pode ajustar o RDBMS para tais fins), mas a verdade é que, na maioria dos cenários, isso simplesmente não é necessário. Além disso, o trade-off é confiabilidade e flexibilidade (você terá problemas se, mais tarde, decidir que precisa executar operações mais complexas com os dados existentes).

Tudo depende das necessidades do aplicativo que você está construindo. É velocidade e disponibilidade, ou segurança, confiabilidade e flexibilidade. Você precisa saber onde está mais valioso em seus dados (e nas conexões de seus dados). Se você ainda não sabe, provavelmente é melhor escolher algo que não o deixe no futuro e permitir que você adicione os recursos e realize as operações necessárias para a sua aplicação.

O MongoDB é ótimo quando você pode representar seus dados como "pacotes" independentes de informações. Você tem CEPs do google maps, incorporados ao CEP são empresas e dentro das empresas são funcionários. Todos os códigos postais são independentes e você pode obter todas as informações de maneira simples, bonita e rápida. Esse é um bom cenário para uma solução não SQL.

Uma vez dito isso, discordo totalmente da tendência atual que estou procurando, que implica que o MongoDB é um tipo de solução pós e superior ao RDBMS e o noSQL deve ser sua solução por padrão. Tudo isso é absurdo. O MongoDB é um banco de dados de nicho e 90% dos projetos são relacionais e precisam de uma opção RDBMS, porque você deseja uma solução de consulta poderosa como SQL para gerar seus relatórios e procurar dados dispersos: "junções" são um profissional, não um trapaceiro. Além disso, os RDBMS modernos suportam coleções BSON e integração geoespacial, então talvez o nicho para noSQL seja ainda mais restrito agora.

O MongoDB é útil para armazenar todos os dados estruturados necessários para criar uma determinada instância de uma página da web. Você pode recuperar os dados para uma determinada página, passá-los para o aplicativo cliente, que pode renderizá-los.

Nesse contexto, o MongoDB é muito rápido e confiável. Mas nunca esqueça que você não possui informações relacionais no seu banco de dados. O que significa que, se você alterar algo na estrutura da sua página da web, poderá não conseguir preencher os buracos nas páginas já armazenadas porque não possui os dados necessários para isso. Mais sobre isso aqui: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/