A crescente irrelevância do MongoDB

A crescente irrelevância do MongoDB 1

Minha relação com MongoDB se divide em duas fases que, acredito, são o normal entre diversos usuários deste produto: deslumbramento e realidade. Neste post exponho a terceira fase que estou experimentando: irrelevância.

Deslumbramento

deslumbramento

Tive uma sorte imensa em meu primeiro contato com o MongoDB: o usei em uma arquitetura de persistência poliglota na qual ele cuidava dos casos nos quais os atributos de algumas entidades variavam bastante. Foi uma experiência muito bem sucedida: o que variava demais ficava no MongoDB e o restante em uma base de dados relacional.

Na época fiquei maravilhado com o desempenho do MongoDB e com a facilidade de instalação e configuração. Além disto a sintaxe das consultas me parecia bastante atraente naquele momento (Javascript!).  O ganho que vi na época (e ainda vejo) na emergência do MongoDB (que provavelmente foi o principal responsável pela popularização das soluções NoSQL) foi o fato de ter nos acordado para um erro tão comum que nem o considerávamos como tal: nem todas as estruturas de dados deveriam ser armazenadas em tabelas. De repente todos nós, desenvolvedores, percebemos que havíamos transformado o universo em tabelas e aquilo não era bom.

Aí segue aquela fase de experimentações em que você se maravilha com o que consegue fazer com a nova ferramenta. Surgirão milhares de posts na Internet relatando experiências legais e isto acaba alimentando o próprio deslumbramento que temos com a nova ferramenta.

Realidade

realidade_mongodb

Conforme o tempo foi passando vi a emergência de tecnologias como MEAN, extremamente interessantes mas que muitas vezes levavam aqueles que a adotavam (em estado de deslumbramento) a repetir nosso erro com a adoção do modelo relacional: MongoDB como solução universal para todos os problemas de persistência.

Vi também alguns projetos em Java adotando MongoDB como única solução e pagando um altíssimo preço. Ficou claro que em diversas situações o MongoDB estava deixando de ser uma solução para se tornar um problema (e dos grandes). As razões eram óbvias, mas o hype acabava por cegar diversas pessoas alguns aspectos fundamentais:

  • O modelo relacional é e continuará relevante por eras: se você precisa de relacionamentos, MongoDB não é seu amigo. E não se engane: redundância de dados sob a forma de documentos embarcados não é uma solução, mas sim um problema disfarçado de solução na maior parte das vezes. Integridade referencial é importante: não está aí há quase quatro décadas por modismo.

    (não acredite no papo furado de que por ser muito diferente é bom e você está com uma mentalidade atrasada)

    (implementar na mão integridade referencial é uma experiência MUITO triste)

  • MongoDB não possuía controle transacional ENTRE documentos: ok, você obtém um desempenho excelente ao não ter um ACID completo, mas quando precisa lidar com mais de um documento em uma mesma unidade de processamento ACID faz MUITA falta.
  • Ainda não há uma longa tradição na manutenção de bancos de dados baseados em documentos, então ainda não há boas práticas comprovadas pelo tempo, mas sim declaradas por um ou outro que se auto proclama “autoridade no assunto”.

    (suspeite dos “gurus”)

  • O argumento de desempenho fantástico do MongoDB é falacioso se você não souber de antemão qual o desempenho que seu projeto precisa. Ter o mais rápido não equivale a ter a melhor solução.

Esta é a fase na qual você passa a saber de forma clara onde a ferramenta pode ou não ser usada.

Irrelevância

k7tape

Confesso que não esperava por este estado na minha experiência com o MongoDB, mas ele ocorreu de uma forma tão natural que um belo dia acordei e percebi que não iria mais adotá-lo como solução. Repare: considero irrelevante o produto MongoDB, não o modelo de persistência baseado em documentos. Esta irrelevância se manifestou para mim em dois momentos.

Primeiro momento: TokuMX

tokutek

Algumas das limitações do MongoDB atrapalhavam bastante meu trabalho. Dentre estas, a principal era o fato de não haver transações quando manipulamos mais de um documento em uma mesma unidade de processamento. Buscando alternativas encontrei o TokuMX: um fork do MongoDB que era atraente pelas seguintes razões:

  • Me possibilitava ter transações entre múltiplos documentos em uma mesma unidade de processamento.
  • Ordens de magnitude mais rápido que o MongoDB.
  • Consome uma quantidade de espaço de armazenamento significativamente menor ( isto pude comprovar na prática) .
  • 100% compatível com o MongoDB: basta substituir minha instância do MongoDB pelo TokuMX que meus clientes sequer perceberiam a mudança e já teriam os ganhos acima.

A partir deste momento TokuMX tomou o lugar do MongoDB em meus projetos. Claro que ele não era uma solução perfeita. Algumas de suas limitações poderiam ser bastante chatas:

  • Não há uma distribuição do TokuMX para Windows.
  • As bibliotecas Java usadas para lidar com MongoDB não tiram ainda proveito do suporte transacional do TokuMX. Spring Data não oferece suporte e os drivers que usei também não.  Apesar disto, é possível tirar proveito desta funcionalidade através do envio de comandos ao SGBD, mas não é uma solução tãããão elegante quanto deveria ser.

No entanto a irrelevância do MongoDB neste momento é temporária. Nada impede que surja uma nova versão que supere o TokuMX.

Segunda fase: PostgreSQL

Postgresql_logo

Este foi o prego no caixão. O PostgreSQL desde a versão 9.2 já oferece suporte ao tipo de dados JSON e JSONB em suas tabelas. É uma solução interessante pois mescla em um mesmo SGBD os modelos de persistência baseado em documentos e relacional. Tudo isto dentro de uma arquitetura de anos cuja qualidade já está pra lá de comprovada.

O único ponto que o MongoDB mantinha neste caso era seu desempenho. Era, pois em 2014 a versão 9.4 do PostgreSQL superou (e muito) o desempenho do MongoDB. Duvida? Aqui está o link. Não sei ainda como o PostgreSQL se compara ao TokuMX, mas o simples fato de poder usar um único SGBD ao invés de dois já é uma vantagem bastante interessante para mim. Some a isto o fato de ter o ACID completo e acessível de uma forma simples, PostgreSQL acaba de tomar o lugar do TokuMX.

Concluindo

Se você comparar o MongoDB com as alternativas do mercado, verá que a maior parte da sua relevância se foi. Não o considero um produto ruim, mas sim inferior aos desdobramentos que vieram na sequência (TokuMX e PostgreSQL 9.4). Se há soluções superiores e com um custo mais interessante, o que posso fazer agora é apenas aguardar para ver como o MongoDB evoluirá em 2015 e além.

14 comments on “A crescente irrelevância do MongoDB

  1. Dyego

    Não sei como VC aguenta o pgsql, são tantas as chatices com maiúsculas e minúsculas e a cjatisse das localizações com acentos que me decepcionei muito com ele…

    Responda

    Eduardo Frazão Reply:

    Você se decepcionou com um banco featureful só por causa de case sensitive?

    Responda

  2. Leonardo

    Ola Henrique,

    Feliz ano novo! Não acho que o Mongodb seja esse vilão todo. Acho um banco de dados bem interessante, em constante evolução, fácil de usar (mas acho json uma chatice), nem tão fácil de configurar e otimizar, com sharding e clustering que ao meu ver funcionam bem. Na época o driver que utilizei foi o reactive mongo (reactivemongo.org) + rogue (https://github.com/foursquare/rogue) que são um complemento interessante. Gostei muito da funcionalidade geoespacial e ainda não explorei a agregação (http://docs.mongodb.org/manual/core/aggregation-introduction/) mas parece extremamente interessante. Tem um vídeo interessante do google IO sobre sql x nosql que apesar de não falar de mongodb, retrata bem as diferenças de uso e melhores práticas: https://www.youtube.com/watch?v=rRoy6I4gKWU. Outro artigo dá algumas idéias de como trabalhar com transações e mongodb http://edgystuff.tumblr.com/post/93523827905/how-to-implement-robust-and-scalable-transactions.
    Como fica claro em várias fontes pela internet, o mongodb não é aplicável em qualquer contexto. Pode ser que esse tenha sido o seu caso. No meu caso, não tenho o que reclamar… Abs,

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Leo, pra você também, valeu!

    Na realidade, não estou dizendo que é um vilão ou seja uma solução ruim: apenas que não tem mais toda a relevância que tinha quando apareceu, época na qual era a principal referência em persistência baseada em documentos. Atualmente fica em terceiro lugar para mim como pode ser visto no post.

    Este artigo sobre as transações eu já li e apliquei, mas a solução do TokuMX é ordens de magnitude mais simples e robusta neste ponto, razão pela qual acabou tomando o lugar do MongoDB.

    No meu caso, apliquei em diversas situações nas quais deu muito certo e vi outras nas quais foi um fracasso completo justamente por que a equipe o via como solução para todos os problemas.

    Responda

  3. Leo Silva

    Fala Henrique, muito bom o post!

    De fato, eu vi a algum tempo sobre o Postgres trabalhar da mesma maneira e achei foda pelo mesmo motivo que você.
    Eu já trabalhei com o mongo em um projeto a alguns anos, onde havia uma arquitetura mesclada: oracle + mongodb, porém logo no inicio de prod já houve problemas em relação a memória consumida por ele.
    Quando olhei o post imaginei que fosse exageiro da sua parte, levando em conta o título, mas ao terminar de ler o artigo te dou toda a razão.
    No meu caso o que me fez gostar do Mongo inicialmente foi a facilidade de configuração e principalmente a utilização de javascript pra realização de operações, é tipo uma terapia pra mim kkkkkk.

    Mas é isso ai, ótimo post, valeu!

    Abç

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Leo, valeu, obrigado!

    Responda

  4. Rafael Jesus

    Fala Kiko,

    Cara realmente, se a maioria do seu dado é transacional não adianta, agora se vc precisa de meia duzia de rollback vc consegue sobreviver,

    Não vejo grande vantagem em usar mongo ou qq outro NoSQL se vc n tem necessidade de usar replica sets, precisa de alta disponibilidade, precisa escalar de fato sua aplicação, em outras palavras vc precisa de dado, muito dado,

    Dado q um dos maiores beneficios do Mongo é ser tão fácil escalar q o próprio dev em poucas horas,

    E isso ocasiona q tem um monte de dev q n sabem a grandeza q uma app precisa ter e ja sobe 2 maquinas c mingo e sharding configurado, vi isso de uma pessoa muito conhecida na comumidade,

    Neste cenário bancos NoSQL brilham e já comprovaram pq estão ai e ja tem milhares de bancos NoSQL cada um c uma caracteristica, c transações, alta disponibilidade, aerospikedb scala mais q cassandra q escala mais q mongo e etc…

    Ja no embalo Kiko, tem muita gente usando uma unica solução p tudo ex Javeiro so usa Java, Rubista Ruby, Javascripters usam Node e Mongo pra tudo e depois se decepcionam pq Node n e bom se sua app usa muita CPU,

    E tbm tem muito rubista se ferrando ou ferrando c o bolso dos investidores escalando aumentando maquinas na Amazon pq insistem usar o MRI,

    Enfim, por isso q sou total a favor de desenvolvimento poliglota, mas ha pouquissimas empresas preaparadas para tal profissional,

    Continue escrevendo Kiko,

    Abrcs

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Rafael, obrigado, valeu!

    Sim: este mito da “ferramenta universal” é furadíssimo.

    Sobre a questão transacional, nem tem mais por que usar o MongoDB (por enquanto), dado que o TokuMX nos dá exatamente isto e ainda um desempenho bastante superior ao MongoDB.

    Responda

    Rafael Jesus Reply:

    Eu nao conhecia TokuMX, vo da uma estudada :)

    Responda

  5. Matheus Moreira

    Tarde, Kiko!

    Achei particularmente interessante a referência ao PostgreSQL como alternativa ao MongoDB. Já o utilizou em alguma solução em substituição ao Mongo ou mesmo ao TokuMX?

    Abraço

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Matheus,

    no caso do PostgreSQL eu apenas fiz algumas POCs, não cheguei a usar ainda em produção, mas pode ser que em muito breve já tenha um caso com experiência direta pra compartilhar. :)

    Responda

    Matheus Moreira Reply:

    Massa!

    Eu e um amigo fizemos um sistema de questionário eletrônico para um cliente e um tempo depois eu pensei se a modelagem dos dados não seria favorecida se adotássemos um esquema documental. Depois vou experimentar isso.

    Você tem sugestão de textos a respeito de modelagens voltadas para soluções NoSQL?

    Abraço

    Responda

  6. Mauro

    Olá Kico,

    Muito bom o artigo. (sua experiência tornou o artigo muito melhor).
    Você já ouviu falar no ToroDB? https://www.8kdata.com/torodb
    Parece que o caminho será “postgrelizar o MongoDB” e/ou “Mongolizar o PostgreSQL”, unindo o que há de melhor dos mundos SQL e NoSQL… Será?

    Abraço.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Mauro, obrigado!

    Este aí não conhecia, vou dar uma olhada, valeu!

    Responda

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.