MongoDB - Introdução

Vou começar a publicar uma série sobre o MongoDB, o banco NoSQL que é a novidade do momento e que vem agradando pela sua facilidade, velocidade e suporte da comunidade.

O MongoDB é um banco de dados open source, criado a cerca de 5 anos, escrito em C++, desenvolvido pela 10gen e que vem com um grande poder de escalabilidade e alta-performance (ou como o proprio fabricante o denomina: Agil e Escalável).

Um banco de dados que possui algumas características interessantes. Possui uma aproximação com um memcached, não possui tantas funções quanto um Oracle/SQL Server/MySQL/RDBMs mas definitivamente é muito mais simples que ambos.

Ele possui grandes virtudes como armazenamento baseado em documentos (Documents-Oriented Storage), suporte a index, sharding, schemaless, Map/Reduce, etc. features que serão abordadas com mais profundidade em posts posteriores.

Possuindo versões de 32 e 64bits, pode ser instalado em Windows, OSX, Linux e Solaris. O MongoDB utiliza a storage engine baseado em memory-mapped files, por isso, para bases de dados maiores que 2GB, é necessário utilizar a versão de 64bits.

O shell do banco de dados é baseado em JavaScript, mas não se assuste, é muito simples de utiliza-lo e você [quase] nunca terá de usar a linguagem.

O MongoDB trabalha com o padrão JSON, isso deixa os documentos mais legíveis e permite a flexibilidade nos documentos, não sendo necessário a criação de "campos" para armazenamento. Seus dados são armazenados em formato BSON, que trás algumas vantagens como maior quantidade de datatypes e acesso ao dado com mais velocidade, mas também algumas desvantagens como limitação no tamanho de um documento em 16MB.

Uma coisa que muitos DBA's se assustam quando escutam pela primeira vez sobre MongoDB é a falta de JOINs nativos [é possível fazer JOINs com algumas magias negras] e principalmente a não existência de transações. O que parece ruim, em alguns casos é bom.

Com a ausência de JOINs foi possível criar um banco de dados que não possui campos fixos, ou seja, é possível criar documentos com características diferentes, por exemplo, estamos criando um catálogo de produtos para a grande rede de lojas "Casas Amazonenses", uma rede muito grande com uma grande variedade de produtos eletrônicos, produtos para casa, informática, etc. Teríamos assim, em um modelo relacional parecido com:

Nesse modelo um produto tem um tipo, que pode ou não ser reutilizado. Para buscar um produto com seu tipo basta fazer um Join, tudo muito bonito e simples, porém, esse modelo mostra como estamos preso ao schema. Para adicionar uma informação, seria necessário mudar a estrutura dos dados, ou seja, para adicionar uma coluna "descricao" ao produto, os metadados seriam modificados, o bloco contendo a tupla seria realocado e para cada registro, existiria a possibilidade de ter uma descrição. Isso é apenas um exemplo do quão amarrados ao schema o banco relacional nos deixa.

id	nome	descricao	tipo
1	Cama casal	Linda cama de casal	Casa
2	Cama solteiro		Casa [tive que descrever pois não posso deixar FK vazia]
3	TV Tubo, 29”		Eletrônicos
4		TV Led, 40”, HD, 3D, cheia de coisa	Eletrônicos

Esse mesmo modelo, no MongoDB, seria simples [não vou colocar em JSON, para não pular explicações e nem acabar com a surpresa] como:

"id" : 1, "nome" : "Cama casal", "descricao" : "Linda cama de casal", "tipo" : "Casa";
"id" : 2, "nome" : "Cama solteiro";
"id" : 3, "nome" : "TV Tubo, 29”", "tipo" : "Eletrônicos";
"id" : 1, "descricao" : "TV Led, 40”, HD, 3D,  "cheia de coisa", "tipo" : "Casa";

A falta de transações atrapalha em alguns casos. O MongoDB apenas obedece o "D" do ACID, isso se você possuir o journaling ativo, que por sinal, só na versão 64bits, ou seja, se o seu projeto depende em 100% de ACID compliance, o MongoDB não vai te ajudar muito.

Bom, acho que consegui uma breve introdução ao MongoDB, nos próximos posts, vamos começar a mexer mais na prática.