Hoje, 27 de novembro de 2006 foi lançado o primeiro candidato a lançamento do PostgreSQL 8.2. Dentro de uma ou duas semanas a nova versão deve ser lançada oficialmente!

Muitas novidades interessantes estão vindo neste novo lançamento! Ao todo são quase 200 melhorias incluindo novas facilidades, algumas correções, aumento de performance e novas opções de configuração e administração.

Uma das novidades ressaltadas por Robert Treat, é a questão da usabilidade. Novas sintaxes que entram em conformidade com o SQL 2003 estão saindo do forno como a possibilidade de se realizar vários INSERTs em uma única linha ou utilizar um SELECT para um comando COPY.

A parte de performance apresenta muitas coisas interessantes. Uma que deve ajudar muito é o fato do otimizador de consultas agora otimizar os OUTER JOINs. Antes um OUTER JOIN colocado no local errado dentro de um SELECT complexo simplesmente arruinava a performance. Outra coisa interessante é a possibilidade de criar índices sem bloquear a escrita na mesma.

Graças a contribuição do Euler Taveira (desenvolvedor brasileiro do PostgreSQL), agora é possível obter de uma data, o nome do mês ou dia da semana em várias línguas, inclusive em pt_BR!

Novas opções de LOG e controle de processos no PostgreSQL também fazem parte da nova versão. Novas views monitoram melhor os processos, novas opções no arquivo postgresql.conf inclusive a possibilidade de desmembrar este arquivo incluindo outros.

Bom, vale a pena conferir o release que já está disponível na documentação oficial, e ver com seus próprios olhos as novidades!

Hoje estava acompanhando as postagens no Planeta PostgreSQL e me deparei com este excelente texto do Sr. Frank Wiles e percebi que algo que me incomodava há muito tempo parece ser verdade! A lei do 80 - 20 não se aplica apenas aos usuários normais, se aplica aos desenvolvedores também.

Para quem não conhece a “Lei do 80 - 20″, ela diz, algo assim: “80% dos usuários utilizam no máximo 20% dos recursos do sistema”. Esta abordagem é clássica quando sugerimos alguém a migrar do M$ Office para o BROffice.

Mas a minha vida de DBA tem mostrado que isto não se aplica somente as aplicações de escritório. Lembro-me que neste ano eu estava dando uma palestra com o Fernando Ike no VII FISL sobre migração de Oracle para PostgreSQL. No final da apresentação uma pessoa que se identificou como sendo de uma importante organização brasileira questionou se o PostgreSQL seria bom para cortar custos mas que no fundo não daria conta da carga que o Oracle suporta. Infelizmente o tempo para as respostas era curto e haviam outras perguntas para serem respondidas, portando não pude responder plenamente o questionamento. No entanto acho que o Sr. Frank Wiles deu uma excelente resposta.

Já vi aplicações em Oracle com mais de 100GB que não utilizam nem 5% dos recursos do SGDB. Para dificultar a engenharia reversa nos bancos de dados, existem empresas que chegam ao cúmulo de não utilizar sequer chaves estrangeiras. Um fornecedor uma vez confessou para mim que eles utilizam o Oracle como “caixa de sapatos”. O que vejo são aplicações muito ruins que utilizam SGDBs proprietários de forma muito ruim. Quando questionamos em porque a aplicação não pode usar um SGDB livre, eles dizem que tem medo do banco de dados não ser seguro.

De fato, creio que o nosso maior problema ainda é o FUD. Ok, o PostgreSQL ainda não tem soluções de Cluster tão maduras quanto a Oracle ou o DB2. Mas veja bem… quantas empresas você conhece que realmente utilizam isto de forma acertada? Quantas empresas não superdimencionam exageradamente as suas demandas?

Para mim, o problema no Brasil é muito mais relacionado a falta de informação dos nossos dos nossos profissionais que preferem apostar suas fichas em marcas conhecidas do que saber realmente o que vão precisar utilizar do SGDB, e quais atendem às suas necessidades.

No entanto, enquanto o números casos de sucesso do PostgreSQL cresce nas grandes empresas, fica cada vez mais fácil convencer as pessoas de que o PostgreSQL é um SGDB robusto o suficiente. É claro que ele não atenderá a 100% das necessidades. É preciso utilizar a ferramenta certa para resolver cada problema. Em alguns casos, podemos utilizar o MySQL, DB2 ou até mesmos arquivo texto. Tudo depende da demanda. No entanto, creio que o PostgreSQL tem obtido enorme êxito no mercado corporativo, sucesso que deve aumentar muito se conseguir manter o rítimo e a qualidade do seu desenvolvimento.

Todo desenvolvedor que tenha um conhecimento razoável sobre banco de dados já passou pela dúvida sobre como lidar com a possibilidade de concentrar boa parte das regras de negócio dentro do banco de dados.

Atualmente, com a disponibilidade de várias linguagens de programação, isto se torna cada vez mais tentador: a Oracle possui além do consagrado PL/SQL, suporte a Java, o PostgreSQL chegou num estado de arte suportando uma infinidade de linguagens de programação dentro de seu SGDB e agora já faz um ano que o MySQL também possui sua própria implementação de linguagem procedural.

Mas o uso desgovernado deste tipo de expediente pode trazer algumas desvantagens. Longe de querer ditar melhores práticas, gostaria aqui de discutir um pouco este tema que tem me intrigado por algum tempo.

Nos primórdios da informática, onde reinavam solenes apenas os computadores de grande porte, não havia a opção de distribuir a carga de processamento em várias máquinas separadas. Os SGDBs relacionais também começaram a nascer somente no final da década de 70 com o DB2, Oracle e Ingres. Sendo assim, toda a aplicação se concentrava em geral na mesma máquina.

Com o surgimento dos microcomputadores veio a revolução da arquitetura cliente-servidor no final da década de 80. A idéia era criar aplicações rodando em microcomputadores (clientes) e armazenar as informações em SGDBs que ficassem em máquinas mais confiáveis (servidores). Com isso foi possível adquirir servidores com um preço bem mais acessível que os computadores de grande porte, uma vez que a carga de processamento da aplicação ficou distribuída nos microcomputadores dos usuários.

Nesta época, linguagens como o VB e o Delphi invadiram o mercado construindo aplicações cliente servidor com pães numa padaria. As aplicações cliente-servidor em boa parte foram muito bem sucedida, mas em ambientes corporativos elas começaram a apresentar uma performance muito insatisfatória. Conforme o tamanho do código cresce e as aplicações vão ficando mais pesadas várias coisas acontecem:

• O código fica difícil de manter (bem, isto não é nenhuma novidade…)
• Em transações longas, onde muito cálculo é utilizado, as máquinas utilizadas no cliente tem baixa capacidade de processamento, tornando a operação lenta.
• Em transações longas com várias consultas ao banco de dados, o tráfego de rede é muito alto e gera um gargalo de desempenho.
• Pequenas falhas na rede durante o processamento de transações longas podem no mínimo obrigar toda a operação a ser reiniciada.

É neste ponto em que entra em cena a linguagem procedural embutida no banco de dados. Com isso, é possível disparar gatilhos em circunstâncias determinadas e executar procedures e funções dentro do SGDB. O ganho de velocidade em aplicações cliente-servidor é realmente fantástico em transações longas.

Mas como tudo na vida , algumas pessoas se empolgaram! A idéia destas pessoas foi a de utilizar as aplicações no cliente apenas para exibir e receber informações, deixando todo o processamento das informações dentro do SGDB. Uma vantagem interessante desta técnica ocorre quando você possui mais de uma aplicação acessando o mesmo banco de dados. Um exemplo disto poderia ser uma aplicação cliente-servidor tradicional utilizada para alimentar e processar as informações, uma planilha extraindo informações complexas do banco de dados e uma aplicação web fazendo consultas de informações específicas. Neste ponto, centralizar toda a “inteligência” ou “regras de negócio” dentro do SGDB facilita a vida de quem tem que manter o código destas diferentes aplicações.

E qual a desvantagem disto? Bem, os ajustes de desempenho do SGDB tem que mudar drasticamente. Antes a coisa mais importante no desempenho de um banco de dados transacional era a velocidade dos seus discos. Com o acúmulo de tarefas de processamento da aplicação dentro do SGDB na mesma máquina o processador começa a assumir um papel cada vez mais importante. O resultado disto pode ser um SGDB muito lento.

Enquanto isto novas tendências de mercado começaram a ganhar força: Programação Orientada a Objeto e Aplicações Web. Na programação orientada a objeto, as linguagens procedurais perdem seu papel, pois estão muito mais próxima da lógica relacional dos SGDBs, embora o Sr. C. J. Date afirme que a maior parte dos fundamentos da P.O.O. estão na teoria relacional. Seja como for, outra tendência que ganhou força com a orientação a objetos é a programação em camadas. Com isso, o aplicativo começa a ser dividido em unidades funcionais, sendo que algumas delas certamente ficarão a cargo de servidores dedicados com maior capacidade de processamento, e conexão de rede dedicada com o SGDB. O mesmo acontece naturalmente em aplicações Web onde o processamento não é realizado em um computador cliente e sim no servidor web (ou em mais servidores se a aplicação for realizada em várias camadas).

Hoje se fala muito em camadas de abstração de bancos de dados e em frameworks MVC. Eles permitem que você desenvolva a aplicação sem se preocupar com qual banco de dados está utilizando. Desta forma, as linguagens procedurais nos SGDBs perderiam completamente sua função! A idéia é realmente tentadora.

No entanto, quando estudamos as boas opções no mercado, verifica-se a existência de brechas para enviar comandos específicos para cada SGDB. Isto ocorre porque se a abstração de SGDB fosse perfeita, certamente não precisaríamos de diferentes SGDBs no mercado. Há momentos em que é preciso acessar funcionalidades específicas de cada SGDB que as camadas de abstração não são capazes de lidar diretamente. Quando se precisa de funcionalidades avançadas e/ou alto desempenho em longas transações, as linguagem procedurais ainda são utilizadas mesmo em aplicações com várias camadas como no modelo MVC.

É claro que as camadas de abstração de dados tendem a evoluir, assim como o padrão SQL tem evoluído. No entanto estamos longe de uma padronização das linguagens procedurais dentro de bancos de dados, além de haverem novas funcionalidades sendo implementadas todos os dias nos SGDBs relacionais. Dito isto, é provável que aplicações continuem se beneficiando de camadas de abstração de dados, no entanto elas não cobrirão plenamente as necessidades de grandes aplicações corporativas, devendo haver sempre brechas para acessar diretamente as funcionalidades especificas de cada SGDB.

Enfim não existe uma regra clara para utilização de linguagens procedurais dem SGDBs. Existem funcionalidades como prover auditabilidade, gerar logs e realizar a carga de dados complexos onde estes são consagrados, além do processamento de longas transações com velocidade e confiabilidade ainda imbatíveis.

Em sistemas pequenos, a centralização da inteligência da aplicação dentro de SGDBs é aceitável, porém com o aumento de aplicações Web e frameworks como o Ruby On Rails, esta não parece ser uma tendência de longo prazo.

Por fim, este assunto é bastante polêmico e não existem regras formais para o uso de linguagens procedurais em SGDBs. A criatividade e o bom censo dos desenvolvedores e DBAs podem sempre apontar para novos rumos ou demonstrar equívocos.

Se você tem uma opinião diferente ou quer acrescentar alguma coisa, deixe seu comentário abaixo.

Nestes últimos tempos voltei a fazer algo que tinha deixado de lado no começo do ano. Mexer ativamente com Bancos de Dados. Com a saída de um colega de trabalho, passei a assumir menos compromissos burocráticos e voltar mais para a vida de DBA. A chegada de alguns discos SCSI para o servidor de testes também veio em boa hora…

Por fim, a comunidade do PostgreSQL parece que está aflorando no Brasil. Com uma presença marcante no FISL deste ano e um encontro no CONISLI, a comunidade começa a se articular melhor. E desta vez eu resolvi entrar na dança literalmente.

Primeiro coloquei algumas coisas minhas daqui do midstorm no site do PostgreSQL. Este ano fiz uma promessa de começar a escrever mais coisas técnicas e parar de ficar só no blá blá blá. Ainda não escrevi muita coisa. Mas gostei de algumas coisas, como o texto sobre schemas e traduzir algumas coisas.

O documento mais novo me deu um trabalhão. Foi a idéia de traduzir mais um texto do Power PostgreSQL, que é uma tabela com todos os parâmetros o arquivo postgresql.conf. Mas eu resolvi adicionar a comparação entre as versões 7.4, 8.0, 8.1 e 8.2, uma vez que o documento em questão só cobria a versão 8.0. Na tradução do Check List de performance, já fui cobrado na lista do PostgreSQL-Brasil para citar o auto-vacuum do 8.1. Isto deu um trabalho danado, e o resultado ficou por nada menos de 52 folhas de tamanho ofício.

Ainda quero escrever muitas coisas em breve que são na verdade áreas de estudo que pretendo fechar algumas dúvidas pessoais e testar algumas coisas:

• Terminar a segunda parte do artigo da SQL-Magazine sobre migração de Oracle para PostgreSQL
• Alguns testes de performance no meu AMD 64 comparando desempenho, consumo de disco e memória em 32 e em 64 bits.
• Alguns tests de performance alterando a separação de diferentes segmentos do SGDB em diferentes discos (SO, logs, tabelas e índices);
• Uma série sobre localização (datas, moeda, ordenação, busca fonética, encoding, character set, parâmetros lc, etc);
• Uma boa análise sobre a parte de logs;
• Um pequeno framework para algumas funções corriqueiras em Bancos de Dados.
• Testes com DBI-Link

Bem… tem coisa aqui para o final de 2006 e boa parte de 2007… e agora estou entrando definitivamente para a equipe de tradução do da documentação do PostgreSQL. Ontem o Euler Taveira me passou um primeiro arquivo para eu revisar e assim poder começar a ajudar o SGDB que tanto me ajudou!!!

Bem, espero que eu consiga dar conta de mais esta empreitada. Já vi pelo status da tradução que tem muito trabalho pela frente…

Há algum tempo eu já havia postado sobre o MSN aqui. Estes dias, lendo alguns feeds de notícia por aí encontrei esta pérola e resolvi testar. E fui eu entrar no orkut e encontrar a opção de integrar o Orkut com o Talk.

Aos poucos foram pipocando novos contatos na minha conta. Muito interessante. Com a febre do Orkut no Brasil, isto pode virar um bom motivo para mais gente usar o Jabber, mesmo que não saibam o que é Jabber!

Se por um lado o MSN deve perder um pouco da sua hegemonia, o Google vai escrevendo novas linhas em direção ao EPIC. Hum… acho que não estou muito otimista hoje. De toda forma é bacana voltar a encontrar as pessoas. Acho que vou poder sobreviver mais um bom tempo se usar o MSN.

Hoje começou o IV CONISLI em São Paulo. Cheguei no final da manhã após trombar com alguns amigos de Diadema na saída do metrô e rachar um taxi até o Anhembi.

Cheguei no credenciamento que estava um pouco bagunçado pois eles não tinham uma lista por órdem alfabética. Depois de insistir um pouco acabaram me deixando anotar o meu nome no crachá com pincel atômico. É um detalhe bizarro, mas insistem em colocar seu nome completo no crachá num evento de Software Livre. E todo evento em que isto ocorre as pessoas olham para os nomes nas etiquetas tentando imaginar quem seria a pessoa a sua frente. Realmente gostei de poder escrever meu nickname no crachá!

Logo na entrada encontre a Ariane Paola que está na organização. Radio na mão e zum, sumiu rapidamente. Logo na entrada encontrei o Fernando Ike e o André Lopes no Stand do Debian. Depois fui ver o pessoal da Celepar, PostgreSQL, Coletivo Digital, Serpro, Comprei alguns livros na Tempo Real e quase comprei um teclado dobrável que eles estão doando para o sorteio no BR-Linux. Mas acabei comprando 3 livros e achei que estava de bom tamanho. Visitei o stand de mais algumas empresas e vi mais algumas personalidades ligadas ao PSL-ABCD por lá, como o Rencka que estava com seu fã clube do Centro Público , e depois fui almoçar no restaurante do hotel do Anhembi. Encontrei o Corinto Meffe do Ministério do Planejamento por lá. Mais tarde encontrei o Dafid Fetter no Stand do PostgreSQL e conheci finalmente pessoalmente algumas personalidades da turma do elefante no Brasil: Leonardo Cézar, Rodrigo Hjort, Eduardo Mikos, Diogo Biazus, Euler Taveira, Alvaro Melo entre outros que não guardei o nome.

Depois fui acertar alguns retoques com o fike para a nossa palestra e quando vi já estava na hora da apresentação. A apresentação foi bem tranquila e espero não ter me enrolado muito. Depois assisti a palestra do pessoal da CELEPAR que como sempre me surpreendeu pela qualidade do trabalho que eles estão desenvolvendo por ali. Acho que todos ali ficaram babando no trabalho deles.

No geral achei que o CONISLI estava bom, com muita coisa interessante para se ver. Mas senti a falta de muita gente neste ano. Por um lado foi bom pois deu para conversar com mais tranquilidade. No entanto a ausência de muitas personalidades num evento do porte de um CONISLI me deixou um pouco preocupado. Espero que amanhã, no sábado o evento consiga atrair um público maior.

De toda forma eu adorei rever vários amigos e fazer novos. Especialmente a turma do PostgreSQL que tem se destacado em muitos eventos de SL no Brasil. Espero que consigamos organizar muita coisa boa para o ano que vem!