Após a publicação do resultado do Benckmark realizado pela Sun já comentado de passagem por aqui, comentários importantes se espalharam por aí. De olho no Blog do Sr. Josh Berkus, vi que ele publicou hoje comentários sobre o que foi publicado de notório sobre isso na Internet.

A primeira coisa interessante é notar o que a Information Week publicou sobre isso. Vale lembrar que o jornalista que escreveu o artigo não é um simpatizante do Software Livre. Aparentemente o pessoal do MySQL concordou graciosamente com a opinião do Josh, o que mostra que o pessoal que realmente entende disso no MySQL não fala mais bobagem sobre o assunto. É claro que estamos falando de um Benckmark focado em ambiente transacional, onde o uso do MyISAM é proibitivo. Vejamos como o MySQL vai se sair com o seu novo storage engine na próxima versão. Se eles conseguirem abandonar definitivamente o InnoDB (que pertence a Oracle, hoje) será realmente um feito notável e um grande avanço para os bancos de dados livres.

Já um blog sobre Oracle, questionou um pouco alguns resultados, mas de qualquer forma, isso não quer dizer que eles não sejam significativos. Seja como for… será interessante aguardar a disponibilização para download do Oracle 11g. Não postei nada sobre isso, por um motivo simples, a nova versão e sua documentação não estão disponíveis para download até a data deste post. De qualquer forma, o que vejo nas últimas versões do Oracle são grandes melhorias na parte de administração do Oracle e poucas melhorias na parte de performance. Já o PostgreSQL tem lançado uma versão por ano com um aumento de performance significativo. É claro que este aumento de performance a cada versão do PostgreSQL (e existem boas novidades previstas na versão 8.3) não poderão se manter neste ritmo por muitos anos, mas é esperado como certo que em alguns anos o PostgreSQL ultrapassará o Oracle, mantendo um TCO significativamente mais baixo.

Sem dúvida, teremos mais boas notícias em breve mostrando que as coisas mudam, e rapidamente!

Há algum tempo eu escrevi sobre a lei dos 80-20 por aqui. Mas após uma conversa com o Everaldo Canuto, fiquei com vontade de escrever novamente sobre isso. Existem dezenas de linguagens disponíveis e utilizadas com frequência. Algumas tem nichos específicos de mercado como LISP, LUA ou AWK. E várias outras concorrem por fatias semelhantes de mercado. Em Banco de Dados, as coisas mudam, existem poucos fornecedores de SGDB que se destacam no mercado. Além disso, existe uma vontade mais que justificada de centralizar todos os dados de uma instituição no mesmo banco de dados. Administrar um ambiente com vários SGDBs de fornecedores diferentes é uma grande dor de cabeça, embora isto quase sempre ocorra. Mesmo assim, usar a ferramenta adequada para cada problema parece algo que merece ponderação. Existem inúmeros projetos em que a escolha do SGDB utilizado sequer passa por uma verificação das características realmente desejadas. Vejamos algumas opções que podemos utilizar e nem sempre são citadas:

Arquivos texto

Quem disse que não dá para fazer um monte de coisas bacanas guardando as informações apenas em arquivos texto? Por trás da cortina, há uma infinidade de programas que guardam seus dados em arquivos texto. Em aplicações de desktop, monousuário com uma quantidade de dados pequena e pouco complexos, os arquivos texto podem ser muito vantajosos. Arquivos de configuração são um exemplo comum, mas aplicações que trabalham com um pequeno volume de dados e poucas tabelas podem utilizar arquivos texto com tranquilidade.

Vantagens:

• Tecnologia de domínio público
• Praticamente toda linguagem de programação possui funções embutidas para ler e gravar dados em arquivos texto
• Com um volume de até alguns milhares de linhas, o acesso pode ser bem mais rápido e simples que em um SGDB tradicional;
• Você pode utilizar formatos como XML, CVS e outros que podem ser importados e exportados por outros programas facilmente.
• Ocupa pouco espaço, é simples de realizar backup e consome poucos recursos da máquina.

Se você precisa usar uma quantidade maior de dados e quer o poder de uma linguagem SQL na mão, o SQLite pode ser a solução! Não é um SGDB, é uma biblioteca leve que você utiliza junto com o seu programa. Se você tem uma aplicação local como um site web com até 100 mil hits por dia, até 1GB de dados e poucas gravações concorrentes, o SQLite uma opção imbatível.

Vantagens:

• Licenciado como Domínio Público
• SQL e ACID
• Apenas um arquivo para todo o banco de dados
• Ocupa pouco espaço em disco (cerca de 250Kb)
• Consome poucos recursos da máquina

Você tem uma estrutura de dados mais rígida e está preocupado com velocidade, transações concorrentes, replicação e precisa fazer tudo isso com hardware limitado? O BDB é uma biblioteca assim como o SQLite, mas com características menos flexíveis e mais robustas. É excelente em aplicações embarcadas e uma opção natural para serviços de diretório e outras aplicações, Você não tem uma linguagem de consultas como o SQL, tudo tem de ser definido via programação, você tem liberdade de definir estruturas totalmente adaptadas para a sua aplicação. Se você pode abrir mão da flexibilidade do SQL e precisa de desempenho e robustez, o BDB é uma escolha imbatível.

Vantagens:

• Licença permite uso sem custos para aplicações com licenças livres ou para uso local
• ACID, controle de transações avançado com MVCC
• Replicação
• Consome poucos recursos com bom desempenho

Ok, você precisa de um SGDB com todas a flexibilidade do SQL, funções, gatilhos, ACID, índices avançados e suportar diferentes aplicações com confiabilidade e robustez. O PostgreSQL é provavelmente um bom candidato. O PostgreSQL tem crescido com muita força nos últimos 10 anos e já provou que é capaz de suportar aplicações pesadas com bom desempenho.

Vantagens:

• Licença BSD
• Excelente conformidade com o padrão SQL
• PL/pgSQL, PL/python, PL/Perl, PL/Ruby, PL/Java e outras linguagens procedurais
• Replicação com Slony, pgPool e Hot Stand By
• Particionamento de tabelas, MVCC, GiST, Tablespaces, Point In Time Recovery e outras funções avançadas

Há casos em que nenhuma destas soluções pode servir… em aplicações muito específicas, com grandes exigências de clusterização ou onde as demandas de integração com SGDBs já existentes são impressindíveis. Antes de pensar em sair comprando licenças da Oracle, DB2 ou Teradata, verifique quais são as suas reais necessidades. O fato é que muitas pessoas tem medo de adotar uma solução de um fornecedor que não gaste milhões de dólares em propaganda todos os anos. Antes de dizer que determinada solução não serve, teste e homologue. Mesmo no mundo lento e conservador dos bancos de dados as coisas mudam. Mudar pode significar uma implementação mais rápida, simples ou até um diferencial no mercado para o seu produto.

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.

Hoje, eu estava lendo um artigo do BR-Linux comentando que o criador do PHP recomendou o uso do MySQL ao invés do PostgreSQL para aumentar a velocidade das aplicações. Isto me lembrou de outro artigo postado do BR-Linux onde o autor compara o desempenho de diversas linguagens de programação.
Como fui adolescente há não muito tempo, ainda me lembro das intermináveis discussões sobre as qualidades do MSX e Apple II.

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } –>

O Software Livre traz consigo uma liberdade que para muitos é difícil de desfrutar. Bem, mas antes de mais nada eu gostaria de lembrar de algo mais agradável, que tem haver com a maioria dos bons programadores: o café e a cerveja!

Ambos possuíam fabricação caseira ou semi-industrial até alguns séculos atrás. Um bom café era chato de ser preparado e a cerveja depois de pouco tempo de fabricação azedava. Com o advento da pasteurização, surgiram as grandes cervejarias e com o advento do café solúvel, qualquer criança prepara um café em segundos. O problema disso é que a qualidade do café e da cerveja caiu drasticamente. Para atender a um processo de fabricação em larga escala, algumas coisas se perderam no caminho. Mais que isso, o processo de comercialização em larga escala exige que se tenha um produto com boa aceitação pela maioria dos consumidores. Assim, foram consagradas fórmulas medias capazes de satisfazer a maioria dos paladares em todo o mudo. Há poucas décadas, a liberdade de escolha está ressurgindo. Pequenas cafeterias e cervejarias estão ressurgindo, oferecendo diferentes tipos de café e cerveja de fabricação artesanal. Isto não significa que passaremos a consumir produtos artesanais ao invés de industrializados. Significa que existem sabores diferentes dos que estamos acostumados. Alguns podem ser muito interessantes, outros não. Alguns caem bem com determinados tipos de comida, ou combinam com um clima em particular. A indústria continuará oferecendo bom café e cerveja para a maioria das ocasiões. Haverá no entanto momentos em que outras opções podem ser mais interessantes. Certamente não se pretende que um substitua o outro.

Dizer que a linguagem A é melhor que B, ou comparar editores e SGDBs tem o mesmo efeito. Mesmo a solução de maior sucesso pode ser menos apropriada do que outra melhor adaptada para situações específicas. Já dei algumas palestras de PostgreSQL por aí e sempre mantive um excelente relacionamento com palestrantes sobre MySQL.

Sou obrigado a reconhecer que uso ambos. Aliás, eu diria que há projetos em que o SQLite é uma excelente opção. Em outros sou obrigado a dizer que ainda precisamos de algo do porte de um Oracle.

O mais importante afinal é que você possa escolher a cerveja que mais lhe agrade e se sentir satisfeito com ela. Se der sorte, pode descobrir outras muito interessantes que podem lhe apetecer em alguns momentos. No final, refinando seu paladar você só tem a ganhar.

“Álcool: A causa de, e a solução para, todos os problemas da vida.” —Homer Simpson