semi- estruturado

Python, noSQL e o 2º noSQL Brasil

2011-10-03T12:07:00.000-07:00

Pela 2ª vez teremos em SP o Encontro noSQL Brasil, oficialmente no:sql(br)/v2.

As comunidades Python e noSQL têm em comum a convicção de que a tecnologia que todo mundo usa não é necessariamente a solução para todos os problemas.

Estive na 1ª edição do no:sql(br) e foi muito bom, com vários palestrantes internacionais e nacionais que não estão brincando, estão usando noSQL para resolver problemas reais em sistemas de missão crítica.

Para quem está chegando agora, os proponentes do noSQL não tem nada contra SQL em si: a questão é deixar claro que o modelo relacional não resolve bem todos os problemas de persistência de dados. Então noSQL=not only SQL (não só SQL) virou a bandeira de vários projetos de bancos de dados não relacionais muito diferentes entre si, mas unidos pela causa de espalhar a notícia de que existe coisa boa além (ou aquém) da primeira forma normal.

A comunidade Python tem uma longa tradição de buscar alternativas quando o modelo relacional não atende. Temos APIs robustas para acesso a bases chave-valor e serialização de objetos na própria biblioteca padrão, suporte de primeira classe no Google Datastore via App Engine, além do ZODB, um BD OO transacional ACID em produção desde 1998, usado nos projetos Plone e ERP5.

Por isso e pelas características dinâmicas da linguagem, Python está surfando muito bem a onda do noSQL, e os fornecedores sabem disso, tanto que Python costuma ser uma das primeiras linguagens com suporte oficial na maioria dos produtos noSQL.

Assim como dominar Python ajuda a te diferenciar profissionalmente, conhecer alternativas ao modelo relacional pode abrir portas para excelentes oportunidaes, e o no:sql(br)/v2 é o melhor evento para se atualizar sobre essa tendência irreversível, como afirma o próprio Mike Stonebraker, pai do PostgreSQL (PDF).

E eu não perco por nada nesse mundo a palestra do grande Klaus Wuestefeld sobre o Prevayler, o sistema de prevalência de objetos que ele inventou há 10 anos e que o Martin Fowler resolveu reinventar sem dar crédito, mesmo depois de ser avisado de estar reinventado.

Primeiro encontro no:sql(br)

2010-05-18T14:18:00.000-07:00

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.

E se o banco de dados se adaptasse aos dados?

2010-03-15T13:14:00.000-07:00

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.