Parte II – Vantagens do Oracle
- Suporte: Eu sei, a Oracle possui suporte. Mas como todo suporte de software proprietário, é um monopólio. Você não tem opção. Se quiser ter acesso ao patches de correção, tem que chamar a Oracle. Se quiser que alguém decifre o que tem nos arquivos de trace binários tem de chamar a Oracle, e por aí vai. Com o PostgreSQL você pode contratar qualquer empresa que possui em seu quadro de funcionários desenvolvedores que você provavelmente estará em terreno seguro. Você pode contratar a Timbira que possui ótimos desenvolvedores do PostgreSQL na sua equipe. Se não gostar da gente, contrate outra. É só entrar no site PostgreSQL e escolher uma. E se você acha que precisa ter alguém para processar quando der tudo errado, saiba que na licença de uso da Oracle ela não se responsabiliza por dados pelo seu uso. Se quiser, vai lá e tenta processar a Oracle, boa sorte.
- Custo: Não é apenas o custo da licença do Oracle que é alta, senhores. É todo o ecossistema: suporte, cursos, certificação e tudo o mais. Alguém tem que pagar os eventos, propaganda, projetos naufragados, “verbas de representação”, aquisições e outros custos que vão muito além do desenvolvimento do software em si. Certo dia recebemos um vendedor da Oracle que demonstrou para o cliente o Exatada. O hardware (ou “a lata” como eles diziam) custava apenas alguns minhões, mas as licenças do Oracle, muitos milhões! Só para lembrar, custo com treinamento e suporte você tem com qualquer um.
- Leveza: Você consegue rodar o PostgreSQL no seu vídeo-game, ou em alta plataforma. Você escolhe. Isso confere uma flexibilidade muito grande. Muita gente instala o PostgreSQL embarcado junto com a aplicação e o cliente mal sabe que existe um banco de dados lá. Você não vai ver pessoas usando o Oracle em appliances por exemplo.
- Simplicidade: As coisas podem ser simples e intuitivas. Você instala o PostgreSQL em qualquer máquina em segundos. Se quiser compilar e enfeitar um pouco, não leva mais do que 5 minutos. Criar uma base, renomear e operações assim são quase instantâneas. Muitas vezes testei uma nova funcionalidade sem sequer ler documentação. Simplesmente funciona do jeito que você imagina que deveria funcionar. Compare o uso do psql com o SQL*Plus, e você irá concordar comigo.
- Liberdade: A licença BSD é uma das licenças mais livres que existem. Você pode inclusive fechar o código do PostgreSQL, e muitas empresas de fato o fazem. Até a Oracle pode usar o código do postgres se desejar. Assim como o Windows e o MacOS usam código do FreeBSD. A única limitação é citar de onde o código original vem. No Oracle você tem uma licença de uso. Não é qualquer um que pode usar o Oracle e não é para qualquer coisa. Você não pode sequer publicar um teste de desempenho usando Oracle sem autorização prévia. Sério.
- Particionamento: Sim, o particionamento no PostgreSQL não é simples e tem vários problemas. Mas tem vantagens em relação ao Oracle também. No Oracle, se você precisar particionar uma tabela já existente, vai ter que reconstruir isso do zero. Isso significa abrir uma boa janela de manutenção para fazer isso. O PostgreSQL consegue particionar uma tabela com o sistema em pleno voo, aos poucos e de forma bem flexível. Outra questão é na hora de fazer um expurgo de uma partição com o DROP. No Oracle você tem que desabilitar as FKs apontadas para ela antes de fazer isso.
- PLs: Praticamente todo banco de dados tem uma Procedure Language embutida. O PostgreSQL, além do C, possui o PL/pgSQL, que é baseado no PL/SQL do Oracle. Mas a brincadeira vai muito além disso, você pode usar as linguagens mais comuns como PL/Python, PL/PHP, PL/Java, PL/Perl, PL/sh ou coisas mais específicas como PL/R, PL/LOL entre outros.
- Foreign Data Wraper: A habilidade de se comunicar com o universo nunca foi tão importante. Os grandes e pesados bancos de dados deixam pouco a pouco de ser o centro da aplicação. Outras bases entram em cena e a comunicação entre aplicações é regra hoje em dia. Claro que a Oracle possui o famoso Gateway, um das raras opções do Oracle que podem ser adquiridas para quem tem uma versão Standard do Oracle. Mas o FDW se mostra uma opção mais simples, robusta e flexível. A infraestrutura existente não só permite o PostgreSQL se comunicar com praticamente qualquer coisa, como também permite que em apenas poucas horas de trabalho em C, você crie um conector novo para uma situação diferente.
- Extensibilidade: O PostgreSQL possui vários níveis de extensibilidade: Você pode criar uma nova funcionalidade e mandar para a equipe de desenvolvimento e incluir esta nova funcionalidade no código do PostgreSQL. Assim, quando uma nova versão for lançada, seu código irá vir junto. É comum algumas empresas encomendarem o desenvolvimento de novas funcionalidades e elas depois fazerem do conjunto. Dependendo do caso, esta funcionalidade pode entrar como um módulo separado e opcional, mas ainda assim distribuído em separado na pasta contrib. Estas funcionalidades são conhecidas como extensões, assim como as extensões do seu navegador. Mas qualquer um pode criar uma nova extensão e publicar no PGXN, que é uma rede de extensões para o PostgreSQL que podem ser instaladas apenas com um comando “CREATE EXTENSION”. Este é um cenário simplesmente inimaginável no Oracle. Claro, só ecossistemas baseados em Software Livre conseguem este tipo de proeza. E o PostgreSQL tem realmente uma comunidade vibrante neste sentido.
- ISO SQL: Já foi-se o tempo em que eu confiava nas decisões tomadas pelo comitê do ISO que cria as norma. No entanto, ter um padrão ruim é sempre melhor que não ter nenhum. O PostgreSQL segue bem o padrão e prima por fazê-lo o tempo todo. O Oracle foge bem disso, embora algumas coisas tenham melhorado nos últimos tempos, não é cultura dos usuários do Oracle utilizar as opções que são padrão ISO.
- Tipos de dados: Isto é uma das coisas mais inexplicáveis da Oracle em minha opinião. Não possuir tipos de dados como INTEGER ou BOOLEAN. Os formatos de data são bem confusos. O campo do tipo DATE guarda data e hora. Não existe um tipo de dada TIME. O tipo INTERVAL se subdivide em dois subtipos YEAR TO MONTH e DAY TO SECOND. O PostgreSQL possui uma infinidade de tipos, inclusive alguns muito úteis como ENUM, ARRAYs, tipos de intervalo, geométricos, HSTORE, entre outros. A Oracle possui uma variedade maior de dados dentro do PL/SQL, mas para armazenar em tabelas e utilizar em SQL puro não. Daí você já vai vendo a confusão e as limitações que isso implica.
- DDL transacional: Todo comando DDL gera um COMMIT implícito no Oracle. Isto complica muito o deploy de novos objetos e algumas rotinas mais complexas. No postgres, qualquer CREATE, DROP ou ALTER é transacional e você pode fazer um ROLLBACK à qualquer momento.
Obrigado por compartilhar…ótimo texto 🙂
Como não conheço Oracle, achei péssimo principalmente dois tópicos que você sitou.. Tipos de dados(como assim não tem o boolean?) e DDL transacional(isso iria complicar e muito a minha vida).
Veja: http://docs.oracle.com/database/121/SQLRF/sql_elements001.htm#SQLRF30021 (Durante toda minha vida odiei esse negócio de DATE com TIME embutido, VARCHAR2 e outras questões, mas se você conversar com um DBA Oracle cheio de certificações ele manterá sua opinião de que é o melhor – e único – SGBDR do mundo)
Bom dia, a segunda parte http://savepoint.blog.br/oracle-x-postgresql-parte-ii-vantagens-do-oracle/ esta dando página não encontrada.
Deve ter sido alguma indisponibilidade aqui no nosso servidor. Agora parece que está abrindo normal.
E uma solução de Cluster para o PostgreSQL, tipo o RAC para Oracle… Isso você não comentou. O Oracle RAC é fantástico. Já fui evangelista de PostgreSQL no começo dos anos 2000. Mas as soluções de Cluster para PostgreSQL não são tão simples como gerenciar o Oracle RAC. E o Oracle é superior quando se trata de inserir Imagens/Docs/Planilhas/etc dentro do Banco.
Por que você armazenaria arquivos dentro do banco?
O sistema de arquivos não é melhor para isso?
Como você lidaria com cdn se os arquivos estão no banco?
Perguntas sinceras, sem trolling.
O motivo para armazenar arquivos dentro do banco de dados é por simplicidade e para garantir a unicidade da transação. Um rollback numa transação faria com que a gravação do arquivo fosse revertida junto. Este é um grande problema, pois garantir a sincronia entre o que foi gravado no sistema de arquivos e o que foi gravado no banco de dados exige um pouco mais de trabalho.
Sim o sistema de arquivos foi construído para gravar… arquivos!
Via de regra não é uma boa ideia guardar um grande volume de arquivos binários no banco de dados. Nem no PostgreSQL nem em nenhum outro RDBMS que eu conheço.
Comentei sobre o Parallel Query no post sobre vantagens do Oracle. Aqui a intenção é outra.
Qual a solução de cluster tipo “RAC like” eu teria para PostgreSQL e quanto custaria isso em cifras $$$$$$$?
Se você se refere à uma solução de cluster no estilo Shared All, como no RAC, não existe um equivalente. Sempre discuto sobre as reais vantagens do RAC, é uma discussão séria que poucos DBAs conseguem levar com coerência. Existem diversas soluções de alta disponibilidade, replicação e clusterização. Há uma tabela com várias soluções existentes em http://www.postgresql.org/docs/current/static/different-replication-solutions.html .
Um cluster tradicional no estilho Shared Nothing pode ser implementado com o PL/Proxy ou utilizando o Postgres-XC: http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki
Telles,
excelente texto e parabéns, mas faria uma única ressalva
quanto ao particionamento.
O Oracle possui sim através da dbms_redefinition a opção de redefinir a tabela particionada online.
Enquanto o PG não direcionar o Select automaticamente para a correta partição quando a chave da mesma se encontra na cláusula WHERE, considerarei o mesmo inferior ao Oracle neste quesito.
Abraços
Sim, o PostgreSQL redireciona o SELECT automaticamente para a partição correta se houver a mesma chave na cláusula WHERE, isso é um princípio básico e sempre funcionou bem.
Perfeito, eu tenho de usar o extract da data com a mesma chave da partição.
O que eu quis dizer é que no Oracle o simples uso do between dentro de um mesmo mês por exemplo já iria direto para a particão mensal da tabela sem a necessidade de alteração no SQL do aplicativo.
Abraços.
ex.
between ’01-01-2015′ and ’10-01-2015′
Oracle Leitura Partição Mensal
PG Leitura FULL da tabela Pai ou Índice
Ótima série de artigos, apreciei bastante as observações realizadas.
Apenas um detalhe insignificante:
No tópico “Extensibilidade”, a primeira frase lê-se: O Oracle possui vários níveis de extensibilidade. Pelo contexto conclui-se rapidamente que não se trata do Oracle e sim do PostgreSQL.
Obrigado, já corrigi aqui.
Obrigado. Eu gostaria de implementar uma solução tipo RAC para PostgreSQL. Vi essa:
http://www.enterprisedb.com/services/packaged-services/high-availability
Que acredito que tenha um custo. Mas quanto ao custo não vejo problema. Você conhece essa ou conhece alguém que usa? Obrigado novamente.
A solução de alta disponibilidade apresentada pela EDB é antiga e conhecida. Trata-se de um cluster Ativo – Passivo onde o banco fica no ar em um nó e se houver algum problema você desliga o servidor ativo e monta os discos no servidor passivo e liga o banco. Já utilizei com Oracle também. Nunca gostei desta solução, sinceramente não acho boa.
Se você quer uma solução de alta disponibilidade, lembre-se que o RAC não é uma boa opção. Se houver uma corrupção no dados ou uma falha no storage, você fica completamente na mão. E adivinha qual parte é mais sensível num banco de dados? Ah… você acha que ASM não dá problema? Que storage não quebra?
Um standby é uma solução muito mais confiável quando o assunto é alta disponibilidade. O PostgreSQL tem uma solução muito robusta para standby com replicação via log shipping ou streaming, síncrona ou assíncrona, Hot ou Warm, com cascateamento, backup no standby, etc.
A versão 9.4 do PostgreSQL já saiu com a infraestrutura para um novo esquema de replicação que inclui funcionalidades avançadas como o Parallel Query. Vale à pena esperar a versão 9.5 que deve vir com isso já implementado. Mas veja essa tara toda pelo RAC nem sempre se justifica, já tive muitos problemas com ele, particularmente em ambientes OLTP. Em alguns casos a performance só melhorou quando finalmente consegui convencer o cliente a desligar o RAC.
trabalho para uma empresa que usa Oracle e Postgres, ja chegaramos a ter 424 lojas alimentados ambas as tabelas, e te falo, o oracle é pago, tem suporte e tudo mais, em 8 anos ja deixou a gente na mão mais de 5 vezes, o postgres nunca gargalou e nunca deu pau nem em um indice que seja, em um hardware infinitamente inferior.