Introdução ao MongoDB: um banco de dados NoSQL

Já faz algum tempo que venho estudando o MongoDB.  Dentro da turma dos SGBDs NoSQL este foi aquele com o qual acabei criando maior simpatia pela sua simplicidade e documentação (apesar de muita gente falar do Apache Cassandra, sua documentação ainda é horrível).

O MongoDB é um banco de dados orientados a documentos. Sendo assim, se você, assim como eu (e 99% dos desenvolvedores) vêm de um ambiente dominado pelo modelo relacional, em um primeiro momento verá este SGBD como um alienígena – o que é incrívelmente empolgante e assustador. Meu objetivo neste post não é ensinar a usar o MongoDB (será assunto do próximo), mas sim expor as principais diferenças entre este e o confortável modelo relacional.

Este assustador (e maravilhoso) “mundo novo”

Para os acostumados com o modelo relacional, o MongoDB se mostrará assustador no primeiro contato porque a maior parte dos conceitos que nos forneciam uma certa sensação de segurança basicamente “desaparecem”. Aqui é obrigatório saber lidar com o medo: conforme mostrarei neste post, há riscos, mas os ganhos os compensam.

Não acho que o modelo não relacional possa ser aplicado a todos os casos, porém é sempre importante conhecer mais de um paradigma para que possamos no mínimo ampliar nossos horizontes quando nos deparamos com situações que fogem da nossa zona de conforto (e o MongoDB pode ser bastante desconfortável neste primeiro momento).

Não há registros, mas documentos

Algo sempre me incomodou no modelo relacional: com ele tentamos representar o mundo real (que é n-dimensional) usando uma abordagem bidimensional. Tudo o que eu for representar em minhas tabelas possui apenas duas dimensões: linhas e colunas. É verdade que podemos representar quantas dimensões quisermos no modelo relacional a partir de relacionamentos, porém sempre fica aquela sensação de se estar “forçando a barra”.

Além disto, por mais bem feita que seja o processo de análise, sempre há a possibilidade de posteriormente mais um atributo ser encontardo. O mundo é um ambiente complexo: acredito que para representá-lo, precisamos também de uma terminologia complexa.

No MongoDB, o equivalente aos registros são os documentos, que utilizam a sintaxe JSON. A melhor maneira de se ter um feeling do que quero dizer é ver o bicho. Sendo assim, observe o código abaixo:


Kico = {
nome: "Henrique Lobo Weissmann",
apelido: "Kico (ou seria este o nome?)",
cidade: "Belo Horizonte"
}

Eu criei um documento chamado kico que possui 3 atributos: nome, apelido e cidade. Repare que em momento algum defini o tamanho máximo de cada atributo, regras de validação ou qualquer tipo de restrição. Em seguida, se quiser armazená-lo em um banco de dados, bastaria executar o código abaixo:


db.kicodb.save(Kico)

Neste caso, eu estaria armazenando o documento Kico no banco de dados kicodb. Agora, observe o código abaixo:


Nanna = {nome:"Maria Angélica Alvares da Silva e Silva",
apelido:"Nãnna",
esposaDo:"Kico",
cidade:{nome:"Belo Horizonte", estado:{nome:"Minas Gerais", pais:"Brasil"}},
caes:[{nome:"Fraude", raça:"Pinscher?"}, {nome:"Zé", raça:"Schnauzer"}]}

db.kicodb.save(Nanna)

Repare que um registro com estrutura completamente diferente foi incluida no banco de dados. Até o atributo cidade é diferente. Enquanto no registro “Kico” eu tenho apenas uma string, no objeto Nanna eu tenho um outro documento. Outro ponto interessante: repare que eu tenho inclusive uma coleção associada ao objeto Nanna.

E tudo é mesmo assim salvo no mesmo banco de dados sem problema algum. Na realidade, eu poderia armazenar até o registro abaixo sem problemas:


esquisitao = {quantidade:34, poemaFavorito:"Batatinha"}

Como pode ser visto, não há regras de validação rígidas: qualquer tipo de documento pode ser armazenado no banco de dados. Claro: na prática somente objetos semelhantes são armazenados na base de dados, porém é bacana saber que se um dia aparecer algum novo atributo, poderemos inclui-lo apenas nos documentos aonde o mesmo é necessário, ao contrário do modelo relacional, aonde uma coluna se aplica a todos os registros.

Desvantagem: o desenvolvedor precisa ficar esperto para que suas bases de dados não virem um “samba do criolo doido”

Vantagens:

  • Finalmente você se livrou de uma abordagem bidimensional e pode representar objetos do mundo real como realmente são: complexos e únicos.
  • Caso no futuro surja algum caso no qual novos atributos apareçam, você pode aplicá-los somente aonde é necessário, e não em todos os casos, como no modelo relacional, aonde normalmente cria-se uma nova “coluna” na tabela relacionada

Redundância de dados máxima

No modelo relacional somos o tempo inteiro incentivados a reduzir ao máximo possível a redundância de dados. Aliás, os relacionamentos existem justamente para isto. E é um modelo que inegávelmente funciona muito bem. Já no MongoDB a situação é inversa: não há relacionamentos, e a duplicação de dados, pelo que pude observar é até incentivada.

Dê uma olhada no código abaixo:


pessoa1 = {nome:"Peçonhento", cidade:{nome:"Belo Horizonte", estado:"MG"}}

pessoa2 = {nome:"Zequinha", cidade:{nome:"Belo Horizonte", estado: "MG"}}

pessoa3 = {nome:"Joca", cidade:"Lagoa Santa"}

pessoa4 = {nome:"Complexado", cidade:{nome:"Rio de Janeiro", estado:{nome:"Rio de Janeiro", pais:{nome:"Brasil"}}}

Lembre-se de que aqui não há tabelas: há coleções de documentos. Em cada documento armazeno os dados da forma que eu quiser. Eu poderia criar uma coleção contendo apenas cidades e em seguida criar um relacionamento entre duas ou mais coleções distintas, é verdade (foge do assunto deste post), mas isto iria contra a idéia básica por trás do modelo orientado a documentos.

A idéia básica aqui é a de que um documento deve ser auto-contido, ou seja, isolado já deve conter todas as informações de que necessita. Por que isto? Simples: porque assim você ao invés de fazer uma consulta com vários joins como é o caso do modelo relacional executa uma única consulta, que já te retorna o documento inteiro. Resultado: mais performance.

Desvantagem: se você quiser alterar todos os registros relacionados a uma unidade semântica, precisa tratá-los um a um

Vantagem: maior performance. Uma única consulta já te retorna tudo o que você precisa saber a respeito do documento. Esta é uma das razões pelas quais vêm sendo adotado em projetos que exigem alta performance.

Concluindo

Estas são as duas principais diferenças (que só são vantagens de acordo com o caso) que vi no MongoDB (do modelo baseado em documenots na realidade) com relação ao modelo relacional. É aplicado a todos os casos? Óbvio que não.

O importante a meu ver é sair da área de conforto do modelo relacional: isto, como mencionei, amplia os nossos horizontes, faz com que vejamos outras possibilidades além de tabelas para armazenar nossos dados. Fico assustado quando topo com desenvolvedores que só conseguem desenvolver algo que envolva tabelas, colunas e registros. Aliás, a grande vantagem que vejo nesta “moda” de modelos noSQL é justamente esta: a exposição de “novos” paradigmas a um mundo dominado pelo modelo relacional, que só considero ruim quando tomado como a única alternativa viável pela maior parte das pessoas.

Este post é fundamental para que eu possa partir para os próximos, nos quais exporei como usar o MongoDB e, ainda mais importante, como aplicá-lo com Groovy e Java. Grande abraço!

Ah, quer baixar o MongoDB? Este é o site oficial: http://www.mongodb.org

75 thoughts on “Introdução ao MongoDB: um banco de dados NoSQL

  1. Oi Carlos, eu concordo com você. Na realidade, até hoje, encontrei poucas situações que justificassem o uso do MongoDB: basicamente apenas em situações nas quais eu topava com tabelas muito esparsas ou casos em que os atributos variassem demais de registro para registro.

    Tirando isto, o modelo relacional resolve bem os nossos problemas: de fato, se eu quero fazer um relatório gerencial, o formato tabular vêm bem mais a calhar do que o documental.

    Acho que a melhor alternativa é mesclar os dois mesmo: relacional para uma parte, documental ou gráfico para outra.

    Responda

  2. Excelente Post, extremamente claro e objetivo. Obrigado, me ajudou muito! :)

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Que bom que foi util. Obrigado

    Responda

  3. Parabéns pelo artigo, você me ajudou bastante agora que estou começando com o MongoDB.

    Como você mesmo disse: É assustador e MARAVILHOSO ao mesmo tempo. Simplesmente estou adorando.

    Valeu!

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Opa, bacana que tenha gostado.
    Mas uma dica: opte por um modelo de persistência misto.
    Coloque a parte que requeira relacionamentos fora do mongodb.

    Responda

    Marcio Vinicius Reply:

    Opa valeu pela dica, muito interessante.

    Abraços estou acompanhando seu site.

    Responda

  4. Velho! muito bom artigo, parabens! simples e objetivo.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Opa, obrigado Tomaz!

    Responda

  5. hahahahahahahahahahhahhaha, “A melhor maneira de se ter um feeling do que quero dizer é ver o bicho.”

    “o desenvolvedor precisa ficar esperto para que suas bases de dados não virem um “samba do criolo doido””
    ri muito .. ahahaha.. q isso gente.
    Bom summary.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    E?

    Responda

    Andressa Reply:

    e nada. So elogiei seu post cara.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Andressa, me desculpe pelo mal jeito. É que realmente na hora (estava exausto) não havia entendido o seu comentário.
    Mil desculpas: realmente não queria soar grosseiro de forma alguma.

    Responda

  6. Estou começando com Banco de dados NoSql e gostaria de saber onde encontrar uma base de dados para testes no MongoDB sendo que esta base como ja sabemos deve ter um grande volume e variabilidade….obrigado pessoal.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Fernando,

    sinceramente não sei viu. Talvez o melhor a fazer seja você mesmo criar esta base de dados usando algum script ou algo similar. Nunca vi alguém fornecendo uma base assim para download.

    Responda

  7. Ola,
    O que seria esse complexo que vc diz ? … ou seja.. pra vc quando que os joins começam a ficar complexos ?

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Diego,

    sua pergunta é excelente e vai ser o assunto de um post futuro meu.

    Vamos lá: muitas vezes você se depara com situações nas quais precisa fazer uma série de joins em suas tabelas no banco de dados relacional. Quando redundância de dados é um problema para você, ou seja, quando precisa ter apenas um registro para representar uma entidade, o modelo relacional É o que você deve adotar.

    No entanto, há situações nas quais você não liga para o fato de haver redundância de dados, como é o caso do MongoDB. Nestes casos, o join acaba dando lugar aos documentos embarcados, cuja obtenção a partir do MongoDB acaba se tornando muito mais simples e eficiente.

    Este é o ponto então: unicidade dos registros? Modelo relacional. Não precisam ser únicos? documental talvez te atenda.

    E digo mais: se você observar que precisa o tempo inteiro ficar fazendo referências entre documentos, é sinal de que deve adotar uma base de dados relacional o quanto antes. O maior erro que vejo na adoção do banco de dados documental é tentar recriar o modelo relacional neste.

    Responda

    diego Reply:

    Olá, obrigado pela resposta..

    vou aguardar o post

    Responda

  8. Oi Kiko, me diz uma coisa, HOJE como você vê a adoção do MongoDB para sistemas ERP por exemplo.

    Relacionamento entre registros? (Hoje faço “manualmente”)
    Uma coisa que eu não sei se é vantagem ou desvantagem

    imagine um registro onde temos 1-n (Cliente e Contatos), sendo que contatos fica como emmbeded, blz, se eu trouxer um cliente ele já retorna o contato, mas se eu quiser trazer uma lista de todos os clientes? ai vai retornar todos os contatos, fico na dúvida se compensa adotar ele no projeto novo ou modelo relacional, problema do modelo relacional é atualização de squema (hoje temos migrations) mas fantástico mesmo é o schema free

    i ai, o que você acha nos dias de hoje, levando em consideração que já se foi mais de 4 anos desse post!

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Rodrigo,

    bom: eu sempre fui a favor de uma abordagem mista. Se você pensa em documentos se relacionando, MongoDB não é uma boa opção para você, mas sim o modelo relacional.

    Ano passado escrevi algumas coisas sobre isto: http://www.itexto.net/devkico/?p=1621

    Responda

  9. Excelente post!!

    Realmente tirou minhas dúvidas a respeito do MongoDB e vou procurar mais artigos e livros sobre esse SGBD NoSQL.

    Parabéns.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Obrigado!

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *