EDIT: Meu time no NodeKO

1. Crie o LSB Script para o MongoDB em “/etc/init.d” conforme abaixo:

#! /bin/sh

# /etc/init.d/mongodb

#

# Carry out specific functions when asked to by the system

case “$1″ in

start)

echo “Starting MongoDB”

mongod –fork –logpath /var/log/mongodb.log –logappend

;;

stop)

echo “Stopping Mongodb”

mongo localhost/admin –eval “db.shutdownServer();”

;;

*)

echo “Usage: /etc/init.d/mongodb {start|stop}”

exit 1

;;

esac

exit 0

$ update-rc.d /etc/init.d/mongodb defaults

E é isso

1. Abra o console do MongoDB para forçar que todos os dados sejam descarregados para o disco e colocar o banco em modo read-only:

$ mongo

> use admin;

> db.runCommand({“fsync”:1,”lock”:1})

2. Copie os seus dados para o seu dispositivo de backup

$ cp -R /data/db /mnt/backup

3. Destrave o seu banco e seja feliz:

> db.$cmd.sys.unlock.findOne();

E é só. “Só isso?”. Sim, é só isso. A única coisa a se mencionar é para fazer estas operações sempre em um MongoDB slave, permitindo que os usuários da sua aplicação possam fazer escritas no MongoDB master (você está usando MongoDB em modelo Master-Slave, né?).

O grande problema desta “verdade universal” é quando ela não se mostra tão universal assim (pois, como todos sabem, there is no silver bullet) e, por falta de um melhor repertório tecnológico ou por basear decisões técnicas em dogmas, acabam recorrendo a alguns “jeitinhos” que, no fundo no fundo, nada mais são do que dívidas técnicas (dívidas pesadas, como aquelas que você contrai quando pede dinheiro emprestado a um mafioso) que um dia vão ter que ser pagas (imagine os capangas do mafioso batendo à sua porta).

"Si, io *SEMPRE* usarei Oracle, Don Vito."

Exemplos destas dívidas técnicas não faltam por aí, mas vou citar dois cenários nada incomuns:

1. Cenário: aplicação possui algumas entidades cujas estruturas não são bem definidas ou cujos atributos podem ser definidos/removidos pelo usuário final. Jeitinho: criar uma grande tabela do tipo chave-valor para armazenar o nome dos atributos, seus respectivos valores e a chave da entidade ao qual estes atributos pertecem. Problema: como seu banco se comporta quando você precisa fazer JOINs usando estas tabelas, que possuem centenas de milhões de registros?
2. Cenário: aplicação permite que entidades sejam (re)definidas em tempo de execução pelo usuário. Jeitinho: (1) criar uma tabela nova para cada entidade (re)definida e (2) as informações sobre esta entidade (metadados) ficam guardadas em um outro conjunto de tabelas e… Problema: precisa explicar?

Provavelmente você deve estar rindo porque você já se deparou com alguma destas aberrações e que lhe tiraram boas horas de sono. Horas estas que poderiam muito bem ter sido poupadas se ferramentas certas fossem usadas. E é nesta hora que ampliar um pouco os horizontes e, neste caso, conhecer um pouco sobre NoSQL iria resolver sua vida.

NoSQLACID

NoSQL é o termo usado para se referir a um conjunto de novas tecnologias de armazenamento de dados que não seguem as regras estabelecidas pela álgebra relacional e podem não conter todas as propriedades que caracterizam um banco de dados relacional como transacional.

Na verdade, embora o termo leve “SQL” no nome, seria muito mais correto se o nome fosse NoACID, uma vez que, em troca de obter coisas como escalabilidade horizontal e/ou habilidade para lidar com imensos conjuntos de dados (e considere algo como imenso a partir do momento em que você tiver que movimentar algumas dezenas de Terabytes) de maneira muito rápida, estes bancos de dados NoSQL abrem mão de coisas como consistência e o tamanho do escopo de uma transação (explicações sobre isso ficam para um próximo post). E, para o contexto em estes bancos foram criados (a maioria nasceu como solução de armazenamento de informações para redes sociais ou sites de mídia), o trade-off ACID x escalabilidade valia muito a pena. Afinal de contas, ninguém vai morrer se o Orkut perder uma ou duas atualizações de profiles. Por outro lado, este mesmo trade-off não faz o menor sentido para uma aplicação de compensação financeira, por exemplo (se fizer sentido para você, diga-me para qual banco você trabalha, por favor).

Além da questão de consistência, outra característica comum e muito interessante destes bancos é o fato de eles serem schema-free, i.e., diferentemente de um banco de dados relacional, em que entidades são mapeadas como tabelas, que possuem uma estrutura de dados bem definida usando colunas (que possuem um tamanho fixo), um banco de dados não-relacional pode guardar um vários tipos de entidades cada qual com estruturas diferentes. Por exemplo, você pode ter uma entidade Pessoa no seu sistema, mas as instâncias desta entidade podem ter estruturas diferentes entre si.

E, por fim, embora o nome (banco de dados não-relacional) sugira erradamente que estes bancos não permitem relacionamento entre entidades, a maioria deles suporta os mesmos tipos de relacionamentos que bancos relacionais suportam (1-1, 1-N, N-M,…), apesar das implementações destas poderem diferir um pouco do jeito relacional de ser. Além disso, bancos orientados a documentos permitem um tipo de relacionamento que não existe em bancos relacionais que é a incorporação, ou seja, um documento pode embutir outros documentos em sua estrutura.

E por onde começar?

Primeiro de tudo, escolha uma das várias alternativas de bancos não-relacionais disponíveis por aí. Eu sou meio suspeito, gosto muito do MongoDB e do CouchDB, dois bancos de dados orientados a documentos e que usam Javascript como linguagem para manipulação de dados. Mas existem outras alternativas muito boas, como o Apache Cassandra, Riak ou Redis (que são do tipo key-value) ou o Neo4J (banco de dados de grafos). Em segundo lugar, esqueça por alguns instantes SQL, pare de pensar em forma de tabelas, projeções, JOINs, etc etc etc. Muitas vezes o desenho que estamos acostumados a dar às nossas entidades no mundo relacional são completamente diferentes do desenho a que teremos numa abordagem orientada a documentos, por exemplo. E, por fim, não entre no hype do NoSQL e comece a tentar enfiar bancos não-relacionais em qualquer lugar porque nem sempre eles serão a melhor solução. NoSQL não é silver bullet

Mas, o fato é que começamos 2010 e botei na minha cabeça que, além de me exercitar todos os dias, acordar cedo, parar de tomar refrigerantes e moderar o consumo de doces, eu vou passar a atualizar este blog regularmente, muito disso inspirado pelos meus colegas de Locaweb, como Fábio Kung, Daniel Cuckier e Fábio Akita. E, por “regularmente”, entenda-se 1 vez por semana, ao menos, o que, ao final deste ano vai resultar em, no mínimo, 52 posts.

Claro, eventualmente, posso acabar me atrasando e entregar dois posts em uma semana, mas o objetivo é ter 52 posts até 31/12/2010 Mas não 52 posts quaisquer. Minha idéia é que estes 52 textos tratem não só sobre tecnologia ou arquitetura de software, mas também tratem sobre vários outros aspectos que fazem parte do nosso mundinho de desenvolvimento de software, tais como relações humanas, aspectos econômicos ou qualquer outra coisa que nos afete E, lógico, aceito sugestões de temas também.