Dez principais razões para migrar do Oracle para o PostgreSQL

O Oracle Relational Database Management System (RDBMS) tem sido amplamente utilizado por grandes organizações e é considerado, de longe, a tecnologia de banco de dados mais avançada disponível no mercado. Normalmente, é o RDBMS mais frequentemente comparado com outros produtos de banco de dados, servindo como o padrão “de fato” do que um produto deve oferecer. Ele é classificado pela db-engines.com como o RDBMS nº 1 disponível no mercado hoje.

O PostgreSQL é classificado como o 4º RDBMS, mas isso não significa que não haja vantagens em migrar para o  PostgreSQL. O PostgreSQL existe desde 1989, com código aberto em 1996. O PostgreSQL ganhou o DBMS do ano em dois anos consecutivos de 2017 e 2018. Isso apenas indica que não há sinais de parar de atrair um grande número de usuários e grandes organizações.

Uma das razões pelas quais o PostgreSQL atraiu muita atenção é porque as pessoas estão procurando uma alternativa ao Oracle para que possam cortar os altos custos das organizações e escapar do aprisionamento de fornecedores.

Mudar de um Oracle Database funcional e produtivo pode ser uma tarefa assustadora. Preocupações como o TCO (Total Cost of Ownership) da empresa é uma das razões pelas quais as empresas arrastam sua decisão de abandonar ou não a Oracle.

Neste blog, veremos alguns dos principais motivos pelos quais as empresas estão optando por deixar a Oracle e migrar para o PostgreSQL.

Primeiro motivo:é um verdadeiro projeto de código aberto

O PostgreSQL é de código aberto e é lançado sob a Licença PostgreSQL, uma licença liberal de código aberto, semelhante às licenças BSD ou MIT. A aquisição do produto e do suporte não requer taxa.

Se você quiser aproveitar o software de banco de dados, isso significa que você pode obter todos os recursos disponíveis do banco de dados PostgreSQL gratuitamente. O PostgreSQL tem mais de 30 anos de maturidade no mundo do banco de dados e tem sido baseado em toque como código aberto desde 1996. Ele desfrutou de décadas de desenvolvedores trabalhando para criar extensões. Isso, por si só, faz com que desenvolvedores, instituições e organizações escolham o PostgreSQL para aplicativos corporativos; impulsionando os principais aplicativos de negócios e móveis.

Mais uma vez, as organizações estão despertando para a percepção de que soluções de banco de dados de código aberto, como o Postgres, oferecem maior capacidade, flexibilidade e suporte que não dependem inteiramente de nenhuma empresa ou desenvolvedor. O Postgres, como o Linux antes dele, foi (e continua sendo) projetado por usuários dedicados que resolvem problemas de negócios do dia-a-dia que optam por devolver suas soluções à comunidade. Ao contrário de um grande desenvolvedor como a Oracle, que pode ter motivos diferentes para desenvolver produtos que são lucrativos ou suportam um mercado restrito, mas lucrativo, a comunidade Postgres está empenhada em desenvolver as melhores ferramentas possíveis para usuários de banco de dados relacionais diários.

O PostgreSQL geralmente executa essas tarefas sem adicionar muita complexidade. Seu design é focado estritamente no manuseio do banco de dados sem ter que desperdiçar recursos, como gerenciar ambientes de TI adicionais por meio de recursos adicionais. É uma das coisas que os consumidores deste software de código aberto gostam ao migrar do Oracle para o PostgreSQL. Gastar horas para estudar tecnologia complexa sobre como funciona um banco de dados Oracle ou como otimizar e ajustar pode acabar com seu suporte caro. Isso atrai instituições ou organizações para encontrar uma alternativa que pode ser menos dor de cabeça no custo e traz lucro e produtividade. Confira nosso blog anterior sobre como o PostgreSQL é capaz de combinar a presença da sintaxe SQL com a sintaxe do Oracle.

Motivo dois:sem licença e uma grande comunidade

Para usuários da plataforma Oracle RDBMS, é difícil encontrar qualquer tipo de suporte da comunidade que seja gratuito ou sem uma taxa alta. Instituições, organizações e desenvolvedores muitas vezes acabam encontrando uma alternativa de informação online que pode oferecer respostas ou soluções para seus problemas de forma gratuita.

Ao usar o Oracle, é difícil decidir sobre um produto específico ou optar pelo Suporte ao Produto porque (normalmente) há muito dinheiro envolvido. Você pode experimentar um produto específico para testá-lo, acabar comprando, apenas para perceber que não pode ajudá-lo. Com o PostgreSQL, a comunidade é gratuita e está repleta de especialistas com vasta experiência que ficarão felizes em ajudá-lo com seus problemas atuais.

Você pode se inscrever na lista de discussão aqui em https://lists.postgresql.org/ para começar a entrar em contato com a comunidade. Novatos ou prodígios do PostgreSQL tocam aqui para comunicar, mostrar e compartilhar suas soluções, tecnologia, bugs, novas descobertas ou até mesmo compartilhar seus softwares emergentes. Você pode até pedir ajuda no chat do IRC usando irc.freenode.net e juntando-se ao canal #postgresql. Você também pode entrar em contato com a comunidade pelo Slack entrando em https://postgres-slack.herokuapp.com/ ou https://postgresteam.slack.com/. Há muitas opções a serem tomadas e muitas organizações de código aberto que podem oferecer perguntas

Para mais detalhes e informações sobre por onde começar, confira aqui https://www.postgresql.org/community/.

Se você quiser fazer check-out dos Serviços Profissionais no PostgreSQL, há várias opções para escolher. Mesmo verificando o site deles em https://www.postgresql.org/support/professional_support/northamerica/, você pode encontrar uma grande lista de empresas lá e algumas delas estão a um preço barato. Mesmo aqui na Multiplenines, também oferecemos suporte para Postgres, que faz parte da licença ClusterControl ou uma consultoria de DBA.

Motivo três:  amplo suporte para conformidade com SQL

O PostgreSQL sempre quis se adaptar e se adequar ao SQL como um padrão de fato para sua linguagem. O nome formal do padrão SQL é ISO/IEC 9075 “Database Language SQL”. Quaisquer versões revisadas sucessivas das versões padrão substituem a anterior, portanto, reivindicações de conformidade com versões anteriores não têm mérito oficial.

Ao contrário do Oracle, algumas palavras-chave ou operadores ainda estão presentes que não estão em conformidade com o padrão ANSI SQL (Structured Query Language). Exemplo, o operador OUTER JOIN (+) pode atribuir confusões com outros DBA's que não tocaram ou com a menor familiaridade com Oracle. O PostgreSQL segue o padrão ANSI-SQL para a sintaxe JOIN e isso deixa uma vantagem para pular fácil e simplesmente com outros bancos de dados RDBMS de código aberto, como bancos de dados MySQL/Percona/MariaDB.

Outra sintaxe muito comum no Oracle é o uso de consultas hierárquicas. O Oracle usa a sintaxe START WITH..CONNECT BY não padrão, enquanto no SQL:1999, as consultas hierárquicas são implementadas por meio de expressões de tabela comuns recursivas. Por exemplo, as consultas abaixo diferem sua sintaxe de acordo com as consultas hierárquicas:

Oráculo

SELECT

    restaurant_name, 

    city_name 

FROM

    restaurants rs 

START WITH rs.city_name = 'TOKYO'

CONNECT BY PRIOR rs.restaurant_name = rs.city_name;

PostgreSQL

WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name

                                 FROM restaurants

                                WHERE city_name = 'TOKYO'

                                UNION

                               SELECT m.restaurant_name, m.city_name

                                 FROM restaurants m

                                 JOIN tmp ON tmp.restaurant_name = m.city_name)

                  SELECT restaurant_name, city_name FROM tmp;

O PostgreSQL tem uma abordagem muito semelhante aos outros RDBMS de código aberto como MySQL/MariaDB.

De acordo com o manual do PostgreSQL, o desenvolvimento do PostgreSQL visa a conformidade com a versão oficial mais recente do padrão, onde tal conformidade não contradiz as características tradicionais ou o senso comum. Muitos dos recursos exigidos pelo padrão SQL são suportados, embora às vezes com sintaxe ou função ligeiramente diferentes. Isso é, de fato, o que há de ótimo no PostgreSQL, pois também é suportado e colaborado por diferentes organizações, sejam elas pequenas ou grandes. A beleza permanece em sua conformidade de linguagem SQL com o que tem o push-through padrão.

O desenvolvimento do PostgreSQL visa a conformidade com a versão oficial mais recente do padrão, onde tal conformidade não contradiz as características tradicionais ou o senso comum. Muitos dos recursos exigidos pelo padrão SQL são suportados, embora às vezes com sintaxe ou função ligeiramente diferentes. Movimentos adicionais em direção à conformidade podem ser esperados ao longo do tempo.

Motivo quatro:paralelismo de consulta

Para ser justo, o Query Parallelism do PostgreSQL não é tão rico quando comparado à execução paralela do Oracle para instruções SQL. Entre os recursos do paralelismo da Oracle estão o enfileiramento de instruções com dicas, capacidade de definir o grau de paralelismo (DOP), definir uma política de grau paralelo ou paralelismo adaptativo.

O PostgreSQL tem um grau simples de paralelismo baseado nos planos suportados, mas isso não define que o Oracle se sobreponha ao PostgreSQL de código aberto.

O paralelismo do PostgreSQL tem sido constantemente aprimorado e aprimorado continuamente pela comunidade. Quando o PostgreSQL 10 foi lançado, ele adicionou mais apelo ao público, especialmente as melhorias no suporte ao paralelismo para merge join, bitmap heap scan, index scan e index-only scan, reunir merge, etc. As melhorias também adicionam estatísticas ao pg_stat_activity.

Nas versões do PostgreSQL <10, o paralelismo está desabilitado por padrão e você precisa definir a variável max_parallel_workers_per_gather.

postgres=# \timing

Timing is on.

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                   QUERY PLAN                                                   

----------------------------------------------------------------------------------------------------------------

 Seq Scan on movies  (cost=0.00..215677.28 rows=41630 width=68) (actual time=0.013..522.520 rows=84473 loops=1)

   Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

   Rows Removed by Filter: 8241546

 Planning time: 0.039 ms

 Execution time: 525.195 ms

(5 rows)



Time: 525.582 ms

postgres=# \o /dev/null 

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 596.947 ms

O plano de consulta revela que o tempo real pode ir em torno de 522,5 ms, então o tempo real de execução da consulta é de cerca de 596,95 ms. Ao permitir o paralelismo,

postgres=# set max_parallel_workers_per_gather=2;

Time: 0.247 ms

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                          QUERY PLAN                                                           

-------------------------------------------------------------------------------------------------------------------------------

 Gather  (cost=1000.00..147987.62 rows=41630 width=68) (actual time=0.172..339.258 rows=84473 loops=1)

   Workers Planned: 2

   Workers Launched: 2

   ->  Parallel Seq Scan on movies  (cost=0.00..142824.62 rows=17346 width=68) (actual time=0.029..264.980 rows=28158 loops=3)

         Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

         Rows Removed by Filter: 2747182

 Planning time: 0.096 ms

 Execution time: 342.735 ms

(8 rows)



Time: 343.142 ms

postgres=# \o /dev/null

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 346.020 ms

O plano de consulta determina que a consulta precisa usar paralelismo e, em seguida, usa um nó Gather. O tempo real é estimado em 339ms com 2 trabalhos e estimado em 264ms antes de ser agregado pelo plano de consulta. Agora, o tempo real de execução da consulta levou 346ms, o que é muito próximo do tempo real estimado do plano de consulta.

Isto apenas ilustra o quão rápido e benéfico é com o PostgreSQL. Embora o PostgreSQL tenha seus próprios limites quando o paralelismo pode ocorrer ou quando o plano de consulta determina que é mais rápido do que usar o paralelismo, ele não faz com que seu recurso seja uma grande diferença em relação ao Oracle. O paralelismo do PostgreSQL é flexível e pode ser ativado ou utilizado corretamente desde que sua consulta corresponda à sequência necessária para o paralelismo de consulta.

Motivo cinco:suporte avançado a JSON e está sempre melhorando

O suporte a JSON no PostgreSQL está sempre no mesmo nível em comparação com outros RDBMS de código aberto. Dê uma olhada neste blog externo do LiveJournal onde o suporte JSON do PostgreSQL se revela sempre mais avançado quando comparado aos outros RDBMS. O PostgreSQL possui um grande número de funções e recursos JSON.

O tipo de dados JSON foi introduzido no PostgreSQL-9.2. Desde então, ele tem muitos aprimoramentos significativos e, entre as principais adições, surgiu o PostgreSQL-9.4 com a adição do tipo de dados JSONB. O PostgreSQL oferece dois tipos de dados para armazenar dados JSON:json e jsonb. Com jsonb, é uma versão avançada do tipo de dados JSON que armazena os dados JSON em formato binário. Este é o principal aprimoramento que fez uma grande diferença na maneira como os dados JSON eram pesquisados ​​e processados ​​no PostgreSQL.

O Oracle também oferece amplo suporte a JSON. Em contraste, o PostgreSQL tem amplo suporte, bem como funções que podem ser usadas para recuperação de dados, formatação de dados ou operações condicionais que afetam a saída dos dados ou mesmo os dados armazenados no banco de dados. Os dados armazenados com o tipo de dados jsonb têm uma vantagem maior com a capacidade de usar GIN (Generalized Inverted Index), que pode ser usado para pesquisar com eficiência chaves ou pares chave/valor que ocorrem em um grande número de documentos jsonb.

O PostgreSQL tem extensões adicionais que são úteis para implementar TRANSFORM FOR TYPE para o tipo jsonb em suas linguagens de procedimento suportadas. Essas extensões são jsonb_plperl e jsonb_plperlu para PL/Perl. Considerando que para PL/Python, estes são jsonb_plpythonu, jsonb_plpython2u e jsonb_plpython3u. Por exemplo, usando valores jsonb para mapear arrays Perl, você pode usar as extensões jsonb_plperl ou jsonb_plperlu.

ArangoDB postou um benchmark comparando o desempenho JSON do PostgreSQL junto com outros bancos de dados com suporte a JSON. Embora seja um blog antigo, ainda mostra como o JSON do PostgreSQL se comporta em comparação com outros bancos de dados onde o JSON é o recurso principal em seu kernel de banco de dados. Isso só faz com que o PostgreSQL tenha sua própria vantagem, mesmo com seu recurso paralelo.

Razão Seis:Suporte a DBaaS pelos principais fornecedores de nuvem

O PostgreSQL tem sido amplamente suportado como DBaaS. Esses serviços são provenientes da Amazon, da Microsoft com seu Banco de Dados Azure para PostgreSQL e do Cloud SQL do Google para PostgreSQL.

Em comparação, Oracle, está disponível apenas no Amazon RDS for Oracle. Os serviços oferecidos pelos principais players começam a um preço acessível e são muito flexíveis para configurar de acordo com suas necessidades. Isso ajuda as instituições e organizações a se configurarem adequadamente e a aliviarem seu grande custo atrelado à plataforma Oracle.

Sete Razão:  Melhor gerenciamento de grandes quantidades de dados

O PostgreSQL RDBMS não foi projetado para lidar com cargas de trabalho analíticas e de armazenamento de dados. O PostgreSQL é um banco de dados orientado a linhas, mas tem a capacidade de armazenar uma grande quantidade de dados. O PostgreSQL tem os seguintes limites para lidar com armazenamento de dados:

Se você quiser usar os recursos principais do PostgreSQL, poderá armazenar uma grande quantidade de dados usando jsonb. Por exemplo, uma grande quantidade de documentos (PDF, Word, Planilhas) e armazená-los usando o tipo de dados jsonb. Para aplicativos e sistemas de geolocalização, você pode usar o PostGIS.

Motivo Oito:Escalabilidade, Alta Disponibilidade, Redundância/Geo-Redundância e Soluções Tolerantes a Falhas a Baixo Custo

A Oracle oferece soluções semelhantes, mas poderosas, como Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware e Oracle Data Guard, para citar alguns. Essas tecnologias podem aumentar seus custos crescentes e são imprevisivelmente caras para implantar e tornar estáveis. É difícil abandonar essas soluções. O treinamento e as habilidades devem ser aprimorados e desenvolver as pessoas envolvidas no processo de implantação e implementação.

PostgreSQL tem suporte massivo e tem muitas opções para escolher. O PostgreSQL inclui streaming e replicação lógica integrados ao pacote principal do software. Você também pode configurar uma replicação síncrona para o PostgreSQL ter mais clusters de alta disponibilidade, enquanto faz um nó stand by processar suas consultas de leitura. Para alta disponibilidade, sugerimos que você leia nosso blog Top PG Clustering High Availability (HA) Solutions for PostgreSQL, que abrange muitas ferramentas e tecnologias excelentes para você escolher.

Também existem recursos empresariais que oferecem soluções de alta disponibilidade, monitoramento e backup. O ClusterControl é uma dessas tecnologias e oferece um preço acessível em comparação com as Soluções Oracle.

Motivo nove:  Suporte para várias linguagens de procedimento:PL/pgSQL, PL/Tcl, PL/Perl e PL/Python.

Desde a versão 9.4, o PostgreSQL possui um ótimo recurso onde você pode definir uma nova linguagem procedural de acordo com sua escolha. Embora nem todas as variedades de linguagens de programação sejam suportadas, mas existem várias linguagens que são suportadas. Atualmente, com distribuição base, inclui PL/pgSQL, PL/Tcl, PL/Perl e PL/Python. Os idiomas externos são:

A grande vantagem disso é que, diferentemente da Oracle, os desenvolvedores que migraram recentemente para o PostgreSQL podem fornecer rapidamente lógica de negócios para seus sistemas de aplicativos sem perder tempo aprendendo sobre PL/SQL. O PostgreSQL torna o ambiente para desenvolvedores mais fácil e eficiente. Essa natureza do PostgreSQL contribui para a razão pela qual os desenvolvedores adoram o PostgreSQL e começam a mudar as soluções de plataforma corporativa para o ambiente de código aberto.

Razão dez:  índices flexíveis para dados grandes e textuais (GIN, GiST, SP-GiST e BRIN)

O PostgreSQL tem uma grande vantagem no que diz respeito ao suporte de índices que são benéficos para lidar com grandes volumes de dados. O Oracle tem muitos tipos de índice que também são benéficos para lidar com grandes conjuntos de dados, especialmente para indexação de texto completo. Mas para o PostgreSQL, esses tipos de índices são feitos para serem flexíveis de acordo com o seu propósito. Por exemplo, esses tipos de índices são aplicáveis ​​para dados grandes:

GIN - (índices invertidos generalizados) 

Este tipo de índice é aplicável para colunas de tipo de dados jsonb, hstore, range e arrays. É útil quando você tem tipos de dados que contêm vários valores em uma única coluna. De acordo com a documentação do PostgreSQL, “o GIN foi projetado para lidar com casos em que os itens a serem indexados são valores compostos, e as consultas a serem tratadas pelo índice precisam procurar por valores de elementos que aparecem nos itens compostos. Por exemplo, os itens podem ser documentos e as consultas podem ser pesquisas de documentos que contenham palavras específicas.”

GiST - (Árvore de pesquisa generalizada)

Uma árvore de pesquisa com altura balanceada que consiste em páginas de nó. Os nós consistem em linhas de índice. Cada linha de um nó folha (linha folha), em geral, contém algum predicado (expressão booleana) e uma referência a uma linha da tabela (TID). Índices GiST são melhores se você usar isso para tipos de dados geométricos, como, você quer ver se dois polígonos continham algum ponto. Em um caso, um ponto específico pode estar contido dentro de uma caixa, enquanto outro ponto só existe dentro de um polígono. Os tipos de dados mais comuns em que você deseja aproveitar os índices GiST são tipos de geometria e texto ao lidar com pesquisa de texto completo

Ao escolher qual tipo de índice usar, GiST ou GIN, considere estas diferenças de desempenho:

• As pesquisas de índice GIN são cerca de três vezes mais rápidas que o GiST
• Os índices GIN demoram cerca de três vezes mais para serem construídos do que o GiST
• Os índices GIN são moderadamente mais lentos para atualizar do que os índices GiST, mas cerca de 10 vezes mais lentos se o suporte à atualização rápida estiver desativado
• Os índices GIN são duas a três vezes maiores que os índices GiST

Como regra geral, os índices GIN são melhores para dados estáticos porque as pesquisas são mais rápidas. Para dados dinâmicos, os índices GiST são mais rápidos de atualizar.

SP-GiST - (GiST Particionado por Espaço) 

Para conjuntos de dados maiores com agrupamento natural, mas irregular. Esse tipo de índice alavanca árvores de particionamento de espaço. Os índices SP-GiST são mais úteis quando seus dados têm um elemento de agrupamento natural e também não são uma árvore igualmente equilibrada. Um ótimo exemplo disso são os números de telefone, por exemplo, nos EUA, eles usam o seguinte formato:

• 3 dígitos para código de área
• 3 dígitos para prefixo (historicamente relacionado ao switch de uma operadora de telefonia)
• 4 dígitos para o número da linha

Isso significa que você tem um agrupamento natural em torno do primeiro conjunto de 3 dígitos, em torno do segundo conjunto de 3 dígitos, então os números podem se espalhar em uma distribuição mais uniforme. Mas, com números de telefone, alguns códigos de área têm uma saturação muito maior do que outros. O resultado pode ser que a árvore seja muito desequilibrada. Por causa desse agrupamento natural inicial e da distribuição desigual de dados – dados como números de telefone podem ser um bom argumento para o SP-GiST.

BRIN - (Índice de intervalo de bloqueio) 

Para conjuntos de dados realmente grandes que se alinham sequencialmente. Um intervalo de blocos é um grupo de páginas adjacentes umas às outras, onde as informações resumidas sobre todas essas páginas são armazenadas no Índice. Os índices de intervalo de blocos podem se concentrar em alguns casos de uso semelhantes ao SP-GiST, pois são melhores quando há alguma ordenação natural nos dados e os dados tendem a ser muito grandes. Tem uma tabela de registros de bilhões, especialmente se forem dados de séries temporais? A BRIN pode ajudar. Se você estiver consultando um grande conjunto de dados que são naturalmente agrupados, como dados para vários CEPs (que então se acumulam em alguma cidade), o BRIN ajuda a garantir que CEPs semelhantes estejam localizados próximos uns dos outros no disco.

Quando você tem conjuntos de dados muito grandes ordenados, como datas ou códigos postais, os índices BRIN permitem que você ignore ou exclua muitos dados desnecessários muito rapidamente. Além disso, os BRIN são mantidos como índices menores em relação ao tamanho geral dos dados, tornando-os uma grande vitória para quando você tem um grande conjunto de dados.

Conclusão

O PostgreSQL tem algumas vantagens importantes ao competir com a plataforma empresarial e as soluções de negócios da Oracle. É definitivamente fácil considerar o PostgreSQL como sua escolha de RDBMS de código aberto, pois é quase poderoso como o Oracle.

O Oracle é difícil de vencer (e essa é uma verdade difícil de aceitar) e também não é fácil abandonar a plataforma empresarial do gigante da tecnologia. Quando os sistemas fornecem energia e resultados produtivos, isso pode ser um dilema.

Às vezes, porém, há situações em que uma decisão precisa ser tomada, pois o investimento excessivo contínuo no custo de sua plataforma pode superar o custo de suas outras camadas de negócios e prioridades que podem afetar o progresso.

O PostgreSQL e suas soluções de plataforma subjacentes podem ser a escolha para ajudá-lo a reduzir os custos, aliviar seus problemas orçamentários; todos com alterações moderadas a pequenas.