3 razões para usar MongoDB

[Mário Monteiro 179]

3 razões para usar MongoDB

 

O MongoDB é um banco de dados orientado a documentos de alta performance, open source e schema-free, escrito em C++. Ele é uma mistura entre os repositórios escaláveis baseados em chave/valor e a tradicional riqueza de funcionalidades dos bancos relacionais.

 

Tem-se falado muito de bancos NoSQL e também do MongoDB, mas por que você deveria usá-lo? Hoje vou te dar três razões para que você passe a usar o MongoDB.

 

01. Consultas simples

 

MongoDB é um banco NoSQL baseado em documento sem transações e sem joins. Quando um aplicativo utiliza esse tipo de banco de dados, o resultado que se tem são consultas muito simples. Elas são mais fáceis de escrever. Elas são mais fácil de ajustar. Deixam os desenvolvedores fazerem seu trabalho mais facilmente. Em um exemplo onde 'usuarios' possuem 'eventos', existe uma tabela para cada um, com um usuario_id na tabela de eventos. Vamos dizer que eu quero todos os usuários que publicaram um evento.

 

Em um banco de dados SQL, tenho duas tabelas: usuários e eventos. Eu poderia escrever esta consulta da seguinte forma:

 

SELECT * from `usuarios` INNER JOIN `eventos` ON `eventos`.`usuario_id` = `usuarios`.`id` where `eventos`.`publicado` is not null group by `usuarios`.`email`;

 

Analogamente, em um banco de dados MongoDB, digamos que eu tenha apenas uma coleção: usuários. Cada documento de usuário tem um atributo chamado "eventos", que é uma lista de documentos incorporados. Parece algo como isto em JSON:

 

{

 

nome : Jean carlo Nascimento,

 

email: jnascimento@gmail.com,

 

eventos : [

 

{titulo : Primeiro!},

 

{titulo : Legal!},

 

{titulo : Festao, publicado : true}

 

]}

 

Para executar a mesma consulta em MongoDB, fica:

 

db.usuarios.find (('eventos.publicado': ($ ne: null)))

 

Mais simples. Mais simples de ler, de escrever. E você pode ver claramente como ele faz as coisas mais fáceis de entender.

 

02. Sharding

 

Sharding é um conceito simples: se você tem um monte de dados e está no limite de disco e/ou a falta de espaço, a resposta é ter os seus dados divididos entre várias máquinas. Você fica com mais rendimento e com maior capacidade de armazenamento em disco. Em um mundo perfeito, como seu armazenamento e desempenho precisa crescer, basta acrescentar mais shards.

 

MongoDB é muito próximo a este mundo perfeito. Se você tem um processo mongod execução, e quer usar sharding, você:

 

1. Abre uma nova máquina.

2. Inicia um processo novo mongod para atuar como um membro do cluster shard.

3. Inicia um processo novo mongod para atuar como um banco com configuração separada, para manter informações sobre quais bancos possuem shard.

4. Inicia um processo mongo e informa como encontrar o db atual, o novo membro do shard, o banco de dados de configuração.

5. Digita ~ 5 para permitir sharding em qualquer banco de dados e coleções que você quiser.

6. Modifica seus aplicativos para se conectarem ao processo mongo ao invés do antigo processo mongod.

7. Pronto.

 

Para saber mais como configurar o sharding, leia http://www.mongodb.org/display/DOCS/Configuring+Sharding

 

Toda a comunicação é feita sobre IP. Para configurar os processos mongod e mongo, podem ser executados em suas próprias máquinas ou correr na mesma máquina como um de seus shards. Isso pode ser feito com qualquer tempo de inatividade. E você não precisa ter um olho para o sharding quando começar, você pode tomar um antigo processo regular mongod e vai "simplesmente funcionar".

 

Existem soluções para esse problema no MySQL, mas eles exigem manipulação de dados em uma camada acima da base de dados. O próprio banco não oferece suporte a esse recurso. Além disso, você não precisa pensar sharding até que você precise dele, você não tem que pré-otimizar.

 

Agora pense em vídeo HD, geolocalização, mensagens em tempo real, realidade aumentada, imagens em tempo próximo ao real por satélite. Pense em todos esses dados, e na velocidade que as pessoas vão querer isso (e mashups e derivados disso). Então, pense sobre qual banco de dados que você deseja começar a usar agora.

 

 

3. GridFS

 

Digamos que você tenha uma aplicação onde o usuário pode fazer upload de uma foto de perfil. A prática corrente é a de armazenar o caminho para o arquivo no banco de dados, armazenar o arquivo no filesystem (sistema de arquivos compartilhado se você tiver vários servidores de aplicação) ou S3. Se você usar um sistema de arquivos, algum tipo de apoio é normalmente realizado também. Se você tem múltiplas aplicações, você tem que usar um sistema de arquivos compartilhados.

 

Com GridFS, você armazena arquivos no banco de dados. MongoDB foi construído para fazer isso. Por que isso é uma razão "para usar MongoDB"? Porque o MongoDB tem replicação e sharding de coleções. E adivinhem? Você pode aplicar esse material para coleções GridFS perfeitamente bem. Quando você guarda os arquivos no MongoDB, recebe toda a capacidade de replicação e sharding gratuitamente. Quer backup dos arquivos do usuário? Basta replicar as coleções GridFS.

 

Guardar os arquivos em um banco de dados é o caminho que deveríamos fazer de agora em diante.

 

Para conhecer melhor o GridFS, leia esse texto.

 

Conclusão

 

Então, se você utilizar o MongoDB, será fantástico por causa de uma sintaxe de consulta simples, a habilidade de shard dos dados entre máquinas com a facilidade e a possibilidade de armazenar arquivos em GridFS tirando partido de replicação e sharding. Isso porque não levei em conta a facilidade de instalação dele, que ganha de longe do CouchDB!

 

Fonte: iMasters

[EuToComProblema! 1]

E quanto as propriedades ACID (ACID em transação) dos SGDBs?

 

Suponho que não atenda a todas, correto?

[Maykonn 6]

E quanto as propriedades ACID (ACID em transação) dos SGDBs?

 

Suponho que não atenda a todas, correto?

 

Isso é para Bancos Relacionais... !!! ???

[EuToComProblema! 1]

Teoricamente sim, mas esquecendo a transação (que acredito não ter no Mongo)

 

Estas são propriedades importantes...

por exemplo, se não existe garantia de consistência dos dados não se pode confiar no sistema...

 

em outras palavras, gostaria de saber se esse MongoDB atente a todas essas propriedades ou apenas a algumas.

 

fiquei curioso desde que vi essa parte do fórum, só não corri atrás ainda pq sabem como eh a vida de programador ¬¬

[Maykonn 6]

Teoricamente sim, mas esquecendo a transação (que acredito não ter no Mongo)

 

Estas são propriedades importantes...

por exemplo, se não existe garantia de consistência dos dados não se pode confiar no sistema...

 

em outras palavras, gostaria de saber se esse MongoDB atente a todas essas propriedades ou apenas a algumas.

 

fiquei curioso desde que vi essa parte do fórum, só não corri atrás ainda pq sabem como eh a vida de programador ¬¬

 

Somos dois então. :D

Esse fórum promete!

[VascoDaGama 2]

prefiro não armazenar arquivos binários no sgdb por questões de performance e portabilidade.

 

performance:

- quando precisar fazer leitura do arquivo exigirá um processo a mais.. o qual, acho desnecessário.

- replication fica mais pesado, aumentando probabilidade de falhas. Isso pode ocorrer com o que o mongo propõe ?

 

 

portabilidade:

- imagine se um dia precisar migrar para outro tipo de sistema, oracle, mysql, postgre, sqlserver.. ou qq outro inovador.. sempre haverá um novo ou um antigo que se moderniza e tal.. como fica a questão da portabilidade nesse caso específico do mngo que é um sgdb "nao relacional".. Se eu quiser migrar para um banco relacional, imagine a dificuldade, os altos custos, (*)falta de profissionais qualificados no mercado.

 

 

(*)falta de profissionais qualificados no mercado

sim... é um sistema novo e não há profissionais suficiente para atender a demanda do mercado.

se o sgdb se tornar confia´vel e amplamente difundido, essa questão será de menos.

 

 

obs: li em outro post dizendo que vários sites estao usando o mongo e citou o twitter.. mas pelo que entendo, o twitter utiliza MySQL também, inclusive está recrutando profissionais com experiência em MySQL, clusterização, replications, etc..

Pelo que estou vendo o pessoal do mongo está fazendo muita propaganda... que nao estou querendo menosprezar.. mas propaganda demais é questionável.. quero ver na prática o quão eficiente é. Provando na prática e não em artigos superficiais.

[Prog 183]

Pessoal, a questão é muito simples... NoSQL e SGBDR possuem propostas e conceitos diferentes.

 

Ambos possuem fatias de mercado, conforme os sistemas Internet vão se tornando mais complexos, a exigência também vai mudando. É sabido que SGBDR possui maior fatia do mercado, mas cada cenário, dada a sua necessidade, pode ser suprida por um e/ou outro, ou até mesmo cair como uma luva para uma das inúmeras soluções NoSQL (cada um dos produtos existentes possui características que podem servir muito bem dado este ou aquele projeto).

 

Outra coisa, a fato de ter uma solução em NoSQL não elimina o uso de um SGBDR, coexistir numa mesma solução não é nenhum "crime"!

 

MongoDB não possui características ACID, porém é possível encontrar tais características em outras soluções. Opções NoSQL, além do MongoDB:

- Cassandra, CouchDB, Hadoop, MemcacheDB, SimpleDB, Neo4j e mais uma cassetada...

Veja em http://nosql-database.org/

 

Alguns bons artigos sobre o assunto:

http://escalabilidade.com/2010/03/08/introducao-ao-nosql-parte-i/

http://escalabilidade.com/2010/04/06/introducao-ao-nosql-parte-ii/

http://escalabilidade.com/2010/05/26/voltdb-escalabilidade-de-nosql-em-sql/

http://imasters.com.br/artigo/13805/bancodedados/o_mysql_e_o_nosql/

http://imasters.com.br/artigo/17043/bancodedados/nosql_voce_realmente_sabe_do_que_estamos_falando/

http://www.linhadecodigo.com.br/artigo/2840/Apache-Cassandra-NoSQL-uma-tecnologia-emergente.aspx

[Suissa 1]

Opa fui eu que escrevi este artigo ae no imasters, então vamos as minhas considerações.

 

Não o MongoDb não usporta ACID, existem alguns nosqls que suportam, para isto leiam sobre o CAP Theorem e o BASE para entender como os NOSQLs podem trabalhar.

 

Sobre utilizar arquivos no banco o Google é o melhor case possível pois ele armazena tudo no BigTable e por isso nós podemos acessar os arquivos onde estivermos mesmo vários servidores podendo estar OFF, para isso ele foi produzido para que você replique e particione os arquivos facilmente, independendo do seu SO.

 

Algumas fontes:

http://www.thoughtworks.com/articles/nosql-comparison

http://codahale.com/you-cant-sacrifice-partition-tolerance/

http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

 

Bom então você não está muito a par do que acontece no mundo NOSQL, pois o mongo tem cases muito interessantes. No próprio site dele você pode ver alguns sites que os utilizam

 

Agora aconteceu um problema com o 4square que teve problema em um shard onde eles só liam direto da RAM e esse shard passou dos 66Gbs disponiveis na máquina e com isso ele começou a ler do HD e ficou muito lento. Mas ae que está a questão tudo depende de como você implementa. Se você implementar erroneamente um oracle mesmo ele sendo o DEUS dos sgbds ele vai dar pau.

 

http://mashable.com/2010/10/07/mongodb-foursquare/

 

Espero que você teste por si só e tire suas conclusões ;D

 

Então pessoal é aquela questão ninguém utilizaria um NOSQL da vida para transações financeiras por exemplo, e como ja haviam dito para mim é interessante utilizar 2 bancos um nosql e um mysql da vida pois no relacional você poderia só escrever e te-lo como um backup para ter mais segurança enquanto o nosql te da maior velocidade nas consultas e escritas.