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
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
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
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
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
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.
Deixe uma resposta