O evento foi totalmente gratuito,  organizado da comunidade para a comunidade,  o @porcelli assumiu todos os custos sozinho e contou com a colaboração voluntária do público para cobrir as despesas com o evento. Uma ideia genial, principalmente por abraçar a causar e assumir as despesas sem ter certeza do retorno. Deixo aqui meus parabéns ao Porcelli, por ter feito o evento acontecer e ter assumido praticamente sozinho todos os riscos do negócio.

Não pude ficar até o final, mas acompanhei todas as palestras da parte da manhã, tive o prazer de encontrar vários amigos e conhecer o Alberto Lerner, da 10Gen, empresa mantenedora do MongoDB. As palestras que assisti tiveram um ótimo conteúdo técnico e mostra o quanto os bancos NoSQL podem ser uma ótima alternativa para armazenar e organizar dados, onde o SQL tradicional não se encaixaria de forma eficiente. Ficou claro também que os desenvolvedores não são contra o SQL, apenas criaram uma opção de escolha.

Eu tenho acompanhado esse assunto desde o início do hype, testei o CouchDB, MongoDB e Cassandra. Acabei escolhendo o MongoDB e estou trabalhando em dois projetos onde o MongoDB se encaixou como uma luva, pelo simples motivo de ser orientado a documentos e não precisar de um schema previamente criado. Nas próximas semanas estarei publicando maiores informações sobre o MongoDB e quero compartilhar essa experiência, os benefícios e os problemas que tive durante a construção dessas aplicações.

E já estou aguardando a segunda edição do evento! Até lá, espero ter um caso de sucesso para apresentar.

Site do evento: http://nosqlbr.com/

Com um banco de dados orientado a documentos, não existe a necessidade de criar o modelo das tabelas, basta definir um documento (estilo JSON) e inserir na base. Esses documentos podem ter campos a mais ou a menos dependendo da necessidade e tudo pode ser indexado e encontrado facilmente.

Estou trabalhando em um projeto onde é necessário indexar uma grande quantidade de informações e documentos. O problema é que muitos documentos não seguem um padrão e existe a necessidade de estar alimentando a base a todo instante com novas informações. Já desenvolvi modelos de busca neste estilo utilizando o Xapian, que é uma excelente ferramenta. Porém a performance fica bastante prejudicada quando a base é atualizada várias vezes ao dia, pois o Xapian mantém muito bem sua performance quando sua base (Quartz) está com os índices devidamente criados e compactados. Ficar atualizando esses índices o tempo todo prejudica a aplicação.

Fiz um teste importando todos esse volume de informações em uma base do MongoDB. Fiquei surpreso pela rapidez em importar os dados, cheguei a acreditar que tivesse acontecido algum problema durante a importação. Mas mexendo no banco, pude observar que tudo foi importado. Com algumas ferramentas desenvolvidas em Python, é possível alimentar a base a todo instante com novas informações e percebi que isso não atrapalha a performance das consultas. Mais um ponto a favor do MongoDB.

A aplicação frontend está sendo desenvolvida em Django, que não suporta oficialmente o MongoDB, mas utilizando módulos externos, é possível fazer o Django falar com MongoDB sem muita dificuldade. Cheguei a testar o MongoEngine e outras receitas (como nos posts integrating MongoDB and Django e Python, Django e MongoDB) mas para meu caso, foi mais fácil usar as ferramentas desenvolvidas internamente em Python para inserir e buscar valores da base.

De uma forma geral o MongoDB é uma ótima solução para armazenar e buscar um volume grande de documentos. Não posso dizer que é melhor ou pior que um banco de dados relacional, tudo depende do modelo de negócio, da aplicação e do que pretende fazer com as informações. Cada caso é um caso, seria muito injusto em dizer que vou substituir todas minhas aplicações de banco de dados relacional para o banco de dados orientado a documentos. Mas os testes serviram para mostrar não é apenas um hype, os bancos orientados a documentos podem ser uma ótima solução para casos mais complexos, que não dependem apenas de um simples CRUD.

De bônus, vale a leitura do post Choosing a non-relational database; why we migrated from MySQL to MongoDB, estou totalmente de acordo com as opiniões do autor e passei por situações bem parecidas.

Nos próximos dias publicarei mais informações sobre MongoDB e um pequeno tutorial. Se desejar ser informado, aproveite para assinar o conteúdo desse blog, basta inserir seu e-mail no campo logo abaixo deste post (e-mails só serão enviados quando existir atualização de conteúdo do blog).

Resolvi dar uma espiadinha em outro banco de dados no mesmo estilo, o MongoDB. Instalei no meu ambiente e realizei os mesmos testes. No CouchDB demorei muito tempo para realizar algumas operações simples, enquanto que no MongoDB, realizei  os mesmos procedimentos de maneira mais rápida e sem me enroscar nas configurações e na manutenção do banco. Em termos de performance — no caso da minha aplicação — os dois bancos se mostraram praticamente iguais.

Embora o CouchDB também tenha bibliotecas para trabalhar em Python, a do MongoDB parece ser mais simples e direta. Pelo menos me identifiquei melhor com sua biblioteca e consegui adaptar minha aplicação rapidamente para trabalhar com o MongoDB, descartando o tempo que levei para o aprendizado e leitura das documentações, demorei menos tempo para desenvolver um script totalmente funcional para MongoDB do que para CouchDB. Isso não quer dizer que o CouchDB seja ruim e ainda não tenho o volume de informações necessárias para fazer um benchmark ou dar opinião sobre qual é melhor.

É muito simples trabalhar em Python com o MongoDB, veja um exemplo:

#!/usr/bin/python

from pymongo import Connection
import datetime

con = Connection('localhost', 27017)
db = con['teste01']

user = {"nome":"Fulano",
        "sobrenome":"de Tal",
        "email":"fulano@detal.net",
        "data_inclusao": datetime.datetime.now()}

# Insere
users = db.users
users.insert(user)

O código acima cria um banco no MongoDB (veja as instruções para instalação e veja também a documentação Python para MongoDB) e insere um registro no dict user para o banco de dados. Como o trabalho é feito em um banco de dados não relacional, não há necessidades de definir o layout da tabela. O layout é definido à medida que os documentos são definidos e é flexível, podendo ser alterada a qualquer momento.

A pesquisa na base de dados pode ser feita com o seguinte código:

#!/usr/bin/python

from pymongo import Connection

con = Connection('localhost', 27017)
db = con['teste01']

# Pesquisa um só
users = db.users
a = users.find_one({"email":"fulano@detal.net"})
print a

# Pesquisa varios
for u in users.find():
    print u['nome'], u['email']

Entre o CouchDB e o MongoDB eu me identifiquei mais com o segundo. Consegui fazer as tarefas de forma mais rápida e eficiente. Mas o primeiro também é um ótimo banco, merece ser estudado. Provavelmente continuarei meus estudos e desenvolvendo a pesquisa em cima do MongoDB, pois tem uma documentação um pouco melhor e mais ferramentas para trabalhar na base de dados.

O próximo passo é integrar uma aplicação Django no MongoDB. Mas isso é motivo para outro post!