Parte I – Semelhanças

Parte II – Vantagens do Oracle

22 respostas

  1. 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).

  2. 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.

    1. 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.

      1. 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.

  3. Qual a solução de cluster tipo “RAC like” eu teria para PostgreSQL e quanto custaria isso em cifras $$$$$$$?

    1. 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

      1. 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

        1. 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.

          1. 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

  4. Ó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.

    1. 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.

  5. 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.

  6. 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.

Deixe uma resposta