MongoDB

Gustavo Dettenborn Departamento de Informtica - Universidade Catlica do Tocantins Palmas TO Brasil

gustavodettenborn@gmail.com

Abstract. This article visualize the presentation and testing of the database MongoDB. With the increasing demand in handling information effectively, rapidly and realiably the class of database NoSQL present themselves as capable of providing technology solutions focusing availability, high performance, replication and horizontal scaling. Resumo. Neste artigo vizualiza-se a apresentao e realizao de testes do banco de dados MongoDB. Com a crescente demanda pela monipulao das informaes de forma eficaz, rpida e confivel os banco de dados NoSQL apresentam-se como tecnologia capaz de prover solues relacionadas a disponibilidade, alta performance, replicao e escalabilidade horizontal.

1. Introduo
Todas informaes produzidas em qualquer parte do mundo podem estar disponveis em tempo real para qualquer computador, celular ou dispositivo com acesso a internet. Estas vrias formas de acesso possibilitam que muitas interaes (leitura/escrita) sejam realizadas a cada milsimo de segundo. Todo este trfego, cada vez maior, apresenta grandes desafios aos bancos de dados na manipulao/disponibilidade de dados. Contudo, existem alguns problemas que os banco de dados tradicionais (relacionais) apresentam: alta disponibilidade, alta performance, agilidade e escalabilidade horizontal. Com a finalidade de ajudar a prover soluo para estes problemas este trabalho apresenta o MongoDB e realiza testes com a finalidade de mostrar suas qualidades.

2. MongoDB
Dentre as principais caractersticas destacam-se a orientao a documento, modelos livres de modelos, auto particionamento, replicao e escalabilidade. O MongoDB um banco de dados orientado a documento, open source e nativamente escalvel.

Ele classificado como banco de dados NoSQL, ou seja, banco de dados no relacional. NoSQL um termo utilizado para englobar todos bancos de dados que no seguem os conceitos e principios dos bancos de dados relacionais e so relacionados ao acesso e manipulao de grande quantidade de dados [Seguin 2011]. Estes bancos de dados tambm no apresentam transaes. Para entender seu funcionamento necessrio conhecer alguns fundamentos em que se baseia. 2.1 Modelo de Dados Como MongoDB orientado a documento, sua estrutura de modelagem de dados organizada de maneira simples. Onde: banco de dados um conjunto de colees; coleo um conjunto de documentos; documento um conjunto de campos; campo um par chave-valor; chave o nome do campo e valor pode ser string, interger, float, timestamp, binary, documento ou um array de valores [Plugge, Membrey, and Hawkins 2010]. Estas definies esto ilustradas atravs da Figura 1.

Figura 1. Estrutura organizacional de dados do MongoDB [Plugge, Membrey, and Hawkins (2010)]. Pode ser feita uma analogia de coleo com uma caixa e documento com uma sacola. A coleo/caixa pode conter vrios tipos de documentos/sacolas e estas sacolas podem ser diferentes entre si. Assim os bancos de dados orientados por documentos, possuem flexibilidade no momento de definir novos valores para um determinado documento sem a necessidade de modificar qualquer estrutura do banco. 2.2 BSON Este banco orientado a documento pois as informaes so

armazenadas em documentos/arquivos de formato pr-definido. Onde as informaes enviadas devem ser especificadas no formato JSON. Por exemplo: { campo1 : valor1, campo2: valor2}. Porm MongoDB utiliza um tipo de JSON serializado em bytes, o JSON Binrio denominado BSON. Este formato suporta varios tipos de dados, como string, int, arrays e outros documentos [Plugge, Membrey, and Hawkins (2010)]. A velocidade e flexibilidade apresentam-se pelo fato de se utilizar este formato de arquivos para escrita e leitura. 2.3 Auto-Sharding MongoDB apresenta uma arquitetura que permite o particionamento automtico das informaes, denominado auto-sharding.

Figura 2. Configurao de um shard simples [Plugge, Membrey, and Hawkins (2010)] Para realizar esta funo ele utiliza o mongos, que o servidor de particionamento(ilustrado atravs da Figura 2). O mongos possui a relao de servidores que fazem parte do cluster e dos bancos de dados que devem ser particionados. Esta definio pode ser a nvel de banco ou coleo. O mongos desempenha uma outra importante funo no balanceamento de carga dos servidores de particionamento. ele quem avalia qual n deve responder cada solicitao.

Este particionamento apresentado de forma transparente ao cliente, tanto que nas consultas ele no precisa informar de qual parte/n a informao deve vir. O cluster formado pode crescer facilmente adicionando-se novos ns e atender de acordo com a demanda. Desta forma o MongoDB nativamente escalvel horizontalmente. A figura 3 abaixo, extrada do manual do MongoDB, ilustra este particionamento. Onde shard so as partes.

Figura 3. Ilustrao de ambiente particionado e replicado [10gen (2012)]. 2.4 Replicao A replicao tratada de maneira parte do particionamento. Ela uma forma de garantir que as informaes, presentes no banco de dados original, estejam presentes em outro local de maneira fiel ao local de origem. A implementao de replicao feita por failover ou redundncia [10gen (2012)]. Este mecanismo permite que apenas um n esteja apto a receber solicitaes para escrita. Isto uma forma de garantir e reforar que as operaes atmicas sobre os arquivos sejam consistentes. 2.5 Atominicidade Quando fala-se em banco de dados relacionais, o conceito de transao aparece como importante propriedade. Porm MongoDB no implementa transaes. Mas apresenta

tcnicas para realizar atomicidade sobre sobre arquivos. Uma das tcnicas aplicadas atualize se o valor for o atual [10gen (2012)], que envia um pedido de alterao caso o valor atual ainda seja o antigo. Um dos motivos para no implementar transaes que, em um ambiente particionado e distribudo seria muito lento, custoso e complexo realizar este tipo de operao. O que foge aos seus ideais de simplicidade, agilidade e rapidez. 2.6 Processos e Apicativos O processo principal do Mongo DB que cria uma instncia do banco de dados o mongod. Ele constituido de aplicativos que do suporte a outras atividades importantes. Neste trabalho foram utilizados os seguintes processos: *mongod - processo principal que inicia o banco de dados; *mongo - linha de comando para configurao e manipulao de informaes. um shell em JavaScript; *mongos - servidor de particionamento. 2.7 Funcionamento e Comandos Nesta parte sero apresentados alguns comandos bsicos utilizados para manipular o banco de dados atravs do shell do MongoDB, que iniciado atravs do comando mongo. 1. > use teste 2. switched to db teste 3. > pessoa = {"nome": "fulano", "sobrenome": "de tal"} 4. { "nome" : "fulano", "sobrenome" : "de tal" } 5. > db.pessoas.insert(pessoa) 6. > db.pessoas.find() 7. { "_id" : ObjectId("4ee567444f94bbf6332be2e2"), "nome" : "fulano", "sobrenome" : "de tal" } 8. > pessoa = {"nome": "fulano", "sobrenome": "de tal", "data_nascimento": "11/12/2011"} 9. { "nome" : "fulano", "sobrenome" : "de tal", "data_nascimento" : "11/12/2011" } 10.> db.pessoas.insert(pessoa) 11.> db.pessoas.find() 12.{ "_id" : ObjectId("4ee567444f94bbf6332be2e2"), "nome" : "fulano", "sobrenome" : "de tal" } 13.{ "_id" : ObjectId("4ee567a34f94bbf6332be2e3"), "nome" : "fulano", "sobrenome" : "de tal", "data_nascimento" : "11/12/2011" } Na linha 1 foi definido o banco a ser utilizado, se no existisse seria criado quando houvesse a primeira insero. Na linha 3 foi definido um documento no formato JSON denominado pessoa com

suas informaes. Na linha 5 ocorreu a definio da coleo pessoas e ao mesmo tempo ela recebeu o documento pessoa. Na linha 7 foram listadas as informaes solicitadas atravs do comando find. Observou-se que o MongoDB define um identificador padro para todos documentos inseridos e que este valor pode ser definido pelo usurio. Para exemplificar porque este banco de dados livre de esquema na linha 8 foi definida uma nova pessoa com um novo campo data_nascimento e posteriormente inseriu-se, na linha 10, na coleo pessoas. J nas linhas 12 e 13 verificou-se as duas pessoas com propriedades diferentes e foi exemplificada a caracterstica de ser livre de modelos. Para obter a lista completa dos comandos e realizar outras operaoes sobre os dados basta digitar db.help() na linha de comando.

3. Testes
Com a finalidade de testar a performance, o particionamento e a replicao do MongoDB dividiu-se os testes em duas partes. Na primeira parte foi comparada a velocidade para execuo de 4 operaes bsicas: escrever; ler; atualizar; remover. Neste teste comparou-se a velocidade entre MongoDB e o banco de dados relacional PostgreSQL. J na segunda parte criou-se um abiente clusterizado para testar a replicao e depois adicionou-se particionamentos para testar o auto-sharding. 3.1 Teste performance MongoDB x PostgreSQL Na primeira etapa de testes comparou-se a rapidez de escrita, leitura, atualizao e remoo entre MongoDB e PostgreSQL. Para realizar os testes criou-se um dicionrio de dados com 100 linhas denominado dicionario.json, onde cada linha possui {palavra: teste, numero: 1}. Cada ao foi executada separada para que o tempo fosse contado. Os grficos abaixo mostram os tempos obtidos em cada tarefa para cada banco de dados com um nmero de linhas especficos.

1.6 1.4
Durao em segundos

1.43 1.32

1.2 1 0.8 0.6 0.4 0.2 0 Escrita Leitura Atualizao Remoo

Operaes

MongoDB PostgreSQL 0.21 0.22 0.23 0.2 0.2 0.24

Figura 4. Operaes para 100 linhas.

12 10
Durao em segundos

11.55

11.39

8 6 4 2 0 Escrita Leitura Atualizao Remoo

Operaes

MongoDB PostgreSQL

0.26

0.22 0.28

0.25

0.19 0.25

Figura 5. Operaes para 1000 linhas.

12 10
Durao em minutos

11.55

8 6 4 2 0.08 0 Escrita Leitura Atualizao Remoo

Operaes

MongoDB PostgreSQL 1.53 0.04 0.04 0.1 0.02 0.03

Figura 6. Operaes para 10000 linhas.

45 40 35
Durao em minutos

40.38 36.14

30 25 20 15 10 5 0 Escrita Leitura Atualizao Remoo

Operaes

18.59

MongoDB PostgreSQL

0.64

0.79 1.17

0.02 0.05

Figura 7. Operaes para 100000 linhas. 3.1.1 Resultado da Escrita Na primeira rodada de teste quando foram utilizadas 100 linhas o MongoDB se mostrou sempre com tempos menores em relao ao PostgreSQL. Mostrando diferena acentuada no momento da escrita, esta diferena a favor do MongoDB aumentava sempre que uma quantidade maior de linhas fosse adicionada. Desta forma, quando

foram inseridas 1000000 de linhas, o MongoDB inseriu em 1 minuto e 6 segundos, j o PostgreSQL realizou a mesma tarefa em 192 minutos e 50 segundos. 3.1.2 Resultado da Leitura No teste de leitura o MongoDB levou vantagem enquanto os testes com 100 e 1000 linhas, pois a partir de 10000 linhas o PostgreSQL realizou a busca com maior velocidade. Desprezando os drivers de conexo, verificou-se que o resgate dos dados foi mais rpido no PostgreSQL. 3.1.3 Resultado da Atualizao Na atualizao verificou-se que MongoDB foi mais rpido mesmo quando a quantidade de dados aumentou. 3.1.3 Resultado da Remoo Para remoo no verificou-se aumento de tempo mesmo quando a quantidade aumentou, tampouco houve relevante diferena de tempo entre MongoDB e PostgreSQL. 3.2 Testes de: Escrita, Leitura, Atualizao e Remoo com Particionamento e Clusterizao Na segunda etapa deste teste foram configurados 3 servidores com instncias de banco de dados replicados entre si. E verificou-se o que ocorreria caso o n principal falhasse. Cada um dos servidores foi configurado da seguinte forma: 1. Servidor1: mongod --shardsvr --dbpath db/ --replSet settrabalho --logpath logmongo/log-shardsvr --fork --port 27020 2. Servidor2: mongod --shardsvr --dbpath db/ --replSet settrabalho --logpath logmongo/log-shardsvr --fork --port 27020 3. Servidor3: mongod --shardsvr --dbpath db/ --replSet settrabalho --logpath logmongo/log-shardsvr --fork --port 27020 Onde o comando mongod define a instncia principal do banco de dados. E as opes definem: --dbpath define o diretrio de localizao do banco; --replSet especifica o nome do ponto de replicao; --logpath define o diretrio de log; e shardsvr d suporte ao particionamento neste banco de dados caso haja interesse. Neste momento, no Servidor1, realiza-se a configurao para que todos os pontos de replicao estejam ligados. Esta informao ser repassada aos demais servidores envolvidos, pelo prprio Servidor1. >mongo localhost:27020/admin >cfg = { _id : "settrabalho", members : [ {_id : 0, host : "Servidor1:27020"}, {_id : 1, host : "servidor2:27020"}, {_id :

2, host : "servidor3:27020"},]} >rs.initiate(cfg) O comando mongo conecta-se diretamente ao banco de dados admin, que o responsvel por aplicar as configuraes da instncia do banco. A varivel cfg foi definida de acordo com o manual de especificaes do MongoDB para criar replicao, onde: o _id deve ser o set ao qual os servidores fazem parte; members um array contendo os servidores de replicao; e rs o comando responsvel por aplicar as configuras de replicao. Quando utiliza-se esta replicao um dos servidores eleito o primrio e os demais secundrios. Caso ocorra a falta do primrio, um dos secundrios ser eleito primrio, seguindo o conceito bsico de replicao. Com os trs servidores replicados pode-se realizar escrita. Ela foi realizada com o script apresentado no teste anterior para verificar se as informaes seriam replicadas. A seguir esto apresentadas imagens de log de cada servidor para ilustrar o que ocorreu nos outros servidores quando o servidor Servidor1 foi desativado. No Servidor1: 1. Mon Dec 12 18:58:41 [conn2] replSet info saving a newer config version to local.system.replset 2. Mon Dec 12 18:58:41 [conn2] replSet replSetInitiate config now saved locally. Should come online in about a minute. 3. Mon Dec 12 18:58:41 [conn2] query admin.$cmd ntoreturn:1 command: { replSetInitiate: { _id: "settrabalho", members: [ { _id: 0.0, host: "servidor1:27020", priority: 1.0 }, { _id: 1.0, host: "servidor2:27020", priority: 1.0 }, { _id: 2.0, host: "servidor3:27020", priority: 1.0 } ] } } reslen:128 313ms 4. Mon Dec 12 18:58:49 [initandlisten] connection accepted from servidor1:34424 #3 5. Mon Dec 12 18:58:49 [startReplSets] replSet STARTUP2 6. Mon Dec 12 18:58:49 [rs Manager] replSet can't see a majority, will not try to elect self 7. Mon Dec 12 18:58:49 [replica set sync] replSet SECONDARY 8. Mon Dec 12 18:58:49 [ReplSetHealthPollTask] replSet info servidor3:27020 is down (or slow to respond): still initializing 9. Mon Dec 12 18:58:49 [ReplSetHealthPollTask] replSet info servidor2:27020 is down (or slow to respond): still initializing 10. Mon Dec 12 18:58:54 [initandlisten] connection

accepted from servidor3:59967 #4 11. Mon Dec 12 18:58:55 [ReplSetHealthPollTask] replSet info servidor3:27020 is up 12. Mon Dec 12 18:58:55 [ReplSetHealthPollTask] replSet member servidor3:27020 STARTUP2 13. Mon Dec 12 18:58:55 [rs Manager] replSet info electSelf 0 14. Mon Dec 12 18:58:55 [rs Manager] replSet PRIMARY Nestas linhas pode ser verificado, atravs do Servidor1, o que ocorre quando a ao rs.initiate(cfg) executada. O servidor cria a configurao de replicao e a repassa aos demais pontos. A partir deste momento os servidores elegem um servidor para ser o primrio, que o responsvel por atender as solicitaes de leitura e escrita. Os outros pontos sero definidos como secundrios e tem o dever de possuir uma cpia fiel ao primrio. O prximo passo ser negar o servio no Servidor1. No Servidor2: 1. Mon Dec 12 19:27:41 [ReplSetHealthPollTask] replSet info servidor1:27020 is down (or slow to respond): DBClientBase::findOne: transport error: servidor1:27020 query: { replSetHeartbeat: "settrabalho", v: 1, pv: 1, checkEmpty: false, from: "servidor2:27020" } 2. Mon Dec 12 19:27:42 [rs Manager] replSet info electSelf 1 3. Mon Dec 12 19:27:42 [rs Manager] replSet PRIMARY 4. Mon Dec 12 19:27:58 [initandlisten] connection accepted from servidor4:53434 #19 5. Mon Dec 12 19:28:56 [conn17] query admin.$cmd ntoreturn:1 command: { writebacklisten: ObjectId('4ee67d9de162a79a2f9668bf') } reslen:60 300000ms O Servidor2 percebe que h uma falha(linha 1) na comunicao com o Servidor1, neste momento ele elege-se(linha 2 e 3) como primrio. Em instantes(linha 4) recebe um pedido de conexo do Servidor4 tornando-se apto a responder(linha 5) a qualquer solicitao. J o Servidor1 volta a se comunicar e assume o papel de secundrio, pois descobre que o Servidor2 agora o primrio. Assim ele realiza uma sincronizao das informaes. Mon Dec 12 19:28:46 [ReplSetHealthPollTask] replSet info servidor2:27020 is up Mon Dec 12 19:28:46 [ReplSetHealthPollTask] replSet member servidor2:27020 PRIMARY Mon Dec 12 19:28:47 [replica set sync] replSet SECONDARY

Verificou-se que o Servidor3 funcionou como secundrio durante todo este processo e realizou a sincronizao das informaes: 1. Mon Dec 12 19:01:59 [ReplSetHealthPollTask] replSet servidor2:27020 RECOVERING 2. Mon Dec 12 19:31:47 [ReplSetHealthPollTask] replSet servidor1:27020 RECOVERING 3. Mon Dec 12 19:34:58 [ReplSetHealthPollTask] replSet servidor2:27020 RECOVERING Analisando-se o log dos servidores envolvidos nesta replicao verificou-se que quando um servidor no envia sinais informando que ainda faz parte da replicao, outro servidor assume o papel de ser o primrio e atender solicitaes de escrita e leitura. Para os testes de insero e leitura em servidores primrios, mesmo que este papel estivesse sendo realizado por outro servidor, a arquitetura atendeu a proposta de realizar a replicao das informaes de maneira rpida e consistente. 3.2.1 Aplicando Particionamento Nesta parte um particionamento adicionado em cada servidor que j possui uma instncia do MongoDB. Observa-se que cada um destes servidores de particionamento poderia estar em outros servidores. Para criar um particionamento necessrio iniciar uma instncia do MongoDB com as seguintes configuraes: Servidor1-particionamento: mongod --configsvr --dbpath config/ --logpath logmongo/log-configsvr --fork --port 27021 Servidor2-particionamento: mongod --configsvr --dbpath config/ --logpath logmongo/log-configsvr --fork --port 27021 Servidor3-particionamento: mongod --configsvr --dbpath config/ --logpath logmongo/log-configsvr --fork --port 27021 Nestes servidores foi utilizada a opo --configsvr que habilita a instncia a receber configuraes de particionamento. Com todos os pontos funcionando. Configura-se o roteador atravs do mongos: Servidor4: mongos --configdb servidor1:27021,servidor2:27021,servidor3:27021 --port 27022 --fork Este comando apresenta a seguinte sada no log: 1. Mon Dec 12 19:18:05 SyncClusterConnection connecting to [servidor1:27021] 2. Mon Dec 12 19:18:05 SyncClusterConnection connecting

3. 4. 5. 6.

to [servidor2:27021] Mon Dec 12 19:18:05 SyncClusterConnection connecting to [servidor3:27021] Mon Dec 12 19:18:05 [Balancer] about to contact config servers and shards Mon Dec 12 19:18:05 [Balancer] config servers and shards contacted successfully Mon Dec 12 19:18:05 [Balancer] balancer id: gustavodettenborn-desktop:27022 started at Dec 12 19:18:05

Onde na linha 1 a 5 verifica-se o roteador conectando aos ns e aplicando as configuraes e iniciando o balancemento. Agora adiciona-se os particionamentos atravs de um console conectado ao mongos. >mongo localhost:27022/admin >db.runCommand( { addshard : "settrabalho/servidor2:27020,servidor1:27020,servidor3:27020 ", name:"shard1" } ); Com os particionamentos criados, pode-se especificar qual banco de dados ser habilitado para tal, com o comando: >db.runCommand( { enablesharding : "benchmark" } ); Tambm configura-se qual coleo poder ser particionada: >db.runCommand( { shardcollection : "benchmark.teste" , key : { numero : 1 } } ); O comando shardcollection informa que a coleo do banco benchmark dever ser dividida entre os ns de particionamento. Aps habilitar o particionamento de um banco de dados garante-se que a informao estar distribuda e poder ser acessada de acordo com o local que ela esteja. Quando trabalha-se com o roteador mongos o acesso a estas informaes torna-se transparente ao cliente. Para realizar os testes de manipulao de dados, utilizou-se o script em anexo e conectou-se diretamente ao roteador. O comandos digitados foram: delete, insert e select. No Servidor4, instncia do mongos, a sada de log foi: Tue Dec 13 15:53:25 [mongosMain] connection accepted from Servidor4:43217 Tue Dec 13 15:53:44 [mongosMain] connection accepted from Servidor4:43229 Como o mongos um roteador que realiza aes de configurao e balanceamento, ele envia a ao que deve atender. A seguir, na sada de log do Servidor1, nas linhas 1 e 2 mostrase o Servidor1 recebendo ordem para remover o banco de dados

benchmark e a coleo que possui. Logo aps na linha 3 verifica-se o comando sendo difundido aos demais bancos. Servidor1: Tue Dec 13 15:47:08 [conn35] query admin.$cmd ntoreturn:1 command: { writebacklisten: ObjectId('4ee67d9de162a79a2f9668bf') } reslen:60 300000ms Tue Dec 13 15:50:26 [conn33] CMD: drop benchmark.teste Tue Dec 13 15:50:26 [conn33] wiping data for: benchmark.teste Tue Dec 13 15:50:47 [conn33] building new index on { _id: 1 } for benchmark.teste Tue Dec 13 15:50:47 [conn33] done for 0 records 0secs Tue Dec 13 15:52:08 [conn35] query admin.$cmd ntoreturn:1 command: { writebacklisten: ObjectId('4ee67d9de162a79a2f9668bf') } reslen:60 300000ms Da mesma forma a sada do log do Servidor2 tambm demonstra o comando delete na linha 2 e nas linhas subsquentes comandos de insert e select. Servidor2: 1. Tue Dec 13 15:49:03 [conn26] query admin.$cmd ntoreturn:1 command: { writebacklisten: ObjectId('4ee67d9de162a79a2f9668bf') } reslen:60 300000ms 2. Tue Dec 13 15:52:12 [replica set sync] CMD: drop benchmark.teste 3. Tue Dec 13 15:52:34 [replica set sync] building new index on { _id: 1 } for benchmark.teste 4. Tue Dec 13 15:52:34 [replica set sync] done for 0 records 0.001secs 5. Tue Dec 13 15:54:03 [conn26] query admin.$cmd ntoreturn:1 command: { writebacklisten: ObjectId('4ee67d9de162a79a2f9668bf') } reslen:60 300000ms 6. Tue Dec 13 15:59:03 [conn26] query admin.$cmd ntoreturn:1 command: { writebacklisten: ObjectId('4ee67d9de162a79a2f9668bf') } reslen:60 300000ms 7. Tue Dec 13 16:04:03 [conn26] query admin.$cmd ntoreturn:1 command: { writebacklisten: ObjectId('4ee67d9de162a79a2f9668bf') } reslen:60 300000ms 8. Tue Dec 13 16:09:03 [conn26] query admin.$cmd ntoreturn:1 command: { writebacklisten:

ObjectId('4ee67d9de162a79a2f9668bf') 300000ms

reslen:60

Observa-se que apenas acompanhando as sadas de log distinguisse qual o servidor que atende as requisies. Pois utilizando-se os camandos enablesharding e shardcollection apenas o MongoDB saber encontrar as informaes.

4. Concluso
MongoDB apresenta uma arquitetura que foca na simplicidade, agilidade e rapidez. Isto ficou evidente atravs dos testes realizados, onde foi verificado que este banco possui rapidez e boa performance tanto na leitura quando escrita de informaes. Destacou-se que as propostas de atingir alta disponibilidade e escalabilidade horizontal podem ser alcanadas atravs do particionamento e replicao. Tambm verifica-se MongoDB no foi feito para concorrer com os banco de dados relacionais. Ele apresenta-se para manipular dados com foco em simplicidade de utilizao, flexibilidade, velocidade. Por isso foca em confiabilidade na execuo de suas tarefas atravs de recursos nativos como replicao e auto-sharding.

Referncias
Seguin, K. (2011) The Little MongoDB Book Plugge, E., Membrey, P. and Hawkins, T. (2010) The Definitive Guide to MongoDB - The NoSQL Database for Cloud and Desktop Computing 10gen (2012) http://www.mongodb.org/display/DOCS/Home Banker, K. (2011) MongoDB in Action Tiwari, T. (2011) Professional NoSQL