Desmistificando os principais mitos sobre MongoDB vs bancos de dados relacionais

Recentemente, eu estava conversando com um amigo sobre a decisão entre bancos de dados para um próximo projeto. Perguntei a ele o que ele pensava sobre o MongoDB. Ele me disse que não achava que funcionaria, com base no que sabia sobre ele. O único problema era que tudo o que ele sabia sobre o MongoDB era de 2013. Ele não acompanhou mais de uma década de melhorias e atualizações. Ao conversar com outros desenvolvedores, essa parece ser uma situação bastante comum. Muitos desenvolvedores tiveram uma primeira impressão do MongoDB entre 2012 e 2014 e formaram suas opiniões com base nisso. Nesta publicação, mergulharemos em um pouco da história dos bancos de dados e veremos como o MongoDB se compara aos bancos de dados relacionais hoje.

Como uma rápida atualização, existem vários tipos de bancos de dados, mas vamos nos concentrar nos bancos de dados relacionais e nos bancos de dados de documentos NoSQL, já que esses são dois dos tipos mais populares em uso atualmente. Os bancos de dados relacionais foram introduzidos na década de 1970 e armazenam dados em tabelas. Embora o termo NoSQL tenha sido criado em 1998 por Carlo Strozzi, levou mais alguns anos para que os bancos de dados NoSQL — e sua abordagem mais flexível para armazenar dados — realmente decolassem. Em 2009, o MongoDB foi lançado com a ideia de armazenar dados em documentos semelhantes a objetos JSON. Quando explico a diferença básica entre bancos de dados relacionais e de documentos para minha família, geralmente digo que um é como uma planilha e o outro é como um Documento do Google. Ainda não tenho certeza de quanto a minha avó entende sobre qual é o meu trabalho, mas pelo menos agora ela conhece a diferença entre os tipos de banco de dados.

Ok, agora que abordamos o básico, veremos os equívocos que surgem ao comparar o MongoDB com bancos de dados relacionais.

Mito 1: o MongoDB não tem um esquema

Um esquema define a estrutura dos dados em um banco de dados. Com bancos de dados relacionais, você normalmente projeta seu esquema com base na normalização dos seus dados. Normalizar significa que você divide seus dados em tabelas diferentes para não duplicar dados. Esses esquemas definidos são ótimos se você puder antecipar todas as suas necessidades futuras de dados e projetá-los elegantemente com antecedência. Atualizar esses esquemas para adicionar novos campos pode adicionar trabalho extra e tempo de inatividade para seu aplicativo.

Com o MongoDB, seu esquema depende das necessidades de sua aplicação. Esta é uma abordagem mais flexível ao projeto de esquema. Mesmo com essa flexibilidade, ainda existem melhores práticas, como a regra de que "os dados acessados juntos devem ser armazenados juntos".

Aqui está um exemplo de como os dados relacionais acima podem ser armazenados no MongoDB:

Você pode ver neste exemplo que você pode obter todos os dados em “Paul Miller” sem ter que fazer JOINS em três tabelas diferentes. Você pode fazer JOINS no MongoDB, mas falaremos mais sobre isso mais tarde.

Com um esquema flexível, os desenvolvedores podem começar a criar aplicativos sem precisar definir previamente um esquema definitivo e ficar limitados a ele. Você pode adicionar facilmente novos campos ao seu esquema sempre que a aplicação precisar deles. Se você quiser ter esse esquema mais estruturado, poderá usar o recurso de validação de esquema do MongoDB. Se você precisar que seu esquema evolua ao longo do tempo, também pode implementar facilmente o padrão de versionamento de esquema.

Por fim, acho que esse mito de que o MongoDB não tem esquema se resume a duas coisas. Primeiro, ele não tinha validação de esquema nos primeiros anos (esse recurso foi adicionado na versão 3.6, em 2017). A outra razão vem da flexibilidade que os desenvolvedores têm na criação de seus esquemas com base nas necessidades de suas aplicações. Liberdade e flexibilidade não significam não ter um esquema; isso apenas significa que é importante seguir as melhores práticas para criar um esquema elegante que faça seu aplicativo executar de forma ideal.

Mito 2: o MongoDB não é compatível com ACID

Os bancos de dados precisam de maneiras de garantir que as operações e os dados resultantes sejam confiáveis, mesmo quando ocorrem erros ou falhas de energia. A principal maneira de fazer isso é implementando quatro propriedades: atomicidade, consistência, isolamento e durabilidade, também conhecidas como ACID.

O MongoDB é compatível com ACID. Sempre que você realiza qualquer operação de criação, leitura, atualização e exclusão em um único documento, a integridade dos dados é preservada. O MongoDB processa um documento por vez. Caso contrário, não seria um banco de dados de documentos. Seria um banco de dados caótico e imprevisível. Você imagina vários autores tentando sobrescrever o mesmo documento ao mesmo tempo? Já participei de documentos no Google Docs com mais de 10 pessoas editando ao mesmo tempo, e certamente isso não parece compatível com ACID.

Isso cobre documentos individuais, mas o que acontece com transações multidocumento? As transações multidocumento são frequentemente usadas em bancos de dados relacionais, já que você geralmente precisa acessar várias tabelas ao realizar ações como atualizar um registro de cliente. O MongoDB garante transações ACID multidocumento entre quaisquer locais do seu cluster MongoDB. Esse suporte está disponível desde a versão 4.0, lançada em 2018.

Na verdade, a transacionalidade é um dos maiores pontos fortes do MongoDB. Muitas empresas do setor de serviços financeiros confiam nas transações do MongoDB para casos de uso de serviços bancários e de negociação. A garantia de tudo ou nada das transações multidocumento do MongoDB está ao seu lado.

Mito 3: o MongoDB não consegue fazer JOINs para lidar com dados relacionais

Anteriormente, mostramos como os bancos de dados relacionais dependem de dados divididos em várias tabelas para um projeto de esquema eficiente. Para trabalhar com dados relacionais, muitas vezes você precisa extrair dados dessas tabelas e combiná-los usando JOINs.

O MongoDB pode fazer JOINs com o comando $lookup. Mas o fato de você poder fazer algo não significa que deva fazê-lo. Os dados do MongoDB são modelados de forma diferente dos dados relacionais. No MongoDB, os dados acessados juntos são armazenados juntos. Como a maior parte dos dados está em um único documento, em vez de espalhada por várias tabelas, você não precisa fazer JOINS, pois os dados já estão no lugar certo. Essa mudança do modelo relacional para o modelo de documentos representa uma grande mudança de mentalidade, mas, depois que você experimenta seus benefícios, é difícil voltar atrás. No entanto, se você ainda precisar fazer JOINs com o MongoDB, o comando $lookup é o seu melhor aliado. Você pode até criar uma VIEW (adicionada em 2016) para unir duas coleções.

O mito de que JOINS não são possíveis se resume à diferença básica entre os modelos relacional e de documento. Os dados armazenados em tabelas e os dados armazenados em documentos exigem abordagens diferentes, mas, em geral, embora seja possível fazer JOINS no MongoDB, você não precisará deles se tiver projetado corretamente o esquema dos seus documentos.