Introdução

Para quem não conhece, o MongoDB é um banco de dados NoSQL e utiliza arquivos mapeados em memória o que dá a grande velocidade do Mongo.
Ele foi escrito em C++ como um banco de dados orientado a documentos, logo, ele gerencia coleções de documentos JSON (BSON na verdade).
É indicado quando precisamos guardar informações de diferentes tipos, estruturadas, semi-estruturadas, desestruturadas e polimórficas e em quantidades massivas.
O Mongo permite uma flexibilidade na persistência de dados porque não possui a rigidez dos bancos relacionais quanto ao formato dos dados a serem persistidos.

O que é NoSQL

Durante muito tempo, utilizamos a abordagem de desenvolvimento tipo waterfall (cascata). Hoje em dia os times diminuíram e trabalham em sprints, iteragindo, enviando e alterando muito código a cada semana e até mesmo a cada dia.
Aplicações que serviam a um conjunto pequeno de usuários agora servem milhares, em escala global, em diferentes plataformas e dispositivos.
Por causa desses novos requisitos, surgiu a necessidade de preencher o espaço deixado em branco pelos bancos de dados relacionais já que não foram desenhados para atender esse tipo de problema.

Prós e contras

Prós

• Schemaless – ideal para armazenamento de documentos sem a rigidez de uma padronização dos dados.
• Facilmente escalável – faz escalamento de leitura utilizando réplicas. Escala escritas utilizando fragmentação (sharding). Basta adicionar outra máquina e partir pro abraço.
• Custo – é opensource, roda em Linux e outras plataformas.
• Consistência – você escolhe o nível de consistência dependendo do valor da informação. Mais rápido, garante a leitura, mais devagar, garante a escrita em todos os nós da rede antes de liberar o recurso.

Contras

• Tamanho dos dados – devido a forma como os dados são armazenados, eles possuem um maior número de bytes extra para controle.
• Menos flexível em pesquisas – não existe JOINs nativos no MongoDB pois devem ser utilizados na aplicação.
• Map/Reduce – utilizado em agregação/análise de dados, no momento ainda não é tão rápido. Quando necessário, é interessante usar algo como o Hadoop para supri-la.
• Informações atualizadas – dependendo a forma da consistência escolhida a propagação de dados poderá gerar gargalos.

Conclusão

Se você estiver pensando que o MongoDB é melhor que um BD Relacional, infelizmente não é assim que a banda toca.
Cada um tem o mérito que merece. É tipo fazer uma mudança de casa utilizando um carro passeio. São ferramentas distintas para serviços distintos.
Mas para aplicações de alto índice de leitura, persistência de informações que possam ser estruturadas no modelo documento, sim, o MongoDB é uma ótima opção. Já para um ERP talvez não seja tão interessante.

Se houver alguma dúvida, sugestão ou percebeu algum erro de digitação, não hesite em entrar em contato que responderei tão rápido quanto puder e atribuirei o crédito pela ajuda.

Até mais!
André Fellows