MongoDb é uma solução incrível, e tenho visto ganhar mercado de forma surpreendente, as facilidades e simplificação no fluxo de desenvolvimento acaba arrebatando o coração de muitos desenvolvedores, porém o que me preocupa, e o motivo que me fez escrever esse artigo, é que talvez está ganhando um mercado e sendo usado em lugares que muito provavelmente ele não é adequado. Sempre ao escolher uma tecnologia é extremamente importante se levar em consideração as limitações e propósitos da mesma, isso vai com certeza evitar uma enorme dor de cabeça no futuro.
Antes de seguirmos gostaria de deixar bem claro que não tenho nada contra o MongoDb, ao contrário, uso extensivamente ele em muitos projetos nos quais ele é aderente, mas ele não é uma bala de prata para resolver todos os problemas, saber onde e quando usá-lo é muito importante. Outro ponto que gostaria de deixar claro é que muitos itens que irei levantar aqui cabem a outros bancos NoSql, direciono ao MongoDb apenas por ser a tecnologia que percebo estar mais associada a esses “errors” na escolha de storage de dados, muitas vezes sendo usado apenas como um banco relacional.
Eric Evans no livro Domain-Driven Design de 2015 escreveu “The problem is not the relational databases, but when you use then for everything” em uma tradução livre, o problema não são os bancos de dados relacionais, mas quando você os usa para tudo. Hoje 5 anos após a publicação poderíamos falar exatamente o mesmo para bancos não relacionais e em especial para o MongoDb.
Bancos NoSql como o mongoDb, são sistemas de armazenamento muito bons em resolver problemas como a escalabilidade e alta disponibilidade, em especial a escalabilidade horizontal, normalmente um grande gargalo de aplicações que usam bancos relacionais e precisam ter baixo tempo de resposta, mas são mais eficientes em armazenar objetos que não precisam ser normalizados.
Quando não se deve usar o mongoDb?
Quando a equipe não domina o MongoDb
MongoDb não é daquelas ferramentas que da pra descobrir como funciona com o projeto andando, é necessário ao menos alguém com o domínio dos fluxos, configurações e da própria ferramenta.
Caso tenha uma equipe com proficiência apenas em bases de dados relacionais e não tenha o tempo necessário para capacita-la, mongoDb não é uma boa. Desenvolver uma aplicação, configurar e manter um cluster MongoDb não são tarefas triviais e terá um penoso caminho até ter uma equipe proficiente nessas tarefas. Muitos erros e problemas associados ao MongoDb são na verdade fruto de uso inadequado do mesmo.
Quando precisa garantir a integridade transacional e ACID
Quando transações atômicas e isoladas forem a única forma de resolver o problema, mongoDb não é interessante. Ainda que versões mais recentes possuam suporte a transações inclusive multi documentos como pode ser lido na documentação (https://docs.mongodb.com/manual/core/transactions/) quando sua aplicação depende disso para seu bom funcionamento é melhor evitar o uso do mongo.
Na própria documentação do mongo é possível encontrar o seguinte alerta:
Outras características interessantes e que precisam ser levados em consideração são a “Eventual Consistency” ou consistência eventual, onde os dados ficarão consistente em algum momento, porém não garantem a consistência o tempo todo e o “Soft-state” onde os dados não precisam ser consistentes com gravação, nem réplicas precisam ser mutualmente consistentes o tempo todo. Essas características são pontos de atenção que podem gerar problemas muito graves se não tratadas adequadamente, como por exemplo receber uma resposta não atualizada quando se busca o saldo de uma conta bancária.
Quando possui uma demanda muito específica
A proposta do MongoDb é ser um banco de uso geral, ele possui quase todas as funcionalidades e características necessárias para uso de um banco de dados completo, isso certamente é um dos fatores importantes que possibilitam usar o mongo como fonte de dados principal em uma aplicação, ao contrário de outras soluções NoSql que possuem um escopo muito mais especializado.
Considerando que o mongo precisa atender a grande maioria dos cenários do dia a dia é evidente que outras soluções mais especializadas serão mais adequadas e atenderão melhor nesses cenários, assim é comum complementar o uso do mongo com outras soluções que para que se propõe, são melhores. Por exemplo:
- Quando possui dados que sempre são acessados apenas por uma chave, bancos chave-valor como Redis e Memcache são bem interessantes. Esses sistemas são constantemente usados para armazenamento de cache e configurações por exemplo;
- Quando se precisa de um sistema mais parrudo de busca talvez soluções como Elasticsearch ou Solr podem ser mais adequadas;
- Quando se precisa de um sistema mais confiável de filas (queues), provavelmente usar soluções mais especializadas como RabbitMQ e ZeroMq por exemplo, é melhor.
Quando os dados forem claramente relacionais
MongoDb é um banco não relacional, tenha isso sempre em mente. Ainda que possua suporte a relacionamentos, não é onde ele se dará melhor. Se tem um domínio bem definido e claramente uma estrutura relacional, é melhor confiar seus dados a um gestor de banco de dados que foi criado e otimizado para manter os relacionamentos e consistência entre os mesmos.
A garantia de integridade relacional no MongoDb não existe, passa a ser responsabilidade da aplicação garantir essa integridade, o que pode gerar muitos problemas de inconsciência se sua equipe não possuir maturidade para assumir essa responsabilidade. Por exemplo remover um usuário sem remover os endereços desse usuário, vai gerar uma série de registros órfãos no banco.
Quando o custo de manter um cluster for um problema
Manter um cluster mongo não é barato, idealmente é sugerido manter ao menos 3 instancias do cluster com máquinas não muito fracas, normalmente acima de 2GB de RAM para garantir a integridade do mesmo. É possível rodar com 2 instancias mais um arbitro, mas é um risco que normalmente não aconselho quando não se sabe exatamente o que se está fazendo.
É claro que esse custo pode ser irrisório em projetos maiores e que já estejam tracionando, porém podem pesar quando se pretende apenas validar um produto, ou ainda possui um produto que não se paga. Então tenha em mente o custo total que manter um cluster mongo vai trazer para o projeto.
Conclusão
O MongoDB é um banco de dados incrível e com certeza não deve ser descartado como um possível storage de dados em seus projetos, apenas certifique-se que o use onde é adequado, assim conseguira aproveitar o que de melhor o mesmo tem a oferecer e evitara problemas e dores de cabeça por uma escolha equivocada.