Olá pessoal, hoje escrevo diretamente da estrada (indo treinar mais uma equipe em MongoDB) para falar sobre uma recente comparação entre MongoDB e ArangoDB. De verdade não foi uma comparação específica somente entre esses dois bancos, mas sim um estudo de caso entre vários, porém, peguei os pontos específicos onde o MongoDB foi citado. Antes de continuar, deixo aqui o link do artigo original escrito por Piotr Sroczkowski, por sinal bem detalhado.

A ideia é expor minhas opiniões sobre os itens comparados e abrir um debate, todos os pontos de vista serão bem-vindos!

Ausência de joins

Bem, esse ponto sempre causa muita polêmica quando é tocado. O que destaco é que quando trabalhamos com NoSQL (especialmente com o modelo de documentos) procuramos modelar nossas entidades agregando o maior número de informações possíveis num único documento para que tenhamos maior performance em nossas queries. Com isso, temos que nos preocupar em "fazer nossos joins" em tempo de modelagem, ao contrário dos bancos relacionais, onde eles serão garantidos pela boa e velha álgebra relacional.

Porém, dizer que o MongoDB não tem join é totalmente incorreto. Na versão 3.2 o operdador $lookup foi introduzido no Aggregation Framework, possibilitando assim "relacionar" dados entre coleções. O uso correto e combinado desse operador proporciona basicamente o mesmo efeito dos joins convencionais. Obviamente, como o MongoDB não trabalha com constraints, esse operador não garante que a coleção do outro lado encontre algum resultado. Nesse caso, traçando um paralelo com os bancos relacionais, o $lookup se assemelha ao LEFT JOIN.

Outro ponto relacionado a essa questão nesse comparativo é a complexidade e limitação do Aggregation Framework. Esse ponto está diretamente ligado ao $lookup, porque esse operador só funciona através da função de agregação do MongoDB. O Aggregation Framework veio para substituir (e muito bem) o mapReduce, esse sim eu diria que é complicado e bastante limitado para debugar. Concordo que o Aggregation Framework não seja tão simples de se entender, principalmente no início, mas ligo esse ponto à falta de familiaridade com os operadores e também o fato de estarmos muito acostumados com a SQL, que nos acompanha há pelo menos 40 anos.

Na minha opinião, quando nos propomos a aprender uma tecnologia nova, temos que ter em mente o fato de que iremos ter uma curva de aprendizado, e cabe a nós atenuá-la ou não. No caso do Aggregation Framework, a MongoDB disponibiliza um mapping de queries SQL aqui. Não tem tudo, mas eu considero uma bússola para iniciarmos com o Aggregation Framework.

A seguir um exemplo simples onde o aggregate ocorre na coleção orders e se relaciona com os documentos da coleção inventory:

db.orders.aggregate([
   {
     $lookup:
       {
         from: "inventory",
         localField: "item",
         foreignField: "sku",
         as: "inventory_docs"
       }
  }
])

O resultado dessa query seria algo assim:

{
   "_id" : 1,
   "item" : "almonds",
   "price" : 12,
   "quantity" : 2,
   "inventory_docs" : [
      { "_id" : 1, "sku" : "almonds", "description" : "product 1", "instock" : 120 }
   ]
}
{
   "_id" : 2,
   "item" : "pecans",
   "price" : 20,
   "quantity" : 1,
   "inventory_docs" : [
      { "_id" : 4, "sku" : "pecans", "description" : "product 4", "instock" : 70 }
   ]
}
{
   "_id" : 3,
   "inventory_docs" : [
      { "_id" : 5, "sku" : null, "description" : "Incomplete" },
      { "_id" : 6 }
   ]
}

No SQL seria algo do tipo:

SELECT *, inventory_docs
FROM orders
WHERE inventory_docs IN (SELECT *
FROM inventory
WHERE sku= orders.item);

Aqui você encontra a documentação completa do $lookup

Portanto, MongoDB não tem join e por isso escolho outro banco orientado a documentos: MITO!

Ausência de uma linguagem dedicada e expressiva

Outro ponto em que não concordo. Seguindo a filosofia dos fundadores do MongoDB, que acreditam que codificar deve ser algo natural, pra que criar mais uma linguagem cheia de funções para aprender, sendo que posso trazer o JavaScript para o lado do banco? É isso que o MongoDB propõe, utilizando a denotação JavaScript, através do uso de funções que recebem JSON como parâmetro.

O JSON, também em minha opinião, veio para solucionar vários problemas. Quem nunca teve que trabalhar com um WebService e aqueles XMLs gigantescos, cheios de dados que nunca eram usados. Esse padrão veio para simplificar muita coisa, e apenas para enumerar uma, cito o tráfego na rede! Os pacotes são muito menores utilizando-se JSON para trafegar informações.

Alguns exemplos de CRUD com MongoDB:

Insert

db.inventory.insertOne(
   { item: "canvas", qty: 100, tags: ["cotton"], size: { h: 28, w: 35.5, uom: "cm" } }
)

Find

db.inventory.find( { status: "D" } )

Equivalente em SQL:

SELECT * FROM inventory WHERE status = "D"

Update

db.inventory.updateOne(
   { item: "paper" },
   {
     $set: { "size.uom": "cm", status: "P" },
     $currentDate: { lastModified: true }
   }
)

Remove

db.inventory.deleteMany({ status : "A" })

Veja a documentação completa aqui.

Então, vamos tirar proveito de todos os benefícios que o JavaScript e o JSON tem pra oferecer e não ficar choramingando por uma linguagem nova para se aprender!

Ausência de transações

Bom, não vou entrar no mérito de que o MongoDB suporta transações em um único documento, porque como diria meu amigo Jhonathan Soares: isso não cola. Mas só pra lembrar, o MongoDB suporta isso desde a entrada do WiredTiger como Storage Engine, mas é um conceito diferente e que não remete ao conceito de transações como estamos acostumados.

Agora na versão 4.0, o MongoDB oferecerá suporte à transações em múltiplos documentos e o mais legal: suportará isso em Replicaset, ou seja, teremos transações em um ambiente replicado.

Concordo que no caso do ArangoDB isso já exista faz algum tempo, mas pra gente é um negócio novo e muito empolgante. Porém, segundo estudos da própria MongoDB, adotar o MongoDB como banco de dados atende de 80% a 90% dos casos de uso das aplicações.

Vamos aguardar a chegada das transações!

Tickets de problemas somente no JIRA

Ok, o Github é muito mais amigável do que o JIRA, mas colocar isso como um ponto para não adotar o MongoDB é demais! Diria até que é mimimi kkk!

Nunca tive problemas relacionados ao código do MongoDB em si, mas já precisei abrir um ticket no JIRA para falar sobre um ambiente no Atlas. E nesse caso funcionou muito bem, até quando teve a substituição do engenheiro inicial por um outro.

Novamente em minha opinião, não colocaria isso como um ponto para não adotar o MongoDB!

Conclusão

Como disse, quero deixar aqui o início de um debate. Nem todo mundo terá a mesma opinião, mas acho muito válida discussão e também levar em conta todos os pontos expostos aqui.

Abraços a todos!