Curiosidades sobre adoção do MongoDB (nosql) nas startups brasileiras

221 views
Skip to first unread message

horacio...@gmail.com

unread,
Mar 30, 2014, 4:15:02 PM3/30/14
to startup...@googlegroups.com
Olá Mundo!

Pessoal gostaria de ter alguns feedbacks de vocês sobre a adoção de bancos orientados a documentos, mais conhecidos como NoSQL como por exemplo o MongoDB (que mantém a persistência dos dados diferentemente do Memcached ou Redis) nas nossas startups. 

Quem está utilizando (projeto)?

Se usa em conjunto com um banco relacional (sim ou não)?

Quais as principais recursos como replica set, sharding, fullTextIndex (FTS), índices geoespacial, etc?

Ps.: as questões são apenas para orientar, mas não limitar as respostas. Seria bom ouvir também coisas do tipo: NÃO TEM NEM PLANOS DE USAR, NEM SEI PARA QUE SERVE, NÃO ME ATENDE POR CAUSA DISSO E DAQUILO, etc.


Um abraço à todos!


--
[]'s
Horacio Ibrahim
-----------------------------

Guilherme Bacellar Moralez

unread,
Mar 30, 2014, 6:53:57 PM3/30/14
to startup...@googlegroups.com
Olá. 

Nos da Kontrolu usamos MongoDB em 99% das funcionalidades e Azure tables para sessão de usuário. 

Estamos nós certificando para usar Sharding e RéplicaSet. 

Posso dizer que o Mongo é extremamente estável e bem rápido. 

Atualmente te só 6GB de dados

O Mongo nós proveu uma flexibilidade de montagem dos dados no formato mais adequado para nossa solução e assim temos uma performance muito boa com queries bem eficientes (índices ajudam muito). 

Tive a oportunidade de conversar com os engenheiros e programadores do Mongo e fiquei surpreso com eles e com as funcionalidades do Mongo. 

Veja, usamos em .net e no decorrer do desenvolvimento ainda estamos criando nossas classes de acesso a dados, mas amigo, o bichinho é porreta, hehehe. Posso afirmar com convicção que ele agüenta a bronca. 

Enviada do meu iPad
--
Você recebeu essa mensagem porque está inscrito no grupo quot;Startup Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para startup-brasi...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para startup...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/startup-brasil.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/startup-brasil/CA%2BOZePC5fahFf%3DYXFUxi5P-yJaS3LB%2B44ZFR7c7KifoUE%2BQQvA%40mail.gmail.com.
Para mais opções, acesse https://groups.google.com/d/optout.

sebastian

unread,
Mar 30, 2014, 7:08:03 PM3/30/14
to startup...@googlegroups.com

On Mar 30, 2014, at 5:15 PM, horacio...@gmail.com wrote:

que mantém a persistência dos dados diferentemente do Memcached ou Redis

bacana a thread, Mongo é massa.

Só uma coisa a falar do Redis.

Ele não é base de dados, é um repositório de estruturas.

Ele pode persistir estado em disco, mas acho que é perder tempo tentar usar ele como database.

O mais valioso que vi nele é usar ele para observar/reagir de vorma escalável usando a feature de pub/sub

Serve também para sessão, mas isso o Memcached tresolve.

O pub/sub já é bem legal e unico do Redis

Vinícius Borriello

unread,
Mar 31, 2014, 10:05:04 AM3/31/14
to startup...@googlegroups.com
Na empresa em que trabalho também estamos usando MongoDb em alguns projetos, principalmente por conta da escalabilidade e flexibilidade. Também utilizamos junto com MySQL no mesmo projeto, pois existem relacionamentos complexos que são dão mais trabalho para manter a consistência dos dados no MongoDb. Vou fazer uma lista com alguns pontos que acho relevantes:
  • A orientação a documentos é muito vantajosa, principalmente quando você ainda está desenvolvendo seu MVP e sua estrutura de dados pode ter pequenas (ou maiores) variações;
  • Facilidade de escalabilidade, é realmente muito simples criar um replica-set/particionamento;
  • MapReduce, apesar das críticas de performance por ele rodar em JS, melhorou consideravelmente nas últimas versões depois da substituição da engine pela V8. É bem simples montar queries complexas utilizando mapreduce, porém se você precisa das respostas em tempo real, dependendo do tamanho das suas coleções, vai precisar de um servidor mais parrudo e índices eficientes, pois realmente não é referência em performance;
  • Aggregation framework é uma maravilha, extremamente rápido e eficiente. A curva de aprendizado não é muito curta, mas definitivamente vale o esforço. Depois de aprender isso não tenho mais vontade de escrever query em SQL. Recentemente migramos relatórios que eram gerados a partir de MapReduce para o Aggregation Framework e o tempo para gerar os dados foi reduzido em média 8 vezes;
  • Pré-agegação de relatórios, não é uma funcionalidade particular do Mongo, mas é muito simples montar relatórios pré-agregados baseado na sua necessidade de granularidade dos dados, e o ganho de performance é espetacular.
Concluindo, estamos muito satisfeitos com o MongoDb, mas existem casos onde ainda é melhor usar SQL por conta do relacionamentos. Por isso nossa solução híbrida.

Abraço,
Vinícius

Guto

unread,
Mar 31, 2014, 10:43:34 AM3/31/14
to startup...@googlegroups.com
Se estiver disposto a pensar fora do modelo relacional e principalmente não vai precisar de "joins", vai em frente com o MongoDB. A aprendizagem é extremamente rápida e há as interfaces para Java, Node.js, Js e outras.

Guto.

P.S.: Se realmente precisar se joins, a funcionalidade MapReduce irá te consolar um pouco. ;-)


Em domingo, 30 de março de 2014 17h15min02s UTC-3, horacioibrahim escreveu:

horacio...@gmail.com

unread,
Mar 31, 2014, 3:13:04 PM3/31/14
to startup...@googlegroups.com
Boas experiências. Achei bem interessante vocês terem passado do MapReduce para Aggregation. "Recentemente migramos relatórios que eram gerados a partir de MapReduce para o Aggregation Framework e o tempo para gerar os dados foi reduzido em média 8 vezes" . 

Interessante também sobre essa questão do MVP. O mongoDB é orientado ao desenvolvimento ágil ;)

@gutobrz  "principalmente não vai precisar de "joins". Quais os problemas com joins não suportados pelo MongoDB? Você tem algum experiência que seja possível contar? (Obviamente partindo do ponto que sabemos que MongoDB não suporta joins e que tem sua própria forma de fazer os seus "joins" tirando alguns vatangans de fazer menos queries no banco e de que podemos usar as referências para outros casos com subdocuments ou embedded documents).





--
Você recebeu essa mensagem porque está inscrito no grupo quot;Startup Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para startup-brasi...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para startup...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/startup-brasil.

Para mais opções, acesse https://groups.google.com/d/optout.

Iuri

unread,
Mar 31, 2014, 3:25:15 PM3/31/14
to startup...@googlegroups.com
Minha base principal é relacional. Uso MongoDB para otimização, como uma view para manter os dados em memória e ainda poder fazer queries nesses dados. Uso com replica sets mas nunca vi uma instância caindo (~1 ano rodando assim).

Recomendo, mas ainda fico com o relacional para a maioria dos casos.


horacio...@gmail.com

unread,
Mar 31, 2014, 4:21:19 PM3/31/14
to startup...@googlegroups.com
Claro que quem está com sua app rodando com relacional não vai chegar de uma hora para outra e usar MongoDB. Mas penso em entender aonde está o não. Porque imagine o time começa a desenvolver com mongo e chega em lugar X (quem é esse X) que não daria para utilizá-lo. Confesso que eu não conheço quais são esses x's, mas um vídeo que ainda não vi completamente pode ter algumas respostas:




Para mais opções, acesse https://groups.google.com/d/optout.

horacio...@gmail.com

unread,
Mar 31, 2014, 4:21:36 PM3/31/14
to startup...@googlegroups.com

Jose Queiroz

unread,
Apr 2, 2014, 10:09:32 PM4/2/14
to startup...@googlegroups.com

Olá,


Utilizamos os MongoDB. Ainda estamos na fase de desenvolvimento, portanto não posso afirmar com precisão questões relacionadas a performance e afins.


Até o momento, a experiência tem sido positiva. A escolha do MongoDB se deu pelo “encaixe” com Python. Digo, pela facilidade e elegância no código que encontramos em manipular os documentos.


Além disso, o MongoDB não é tão cru em termos de recursos comparado às outras bases não relacionais. O meio do caminho entre o relacional e o não relacional neste sentido.


E a base de usuários também pesou, para sanar algum problema.



Em domingo, 30 de março de 2014 17h15min02s UTC-3, horacioibrahim escreveu:

horacio...@gmail.com

unread,
Apr 9, 2014, 10:07:44 AM4/9/14
to startup...@googlegroups.com
Massa galera! 

Obrigado por compartilhar as experiências de vocês. Eu após 4 meses dedicados (partindo para mais 2) aos cursos oferecidos na "universidade mongodb" para conhecer mais fundo o produto estou convencido de certa inversão de valor no qual antes era preciso justificar porque usar mongoDB e agora (para mim) é preciso detalhar o porquê não iremos usar o MongoDB  ;)

Espero que apareçam mais experiências do MongoDB por aqui! 

--
Horacio Ibrahim




--
Você recebeu essa mensagem porque está inscrito no grupo quot;Startup Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para startup-brasi...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para startup...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/startup-brasil.

Para mais opções, acesse https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages