MongoDB - Instalação

A instalação do MongoDB é um dos passos mais complexos em todo o processo de aprendizagem do banco. Requer bastante experiência na área de TI para conseguir fazer.

Para facilitar a sua leitura, deixei em negrito arquivos, diretórios e comandos.

Como explicado na Introdução, o MongoDB possui versões de 32 e 64bits para Windows, Linux, OSX e Solaris. A versão utilizada nesse artigo é a 2.2.1, para OSX.

O primeiro passo para realizar a instalação é acessar a página de downloads do produto e selecionar a versão que mais se adequa ao seu sistema operacional.

Após o download ser concluído, deve-se extrair o conteúdo do arquivo em seu diretório predileto, no meu caso, criei um diretório em /opt/mongodb

Ao descompactar, você encontrará a seguinte estrutura:

Onde GNU-AGPL-3.0 são os termos de licença pública, README são informações sobre como instalar o produto, pra que serve cada executável que está na pasta bin, etc. e THIRD-PARTY-NOTICES são os termos de licença de uso de softwares de terceiros dentro do MongoDB.

No nosso caso, o mais importante está no diretório bin. Entre na pasta bin e encontrará todos os executáveis do MongoDB, por exemplo: mongo e mongod [terminal e daemon, respectivamente], mongoexport, mongoimport, mongorestore, entre outros. Nesse momento, você está quase com a instalação completa, vamos iniciar o bicho?

./mongod

Ops, acho que não funcionou. Você recebeu o erro: ERROR: dbpath (/data/db/) does not exist ? Isso ocorre pois, por padrão, o MongoDB tenta iniciar suas dbs, collections, index, journals em /data/db e para resolver isso temos duas opções: criar o diretório /data/db [é uma abordagem que eu não gosto muito, pois é necessário criar um diretório na raíz do seu disco] ou simplesmente usar o parâmetro: --dbpath. Para isso, criei no diretório de instalação uma pasta chamada data:

mkdir /opt/mongodb/data

Acho que agora podemos iniciar sem problemas:

./mongod --dbpath=/opt/mongodb/data/

Pronto, você deve ter recebido "[initandlisten] waiting for connections on port 27017", isso significa que o seu MongoDB está pronto para receber conexões na porta 27017. Não acredita? Vamos testar.

Abrindo um novo terminal, vamos novamente entrar no diretório de executáveis do seu banco, no meu caso em /opt/mongodb/bin e entrar no terminal do MongoDB:

./mongo

Agora você acessou o terminal do MongoDB, que infelizmente está vazio mas mesmo assim, você pode digitar seu primeiro comando: help()

Viu como foi complexo? Nos próximos passos, vamos dar uma leve pincelada sobre JSON e BSON, vamos também criar nosso primeiro documento.

MongoDB - Introdução

Vou começar a publicar uma série sobre o MongoDB, o banco NoSQL que é a novidade do momento e que vem agradando pela sua facilidade, velocidade e suporte da comunidade.

O MongoDB é um banco de dados open source, criado a cerca de 5 anos, escrito em C++, desenvolvido pela 10gen e que vem com um grande poder de escalabilidade e alta-performance (ou como o proprio fabricante o denomina: Agil e Escalável).

Um banco de dados que possui algumas características interessantes. Possui uma aproximação com um memcached, não possui tantas funções quanto um Oracle/SQL Server/MySQL/RDBMs mas definitivamente é muito mais simples que ambos.

Ele possui grandes virtudes como armazenamento baseado em documentos (Documents-Oriented Storage), suporte a index, sharding, schemaless, Map/Reduce, etc. features que serão abordadas com mais profundidade em posts posteriores.

Possuindo versões de 32 e 64bits, pode ser instalado em Windows, OSX, Linux e Solaris. O MongoDB utiliza a storage engine baseado em memory-mapped files, por isso, para bases de dados maiores que 2GB, é necessário utilizar a versão de 64bits.

O shell do banco de dados é baseado em JavaScript, mas não se assuste, é muito simples de utiliza-lo e você [quase] nunca terá de usar a linguagem.

O MongoDB trabalha com o padrão JSON, isso deixa os documentos mais legíveis e permite a flexibilidade nos documentos, não sendo necessário a criação de "campos" para armazenamento. Seus dados são armazenados em formato BSON, que trás algumas vantagens como maior quantidade de datatypes e acesso ao dado com mais velocidade, mas também algumas desvantagens como limitação no tamanho de um documento em 16MB.

Uma coisa que muitos DBA's se assustam quando escutam pela primeira vez sobre MongoDB é a falta de JOINs nativos [é possível fazer JOINs com algumas magias negras] e principalmente a não existência de transações. O que parece ruim, em alguns casos é bom.

Com a ausência de JOINs foi possível criar um banco de dados que não possui campos fixos, ou seja, é possível criar documentos com características diferentes, por exemplo, estamos criando um catálogo de produtos para a grande rede de lojas "Casas Amazonenses", uma rede muito grande com uma grande variedade de produtos eletrônicos, produtos para casa, informática, etc. Teríamos assim, em um modelo relacional parecido com:

Nesse modelo um produto tem um tipo, que pode ou não ser reutilizado. Para buscar um produto com seu tipo basta fazer um Join, tudo muito bonito e simples, porém, esse modelo mostra como estamos preso ao schema. Para adicionar uma informação, seria necessário mudar a estrutura dos dados, ou seja, para adicionar uma coluna "descricao" ao produto, os metadados seriam modificados, o bloco contendo a tupla seria realocado e para cada registro, existiria a possibilidade de ter uma descrição. Isso é apenas um exemplo do quão amarrados ao schema o banco relacional nos deixa.

id	nome	descricao	tipo
1	Cama casal	Linda cama de casal	Casa
2	Cama solteiro		Casa [tive que descrever pois não posso deixar FK vazia]
3	TV Tubo, 29”		Eletrônicos
4		TV Led, 40”, HD, 3D, cheia de coisa	Eletrônicos

Esse mesmo modelo, no MongoDB, seria simples [não vou colocar em JSON, para não pular explicações e nem acabar com a surpresa] como:

"id" : 1, "nome" : "Cama casal", "descricao" : "Linda cama de casal", "tipo" : "Casa";
"id" : 2, "nome" : "Cama solteiro";
"id" : 3, "nome" : "TV Tubo, 29”", "tipo" : "Eletrônicos";
"id" : 1, "descricao" : "TV Led, 40”, HD, 3D,  "cheia de coisa", "tipo" : "Casa";

A falta de transações atrapalha em alguns casos. O MongoDB apenas obedece o "D" do ACID, isso se você possuir o journaling ativo, que por sinal, só na versão 64bits, ou seja, se o seu projeto depende em 100% de ACID compliance, o MongoDB não vai te ajudar muito.

Bom, acho que consegui uma breve introdução ao MongoDB, nos próximos posts, vamos começar a mexer mais na prática.

Swap MySQL

Enfrentamos um problema complicado demais na ultima semana, o servidor novo de replicação que havíamos colocado no ar estava com um estranho problema de swap em disco, mesmo tendo memória o suficiente para execução no servidor.

A configuração da máquina era:

•  26GB Memória
• 128GB SSD
• CentOS release 6.2 (Final)

Depois de verificar a alocação de memória do InnoDB, percebeu-se que estavam corretamente configuradas:

show global variables like '%cache%';

VARIABLE_NAME	VARIABLE_VALUE
binlog_cache_size	32768
have_query_cache	YES
key_cache_age_threshold	300
key_cache_block_size	1024
key_cache_division_limit	100
max_binlog_cache_size	18446744073709547520
query_cache_limit	1048576
query_cache_min_res_unit	4096
query_cache_size	1073741824
query_cache_type	ON
query_cache_wlock_invalidate	OFF
table_definition_cache	256
table_open_cache	457
thread_cache_size	32

e o show innodb status (convertidos para melhor entendimento):

=======

Total memory allocated 15G; in additional pool allocated 1,5G

Dictionary memory allocated 512M

Buffer pool size    11G

Free buffers        0

Database pages      989137

Modified db pages   305

Pending reads 0

Pending writes: LRU 0, flush list 0, single page 0

Pages read 1674521, created 2505362, written 10421938

1.18 reads/s, 0.14 creates/s, 6.05 writes/s

Buffer pool hit rate 1000 / 1000
========

O que sobrou de opção foi verificar algo no sistema operacional, visto que não encontrava nada que pudesse responder esse swap que estava ocorrendo.

O Linux tem como padrão uma configuração de swappiness.

Mudando essa opção no Linux, setando a variável para gerenciar somente 15% do que vai - com o perdão da palavra - ‘swappar’

vim /etc/sysctl.conf

vm.swappiness=15

Assim, o slave parou de fazer swap. Pode ser que essa solução não se aplique ao seu problema, porém, essa é uma solução muito adotada por administradores de infra, o que deu um bom resultado no nosso ambiente.

Espero ter ajudado.

InnoTop

O InnoTop foi desenvolvido para monitoramento do seu banco MySQL, através dele conseguimos verificar várias opções, conforme imagem abaixo:

Nele é possível, por exemplo, verificar as querys que estão sendo executadas, ver o status do InnoDB, observar vários status do seu banco, etc.

Instalação:

1. Download do script em http://code.google.com/p/innotop/downloads/list
2. Descompactação: tar-xzvf innotop-1.8.0.tar.gz
3. Para executar o programa, executar: ./innotop --user=user --password=pass --delay=1
• Nesse caso, o script irá capturar informações de 1 em 1 segundo.

Na primeira vez instalando o script, tive um problema com um dos plugins do CPAN [Can't locate Term/ReadKey.pm], facilmente solucionado seguindo os passos abaixo:

1. sudo su -
2. perl -MCPAN -e shell
3. Configurar o CPAN conforme suas necessidades e configurações internas;
4. Assim que entrar no console do CPAN, instalar o seguinte plugin:
• install Term::ReadKey
• exit

Pronto, agora, tudo deve estar funcionando com o innotop, aproveite essa boa ferramenta.

Esse é meu primeiro 'artigo', espero que seja útil.