Tuesday, May 18, 2010

Primeiro encontro no:sql(br)

Sábado passado (15/5/2010) aconteceu em São Paulo o 1º encontro no:sql(br). Tinha umas 120-170 pessoas na platéia. Tive que ir embora às 15h então assisti:

Abertura, Alexandre Porcelli, OpenSpotLight
O Porcelli está de parabéns pela iniciativa, coragem de ter organizado tudo com grana própria, e pela qualidade do evento. Também está de parabéns por ter garantido ao final de cada palestra um bom tempo para perguntas do público.

noSQL anti-patterns, Gleicon Moraes, Locaweb
A melhor palestra que eu assisti, na verdade deveria se chamar "SQL anti-patterns", porque o objetivo do Gleicon era mostrar casos de uso comuns e totalmente equivocados de bancos relacionais, "soluções" que criam ainda mais problemas e que deveriam ser implementadas usando bancos não relacionais. Para cada anti-pattern, ele mencionava arquiteturas alternativas usando diferentes ferramentas NoSQL. Excelente.

Performance e simplicidade com Chave/Valor utilizando REDIS, Luiz Fernando Teston, OpenSpotLight
O Teston sabia do que falava e seu entusiasmo é evidente, mas ele perdeu tempo com detalhes como a compilação do Redis e acabou levando 30 minutos até finalmente começar a mostrar porque um banco de chave-valor é melhor do que um MySQL com uma tabela de duas colunas, id e blob.

O papel do REST no Neo4J e CouchDB, um comparativo, Guilherme Silveira, Caelum
O Guilherme é um palestrante e instrutor muito bom, mas nessa palestra ele perdeu muito tempo com analogias nem sempre felizes e não mostrou quase nada dos produtos, muito menos fez comparações. Assim o evento ficou bem prejudicado como um todo porque o CouchDB é um dos produtos NoSQL mais comentados e ele acabou não sendo bem representado no evento.

Introdução ao MongoDB - direto da fonte! - Alberto Lerner
O Alberto Lerner é um engenheiro da 10gen que desenvolve o MongoDB, e antes trabalhou no Google no próprio BigTable. A palestra foi muito boa também, e fiquei mais interessado no MongoDB do que antes. No coffee-break o Cristiano Anderson e o Henrique Bastos (que não trabalham juntos) contaram que tem produtos rodando MongoDB quase em fase de produção. Fiquei com a impressão que acontece aquele lance de Ruby x Python. Tem mais gente falando de Ruby, porém muito mais gente usando Python. Entre CouchDB e MongoDB, o mesmo: o primeiro é mais citado e o segundo é mais usado.

Tio: um NoSQL made in Brasil - Rodrigo Strauss, 1bit
O Rodrigo é um programador C++ das trincheiras do mercado financeiro, ou seja, aplicações de missão crítica onde não pode haver latência alta e muito menos perda de dados. Ele é ativo no grupo de usuários de C++ que o Alberto Fabiano agita. Fiquei muito bem impressionado com o Tio, que é como ele mesmo define um "servidor de estruturas de dados que implementa publish/subscribe", ou seja, serve de infra-estrutura para serviços de troca de mensagens entre sistemas distribuídos. Python é a segunda linguagem favorita dele, portanto muito bem suportada no Tio.

Infelizmente não pude ficar para as palestras sobre Hadoop e Cassandra. O Akita twitou que o Cassandra é o nosql favorito dele.

Na verdade, a maioria dos produtos que foram apresentados não são exatamente concorrentes diretos e mal podem ser comparados. O que eles tẽm em comum é serem servidores para compartilhamento de dados entre sistemas distribuídos, e portanto cada um à sua maneira pode substituir com vantagens um banco de dados relacional em situações específicas. Mas os casos de uso indicados são muito distintos.

É mais ou menos como fazer um evento sobre "NoCar", ou seja, veículos automotivos que não são carros de passeio, e aí tentar comparar tratores, scooters, caminhões, rebocadores de avião, carrinhos de golfe, varredores de rua e tanques de guerra. Cada um deles funciona melhor que um carro de passeio em determinadas funções, mas dificilmente um substitui o outro, e nenhum substitui o carro de passeio na maioria de seus usos cotidianos.

Monday, March 15, 2010

E se o banco de dados se adaptasse aos dados?

Depois de anos trabalhando com bancos de dados relacionais eu cansei. Aprendi programação orientada a objetos, e as regras de normalização deixaram de fazer sentido. Porque o registro de um livro não pode ter vários campos de autor? É natural que a relação de autores seja um atributo do livro.

Não é natural que os autores fiquem em outra tabela, com chaves apontando para o livro, enquanto no registro do livro propriamente dito não tem nem menção de autor algum. Isso é bizarro. A gente só não acha bizarro depois de muito adestramento, pelo qual eu também passei.

O modelo relacional tem muitos méritos, não precisa de mais um defensor. Mas para muitas aplicações, existe um outro modelo de dados mais apropriado, chamado "semiestruturado" (semistructured: este é o melhor termo para pesquisar na literatura científica).

No modelo semiestruturado, podemos ter campos repetitivos (por exemplo, vários campos de autor) e sub-campos, ou campos compostos (um campo autor pode ter sub-campos para o nome e a data de nascimento). Essas duas coisas são proibidas no modelo relacional, como foi definido por Codd.

Na blogosfera há muito sobre o CouchDB e outros bancos de dados semiestruturados. Eu trabalho na BIREME, uma instituição que vem construindo há décadas e com muito sucesso grandes bases de dados bibliográficas com CDS/ISIS, um banco de dados semiestruturado criado pela OIT e Unesco. Nos próximos posts vou contar algo do que tenho aprendido sobre este modelo de dados alternativo.