Oracle X PostgreSQL – Parte II: Vantagens do Oracle

Parte I – Semelhanças

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.