Arquivos do Blog

Azure Database for PostgreSQL (PaaS)

Olá pessoal

Recentemente a Microsoft anunciou que Mysql e PostgreSQL estão agora no Canadá e BRASIL.

O RDS da AWS terá uma concorrência maior com está oferta que é muito bem vinda.

Melhor ainda do ponto de vista de performance, latência e qualidade de entrega de serviços web.

Veja na integra o anuncio em http://bit.ly/2yOzxPL

Com isto abaixo tem um passo a passo para provisionar o PostgreSQL no Brasil.

Acesse o portal do Azure escolha na busca ou no menu “Databases” e escolha Banco de dados PostgreSQL.

Veja também aqui o passo a passo do Mysql como PaaS em http://bit.ly/2ztXngR

O Segundo passo é bem simples para o provisionamento, Escolher Usuário, senha, localização BRAZIL como anunciado, versão do banco de dados e tamanho da unidade computacional. Clique em criar e de sequência no provisionamento.

Aguarde o provisionamento.

O primeiro passo para acessar o banco de dados é acessar no menu a parte de segurança. Veja que o banco já acesso seguro via SSL e é preciso liberar uma regra de firewall para acessar colocando IP.

Para acessar o ambiente o Azure já fornece a string de acesso ao banco de dados.

Se você tem alguma aplicação padrão de mercado já tem os parâmetros e exemplos bem definidos para realizar a conexão sem crise. Isso facilita a vida do DEVOPS e do DEV.

Importante é que estamos em um ambiente que oferece PaaS (plataforma como serviço) e abstrai configuração de sistema operacional, isto garante muito uma vantagem. A Microsoft garante a gestão do poder computacional que você escolheu. Importante neste menu acima acertar parâmetros do banco de dados, repetindo abstraindo sistema operacional.

Legal, provisionamos e criamos, agora vamos conectar.

Utilizaremos o PostgreSQL Administrator.

https://www.postgresql.org/ftp/pgadmin/pgadmin4/v2.0/windows/

Acesse e baixe no site do desenvolvedor.

A instalação é bem simples também.

Aceite as condições da licença que está sob GNU Opensource.

Escolha o diretório.

Instale o programa conforme a imagem acima.

Aguarde o fim da instalação.

Pronto, app instalado vamos adicionar a URL que o Azure disponibilizou para que possamos acessar a administração do banco de dados.

Acesse a configuração ADD NEW Server.

Configure os parâmetros para acessar o banco de dados. Siga as instruções que o próprio Azure ofereceu. Principalmente ativação do SSL na figura 3.

Acesse o banco e coloque a senha.

Outra forma de testar é via Cloudshell

O banco de dados Postgre utiliza a porta padrão 5432.

Bom pessoal

Espero que tenha ajudado.

Anúncios

Amazon RDS com banco de dados Mysql

Olá pessoal

 

Hoje irei mostrar um passo a passo para Amazon RDS com banco de dados Mysql.

Na busca no console do AWS faça a busca do RDS

Clique em Get Started Now

No console temos PaaS de serviços 5 banco de dados, escolheremos o MySQL.

Na primeira parte da configuração temos o tipo de engine escolhida, depois a versão do MySQL, em questão de laboratório a versão não contempla o MultiAZ como alta disponibilidade do AWS, o tipo de disco que podemos escolher o Magnetico e disco de alta performance SSD, neste caso escolhi o Magnetico. Aloquei só 5GB como laboratório.

A segunda parte é escolher o nome da instancia, usuário e senha do banco de dados.

A terceira parte é escolher a rede onde vai ficar o banco, No AWS você pode manter na sua VPC (REDE) ou se for para um ambiente WEB você pode criar uma VPC isolada.

Esta parte escolhemos o nome do banco de dados, o parâmetro da versão do banco o grupo do parâmetro da versão.
O Backup mantive o padrão de 7 dias.

Vamos apertar o botão launch DB instance para criação.

A criação é bem rápida, Clique em VIEW YOUR DB INSTANCES para acompanharmos a criação.

Após o clique podemos acompanhar vários itens do banco de dados onde ele mostra a maquina que estará por traz como plataforma. Esta maquina é gerenciada pela AWS. Durante a criação automaticamente no Endpoint é criadoo acesso externo através de liberação de porta para string de acesso ao banco de dados.

Veja a string de acesso ao banco de dados.

Através do MYSQL WORKBENCK (antigo mysql administrator) iremos acessar a string e ver se está apto a manipular os dados do MYSQL.

Coloque a string que foi liberada e faça o teste de conexão.

Pronto você está liberado para manusear tabelas, storeprocedures e outros serviços do MYSQL no AWS.

Veja informações oficiais do site da AWS.

Criando sua primeira instância RDS:

Um vídeo de introdução para RDS: https://www.youtube.com/watch?v=Kz1zmyHw9G0

O que é RDS? http://docs.AWS.amazon.com/AmazonRDS/Latest/UserGuide/Welcome.html

Introdução: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html

Configurando o RDS dentro um VPC: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.html

Práticas recomendadas de RDS: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html

FAQ: https://aws.amazon.com/rds/faqs/

Centro de conhecimento de suporte de AWS: https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Relational_Database_Service _(Amazon_RDS)

Algumas coisas importantes a considerar:

Uma rápida introdução sobre classes de instância de DB, status: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html

Como funciona o Multi-AZ? http://docs.AWS.amazon.com/AmazonRDS/Latest/UserGuide/Concepts.MultiAZ.html

Minha modificação planejada requer tempo de inatividade: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

Tipos de armazenamento diferentes para diversos fins: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html

Segurança para suas instâncias de RDS: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.html

Limites para RDS: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html

Depois de obter sua instância RDS configurada, confira estes links para usar o RDS para todo o seu potencial:

Monitorar o desempenho da sua instância do RDS: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html

Diferentes Estados de instância de RDS DB: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.html

Guia de RDS geral solução de problemas: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Troubleshooting.html

Vários registros, você pode habilitar para solução de problemas: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html

Usando o AWS CloudTrail com RDS para fins de conformidade: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Auditing.html

 

Esperamos que esses recursos vão responder suas perguntas e ajudar que você a começar usando Amazon RDS. Se você tiver outras dúvidas ou preocupações, por favor em contacto connosco nos fóruns RDS:https://forums.aws.amazon.com/forum.jspa?forumID=60

Pessoal até a próxima.

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