I dieci principali motivi per migrare da Oracle a PostgreSQL

Oracle Relational Database Management System (RDBMS) è stato ampiamente utilizzato dalle grandi organizzazioni ed è considerato di gran lunga la tecnologia di database più avanzata disponibile sul mercato. In genere è l'RDBMS più spesso confrontato con altri prodotti di database che fungono da "de facto" standard di ciò che un prodotto dovrebbe offrire. È classificato da db-engines.com come l'RDBMS n. 1 disponibile oggi sul mercato.

PostgreSQL è classificato come l'RDBMS n. 4, ma ciò non significa che non ci siano vantaggi nella migrazione a PostgreSQL. PostgreSQL è in circolazione dal 1989 ed è open source nel 1996. PostgreSQL ha vinto DBMS dell'anno per due anni consecutivi dal 2017 al 2018. Ciò indica semplicemente che non ci sono segni di smettere di attirare un gran numero di utenti e grandi organizzazioni.

Uno dei motivi per cui PostgreSQL ha attirato molta attenzione è perché le persone cercano un'alternativa a Oracle in modo da poter tagliare i costi elevati delle organizzazioni e sfuggire al blocco dei fornitori.

Il passaggio da un database Oracle funzionante e produttivo può essere un compito arduo. Preoccupazioni come il TCO (Total Cost of Ownership) dell'azienda sono uno dei motivi per cui le aziende trascinano la decisione se abbandonare o meno Oracle.

In questo blog daremo uno sguardo ad alcuni dei motivi principali per cui le aziende scelgono di lasciare Oracle e migrare a PostgreSQL.

Ragione uno:è un vero progetto Open Source

PostgreSQL è open-source ed è rilasciato sotto la licenza PostgreSQL, una licenza liberale Open Source, simile alle licenze BSD o MIT. L'acquisto del prodotto e del supporto non richiede alcun costo.

Se vuoi sfruttare il software del database, significa che puoi ottenere gratuitamente tutte le funzionalità disponibili del database PostgreSQL. PostgreSQL ha più di 30 anni di maturità nel mondo dei database ed è stato touch based come open-source dal 1996. Ha goduto di decenni di sviluppatori che hanno lavorato per creare estensioni. Questo, di per sé, fa sì che sviluppatori, istituzioni e organizzazioni scelgano PostgreSQL per le applicazioni aziendali; alla base delle principali applicazioni aziendali e mobili.

Ancora una volta, le organizzazioni si stanno rendendo conto che le soluzioni di database open source come Postgres offrono maggiore capacità, flessibilità e supporto che non dipendono interamente da nessuna azienda o sviluppatore. Postgres, come Linux prima, è stato (e continua ad essere) progettato da utenti dedicati che risolvono problemi aziendali quotidiani che scelgono di restituire le loro soluzioni alla comunità. A differenza di un grande sviluppatore come Oracle, che può avere diversi motivi per sviluppare prodotti redditizi o supportare un mercato ristretto ma redditizio, la community di Postgres si impegna a sviluppare i migliori strumenti possibili per gli utenti quotidiani di database relazionali.

PostgreSQL spesso esegue queste attività senza aggiungere troppa complessità. Il suo design è incentrato rigorosamente sulla gestione del database senza dover sprecare risorse come la gestione di ambienti IT aggiuntivi attraverso funzionalità aggiuntive. È una delle cose che piace ai consumatori di questo software open source durante la migrazione da Oracle a PostgreSQL. Trascorrere ore a studiare una tecnologia complessa sul funzionamento di un database Oracle o su come ottimizzare e mettere a punto potrebbe rifinire con il suo costoso supporto. Questo attira le istituzioni o le organizzazioni a trovare un'alternativa che possa essere meno gravosa sui costi e portare profitto e produttività. Dai un'occhiata al nostro blog precedente su come PostgreSQL è in grado di far corrispondere la presenza della sintassi SQL con la sintassi di Oracle.

Motivo due:nessuna licenza e una grande community

Per gli utenti della piattaforma Oracle RDBMS, è difficile trovare qualsiasi tipo di supporto della comunità che sia gratuito o senza un costo elevato. Istituzioni, organizzazioni e sviluppatori spesso finiscono per trovare online informazioni alternative in grado di offrire gratuitamente risposte o soluzioni ai loro problemi.

Quando si utilizza Oracle, è difficile decidere su un prodotto specifico o se ricorrere al supporto del prodotto perché (in genere) sono coinvolti molti soldi. Potresti provare un prodotto specifico per testarlo, finire per acquistarlo, solo per renderti conto che non può aiutarti. Con PostgreSQL, la community è gratuita e piena di esperti con una vasta esperienza che saranno felici di aiutarti con i tuoi problemi attuali.

Puoi iscriverti alla mailing list proprio qui su https://lists.postgresql.org/ per iniziare a contattare la community. I principianti o i prodigi di PostgreSQL si basano qui per comunicare, mostrare e condividere le loro soluzioni, tecnologia, bug, nuove scoperte o persino condividere il loro software emergente. Puoi anche chiedere aiuto alla chat di IRC usando irc.freenode.net e unendoti al canale #postgresql. Puoi anche contattare la community tramite Slack unendoti a https://postgres-slack.herokuapp.com/ o https://postgresteam.slack.com/. Ci sono molte opzioni da scegliere e molte organizzazioni Open Source che possono farti domande

Per maggiori dettagli e informazioni su da dove iniziare, dai un'occhiata qui https://www.postgresql.org/community/.

Se vuoi provare i servizi professionali in PostgreSQL, ci sono tantissime opzioni tra cui scegliere. Anche controllando il loro sito Web all'indirizzo https://www.postgresql.org/support/professional_support/northamerica/, puoi trovare un ampio elenco di aziende lì e alcune di queste hanno un prezzo economico. Anche qui a Diversinines, offriamo anche il supporto per Postgres, che fa parte della licenza ClusterControl o di una consulenza DBA.

Motivo tre: ampio supporto per la conformità SQL

PostgreSQL ha sempre voluto adattarsi e conformarsi a SQL come standard de facto per il suo linguaggio. Il nome formale dello standard SQL è ISO/IEC 9075 “Database Language SQL”. Eventuali successive versioni revisionate delle versioni standard sostituiscono la precedente, quindi le affermazioni di conformità alle versioni precedenti non hanno valore ufficiale.

A differenza di Oracle, sono ancora presenti alcune parole chiave o operatori che non sono conformi allo standard ANSI SQL (Structured Query Language). Ad esempio, l'operatore OUTER JOIN (+) può attribuire confusioni con altri DBA che non hanno toccato o con la minima familiarità con Oracle. PostgreSQL segue lo standard ANSI-SQL per la sintassi JOIN e ciò lascia il vantaggio di passare facilmente e semplicemente con altri database RDBMS open source come i database MySQL/Percona/MariaDB.

Un'altra sintassi molto comune con Oracle riguarda l'utilizzo di query gerarchiche. Oracle utilizza la sintassi non standard START WITH..CONNECT BY, mentre in SQL:1999 le query gerarchiche vengono implementate tramite espressioni di tabelle comuni ricorsive. Ad esempio, le query seguenti differiscono nella sintassi in base alle query gerarchiche:

Oracolo

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;

PostgreSQL ha un approccio molto simile agli altri migliori RDBMS open source come MySQL/MariaDB.

Secondo il manuale di PostgreSQL, lo sviluppo di PostgreSQL mira alla conformità con l'ultima versione ufficiale dello standard laddove tale conformità non contraddica le caratteristiche tradizionali o il buon senso. Molte delle funzionalità richieste dallo standard SQL sono supportate, anche se a volte con sintassi o funzioni leggermente diverse. Questo è, in effetti, ciò che è eccezionale con PostgreSQL poiché è anche supportato e collaborato da diverse organizzazioni, piccole o grandi che siano. La bellezza rimane nella sua conformità del linguaggio SQL a ciò che ha lo standard push through.

Lo sviluppo di PostgreSQL mira alla conformità con l'ultima versione ufficiale dello standard laddove tale conformità non contraddica le caratteristiche tradizionali o il buon senso. Molte delle funzionalità richieste dallo standard SQL sono supportate, anche se a volte con sintassi o funzioni leggermente diverse. Nel tempo sono prevedibili ulteriori passi verso la conformità.

Motivo quattro:parallelismo delle query

Per essere onesti, Query Parallelism di PostgreSQL non è così ricco rispetto all'esecuzione parallela di Oracle per le istruzioni SQL. Tra le caratteristiche del parallelismo di Oracle ci sono l'accodamento di istruzioni con suggerimenti, la capacità di impostare il grado di parallelismo (DOP), impostare una politica dei gradi paralleli o il parallelismo adattivo.

PostgreSQL ha un semplice grado di parallelismo basato sui piani supportati, ma ciò non definisce che Oracle sia in vantaggio rispetto a PostgreSQL open source.

Il parallelismo di PostgreSQL è stato costantemente migliorato e continuamente migliorato dalla comunità. Quando è stato rilasciato PostgreSQL 10, ha aggiunto più appeal al pubblico, in particolare i miglioramenti al supporto del parallelismo per merge join, scansione heap bitmap, scansione indice e scansione solo indice, merge merge, ecc. I miglioramenti aggiungono anche statistiche a pg_stat_activity.

Nelle versioni di PostgreSQL <10, il parallelismo è disabilitato per impostazione predefinita ed è necessario impostare la variabile 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

Il piano di query rivela che il tempo effettivo può aggirarsi intorno a 522,5 ms, quindi il tempo di esecuzione della query reale è di circa 596,95 ms. Pur consentendo il parallelismo,

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

Il piano di query determina che la query deve utilizzare il parallelismo e quindi utilizza un nodo Gather. È il tempo effettivo stimato a 339 ms con 2 lavori e le stime a 264 ms prima che sia stato aggregato dal piano di query. Ora, il tempo reale di esecuzione della query ha richiesto 346 ms, che è molto vicino al tempo effettivo stimato dal piano di query.

Questo illustra solo quanto sia veloce e vantaggioso con PostgreSQL. Sebbene PostgreSQL abbia i suoi limiti quando può verificarsi il parallelismo o quando il piano di query determina che è più veloce dell'uso del parallelismo, non fa la sua caratteristica un'enorme differenza rispetto a Oracle. Il parallelismo di PostgreSQL è flessibile e può essere abilitato o utilizzato correttamente purché la query corrisponda alla sequenza richiesta per il parallelismo delle query.

Motivo cinque:supporto JSON avanzato e miglioramento continuo

Il supporto JSON in PostgreSQL è sempre alla pari rispetto agli altri RDBMS open source. Dai un'occhiata a questo blog esterno di LiveJournal dove il supporto JSON di PostgreSQL si rivela sempre più avanzato rispetto agli altri RDBMS. PostgreSQL ha un gran numero di funzioni e caratteristiche JSON.

Il tipo di dati JSON è stato introdotto in PostgreSQL-9.2. Da allora, ha molti miglioramenti significativi e tra le principali aggiunte sono emerse PostgreSQL-9.4 con l'aggiunta del tipo di dati JSONB. PostgreSQL offre due tipi di dati per la memorizzazione dei dati JSON:json e jsonb. Con jsonb, è una versione avanzata del tipo di dati JSON che memorizza i dati JSON in formato binario. Questo è il principale miglioramento che ha fatto una grande differenza nel modo in cui i dati JSON sono stati ricercati ed elaborati in PostgreSQL.

Oracle ha anche un ampio supporto per JSON. Al contrario, PostgreSQL ha un ampio supporto e funzioni che possono essere utilizzate per il recupero dei dati, la formattazione dei dati o le operazioni condizionali che influiscono sull'output dei dati o anche sui dati archiviati nel database. I dati archiviati con il tipo di dati jsonb hanno un vantaggio maggiore con la possibilità di utilizzare GIN (Generalized Inverted Index) che può essere utilizzato per cercare in modo efficiente chiavi o coppie chiave/valore che si verificano all'interno di un gran numero di documenti jsonb.

PostgreSQL ha estensioni aggiuntive utili per implementare TRANSFORM FOR TYPE per il tipo jsonb nei linguaggi di procedura supportati. Queste estensioni sono jsonb_plperl e jsonb_plperlu per PL/Perl. Mentre per PL/Python, questi sono jsonb_plpythonu, jsonb_plpython2u e jsonb_plpython3u. Ad esempio, utilizzando i valori jsonb per mappare gli array Perl, puoi usare le estensioni jsonb_plperl o jsonb_plperlu.

ArangoDB ha pubblicato un benchmark che confronta le prestazioni JSON di PostgreSQL con altri database di supporto JSON. Sebbene sia un vecchio blog, mostra comunque le prestazioni di JSON di PostgreSQL rispetto ad altri database in cui JSON è la sua caratteristica principale nel kernel del database. Questo fa sì che PostgreSQL abbia il suo vantaggio anche con la sua funzionalità secondaria.

Motivo sei:supporto DBaaS da parte dei principali fornitori di cloud

PostgreSQL è stato ampiamente supportato come DBaaS. Questi servizi provengono da Amazon, Microsoft con il suo database di Azure per PostgreSQL e Cloud SQL di Google per PostgreSQL.

In confronto, Oracle è disponibile solo su Amazon RDS per Oracle. I servizi offerti dai maggiori player partono da un prezzo accessibile e sono molto flessibili da configurare in base alle proprie esigenze. Questo aiuta le istituzioni e le organizzazioni a configurarsi di conseguenza e ad alleviare i suoi ingenti costi legati alla piattaforma Oracle.

Motivo sette: Migliore gestione di enormi quantità di dati

Gli RDBMS PostgreSQL non sono progettati per gestire carichi di lavoro analitici e di data warehousing. PostgreSQL è un database orientato alle righe, ma ha la capacità di memorizzare grandi quantità di dati. PostgreSQL ha i seguenti limiti per gestire l'archivio dati:

Se si desidera utilizzare le funzionalità principali di PostgreSQL, è possibile archiviare grandi quantità di dati utilizzando jsonb. Ad esempio, una grande quantità di documenti (PDF, Word, fogli di calcolo) e archiviarla utilizzando il tipo di dati jsonb. Per applicazioni e sistemi di geolocalizzazione, puoi utilizzare PostGIS.

Motivo otto:scalabilità, alta disponibilità, ridondanza/geo-ridondanza e soluzioni a tolleranza di errore a buon mercato

Oracle offre soluzioni simili, ma potenti, come Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware e Oracle Data Guard solo per citarne alcuni. Queste tecnologie possono aumentare i tuoi costi crescenti e sono imprevedibilmente costose da implementare e rendere stabili. È difficile abbandonare queste soluzioni. La formazione e le competenze devono essere migliorate e sviluppare le persone coinvolte nel processo di dispiegamento e attuazione.

PostgreSQL ha un supporto enorme e ha molte opzioni tra cui scegliere. PostgreSQL include lo streaming e la replica logica integrati nel pacchetto principale del software. Potresti anche impostare una replica sincrona per PostgreSQL per avere più cluster ad alta disponibilità, mentre fai in modo che un nodo stand-by elabori le tue query di lettura. Per un'elevata disponibilità, ti suggeriamo di leggere il nostro blog Top PG Clustering High Availability (HA) Solutions for PostgreSQL e che copre molti ottimi strumenti e tecnologie tra cui scegliere.

Ci sono anche funzionalità aziendali che offrono soluzioni di alta disponibilità, monitoraggio e backup. ClusterControl è una di queste tecnologie e offre un prezzo accessibile rispetto alle soluzioni Oracle.

Motivo nove: Supporto per diversi linguaggi procedurali:PL/pgSQL, PL/Tcl, PL/Perl e PL/Python.

Dalla versione 9.4, PostgreSQL ha un'ottima funzionalità in cui puoi definire un nuovo linguaggio procedurale in base alla tua scelta. Sebbene non tutte le varietà di linguaggi di programmazione siano supportate, ha un certo numero di linguaggi supportati. Attualmente, con la distribuzione di base, include PL/pgSQL, PL/Tcl, PL/Perl e PL/Python. Le lingue esterne sono:

La cosa grandiosa di questo è che, a differenza di Oracle, gli sviluppatori che sono passati di recente a PostgreSQL possono fornire rapidamente la logica di business ai loro sistemi applicativi senza perdere altro tempo per conoscere PL/SQL. PostgreSQL rende l'ambiente per gli sviluppatori più semplice ed efficiente. Questa natura di PostgreSQL contribuisce al motivo per cui gli sviluppatori amano PostgreSQL e iniziano a passare dalle soluzioni della piattaforma aziendale all'ambiente open source.

Motivo dieci: indici flessibili per dati di grandi dimensioni e testuali (GIN, GiST, SP-GiST e BRIN)

PostgreSQL ha un enorme vantaggio quando si tratta del supporto di indici utili per la gestione di dati di grandi dimensioni. Oracle ha molti tipi di indice utili anche per la gestione di set di dati di grandi dimensioni, in particolare per l'indicizzazione del testo completo. Ma per PostgreSQL, questi tipi di indici sono fatti per essere flessibili in base al tuo scopo. Ad esempio, questi tipi di indici sono applicabili per dati di grandi dimensioni:

GIN - (Indici invertiti generalizzati) 

Questo tipo di indice è applicabile per le colonne dei tipi di dati jsonb, hstore, range e array. È utile quando si hanno tipi di dati che contengono più valori in una singola colonna. Secondo i documenti PostgreSQL, "GIN è progettato per la gestione dei casi in cui gli elementi da indicizzare sono valori composti e le query che devono essere gestite dall'indice devono cercare i valori degli elementi che appaiono all'interno degli elementi composti. Ad esempio, gli elementi potrebbero essere documenti e le query potrebbero essere ricerche di documenti contenenti parole specifiche."

GiST - (Albero di ricerca generalizzato)

Un albero di ricerca con bilanciamento dell'altezza composto da pagine di nodi. I nodi sono costituiti da righe di indice. Ogni riga di un nodo foglia (riga foglia), in generale, contiene un predicato (espressione booleana) e un riferimento a una riga di tabella (TID). Gli indici GiST sono i migliori se lo usi per il tipo di dati geometrici come se vuoi vedere se due poligoni contenevano un punto. In un caso un punto specifico può essere contenuto all'interno di un riquadro, mentre un altro punto esiste solo all'interno di un poligono. I tipi di dati più comuni su cui desideri sfruttare gli indici GiST sono i tipi di geometria e il testo quando si tratta di ricerca full-text

Nella scelta del tipo di indice da utilizzare, GiST o GIN, considera queste differenze di prestazioni:

• Le ricerche nell'indice GIN sono circa tre volte più veloci di GiST
• Gli indici GIN impiegano circa tre volte più tempo per essere compilati rispetto a GiST
• Gli indici GIN sono moderatamente più lenti da aggiornare rispetto agli indici GiST, ma circa 10 volte più lenti se il supporto per l'aggiornamento rapido fosse disabilitato
• Gli indici GIN sono da due a tre volte più grandi degli indici GiST

Come regola pratica, gli indici GIN sono i migliori per i dati statici perché le ricerche sono più veloci. Per i dati dinamici, gli indici GiST sono più veloci da aggiornare.

SP-GiST - (GiST a partizioni spaziali) 

Per set di dati più grandi con clustering naturale ma irregolare. Questo tipo di indice sfrutta gli alberi di partizionamento dello spazio. Gli indici SP-GiST sono più utili quando i dati hanno un elemento di clustering naturale e non sono un albero ugualmente equilibrato. Un ottimo esempio sono i numeri di telefono, ad esempio negli Stati Uniti usano il seguente formato:

• 3 cifre per prefisso
• 3 cifre per il prefisso (storicamente correlato al passaggio di un operatore telefonico)
• 4 cifre per il numero di riga

Ciò significa che hai un certo raggruppamento naturale attorno al primo set di 3 cifre, attorno al secondo set di 3 cifre, quindi i numeri potrebbero allargarsi in una distribuzione più uniforme. Ma con i numeri di telefono alcuni prefissi hanno una saturazione molto più alta di altri. Il risultato potrebbe essere che l'albero è molto sbilanciato. A causa di quel naturale raggruppamento in anticipo e della distribuzione ineguale dei dati, dati come i numeri di telefono potrebbero essere un buon caso per SP-GiST.

BRIN - (Indice dell'intervallo di blocchi) 

Per set di dati molto grandi che si allineano in sequenza. Un intervallo di blocchi è un gruppo di pagine adiacenti l'una all'altra, in cui le informazioni di riepilogo su tutte quelle pagine sono archiviate nell'Indice. Gli indici di intervallo di blocchi possono concentrarsi su alcuni casi d'uso simili a SP-GiST in quanto sono i migliori quando c'è un ordinamento naturale dei dati e i dati tendono ad essere molto grandi. Hai una tabella di un miliardo di record, specialmente se si tratta di dati di serie temporali? BRIN potrebbe essere in grado di aiutare. Se stai eseguendo una query su un ampio set di dati che è naturalmente raggruppato insieme, come i dati per diversi codici postali (che poi vengono trasferiti in alcune città), BRIN aiuta a garantire che codici postali simili si trovino uno vicino all'altro sul disco.

Quando si dispone di set di dati molto grandi ordinati come date o codici postali, gli indici BRIN consentono di saltare o escludere molti dati non necessari molto rapidamente. BRIN inoltre vengono mantenuti come indici più piccoli rispetto alla dimensione complessiva dei dati, rendendoli una grande vittoria per quando si dispone di un set di dati di grandi dimensioni.

Conclusione

PostgreSQL presenta alcuni importanti vantaggi rispetto alla piattaforma aziendale e alle soluzioni aziendali di Oracle. È sicuramente facile salutare PostgreSQL come la tua scelta preferita di RDBMS open source poiché è quasi potente come Oracle.

Oracle è difficile da battere (e questa è una dura verità da accettare) e non è nemmeno facile abbandonare la piattaforma aziendale del gigante della tecnologia. Quando i sistemi ti forniscono potenza e risultati produttivi, potrebbe essere un dilemma.

A volte, tuttavia, ci sono situazioni in cui è necessario prendere una decisione poiché un continuo investimento eccessivo nei costi della tua piattaforma può superare il costo degli altri livelli e priorità aziendali che possono influire sui progressi.

PostgreSQL e le sue soluzioni di piattaforma sottostanti possono essere la scelta per aiutarti a ridurre i costi, alleviare i tuoi problemi di budget; il tutto con modifiche da moderate a piccole.