Esta é a minha primeira entrevista com desenvolvedores do PostgreSQL. Eu espero conversar com muitos desenvolvedores do núcleo, grandes desenvolvedores, desenvolvedores brasileiros e desenvolvedores de projetos interessantes relacionados com o PostgreSQL. No momento este é apenas o primeiro, mas você pode esperar ao menos uma por mês.
English note: The original version of this interview in english is posted here.
Josh Berkus é um dos sete membros do time do núcleo do PostgreSQL, que controlam as versões lançadas do Projeto PostgreSQL. Ele é também líder na Sun Microsystems e tem sido consultor de bancos de dados por mais de uma década. Josh também é um ótimo cozinheiro. Note que Josh fala apenas por si próprio, não pela Sun Microsystems ou pelo Projeto PostgreSQL.
1 – Quando você começou a trabalhar com computadores e quando começou a utilizar Software Livre?
Eu comecei trabalhando com computadores em 1981… com o Commodore Vic20. No colegial eu tive um computador de 8 bits Atari, e fiz muitos hacks no seu hardware, assim como fiz alguma programação de jogos em Basic e assembler.
Eu comecei com Software Livre em 1998. Neste tempo eu era um consultor de pequenos negócios e ONGs construindo pequenas aplicações em bancos de dados e incapaz de tolerar os crescentes preços e aumentos de erros – Eu percebi que se eu continuasse utilizando Microsoft, eu iria a bancarrota, enlouquecer, ou ambos. Então eu troquei o MS SQL Server e o Visual Basic para o PostgreSQL 7.0, Linux 2.2 e PHP 3. Depois eu utilizei um pouco de Perl.
Um dos clientes rodando minhas primeiras aplicações em PostgreSQL está rodando até hoje (uma agência de empregos). Um dos meus clientes em plataforma Microsoft também … mas eles tiveram que contratar um funcionário em tempo integral para manter o software em Visual Basic.
Foi também quando eu me envolvi com a comunidade. Durante o mesmo mês, eu descobri erros no MS SQL Server 7 e no PostgreSQL 7.1. Minha postagem no comp.databases.microsoft.sqlserver foi silenciosamente apagada do fórum MSDN, e o erro nunca foi corrigido. No PostgreSQL, Tom Lane (que ingressou no projeto apenas três meses antes) confirmou o erro em horas e me providenciou um path experimental. Foi quando eu fui fisgado.
2 – Como você vê o mercado de bancos de dados livres e proprietários?
Todos os bancos de dados SQL estarão comoditizados nos próximos 10 anos. Isto é, eu espero que em 2015 haverão apenas quatro tipos de bancos de dados em uso: código aberto, shareware e freeware (como o DB2 express), baixo custo e especializado (como o Filemaker e Pervasive), e bancos de dados legados não mais mantidos.
Isto ocorre principalmente devido aos requisitos de um servidor de banco de dados relacional serem bem entendidos em bem definidos, e a maioria dos produtos existentes satisfazem mais de 50% do mercado em termos de funcionalidades. Isto significa que apenas uma pressão na queda dos preços, e nós observamos, recentemente, o crescimento de popularidade do MySQL e PostgreSQL, e as versões livres dos principais vendedores proprietários.
3 – Quais leituras você recomenda para aqueles que estão começando a utilizar bancos de dados?
“Database Design for Mere Mortals” e “SQL Queries for Mere Mortals” são bons para iniciar. Depois, eu sugiro ler estes livros em qualquer ordem: “PostgreSQL”, “Practical Issues in Database Design”, “SQL for Smarties” de Korry Douglas’ e, claro, não esqueça de ler a documentação do PostgreSQL.
Eu também ouvi coisas boas sobre o “SQL Cookbook” e “SQL Hacks” da O’Reily, assim como o “The Practical SQL Handbook”. Mas eu não li eles.
4 – Você foi desenvolvedor do OpenOffice.org e se tornou um desenvolvedor do PostgreSQL em 2002. O que estimulou você a trocar de projeto?
Eu me envolvi com o OpenOffice.org porque eu senti que, em 2000, era crítico para o sucesso do Código Aberto e do Linux, ter uma boa aplicação de escritório. Sem isto, as pessoas jamais poderiam trocar o Windows – incluindo eu!
Em 2002, OpenOffice.org se tornou bastante popular e teve milhões de downloads. Mas eu fui um consultor e jamais ganhei dinheiro utilizando OpenOffice.org, enquanto eu fazia muito trabalho com o PostgreSQL. Além disso, o projeto OpenOffice.org tinha muita política o que acabava afastando muitos dos voluntários. Então eu troquei de projetos.
5 – Você se tornou tesoureiro da SPI em 2006. Que tipo de relação você espera entre a SPI e o PostgreSQL?
É apenas uma forma de arrecadar fundos para nós. A SPI é atualmente apenas uma das 5 ONGs que arrecadam fundos para o PostgreSQL. As outras são o Japanese PostgreSQL Users’ Group, PostgreSQLFr.org, FFIS (Germany), e o PostgreSQL Turkey.
É claro, meu envolvimento pessoal com a SPI é muito maior que isto, mas é realmente separado do PostgreSQL.
6 – A SPI recomenda o uso de licenças livres como a GPL. Por motivos históricos o PostgreSQL adota a licença BSD. Você recomendaria outra licença para projetos como o PostgreSQL? Em quais projetos você recomendaria a adoção do conceito de copyleft?
Atualmente, eu pessoalmente prefiro a licença BSD, e não tenho a intenção de advogar a troca para o PostgreSQL.
Na minha opinião pessoal, a GPL é melhor para projetos onde o perigo de companhias se apropriarem do código sem retornar uma contribuição é significativa, e o desejo de criar um novo padrão é limitado. Licenças como o BSD (incluindo MIT e Apache) são mais apropriadas onde ter o software distribuído o máximo possível é prioritário e o projeto já tem suporte corporativo reconhecido de grandes empresas. Eu não gostaria de trocar o Linux para BSD, porque já está demonstrado o perigo de empresas derivarem e e fecharem o código.
7 – A Sun tem apoiado muito o desenvolvimento do PostgreSQL, a partir do momento que anunciou o suporte oficial. Você acha que o Solaris se tornará uma das plataformas prediletas para o PostgreSQL?
Bem, é claro que isto seria muito bom para o meu trabalho se isto ocorresse.
Num futuro imediato, eu estou apenas focando em colocar o Solaris e o OpenSolaris no mesmo passo que o Linux e o BSD dentro da comunidade do PostgreSQL. Há muito a ser feito antes que isto possa acontecer; Nós precisamos fazer versões regulares a cada 72 horas para a comunidade, há necessidade de mais documentação sobre o PostgreSQL rodando no Solaris, e mais ferramentas opcionais precisam estar disponíveis como binários para o Solaris. Finalmente, a comunidade precisa construir uma base de conhecimento sobre ajuste de performance no Solaris como a que nós temos em outros SOs.
A longo prazo, o OpenSolaris oferece algumas ferramentas e orientações de desenvolvimento que eu acredito que irão expandir o número de usuários PostgreSQL+Solaris, uma vez que nós tenhamos as coisas rotineiras acontecendo automaticamente. O DTrace, cujo suporte foi incluido no PostgreSQL 8.2, é o maior exemplo destas ferramentas; ele prove informações sobre os conflitos de bloqueios que nós não temos nenhum modo fácil de conseguir antes. Além disso, a comunidade Solaris, como a do PostgreSQL, é dedicada a segurança, estabilidade e fazem o trabalho correto e não o estritamente necessário. Desta forma, eu penso que há muitas oportunidades para uma sinergia entre os desenvolvedores do PostgreSQL e Solaris entrando em contato uns com os outros.
8 – Você acredita que ferramentas utilizadas na versão 8.2 como o DTrace devem ser adotadas em outros SOs livres como o Linux e o FreeBSD?
O DTrace já está no FreeBSD 6.2, e a Apple já estabeleceu que o fará numa versão futura do OSX. Os desenvolvedores do Linux estão trabalando numa ferramenta paralela chamada “systemtap”, e nós criamos a funcionalidade Generic Monitoring Framework no PostgreSQL 8.2 então isto irá ser compatível com o systemtap e outros frameworks de rastreamento quando elas estiverem disponíveis.
9 – Você trabalhou com o desenvolvimento do Bizgres. Em que estágio o projeto se encontra hoje e o que podemos esperar para os próximos anos?
O Bizgres é mais como um terreno de testes para funcionalidades de data warehousing para o PostgreSQL. Muitas coisas planejadas para as últimas versões do PostgreSQL estavam no Bizgres primeiro: índices bitmap-on-disk, por exemplo que vai aparecer no PostgreSQL 8.3. Eu sei que os hackers do Bizgres (a maioria da equipe da Greenplum) já estão trabalhando num gerenciador de recursos, tabelas externas anexadas, e acesso somente por índices, mas não há um calendário definido para estas coisas… ainda.
10 – Notamos que o seu site Power PostgreSQL não recebe novos artigos há algum tempo. Ao mesmo tempo, notamos que ele está de cara nova. Podemos esperar novidades nos próximos meses?
No momento em que este artigo é publicado, eu espero que todas as minhas palestras do último de conferências estejam no PowerPostgreSQL. Eu tenho blogado no ITToolBox (http://blogs.ittoolbox.com/database/soup/) ao invés do PowerPostgreSQL porque o ITToolBox me ajuda a alcançar uma maior audiência.
11- A idéia de construir um livro a partir dele continua de pé?
Bem, Joe e eu descobrimos que, após submeter os primeiros quatro capítulos, encontrar tempo para escrever um livro é muito, muito difícil. Eu estimei que para completar o livro iria requerer mais cerca 800 horas de escrita. Infelizmente, as únicas pessoas capazes de terminar o livro por nós estão ocupadas como nós, então não há um prazo de entrega a vista.
12 – O PosgreSQL tem amadurecido muito em soluções de replicação. Você acredita que num futuro próximo existirão também ferramentas de cluster para o PostgreSQL como existem para o Oracle, o BD2 ou a Teradata? Quais são as dificuldades em se implementar algo do tipo?
Bem, nós já temos um substituto para a Teradata, que é o Greenplum Database. Enquanto ele não é código aberto, é baseado no PostgreSQL e tem a sintaxe compatível. Existem soluções de consultas paralelas com menor performance já avaliáveis como o PostgresForest e Octopus.
Cluster com OLTP é um problema muito, muito difícil e nem um dos vários projetos de bancos de dados ou empresas conseguiram resolver este problema satisfatoriamente: nem a Oracle, nem a IBM, nem a MySQL, nem ninguém. Então, colocar qualquer tipo de data sobre quando qualquer um de nossos projetos estarão maduros para a maioria dos usuários seria muito ambicioso neste momento.
13 – Que tipo de conhecimentos um desenvolvedor do PostgreSQL deve ter?
Para hackear o PostgreSQL: algum conhecimento sobre estruturas de bancos de dados e um bom conhecimento de programação C. Para projetos adicionais no pgFoundry você pode usar a linguagem de programação que você quiser. O mais importante, você precisa ter uma certa humildade sobre o seu código e o desejo de trabalhar em uma comunidade de hackers e aprender como as coisas são feitas; um programador que achar que é mais inteligente que todo mundo não terá sucesso.
14 – Quais funcionalidades você imagina que veremos implementadas no PostgreSQL até 2012?
Eu não posso dizer o que nós teremos em 2009, deixemos 2012 em paz. O projeto se move muito, muito rápido. Nós liberamos uma versão principal todo ano e é difícil ver precisamente mais do que uma versão a frente.
Primeiro, eu gostaria de dizer algumas coisas em que eu estou trabalhando na Sun. Isto inclui uma segunda geração do pgMigrator que tornará fácil a atualização de novas versões do PostgreSQL (o pgMigrator, contribuição da EnterpriseDB, atualmente trabalha apenas com o 8.1 para o 8.2). Nós trabalhamos nisto com os programadores da Greenplum. Segundo, eu estou trabalhando em ferramentas de autoajuste/autoconfiguração que ajudarão usuários a ter uma boa performance com o PostgreSQL sem ter que ser um DBA experiente. É provável que seja um projeto de longa duração que eventualmente seja ligado ao nosso novo medidor DTrace. Finalmente, nós estamos patrocinando o trabalho de Dave Cramer na melhoria de performance do driver JDBC, onde nós temos alguns resultados realmente gratificantes.
Em médio prazo, aqui estão algumas coisas relativamente seguras que nós teremos nas próximas 3 versões ou mais, porque existem pessoas trabalhando ativamente nelas:
- Otimizações update-in-place que aumentarão a performance em OLTP entre 30% e 200%.
- Mais funcionalidades SQL99 e SQL03, como WITH RECURSIVE, RULLUP e RANK.
- Interfaces polidas para tabelas externas (possivelmente compatíveis com SQL/MED), para outros servidores/versões do PostgreSQL e para outros SGDBs.
- Tipos de dados mais exóticos, especialmente funcionalidades SQL:XML mais poderosas, e provavelmente tipos biológicos também.
- Ainda mais melhorias no otimizador de consultas.
- A eliminação do vaccuum. Eu não tenho certeza de como nós vamos falê-lo, mas nós precisamos.
- Replicação síncrona e assíncrona multi-master, de diferentes projetos.
- Publicação de benchmarks e especificações TPC.
