MongoDB – o que é e para que serve?

mongodb
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Vamos falar um pouco sobre o MongoDB? Um dos bancos NOSQL (Not Only SQL) mais utilizados no momento, e que ainda por cima é open-source, e está disponível para Windows, Linux e OSX.

O MongoDB é um banco de dados orientado a documentos (document database) no formato JSON, ou seja, diferente de um banco de dados relacional, ele não possui como restrição a necessidade de ter as tabelas e colunas criadas previamente, permitindo que um documento represente toda a informação necessária, com todos os dados que você queira, no formato de um JSON.

Assim como em um JSON utilizado em comunicações HTTP entre aplicações, no documento do MongoDB podem existir valores simples, como números, strings e datas, assim como também podem existir listas de valores e listas de objetos.

Os documentos são agrupados em collections. E um conjunto de collections forma um database (banco de dados). O MongoDB permite que seu database seja replicado para outros servidores, aumentando assim a disponibilidade de suas informações, sendo esse recurso conhecido por replica set. Dessa forma, cada servidor terá uma cópia dos dados.

O MongoDB suporta um recurso mais avançado chamado sharding, que é usado para dividir os dados de uma collection entre mais de um servidor, esse recurso faz sentido ser usado quando você tem alguma collection muito grande, com bilhões de registros, e acaba sendo vantajoso dividir esses dados dentre alguns servidores. Por exemplo, imagine que sua collection atingiu a marca de 5 terabytes, você poderia dividir em 5 servidores, contendo 1 terabyte de dados cada um.

Outro recurso interessante do MongoDB são as capped collections, que nada mais são que collections com tamanhos predefinidos e com conteúdo rotativo. Conteúdo rotativo? Como assim? O MongoDB, por exemplo, nos permite criar uma collection com o tamanho máximo de 3 documentos, e imagine que sejam inseridos 5 documentos em ordem, primeiro o documento1, documento2, até o documento5 por último. O que vai acontecer se buscarmos todos documentos da collection após gravarmos os 5 documentos? O Mongo irá nos retornar os 3 últimos documentos inseridos, ou seja, o documento3, documento4 e documento5, sendo o documento1 e documento2 descartados.

O grande ponto positivo do Mongo é sua flexibilidade, pois a estrutura orientada a documentos nos permite com muito mais facilidade gravar os dados da forma que for melhor para a aplicação, do que em um banco de dados relacional, onde muitas vezes temos que ajustar a aplicação para se adequar a estrutura do banco de dados. Imagine um sistema que vende livros e DVDs, como seria o modelo em um banco relacional? Seria algo próximo de:

Tabela: Produtos
Campos: Codigo, nome, fabricante, descricao, peso
Tabela: Autores
Campos: Codigo, nome, biografia

Como um livro e um DVD podem ter mais de um autor/artista, teríamos que ter uma tabela de relacionamento N para N, mais ou menos assim:

Tabela: AutoresProdutos
Campos: CodigoAutor, codigoProduto

Primeiro ponto a observar, quando a gente pensa na estrutura de classes de um sistema orientado a objetos, essa rabela AutoresProdutos não faz sentido, e dependendo da tecnologia que estamos usando isso pode ou não ser transparente. Outro ponto, os livros tem um campo ISBN, que poderíamos adicionar a tabela Produtos, ou então criar uma outra tabela chamada Atributos, que poderia ser assim:

Tabela: Atributos
Campos: Codigo, codigoProduto, nome, valor

Essa tabela seria filha da tabela de Produtos, e aí poderíamos criar os registros para representar os atributos exclusivos de cada tipo de produto, como ISBN para livros, quantidade de faixas para o DVD, etc. Veja que começamos a aumentar a complexidade do sistema e da implementação, para usarmos uma estrutura de metamodelo no banco de dados. E é nessas horas, quando precisamos de metamodelos, que as vantagens do Mongo se sobressaem, pois com a estrutura de JSON tudo fica muito mais simples.

Para representarmos nossa estrutura acima no Mongo, nós poderíamos ter uma única collection, com todos os dados que precisamos e queremos todos juntos, afinal, muitas vezes, para exibirmos as informações que precisamos no nosso sistema, nós somos forçados a ler e juntar os dados de diversas tabelas, as vezes chegando na casa da dezena. Imagine que temos uma collection chamada Produtos. Nós poderíamos ter o seguinte documento no banco de dados:

{
	"codigo": "12345",
	"nome": "Darth Plagueis",
	"descrição": "Darth Plagueis, mais que qualquer lorde Sith antes dele, ansiava pelo poder absoluto. E de fato se torna capaz de desenvolver uma habilidade de força inimaginável: o controle da vida e da morte...",
	"editora": "Aleph",
	"ISBN": 8576572966,
	"peso": 700.00,
	"paginas": 440,
        "autor": "James Luceno"
}

Repare que não usei o nome fabricante, e sim editora, pois ele faz mais sentido para livros. Agora vamos ver como poderia ser a estrutura de um DVD:

{
	"codigo": "78694",
	"nome": "AC/DC Live at River Plate",
	"descrição": "AC/DC Live At River Plate capta em alta definição a intensidade e o poder da mundialmente aclamada turnê The Black Ice World Tour que deu à banda o prêmio Pollstar Award de melhor turnê mundial do ano de 2010.",
	"gravadora": "Sony",
	"peso": 100.00,
	"faixas": 20,
	"banda": "AC/DC"
}

Repare que aqui não temos editora, e sim gravadora, e no lugar de autor temos banda, e temos campos em comum como o código, o nome e a descrição. E essa flexibilidade traz outra vantagem, nós podemos fazer uma pesquisa nessa collection, procurando todos produtos que tenham a gravadora Sony, veja que mesmo se existir uma editora Sony, ela não irá retornar na pesquisa, pois procuramos por produtos com a gravadora Sony, ao mesmo tempo se procurarmos todos os livros com mais de 400 páginas, não temos que nos preocupar com possíveis DVDs no retorno da pesquisa, pois DVDs não tem páginas. Falando um pouco mais sobre pesquisas, o MongoDB nos permite fazer uma série de filtros e queries, com grande flexibilidade, e veremos uma série de exemplos no nosso próximo post.

Outro ponto a favor para um banco orientado a documentos como o Mongo, é a maior facilidade para lidar com alterações estruturais nos seus dados, sem a restrição das colunas de uma tabela, fica muito mais simples adicionar novos campos em seu documento, sem grandes preocupações, sendo muito mais simples de tratar no sistema.

O MongoDB é rápido, ele possui uma excelente performance, além de ser um banco com alta disponibilidade, e muita flexibilidade, com suporte a um alto volume de dados, e ainda conta com um forte suporte de queries para consultas, dessa forma ele traz uma série de possibilidades para sua utilização, principalmente para atender sistemas com dados dinâmicos e metamodelos, como um sistema para gerenciar catálogos de produtos, os chamados PIM (product information management).

Felizmente o Mongo vem ganhando cada vez mais espaço nas empresas. Eu tive oportunidade de utilizar em alguns dos projetos que participei, inclusive com alto volume de dados e requisições, e sempre obtive ótimos resultados. É um banco de dados que recomendo, assim como o Redis, que já falamos aqui anteriormente, e o Cassandra, que ainda não abordamos aqui, vamos iremos falar em breve.

Por hoje é só, fique ligado que em breve vamos ver como instalar o Mongo, e também teremos um post dedicado a como fazer consultas, com uma série de exemplos.

Quase 20 anos de experiência no mercado de TI.
Atuação em grandes empresas como Netshoes, Borland, JBS, Bradesco, Hospital das Clínicas, Rede, Prodam, HSPE, Instituto Ayrton Senna, e também em empresas internacionais como Delta Dental, T-Mobile, Pepsi e Mckesson.
Fundador da TecPrime Solutions, administrador da comunidade nopCommerce Brasil, e autor dos sites InvestFacil.net e Desenvolvedores.ninja

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *