Parte III – Vantagens do PostgreSQL
Comparar dois produtos com longa história e com comunidades vibrantes é sempre complicado. Quando publiquei minha comparação entre Oracle e PostgreSQL em 2007, muitos comentários de pessoas que não conheciam Oracle ou PostgreSQL surgiram. Uns dizendo que o Oracle não fazia isso ou aquilo e na verdade faz e o inverso também. Por isso me dei ao trabalho de falar sobre as semelhanças primeiro.
O que eu achei interessante relendo os artigos de 2007 é que a lista de hoje deverá se renovar bastante, pois muitas coisas que eu sentia falta naquele tempo foram implementadas no PostgreSQL e outras eu não considero mais tão importantes atualmente. Então teremos uma lista bem diferente agora, vamos à ela:
- Parallel Query: O Oracle RAC é uma tecnologia que avançou muito nos últimos anos mas realmente está longe de ser uma solução definitiva para performance ou alta disponibilidade. Não garante performance quando o gargalo é I/O, que é o maior problema dos bancos de dados, particularmente escrita em I/O. Bons discos flash ajudam muito mais. Não resolvem o problema de alta disponibilidade se seus discos corromperem, um standby resolve melhor essa questão. Mas se você tem um Datawarehouse ou consultas monstruosas em tabelas gigantes, a possibilidade de quebrar uma única consulta em vários processos é uma boa. A Oracle faz isso há muito tempo e faz bem. O PostgreSQL lançou recentemente a versão 9.4 com a infraestrutura para fazer a mesma coisa. É esperado que na próxima versão essa funcionalidade esteja presente. Eu diria que em 2 anos isto deverá estar maduro no postgres.
- Multitenant Architecture: Já faz muito tempo que o PostgreSQL trabalha com várias bases sob o mesmo cluster, dividindo um catálogo global, processos, etc. Também sempre foi uma questão de segundos criar uma nova base. Mas de fato, se você tem varias bases num cluster, migrar apenas uma base para um outro servidor é isso uma tarefa um pouco complexa. A versão 12c da Oracle tem se esforçado tornar este tipo de tarefa mais simples e tornar a convivência na nuvem mais simples.
- Exadata: Mesmo antes da Oracle comprar a Sun, já havia sido lançada a primeira versão do Exadata. O Exadata, além de ser uma forma de empacotar hardware, sistema operacional e banco de dados numa caixa preta, é possui também algumas integrações entre storage em banco de dados muito interessantes que aceleram muito algumas operações. Este nível casamento entre hardware e software provavelmente não será visto no PostgreSQL tão cedo.
- Ferramentas gráficas: O Enterprise Manager até a versão 10g era um problema. Muitas vezes o maior ofensor da base era justamente ele. Mas parece que aos poucos foram melhorando ele. Ainda acho ele bem pesado, mas é uma ferramenta que permite uma visão rápida sobre muitos aspectos do Oracle. O PostgreSQL não possui nenhuma ferramenta gráfica nativa, mas possui alguns projetos livres, notadamente o PGAdmin3 e o PGphpadmin. Assim como no caso do Oracle, algumas das melhores ferramentas são pagas.
- Assistentes de performance: Para um DBA júnior, os assistentes realmente são uma mão na roda e apontam problemas críticos sem muito esforço. Claro que existem erros e um DBA experiente deve saber quando não confiar nesse tipo de coisa, mas de fato ajuda muito numa avaliação inicial.
- Particionamento: O particionamento de tabelas continua sendo um ponto forte do Oracle. Possui inúmeras funcionalidades avançadas e é bem robusto. Já escrevi extensivamente sobre particionamento no PostgreSQL aqui. Muita coisa foi melhorando no PostgreSQL nas últimas versões, mas ainda está longe do Oracle.
- Flashback Query: Levanta a mão quem nunca quis saber o que tinha numa tabela antes de rodarem um UPDATE desastroso… Voltar a base toda para trás no tempo com um Point In Time Recovery pode não ser a melhor solução. O Flashback já me ajudou algumas vezes nesses casos, funciona bem e é bem simples de usar. Só não pode demorar demais, senão os dados somem do UNDO.
- Transações dentro de um PL: Isso é uma coisa que me chateia ainda em alguns momentos. Eu sei que pode não ser elegante dar um COMMIT ou ROLLBACK dentro de um PL. Eu sei que trabalhando bem com EXCEPTIONs muito desse problema pode ser minimizado, mas se eu quero criar um processo em lote com milhões de transações, eu quero poder dar um COMMIT de x em x registros processados e tenho que construir uma aplicação externa só para isso. Acho que isso o PostgreSQL nunca vai mexer. Só não confundam isso com a aberração do Autonomous Transaction, que é algo que a Oracle jamais deveria ter inventado.
- Recovery Manager (RMAN): Eu realmente não iria colocar este item aqui, mas sei que vai aparecer nos comentários depois, então vou me adiantar logo. O RMAN é um item obrigatório para quem usa ASM, que é uma forma de RAW Devices mais sofisticada da Oracle. Eu realmente não sou fã de forma alguma do ASM, nem do RMAN. Gosto de ver meus datafiles no sistema de arquivos e poder lidar diretamente com eles. Engana-se quem acha que com RMAN e ASM coisas ruins não vão acontecer. Vão sim e eu tenho boas histórias de terror para contar. O ganho de performance de 5% a 20% não justifica para mim perder completamente o controle da base. Claro que para quem usa RAC, o ASM se tornou praticamente obrigatório. Veja que o PostgreSQL tem uma arquitetura completamente diferente da Oracle em relação aos seus datafiles, que é muito mais simples e eficiente. Isso significa que varias limitações do Oracle em relação à sua arquitetura simplesmente não existem no PostgreSQL. Para quem bradar pela falta do backup incrementar no PostgreSQL, saiba que o clone do RMAN, o pg_rman, já existe faz tempo. Mas assim como o backup incremental, conheço poucas pessoas realmente usam o pg_rman. Mas quem faz backup utilizando o rsync no PostgreSQL sabe que a vida pode ser muito mais simples. E você pode utilizar o pg_basebackup que é bem simples e funciona de forma bem tranquila. O que não existe é uma integração nativa com ferramentas de backup em fita. Isto realmente falta. E por último, vale lembrar que quem faz backup de bases com vários terabytes sem snapshot via storage, perdeu o bonde da história.
O oracle tem certificação.. acho que falta isso no postgresql.
Lucas, certificação é um tema para lá de polêmico. Apesar de ajudar em licitações de órgãos públicos, as certificações em geral são mais um pedaço de papel, como são as licenças de uso de software. Mais uma forma de se ganhar dinheiro. O fato de alguém de uma certificação OCP da Oracle não garante de forma alguma que ele seja um bom DBA. Ao contratar um DBA prefiro conhecer e testar o que ele sabe fazer, e não as certificações que ele possui.
O conhecimento vem antes de um diploma, a certificação talvez se encaixa como um adicional, mas você tem razão.. ter uma certificação as vezes não quer dizer nada.
Conhecimento não vem com certificação ou diploma.
De qualquer forma, existe certificação Postgresql.
Existe a certificação da EnterpriseDB, mas não uma certificação oficial endossada pelos desenvolvedores do PostgreSQL. Existem algumas outras menos conhecidas, também não endossadas. É um discussão antiga. É provável que nunca venha a existir uma certificação oficial do PostgreSQL. Pelo menos eu não contaria com isso.
Telles,
antes de tudo parabéns pelo artigo!
Quanto ao exadata, seria justo comentar dessa alternativa[1] da fujitsu?
[1] http://www.fujitsu.com/global/about/resources/news/press-releases/2014/0228-02.html
Telles, primeiramente parabéns pelo artigo.
Com relação ao COMMIT dentro de PL, não ficou claro, não deu pra entender a sua experiência.
Pessoalmente, eu também não vejo como positivo COMMIT / ROLLBACK. Para o rollback ainda temos um contorno, que seria o uso de SAVEPOINTS, mas acho que você não era sobre isso que se referiu.
Não há nenhum impedimento para usar esses comandos dentro do seu PL. Se os programas estão bem estruturados, para atender à uma situação específica em que eles realmente sejam necessários, via de regra isso não é problema algum. O que não pode, é colocar isso em camadas onde um programador menos familiarizado com o sistema poderá invocar inadvertidamente sem conhecer o seu resultado.
Eu tenho 22 anos de TI, e já “xinguei” muito coisas assim, mas com o amadurecimento, percebi que na grande maioria das vezes a culpa não está nos comandos, e sim na forma como orquestramos os mesmos dentro da aplicação.
E nisso, pego um gancho para o Autonomous Transaction. Pra mim, uma das melhores coisas que a Oracle já fez, tenho rotinas de LOGs em tabela que não existiriam se não houvesse este recurso. Como você faria pra gravar um log direto no banco sem ter que armar uma extensa parafernalha para tratar esse log posterior à uma exception com rollback por exemplo ? Não é impossível, mas convenhamos, dá um trabalho do cão.
Abraços
Edson Gonçalez
Duas atualizações importantes:
– O PostgreSQL 10 reescreveu completamente a parte de particionamento e fez do jeito certo. O Oracle ainda tem algumas funcionalidades avançadas em particionamento muito interessantes, mas deixou de ser uma grande vantagem em relação ao PostgreSQL;
– O Parallel Query foi lançado no PostgreSQL 9.6 e melhorou muito no 10. Continua não existindo nem deverá existir algo como um cluster shared all no estilo do Oracle RAC. Mas fazer uma consulta quebrar em vários processos independentes já é uma realidade e funciona muito bem. Claro que você pode combinar o sharding com FDW (Foreign Data Wrapper), Particionamento e o Parallel Query para quebrar consultas enormes e distribuir a carga em vários servidores. Mas aí estamos falando de cluster shared nothing, que é diferente do RAC.