O MongoDB é um banco de dados
orientado a documentos de alta performance, open source e schema-free,
escrito em C++. Ele é uma mistura entre os repositórios escaláveis
baseados em chave/valor e a tradicional riqueza de funcionalidades dos
bancos relacionais.

Tem-se falado muito de bancos NoSQL e também do MongoDB, mas por que você deveria usá-lo? Hoje vou te dar três razões para que você passe a usar o MongoDB.

01. Consultas simples

MongoDB é um banco NoSQL baseado em documento sem transações e sem joins. Quando um aplicativo utiliza esse tipo de banco de dados, o resultado que se tem são consultas muito simples. Elas são mais fáceis de escrever. Elas são mais fácil de ajustar. Deixam os desenvolvedores fazerem seu trabalho mais facilmente. Em um exemplo onde ‘usuarios’ possuem ‘eventos’, existe uma tabela para cada um, com um usuario_id na tabela de eventos. Vamos dizer que eu quero todos os usuários que publicaram um evento.

Em um banco de dados SQL, tenho duas tabelas: usuários e eventos. Eu poderia escrever esta consulta da seguinte forma:

SELECT * from `usuarios` INNER JOIN `eventos` ON `eventos`.`usuario_id` = `usuarios`.`id` where `eventos`.`publicado` is not null group by `usuarios`.`email`;

Analogamente, em um banco de dados MongoDB, digamos que eu tenha apenas uma coleção: usuários. Cada documento de usuário tem um atributo chamado “eventos”, que é uma lista de documentos incorporados. Parece algo como isto em JSON:

{

nome : Jean carlo Nascimento,

email: jnascimento@gmail.com,

eventos : [ 

{titulo : Primeiro!},

{titulo : Legal!},

{titulo : Festao, publicado : true}

]}

Para executar a mesma consulta em MongoDB, fica:

db.usuarios.find (('eventos.publicado': ($ ne: null)))

Mais simples. Mais simples de ler, de escrever. E você pode ver claramente como ele faz as coisas mais fáceis de entender.

02. Sharding

Sharding é um conceito simples: se você tem um monte de dados e está no limite de disco e/ou a falta de espaço, a resposta é ter os seus dados divididos entre várias máquinas. Você fica com mais rendimento e com maior capacidade de armazenamento em disco. Em um mundo perfeito, como seu armazenamento e desempenho precisa crescer, basta acrescentar mais shards.

MongoDB é muito próximo a este mundo perfeito. Se você tem um processo mongod execução, e quer usar sharding, você:

1. Abre uma nova máquina.
2. Inicia um processo novo mongod para atuar como um membro do cluster shard.
3. Inicia um processo novo mongod para atuar como um banco com configuração separada, para manter informações sobre quais bancos possuem shard.
4. Inicia um processo mongo e informa como encontrar o db atual, o novo membro do shard, o banco de dados de configuração.
5. Digita ~ 5 para permitir sharding em qualquer banco de dados e coleções que você quiser.
6. Modifica seus aplicativos para se conectarem ao processo mongo ao invés do antigo processo mongod.
7. Pronto.

Para saber mais como configurar o sharding, leia http://www.mongodb.org/display/DOCS/Configuring+Sharding

Toda a comunicação é feita sobre IP. Para configurar os processos mongod e mongo, podem ser executados em suas próprias máquinas ou correr na mesma máquina como um de seus shards. Isso pode ser feito com qualquer tempo de inatividade. E você não precisa ter um olho para o sharding quando começar, você pode tomar um antigo processo regular mongod e vai “simplesmente funcionar”.

Existem soluções para esse problema no MySQL, mas eles exigem manipulação de dados em uma camada acima da base de dados. O próprio banco não oferece suporte a esse recurso. Além disso, você não precisa pensar sharding até que você precise dele, você não tem que pré-otimizar.

Agora pense em vídeo HD, geolocalização, mensagens em tempo real, realidade aumentada, imagens em tempo próximo ao real por satélite. Pense em todos esses dados, e na velocidade que as pessoas vão querer isso (e mashups e derivados disso). Então, pense sobre qual banco de dados que você deseja começar a usar agora.

3. GridFS

Digamos que você tenha uma aplicação onde o usuário pode fazer upload de uma foto de perfil. A prática corrente é a de armazenar o caminho para o arquivo no banco de dados, armazenar o arquivo no filesystem (sistema de arquivos compartilhado se você tiver vários servidores de aplicação) ou S3. Se você usar um sistema de arquivos, algum tipo de apoio é normalmente realizado também. Se você tem múltiplas aplicações, você tem que usar um sistema de arquivos compartilhados.

Com GridFS, você armazena arquivos no banco de dados. MongoDB foi construído para fazer isso. Por que isso é uma razão “para usar MongoDB”? Porque o MongoDB tem replicação e sharding de coleções. E adivinhem? Você pode aplicar esse material para coleções GridFS perfeitamente bem. Quando você guarda os arquivos no MongoDB, recebe toda a capacidade de replicação e sharding gratuitamente. Quer backup dos arquivos do usuário? Basta replicar as coleções GridFS.

Guardar os arquivos em um banco de dados é o caminho que deveríamos fazer de agora em diante.

Para conhecer melhor o GridFS, leia esse texto.

Conclusão

Então, se você utilizar o MongoDB, será fantástico por causa de uma sintaxe de consulta simples, a habilidade de shard dos dados entre máquinas com a facilidade e a possibilidade de armazenar arquivos em GridFS tirando partido de replicação e sharding. Isso porque não levei em conta a facilidade de instalação dele, que ganha de longe do CouchDB!