Minha programação de palestras do PgBr2011:

2011-11-3

9h30 Bruce Momjian, MVCC Unmasked
11h vmWare vPostgres
14h Eu!
15h Leonardo César, \dfS pg_*: Um passeio pelas funções administrativas do postgres
16h20 Greg(ory) Smiþ, Bottom-up Database Benchmarking

2011-11-4

9h Koichi Suzuki, PostgreSQL and Postgres-XC in NTT Group
10h30 Fernando Ike de Oliveira, Escalabilidade, As Modas e (No)SQL
10h30–12h30 Dickson S. Guedes, Estripando o Elefante - dividindo seus problemas em problemas menores
14h30 Euler Taveira de Oliveira, Tudo o que você queria saber sobre PostgreSQL mas tinha vergonha de perguntar
16h50 Flavio Henrique Araque Gurgel, Meu ambiente cresceu e eu não planejei. E agora?

PgBr MMXI

Mais um ano, e volta a Conferência Braſileira de PoſtgreSQL, agora chamada PgBr, e não mais PgConBr. Além de economizar três caracteres (¡dã!), o novo nome evita coliſão com a Conferência global de PoſtgreSQL, realizada todo ano em Otava, Ontário, Canadá, no primeiro ſemeſtre.

Ainda não ſei ſe poderei ir. Eſte ano, apeſar de ſer realizada na capital de São Paulo dos Campos de Piratininga, SP, a conferência realizar‐ſe‐á durante a ſemana de trabalho, como ſe fôra planejada para uma cidade de funcionários públicos, como Braſília, DF. Eu meſmo, funcionário público, ſaio do eſperado e me acho aßoberbado de trabalho, o que me dificulta a ida. Ißo ainda poderia ſer negociado; o que realmente me atrapalha é juſtificar ir ſem paleſtrar, e tenho já mais de um ano afaſtado da área de dados, o que me gera falta de aßunto.

Não que não haja aßuntos intereßantes. Mas após duas experiências ſofridas de paleſtrar ſem preparação adequada (PgBr MMIX, ſobre expreßões comuns de tabelas e PgCon MMX, ſobre modelagem literária), além de meu preſtígio ter baixado baſtante na comunidade, reluto em achar que conſeguirei preparar e apreſentar algo que valha a pena, ainda mais que ainda eſtou ſem meu Debian GNU/Linux em caſa, ainda com os problemas do EFI da Apple — no trabalho, onde ainda é Bios, eſtou no conforto do Debian com GNU Emacs — ſaudades do Open Firmware…

Idéias até tenho — por exemplo, ‘O Paquiderme univerſal’, ſobre como o PoſtgreSQL, ao rodar em todo tipo de plataforma, eſcalando do portátil ao grande porte, com todo tipo de linguagem e extenſão, atende a praticamente todas as demandas poßíveis e imagináveis de computação e geſtão de dados deſte lado do paraíſo relacional; ou ‘A Evolução paquidérmica: para o alto, e ¡avante!’, repaßando a liſta de afazeres do PoſtgreSQL, moſtrando como vamos melhorar, talvez colocando em perſpectiva tanto das noßas verſões mais recentes quanto do eſtado e melhorias mais recentes dos principais concorrentes; ou ‘O Elefante: ſua verdadeira forma, e diſfarces’, moſtrando as facilidades de migração de código, com ênfaſe dividida entre facilidades de compatibilidade com concorrentes e aplicação de padrões que facilitam a migração de e para o PoſtgreSQL. A queſtão é que, no momento, creio que há muito mais gente que poßa fazê-lo muito melhor do que eu.

Vejamos. No momento, não eſtou paßando bem. Talvez amanhã reſolva apreſentar algo, o prazo já ſe encerrará. Mas eu bem preferia que outros apreſentaßem eßes temas, e outros melhores ainda.

Se eu não puder ir, peço que alguém levante a diſcußão: regiſtremos os domínios Poſtgres, PoſtgreSQL e Postgres.org.br?

Yahoo! e PostgreSQL escalável

Esta é de se fazer pensar. Apesar da esperança que japoneses estejam fazendo algo sobre escalabilidade horizontal com o PostgreSQL, quem chega lá primeiro? O Yahoo!. O Yahoo! não publicou código, mas o simples fato de ter divulgado já ajuda outras iniciativas, e dá a esperança de que o código seja publicado.

Mesmo que o PostgreSQL estivesse sob esquerdo de cópia, essa situação de ter algo tão perto, tão longe, seria inevitável: nem o Yahoo! publica sua versão de PostgreSQL, nem o Google publica seu BigTables. A GNU GPL não obriga publicar código de uso interno, e nem pode: restringir uso interno, que não implique em redistribuição, seria transformar um programa de livre em proprietário.

Mas o mais interessante aqui não é o aspecto de licenciamento, é a perspectiva de bases de dados livres muito mais escaláveis que as atuais. O custo aparentemente é baixo, com menos de mil servidores para 2 PB. Um funcionário da Microsoft diz que é um sistema semelhante ao IBM DB2 Database Partitioning Feature, no qual trabalhou ainda sob o nome de Parallel Edition, antes de ir para o lado negro da Força, mas o fato de haver uma patente na jogada sugere que pode ser que a Yahoo! tenha de fato comprado uma jóia — este é um desenvolvimento duma tecnologia comprada com uma empresa chamada Mahat Technologies, da qual não há traços na Teia fora os relacionados a este anúncio, ao menos segundo o Google; e o que o Google não sabe, não existe!

Já há rumores de que a Yahoo! vai colaborar com a comunidade PostgreSQL, o que é reforçado por seu patrocínio à Conferência Mundial de PostgreSQL. A Hitachi e a EnterpriseDB também têm idéias semelhantes, então mesmo que a Yahoo! esteja com a melhor tecnologia e sua patente não permita que ninguém mais faça algo tão bom, ainda assim certamente deve haver grandes melhorias nessa área. O GridSQL já é um projeto livre, e dizem que a Hitachi vai liberar código também, veremos. A NTT Data, outra empresa japonesa, já está devendo o sistema de envio de registros; talvez as coisas no Japão venham devagar, enquanto eles limpam todo o código de quaisquer problemas que os pudessem envergonhar…

Ingres Relacional

Mais uma notícia interessante de tentativas de implementar plenamente o modelo relacional em sistemas de produção. Hugh Darwen nos diz que

O Projeto D do Ingres busca adicionar ao servidor de bases de dados Ingres suporte à linguagem Tutorial D. […]

O Projeto D possibilitará desenvolvimento de bases de dados usando um ambiente de desenvolvimento completamente conforme à especificação D, consistindo do servidor de bases de dados Ingres e um superconjunto da linguagem Tutorial D, incluindo ferramentas de suporte. […] Vai fornecer um SGBD robusto que, no final das contas, implementará tudo do Terceiro Manifesto, dados temporais e do Modelo Relacional

• Imposição de restrições complexas de integridade de dados afetando muito pouco o desempenho da maior parte das restrições.
• Variáveis de relação virtuais, visões materializadas.
• Otimização semântica de expressões relacionais.
• Atribuição múltipla simultânea eficiente.
• Otimização de bases de dados temporais.
• Especialização por restrição.
• Atualizações irrestritas a variáveis de relação virtuais, quando possível.
• Estruturas físicas de armazenamento auto-organizadas (SGBD autônomo).

Como vêem, são objetivos ambiciosos, e que certamente demorarão para amadurecer. Atualmente, o Alphora Dataphor é uma aposta muito mais segura, embora ainda careça de portes para plataformas livres, especificamente Mono e PostgreSQL. Entretanto, o Dataphor ainda é um sistema virtual, enquanto o Projeto D do Ingres, se for bem-sucedido, será um sistema integrado e já nascerá portável, aparentemente.

Resta ver se conseguirão evitar duas decisões que a Alphora viu-se constrangida a tomar: adotar os NULLs do SQL e abandonar a especialização por restrição. E, principalmente, quando chegarão os primeiros frutos.

Leonardo César e os softicidas

Conversa esses dias com o Leonardo César:

Eu: O que é isso?

LC: Isso o quê?

Softcida…

cida = assassinos (?)

E quem são os tais? Maus programadores, gestores, o quê?

Sim, estes mesmos…

Estes últimos, os gestores… certo!

Veja bem, estamos desenvolvendo uma arquitetura bem complexa e distribuída através de webservices (SOAP). Isso envolve alguns bancos e seguradoras e estes normalmente estão utilizando Java ou .Net. O problema é que as ferramentas geram os clientes automaticamente, baseado no WSDL.

Uau! Mas e aí?

E estas ferramentas não são compatíveis com a especificação padrão WSDL e os "programadores" não fazem a mínima questão de ler a especificação e ver que a ferramenta deles não gera o cliente porque fogem do padrão… e daí eu que preciso adequar o WSDL às ferramentas de todos os clientes… por isso odeio softcidas…

Isso me fez lembrar adivinhem o quê? Hybernate!

Pode parecer à primeira vista não ter nada a ver. Mas tem: alguém faz ferramentas de qualquer jeito, sem levar em conta os conceitos e padrões fundamentais, tornando-se um softcida, que vai gerar muito mais problemas do que aparentemente resolve.

Usar Hybernate é cometer softcídio, porque os resultados são terríveis assim que se precisa escalar, e geralmente muito antes, por causa da inconsistência de dados. Evite Hybernate, previna o softcídio. Aprenda dados e SQL.

Administração de Dados: um sistema livre e relacional

Finalmente, habemus um sistema (quase) relacional e livre! Não, o (outramente ótimo) PostgreSQL não é relacional — ele é SQL e, portanto, não relacional. Mas o Alphora é tão livre quanto o PostgreSQL, e é quase completamente relacional, exceto por implementar os NULLs do SQL.

Perde-se algo? Desempenho, por enquanto. O Alphora é implementado por cima de bases SQL, portanto não consegue ter o mesmo desempenho, por acrescentar uma camada com seu próprio interpretador, alguma latência, consumo de recursos &c. Mas creio que vale a pena.

Buracos? Vários. Por enquanto roda somente em MS .Net, e nos SGBDs proprietários mais o MySQL. Mas tendo sido liberado o código-fonte (espero que seja bonito, ainda não vi), a esperança é que logo seja portado para Mono e PostgreSQL. E precisa de mais e melhor documentação.

Administração de Dados: tipos & domínios

Seguindo a série sobre os fundamentos da gestão de dados, falemos sobre os tipos de dados.

Fico impressionado com a quantidade de ‘ferramentas de modelagem de dados’ que não passam de diagramadores — porque não suportam o conceito mais básico depois da própria teoria de dados, que é o de tipagem.

Há muita confusão neste campo por erros terminológicos de ferramentas, métodos e mesmo padrões. Por exemplo, quase todos os sistemas de informática suportam alguns tipos de dados — mas geralmente são apenas alguns poucos tipos básicos, não extensíveis pelo usuário. E quando há essa extensibilidade, chamam-nos tipos abstratos de dados, como se houvesse outros tipos não abstratos. Confundem-se tipos com sua representação, de modo que duas representações são tratadas como tipos diferentes. E, por fim, chamam-se domínios a simples nomes dados a determinados tipos básicos, talvez com algumas restrições de integridade associadas.

Ora, tipos nada mais são que domínios e seus operadores associados; enquanto domínios são listas de valores (não necessariamente discretos) nos quais se pode definir um atributo. Assim, os domínios ISO SQL não são domínios de verdade, e o conceito realmente útil seria o de tipos, mas que também não é realmente suportado, e o que é suportado é de difícil implementação.

Sem uma definição de domínios centralizada no SGBD ou ao menos na ferramenta de modelagem, cada relação do modelo vai tender a ganhar diferentes definições para os mesmos tipos de dados, e o caos é o limite. Sem contar as comparações e cálculos absurdos que se fazem entre tipos de dados incompatíveis.

Em PostgreSQL temos uma sorte: os tipos são um pouco melhor implementados que noutros SGBD ou mesmo no padrão ISO SQL, e em combinação com os domínios SQL realmente se aproximam do conceito matemático. Duro é trabalhar num projeto que realmente implemente os tipos e aloque um programador (C ou D, por exemplo) para criar os tipos assim que possível, antes do resto da programação e implementação da base de dados.

O suporte, embora imperfeito, está aí. Mesmo que tipos SQL muitas vezes não sejam práticos, pelo menos seus ‘domínios’ ajudam. Agora não me venham com diagramas bonitos chamando-os de modelos, se pelo menos os domínios não estão definidos! Quase cem por cento de probabilidade de que, se já não houver grandes inconsistências, elas logo ocorram ao longo da vida da aplicação.

Administração de Dados: os fundamentos

Gostaria de saber dum bom livro-texto de administração de dados. Faz falta, mesmo já com muitos anos de estrada, e mesmo tendo livros tão bons sobre modelos de dados quanto o do Date. Acontece que a ênfase dos livros costuma ser tecnológica; e mesmo um livro conceitual (e conceituado) como o do Date usa os conceitos como base para aplicações tecnológicas, não conseguindo — afinal, trata-se apenas de um livro-texto, não uma enciclopédia de gestão de dados — se preocupar com o projeto e manutenção dos modelos específicos de dados.

Aliás, também gostaria de ter mais contatos na área, a abrangência de meus interesses acaba prejudicando esse corpo-a-corpo tão necessário no Brasil.

Enfim, farei aqui algumas anotações, na esperança de que alguns colegas vejam e comentem.

Primeira anotação: qual o fundamento mais importante da administração de dados?

Resposta irrefutável, mas que virá como surpresa para os empiricistas: uma teoria de dados.

Muita gente começa até com um bom entendimento dos dados em si no sentido de que conhece a aplicação e os usos que fará de que dados. Mas acaba fracassando na organização desses dados, e criando sistemas que não escalam, que são xingados por usuários e mantenedores, que têm de ser refeitos várias vezes até se tornarem aceitáveis, por faltar uma teoria de dados. Daí também vêm tiros no pé como bases de dados multivaloradas (Pick, Caché), navigacionais (Clipper, BTrieve) e orientadas a objeto (Jasmim, de novo Caché). E coisas mais estranhas ainda, como o ReiserFS (não a implementação atual, mas o objetivo final).

Aqui não é o lugar para justificar o modelo relacional como única teoria de dados válida, nem para criticar os outros. Então meus (eventuais) leitores terão de fazer a tarefa de casa, que consiste em ler —­ de preferência, o Date supracitado — e pensar muito.

Migração de MySQL para PoſtgreSQL

Eſtive muito fruſtrado com um detalhe do meu trabalho, o MySQL. O caminho ideal ſeria migrar para PoſtgreSQL.

Cheguei a teſtar vários programetas Perl, Ruby, Python para fazer a migração. Todos funcionam, embora ſem conſertar os problemas de tipos de dados típicos duma baſe MySQL; alguns ſão baſtante ineficientes. E cheguei a ter ſuceßo.

Mas demorei demais, e o patrão arranjou outras prioridades para os deſenvolvedores que iam ajuſtar a aplicação. Projeto abortado, e eu, fruſtrado.

Agora, no CONISLI 2006, encontrei o David FETTER, autor do DBI Link, que nada mais é que um mecaniſmo de federação para PoſtgreSQL: permite gerir diverſas fontes de dados tabulares como tabelas do PoſtgreSQL.

A idéia agora é implantar, junto de cada baſe de dados MySQL, uma baſe de dados PoſtgreSQL, que ſerá a definitiva e enxerga todos os dados MySQL. Funcionando os aplicativos com a baſe PoſtgreSQL, pode-ſe migrar uma tabela de cada vez, ou as tabelas relativas a um aplicativo de cada vez.

CONISLI 2006

Paßei ſexta de manhã, ſábado o dia inteiro e a tarde de domingo no CONISLI, um congreßo de ſiſtemas livres. Pena que não me planejei melhor; a tarde de ſábado, para a qual já tinha compromißo firmado, deve ter ſido a mais intereßante, repleta de paleſtras PoſtgreSQL. Entretanto, ainda foi muito bom. Conheci peßoalmente várias peßoas conhecidas de há anos de liſtas de diſcußões da comunidade brasileira de PoſtgreSQL. Pena que minha ſituação financeira não me permite comprometer-me mais com eles.

Tentando corrigir um livro

Eſtou tentando já há meſes corrigir o (em outros aſpectos excelente) Oracle Essentials, 3ª edição, da O’Reilly:

Dr. Edgar F Codd first described the relational database concept in an IBM Research Report named Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks. His 1970 paper was published in Communications of the ACM, and was called A Relational Model of Data for Large Shared Data Banks. The inexistent System R4 Relational name seems to be a mishearing of IBM’s System R subproject of the Future System project, which was thus named in 1974: probably an author overheard someone mentioning it as something like the IBM System R, (where R stands) for Relational. Also, Oracle was not the first relational database. It was the first SQL DBMS: it is neither a database, but a DBMS, nor relational, but based on SQL, which is not relational. Actually the first relational DBMS seems to have been the original University Ingres, before it became the current PostgreSQL.

O texto original, errôneo, que tem ſido amplamente copiado e divulgado na Teia (ſegundo o Google), aparentemente porque eſtá diſponível como uma amoſtra copiável em Adobe PDF:

The Evolution of the Relational Database

The relational database concept was described first by Dr. Edgar F. Codd in an IBM research publication entitled “System R4 Relational” appearing in 1970. Initially, it was unclear whether any system based on this concept could achieve commercial success. Nevertheless, Relational Software, Incorporated (RSI) began in 1977 and released Oracle V.2 as the world’s first relational database within a couple of years. By 1985, Oracle could claim more than 1,000 relational database customer sites. By comparison, IBM would not embrace relational technology in a commercial product until the Query Management Facility in 1983.

Hoje deve ſer a terceira vez que envio o comentário acima à editora, através de ſua página de comentários. E até agora, ſe recuſaram a publicar, ſeja o meu comentário ſeja uma verſão ſanitizada dele. Se alguém tiver uma maneira mais política de dizer ißo, ou meſmo parte dißo, por favor, comente… e aguarde a publicação de seus comentários na página de errata ou, pelo menos, na de relatos ainda não confirmados. O meu comentário tem ſido ignorado.

Atualização: Há outros erros no mesmo parágrafo, também enviados à O’Reilly:

The first IBM commercial SQL product was actually 1982’s SQL/DS for DOS/VSE, announced in 1981. 1983 saw also the launch of DB2.

E:

Actually the first IBM relational product was BS12.