Porquê você nunca deveria usar MongoDB

[MaizerGomes]

Why You Should Never Use MongoDB
Disclaimer: I do not build database engines. I build web applications. I run 4-6 different projects every year, so I build a lot of web applications. I see apps with different requirements and different data storage needs. I’ve deployed most of the data stores you’ve heard about, and a few that you probably haven’t.

I’ve picked the wrong one a few times. This is a story about one of those times — why we picked it originally, how we discovered it was wrong, and how we recovered. It all happened on an open source project called Diaspora.

Nas andanças aí pela internet tropecei em um artigo muito interessante sobre o uso de base de dados NoSQL, ou melhor, o NÃO uso de bases de dados NoSQL (MongoDB mais concretamente) que acabou tirando muitos dúvidas e medos que eu tinha em relação ao fim das bases de dados relacionais, e também esclareceu alguns mitos sobre esta relativamente "nova" tecnologia.

Eu ainda não cheguei a usar uma dita base de dados NoSQL (ou pelo menos que eu tenha me dado conta... será que Redis conta? Acho que sim..) , somente em alguns campos de certas tabelas que acabo armazenando os dados em json no DB PostgreSQL porque estes não tem uma estrutura fixa (esquema) e necessitam uma certa flexibilidade.
Nunca usei porque nunca tive necessidade em algum projecto e ainda não fez parte dos requisitos mas, através deste artigo, pude entrar um pouco mais dentro da filosofia do NoSQL.

Advertindo que o artigo está escrito em inglês (se você não flutua no inglês, isso não é nada que o chrome não possa lidar e ainda te ajudar a dar algumas gargalhadas com os erros de concordância e traduções directas) e é um pouco longo mas para quem está na dúvida sobre a base de dados que vai usar ou nem sabe o porquê estar a usar a DB que está a usar ou então escolheu porque é o que todo mundo está usando, este artigo vai ajudar.

O artigo conta a trajectória do desenvolvimento de uma rede social distribuída e open source (Diaspora), os erros e as lições.

Eu acho que o ponto levantado nesse artigo pode trazer alguma discussão aqui sobre essa área, apesar de aqui o nome ser front-end 😅

O artigo foi escrito por @saramei, uma desenvolvedora americana do mundo Ruby. 👩‍🎨

Link do artigo

[felipefialho]

O que acha @suissa?

---

Parabéns pela qualidade da issue @MaizerGomes.

[expalmer]

Cada caso é um caso, a algum tempo atrás o pessoal da Propus(o Anderson twitter => @Dump) ajudou na implementação de uma nova coleta de dados que estava sendo feita na Petrobras(Pré-sal), onde a máquina que fazia a perfuração coletava dados e jogava para um Oracle...o relatório desses dados levava 16 horas para ser gerado...então a equipe da Propus com MongoDb (juntamente com o pessoal da Mongo que veio ao Brasil para ajudar no case) terminaram gerando o relatório em 6 segundos.
Cada caso é um caso.

[gpiauilino]

Cada caso é um caso. Mongo jamais foi e jamais será a melhor solução para este tipo de tarefas.

[suissa]

Já respondi lá no grupo do Facebook há pouco tempo, vamos por partes:

Ano de 2013: Dilma era presidente e as coisas mudaram MTO desde lá.

Mas o erro crasso cometido nesse artigo é que a pessoa PRECISAVA de um banco de GRAFOS e queria que o MongoDB trabalhasse como um GRAFO em vez de usar um banco como o Neo4J.

Todo o embasamento teórico desse artigo está completamente errado simplesmente pq a pessoa não sabia que precisava de GRAFOS, pena que não é aquele com pontos falando das coisas RUINS do MongoDB pq não li nada que corroborasse com a ideia de não usar o MongoDB.

@expalmer o @Dump ja foi meu chefe 2x ehehhehehehhee

Ps: Qualquer artigo que inicie com "você nunca deve usar" não merece muita atenção pois grande parte das vezes exprime opiniões pessoais do autor o qual deve ter se fodido com aquela tecnologia por não saber usar.

[felipefialho]

Ps: Qualquer artigo que inicie com "você nunca deve usar" não merece muita atenção pois grande parte das vezes exprime opiniões pessoais do autor o qual deve ter se fodido com aquela tecnologia por não saber usar.

👏 👏 👏

@suissa posso mandar emoldurar?

[suissa]

Se alguëm começar uma rede social NÃO UTILIZANDO GRAFOS é pq começou errado e o resto será mimimi.

REDE SOCIAL === GRAFOS

[expalmer]

Show @suissa! Gostaria de um dia trabalhar com vocês dois kkkk aí sim eu aprenderia de verdade!
o/

[suissa]

Foram ótimos tempos aqui em Sampa @expalmer . Como evangelizo o MongoDb desde 2010 o @dump foi um dos meus primeiros contatos tb nesse mundo NoSQL.

[estevanmaito]

Esse cara que escreveu o artigo que você citou, poderia ter sido esse: https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83#.3xg5a8uwu

O cara criou um app pro Pokemon GO com Node, Mongo/Mongoose e num determinado momento, ele tava na seguinte situação:

At one point last weekend, our server’s 4 NodeJS processes were running at 90% CPU each, which is unacceptable to me for 800–1000 concurrent users.

1000 usuários, 4 processos e 90% de CPU. Já dava pra parar aí e escrever um artigo sobre "nunca use Node e Mongo". Como o @suissa falou, o cara aí de cima não sabia o que ele precisava, mas nesse caso aqui o cidadão sabia o que tava fazendo.

Apparently I simply had to enable Mongoose’s “lean()” function to get plain JSON objects instead of magical Mongoose objects. After that change, the NodeJS processes dropped to around 5–10% CPU usage.

Saber o que tá fazendo permitiu a ele escrever uma linha (ativar o lean()), que economizou 85% de CPU e o app dele aguentou 500k users. Fora a vergonha que ele não passou pra escrever um artigo "não use...".

[rubenmarcus]

@estevanmaito muito bom esse artigo

[felipeuntill]

Um dos aprendizados que tive nestes ultimos 10 anos desenvolvendo sistemas qual realmente me proporcionou maior maturidade profissional foi aprender a respeitar cada ferramenta e suas peculiaridades.

Basta uma simples olhada em qualquer site de framework, banco de dados ou linguagem e você vai ver enormes corporações usando estes recursos, todas eles sem exceção possuem cases de sucesso, portanto presumir que uma ferramenta qual atende projetos enormes é ruim é no mínimo medíocre e insensato.

Com o passar do tempo passamos a criar uma bagagem de aprendizado que define muito da forma como lidamos com a arquitetura de sistemas, eu por exemplo passei anos da minha vida desenvolvendo primariamente com C#/Java/Ruby e apesar de amar Javascript, muitas vezes me pego aplicando design patterns e conceitos de orientação a objetos em aplicações nodejs quais não exigem complexidade alguma, todavia em minha cabeça todo sistema tem de possuir camadas e mais camadas além de trocentos níveis de herança. Se eu não tomar cuidado acabo transformando algo que poderia ser escrito em 100 linhas de código em um sistema apto a rodar em mainframe.

Quando os bancos de dados não relacionais se tornaram uma Buzzword muita gente optou por migrar sem realmente entender quais as aplicabilidades e quais problemas estes bancos de dados realmente resolviam, não existe bala de prata, em alguns cenários o relacional se faz totalmente necessário em outros, qualquer banco de dados keyvalue simplista atende, em situações mais complexas só um banco orientado a grafos sustenta os relacionamentos demasiados.

Para cada problema existe uma solução adequada e achar que algo não é bom porque não funciona pra você é admitir que você não sabia o que estava fazendo quando selecionou o recurso.

[gpiauilino]

Mongo até agora para mim é o pior database para análise e estatística, digo por conta de um grande problema básico:
Dificuldade em serviços de conexão e disponibilidade de documentação assertiva quanto ao carregamento de dados para formato tabular.
Os drivers ODBC não funcionam bem, exigem uma grande experiência para lembrar as picuinhas de um produto que parece que foi desenvolvido por gente preguiçoso.