Como Surgiu o MongoDB

Onde trabalho participo de um grande projeto do site www.carclick.com.br .

Como estudo Oracle fiquei muito curioso sobre o MongoDB.

O MongoDB é um banco de dados NÃO Relacional, ou seja, além de trabalhar com sistema relacional ele também trabalha sem relacionamento de índices e tabelas.

Abaixo uma fonte muito boa que explica bem detalhadamente como funciona:

Abaixo também um PODCAST muito legal que fala sobre.

http://imasters.com.br/banco-de-dados/mongodb/databasecast-historia-do-mongodb/

Case no Brasil de sucesso o Cartola FC da Globo Esporte

https://www.youtube.com/watch?v=ZytjlpGk0tw

INTRODUÇÃO

É fato de que a maior parte dos bancos de dados existentes no mercado hoje são do tipo modelo relacional. Mas fatores novos estão mudando essa história, pelo menos no que se refere ao crescimento intenso da quantidade de dados de certas organizações, e algumas limitações do modelo relacional têm ajudado para alternativas de banco de dados apareçam buscando sanar essas limitações. A alternativa que tem ganhado bastante espaço nas organizações são os banco de dados chamados de NoSQL. Neste artigo, são apresentadas as principais características desses bancos de dados e, em especial, veremos as características do Banco de Dados Orientado a Documento  MongoDB.

SGBDS RELACIONAIS

Surgido nos anos 70, os SGBDs (Sistemas Gerenciadores de Banco  de Dados) relacionais tem recursos que são importantes para facilitar o processo de criação e manutenção de sistemas, alguns deles são:  a verificação e garantias de integridade dos dados, o gerenciamento de concorrência, recuperação de falhas, processos de uso de validação, a segurança, a otimização de consultas, etc..

Os Sistemas Gerenciadores de Banco  de Dados relacionais mais conhecidos são: SQL Server, Oracle, PostgreSQL, MySQL, etc. Usam uma linguagem de manipulação, consulta e definição chamada SQL (Structured Query Language), que foi criada são as relações  (ou tabelas), as quais são compostas de linhas (ou tuplas) e colunas (ou atributos).

Graças ao intenso crescimento do número de aplicações, soluções, recursos e tudo o que se refere a sistemas computacionais nas últimas décadas, o volume de dados associados a tais tipos de sistemas também teve um ritmo de crescimento acelerado. É justamente aí, nesses lugares nos quais o grande volume de dados é o problema, esses bancos baseados no Modelo Relacional, não tem sido eficientes o bastante. E essa é a dificuldade real do uso do Modelo Relacional: a difícil tarefa de conciliar a demanda por escalabilidade cada vez mais intensa.

BANCOS DE DADOS NOSQL

É na Web que encontramos a maior inspiração para o desenvolvimento de novas tecnologias de Banco de Dados. Tudo por causa da necessidade que surge para suprir as aplicações web que cada vez mais tem um grande volume de dados e requisitos diferenciados, como o elevado grau de disponibilidade a escalabilidade sob demanda, surge então uma nova categoria de SGBDs, conhecida como NoSQL, abreviação de Not Only SQL (não apenas SQL),  criada inicialmente para foi proposta com o objetivo de atender aos requisitos de gerenciamento de grandes volumes de dados, semi-estruturados ou não estruturados. Ou seja, sendo utilizado principalmente em casos em que o Modelo Relacional não apresentava performance adequada.

É importante deixar claro que o NoSQL não veio para substituir os bancos de dados relacionais. Os bancos de dados NoSQL servem para uma gama de problemas que nem sempre são os mesmos dos bancos de dados relacionais. E quando se fala em NoSQL sempre se fala das grandes vantagens em termos de escala em comparação aos SGBDs relacionais. Não é verdade que os bancos de dados relacionais não escalam. A verdade é que eles não escalam com facilidade. Abaixo um esquema básico de aplicação web:


Se o sistema acima passar a demanda de usuários aumentarem muito surgem na nossa aplicação problemas com a escalabilidade.  O que se pode fazer é aumentar a capacidade do  servidor, dando-lhe um upgrade no seu processador, no armazenamento e em sua memória.. Ou então, fazer crescer a quantidade das máquinas de servidores web:


E se a aplicação web continuar a crescer? Certamente o banco de dados não iria suportar atender a todas as requisições em um tempo hábil. E se colocássemos mais máquinas rodando o nosso banco de dados?


Com isso, agora devemos escalar nosso banco de dados através de múltiplas máquinas, o que é mais complicado do que com os nossos servidores web.  Na maioria dos casos não podemos simplesmente ligar mais uma máquina rodando o banco e esperar que tudo funcione. Vamos precisar de uma série de configurações e alterações nas nossas aplicações para fazer tudo funcionar na nova arquitetura distribuída.

Os bancos de dados NoSQL vem para tornar este processo que muitas vezes é trabalhoso e complicado em um processo mais simples e robusto.

Como exemplo de aplicações que necessitam de um gerenciamento eficaz de grandes quantidades de dados não estruturados estão às redes sociais, exemplos clássicos nós temos o Twitter, Facebook e outras redes, onde a quantidade de informação gerada pelos usuários possui um crescimento que as bases de dados relacionais não conseguem comportar. Tudo isso se deve o fato dos bancos de dados relacionais não serem eficazes nesse requisito.

Esses bancos de dados NoSQL são  amplamente adotados em empresas como Facebook, Amazon e Google com o intuito de atender às suas  demandas de escalabilidade, alta disponibilidade e dados não estruturados. E vale ressaltar que, atualmente,   diversos bancos de dados NoSQL de código livre estão disponíveis, exemplos disso são o Cassandra, Hypertable, MongoDB, Redis, CouchDB e Dynamo.


As primeiras e mais importantes implementações de um sistema realmente não-relacional são:

BigTable – do Google. Surgiu em 2004 como um banco de dados proprietário de alta performance que tinha como objetivo promover maior escalabilidade e disponibilidade.

Dynamo  – da Amazon. Surgiu em 2007, o sistema que tinha como característica básica ser um banco de dados não-relacional, de alta disponibilidade, utilizado pelos web services da Amazon.

O Cassandra, de 2008, projetado para ser um sistema de banco de dados distribuído e de alta disponibilidade, desenvolvido pelo site Facebook para lidar com grandes volumes de dados. No início de 2010, o Cassandra desbancou o MySQL como banco de dados do Twitter, demonstrando sua importância cada vez mais crescente.

MongoDB, lançada em 2009, um banco de dados orientado a documentos, escalável, de alta performance e livre de esquemas. E é o grande foco do nosso estudo.

 Antes de falarmos mais sobre as soluções NoSQL, mais precisamente do MongoDB, é importante lembrar que o propósito, portanto, não é substituir o Modelo Relacional como um todo, mas apenas em casos nos quais seja necessária uma maior flexibilidade da estruturação do banco.

MONGO GB

Criado pelo ex-Fundador  do DoubleClick e CTO Dwight Merriman e DoubleClick ex-engenheiro e fundador ShopWiki e Eliot CTO Horowitz. Eles se basearam as suas experiências em construção de grande escala, alta disponibilidade, sistemas robustos para criar um novo tipo de banco de dados. O próprio Eliot dá a definição:

O MongoDB não foi concebido em um laboratório. Nós construímos o MongoDB com base em nossas experiências na construção de sistemas robustos de grande escala e alta disponibilidade. Não começamos do zero, realmente tentamos descobrir o que estava quebrado, e combater isso. Assim, a maneira que eu penso sobre MongoDB é que se você pegar o MySql, e alterar o modelo de dados do relacional para orientado a documento, você ganha uma grande quantidade de recursos: documentos embarcados para velocidade, facilidade de gerenciamento, desenvolvimento ágil com bancos de dados sem “schema”, escalabilidade horizontal mais fácil, pois “joins” não são tão importantes. Há muitas coisas que funcionam muito bem nas bases de dados relacionais: índices, consultas dinâmicas e atualizações para citar alguns, e nós não mudamos muito neste ponto. Por exemplo, a maneira de projetar seus índices no MongoDB deve ser exatamente do jeito que você faz isso no MySQL ou Oracle, você só ganha a opção de indexar um campo embarcado.

– Eliot Horowitz, CTO 10gen e Co-fundador

Fazendo uma busca em literatura disponível, podemos resumir MongoDB nas características abaixo:

Open Source;

Alta Performance;

Schema (Esquema) Aberto – para fácil evolução do esquema;

Banco de Dados Orientado a Documento;

Preparador para trabalhar na nuvem;

Atualmente na versão 2.2.

MongoGB é um banco de dados de documento, e isto quer dizer que podemos armazenar dados como documentos.

E o que são documentos? São as unidades básicas de armazenamento e estes não utilizam necessariamente qualquer tipo de estruturação pré-definida, como é o caso das tabelas do Modelo Relacional. Ou seja, o MongoDB  armazena coleções de documentos. Um documento, em geral, é um objeto com um identificador único acrescido de um conjunto de campos, que podem ser strings, listas ou documentos aninhados. Neste modelo temos um conjunto de documentos e em cada documento temos um conjunto de campos (chaves) e o valor deste campo. Outra característica importante é que este modelo não depende de um esquema rígido, ou seja, não exige uma estrutura fixa como ocorre nos bancos tradicionais, os relacionais. Assim, é possível que ocorra uma atualização na estrutura do documento, com a adição de novos campos, por exemplo, sem causar problemas na estrutura do banco de dados. Esta flexibilidade é uma das grandes vantagens deste modelo.

O MongoDB é um destes bancos que utiliza o modelo de armazenamento orientado a documento  que armazena documentos no estilo parecido JSON chamado BSON, como documentos com esquemas dinâmicos, quer dizer que eu não preciso ter a mesma estrutura em casa registro. O objetivo do MongoDB é preencher a lacuna entre valores/chave lojas (que são rápidos e escalonáveis) e bancos de dados relacionais (que têm a funcionalidade rica).  Atualizações in-place rápidas, ou seja, uma transação atômica.

Quem trabalha muito com Banco de Dados Relacionais o MongoDB é uma boa quebra de paradigma já que ele não possui schema – o que quer dizer que  não é necessário estipular a estrutura dos dados ao criar o banco, basta adicionar o documento(JSON) contendo os campos desejados, inclusive um documento pode conter outros documentos.

Um exemplo de objeto armazenado no MongoDB é apresentado a seguir:

aluno = {“nome”:”Neymar Junior”,”período”:5,”nascimento”:”1991-15-09″}

Como o formato BSON pode ser estendido, é possível acrescentar outras informações ao objeto aluno, de maneira que ele incorpore mais informações n o objeto criado, como um array de dados por exemplo.

Exemplo de como salvar um documento no MongoDB:

Db.users.save({a:99})

Em outras palavras, como o comando acima, estamos dizendo para salvar o documento “a:99” na coleção de “scores”. E para buscar todos  documentos salvos, usaríamos:

Db.users.find();

E para apagar tudo que existe na coleção:

Db.users.remove();

Esses documentos do banco de dados MongoDB tem a sua estrutura feita em coleções (collections), uma coleção não requer que documento armazenados nela tenham todos os mesmos campos. Por exemplo, pode ser armazenado um documento de cliente e de um carro em uma mesma coleção mesmo que não faça sentido nenhum fazer isso. Abaixo um exemplo de como podemos criar uma:

db.createCollection( “nome_da_collection” )

 E para visualizarmos todas as coleções de um banco de dados MongoDB utilizamos o seguinte comando:

db.getCollectionNames()

Para um maior entendimento dessas características do  MongoDB, que são expressadas como objetos JSON.  O quadro seguinte mostra exemplos da sintaxe SQL e da sintaxe da Linguagem de Consulta do Mongo.


Exemplos em Javascript e podem ser executado através do Mongo Shell.


Os bancos de dados NoSQL foram especialmente projetados para atender as características de: maior disponibilidade, menor tempo de resposta para consultas, paralelismo de atualização de dados e maior grau de concorrência. O MongoDB inclui um módulo de  sharding automático que permite a construção de um cluster de banco de dados escalável horizontalmente projetado para incorporar novas máquinas de forma dinâmica .

SHARDING

É uma forma de dividir carga no banco que você pode fazer de forma particionada.

Na Figura 1, vemos um cluster consiste de dois ou mais blocos de servidores chamados de shards, um ou mais servidores de configuração e qualquer número de processos roteadores chamados de mongos através dos quais os servidores da aplicação se conectam. 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.


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

O gerenciamento de falhas se dá através da substituição automática do servidor falho por um novo servidor.  Assim, cada shard sempre estará on-line.

GRIDFS

Com GridFS, você armazena arquivos no banco de dados. MongoDB foi construído para fazer isso. Quando você guarda os arquivos no MongoDB, recebe toda a capacidade de replicação e sharding gratuitamente. Essa propriedade é indicada pra se trabalhar com um grande volume de arquivos e muitos acessos simultâneos. Ela também é ideal para trabalhar com arquivos maiores que 4 MB como imagens, vídeo e áudio.

Isso não quer dizer que ela não seja indicada para arquivos menores, muito pelo contrário. A diferença é que, em arquivos maiores que 4MB o GridFS automaticamente divide o arquivo em partes praticamente e gera metadados de também de forma automática.

CONCLUSÕES

Antes de optar por o MongoGB ou um SGSBD tradicional, deve-se levar em consideração as necessidades do problema. Os fatores que devem ser utilizados como critérios de comparação são de tipos diversos, indo desde a escalabilidade do sistema, passando por questões de consistência de dados, até problemas de facilidade de uso ou existência ou não de linguagens de consulta.

Apesar do fato dos bancos NoSQL, e mais especificamente o MongoGB,  serem projetados para não precisar ficar usando junções, ainda podem ocorrer consultas que precisam dessas operações, mesmo que não seja do mesmo nível que faz-se necessário em sistemas relacionais comuns.

E tanto os bancos de dados relacionais quanto os não relacionais podem coexistir. Eles atendem em sua maioria a casos de usos diferentes como ilustrado na figura abaixo:


Podemos então concluir que a principal vantagem do MongoDB é a alta performance, uma única consulta já te retorna tudo o que você precisa saber a respeito do documento (esta é uma das razões pelas quais vêm sendo adotado em projetos que exigem alta performance).  Mas existem outras vantagens, como o Schema Aberto (tipagem dinamica, migrações, flexibilidade, cache), GeoLocalização Nativa e ser Open Source (Diminui seus custos no projeto).

A desvantagem principal é o fato de que se você quiser alterar todos os registros relacionados a uma unidade semântica, precisa tratá-los um a um.

REFERÊNCIAS

“Bancos de Dados NoSQL x SGBDs – Relacionais: Análise Comparativa”. Ricardo W. Brito, Faculdade Farias Brito e Universidade de Fortaleza.

Escalabilidade: http://escalabilidade.com/2010/03/08/introducao-ao-nosql-parte-i  Acessado em 30/11/2013.

 C. Chandler, “CouchDB in Action”, 1ª edição, Manning Publications,  2009.

 A. Lakshman, P. Malik, “Cassandra – A Decentralized Structured StorageSystem”, LADIS 2009

 N. Leavitt, “Will NoSQL Databases Live Up to Their Promise?,” Computer, vol. 43, no. 2, pp. 12-14, Feb. 2010.

 “MongoDB: Sharding Introduction”.http://api.mongodb.org/wiki/current/Sharding Introduction.html.  Acessado em 20/11/2013.

 “NoSQL Relational Database Management System: Home Page”.  Strozzi.it. http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home Page.Acessado em 20/11/2013.

 “Official MongoDB Project Website”.  http://www.mongodb.org/display/DOCS/Home” . Acessado em 20/11/2013.

 “MongoDB”.http://pt.wiki.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart. Acessado em 20/11/2013.

  GridFS no MongoDB – http://www.nosqlbr.com.br/gridfs-no-mongodb.html – Acessado em 25/11/2013.

Dezembro 03, 2013

Text

 

Guia de instalação do MongoDB


Instalar o  MongoDB é uma das tarefas mais simples que você poderá encontrar.  No site oficial do MongoDB, encontra-se todas as distribuições para Windows, Mac OS X, Linux e Solaris. Para outros sistemas, existem uma gama de gerenciadores de pacotes facilitando assim a instalação e configuração em outros sistemas.

Abaixo mostraremos como realizar a instalação no Windows.]]

Instalando no Windows

 Primeiramente, fazer o download da versão mais recente para Windows.

 http://www.mongodb.org/downloads

 

1) Feito o download. Extraia o arquivo baixado (zip), preferencialmente na unidade de disco C:,

Ele irá gerar o diretório mongodb-win32-i386-1.6.4 (o nome vai variar dependendo se sua versão é 32 ou 64 bits).

Crie também uma nova pasta, ainda na unidade C:, e dê-lhe o nome de data. Dentro desta, crie outra com o nome de db.

2) Vá até a pasta C:\mongo\bin e abra o arquivo mongod.exe.


Irá abrir uma janela de prompt de comando que inicia o servidor do MongoDB, encerre a janela para fazê-lo parar, é mais fácil configurar o servidor do MongoDB como um serviço que o Windows controle.

3) No Windows, abra um prompt de comando (Iniciar – > Pesquisar ->digite CMD e pressione enter) e digite os comandos abaixo:

> cd \mongo\bin
> mongod --install --logpath c:\mongo\logs --logappend 
--bind_ip 127.0.0.1 --directoryperdb

Em seguida é mostrado a seguinte mensagem que confirma que o serviço foi criado:

all output going to c:\mongo\logs
Creating service MongoDB.
Service creation successful.
Service can be started from the command line via 'net start "MongoDB"'.

4) Após o MongoDB estar devidamente instalado como serviço, para rodá-lo só precisa digitar:

net start MongoDB

5) Agora já pode executar o cliente de shell. No prompt de comando e estando no diretório c:\mongo\bin digite:

Mongo

Lembrando que o caminho do diretório pode ser encontrado pelo Windows Explorer. O resultado será:

MongoDB shell version: 1.8.1
connecting to: test

Para mais detalhes sobre a instalação e posterior configuração, acesse o tutorial em http://docs.mongodb.org/manual/tutorial/install-mongodb-on-windows/

Dezembro 03, 2013

Video

https://www.youtube.com/watch?v=CvIr-2lMLsk

Vídeo oficial de divulgação do MongoDB (em inglês)

Dezembro 03, 2013

Video

https://www.youtube.com/watch?v=ZytjlpGk0tw

Estudo de Caso com o MongoDB – CartolaFC – com Franklin Amorim (especialista de banco de dados da Globo.com)

Neste vídeo, Franklin comenta os desafios encontrados no processo, as tecnologias utilizadas, os resultados do projeto e as lições aprendidas pela equipe de desenvolvimento.

Dezembro 03, 2013

About


Tumblr criado por 

FABIO BATISTA
Analista de Sistemas, graduado em Análise de Sistemas e trabalha com desenvolvimento Web.

© MongoDB. Todos os direitos reservados – 2013.

Powered by Tumblr (a melhor plataforma). Lightweight Theme by Artur Kim modified by Fabio Machi

Anúncios

Sobre Fabio Silva

MVP Microsoft Azure - Entusiasta Office 365 Profissional apaixonado por tecnologia. Perfil generalista mas com profundo conhecimento em varias tecnologias. Mais de 10 anos de skill em ambientes Linux Analista Senior realizando trabalhos: Comunicação unificada Lync 2013, Sharepoint 2013, Exchange 2013, Vmware e Windows 2012 preparado para nuvem, hibrida e on-premisses. Comunicação unificada Lync 2013, Sharepoint 2013, Exchange 2013, Vmware e Windows 2012 preparado para nuvem, hibrida e on-premisses. Implantação de comunicação unificada e mensageria Lync 2013 e Exchange 2013 na empresa Penso Tecnologia. Itcore Consultor Senior em todas soluções Microsoft e Virtualização. Consultor Microsoft e Linux Senior De Julho de 2012 a Março de 2013 Consultor Microsoft e Linux Senior De Maio de 2012 a Setembro de 2012 Tecban (Técnologia Bancaria) Auditor de Sistemas Pleno Março de 2012 a Maio de 2012 Analista de TI Senior Março de 2011 a Março de 2012 Analista de infra-estrutura de redes e desenvolvimento Maio 2007 a Março de 2011 Analista de Redes Março de 2005 a Maio de 2007 Integradora THS Área de Suporte CPD Janeiro de 2004 a Janeiro de 2005 Especializações: Certificado Microsoft Windows 2003, Certificado Zimbra Network Edition, Certificado Sonicwall. Especialização em Messageria Exchange 2007 e 2010. Especialização em Linux

Publicado em agosto 7, 2014, em Banco de Dados e marcado como . Adicione o link aos favoritos. Deixe um comentário.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: