Da Oracle a PostgreSQL: l'evoluzione dei RDBMS

Da Oracle a PostgreSQL : L'evoluzione dei RDBMS

Le funzionalità di High Availability, Load Balancing e Disaster Recovery con il

sistema di gestione dati Open Source PostgreSQL

Milano, 2 Luglio 2015,

Forum della Qualità del Software e dei Servizi ICT1

Sergio Mior

CEO di Database & TechnologyEsperienza informatica dal 1970

Laurea Economia indirizzo statistico 1972Oracle – PostgreSQL DBA

1998-2015 Correlatore Tesi UniMI Informatica2001-2013 Prof. a Contratto UniMI

2

Business Continuity

3

DownTimeNon

Pianificato

DownTimePianificato

Media Failure

Data failure& Disaster

Human Error

System Maintenance

Backup / Restore-recoverCold-Warm

Data Guard – FailOver

FlashBack – repair error

Data Guard – SwitchOver

Disaster

« Se qualcosa può andar male, andrà male »

Legge di Murphy

4

Disaster

Fonte: Quorum Q1 2013 Disaster Recovery Reporthttp://www.youtube.com/watch?v=pqDRcfI_E1s 5

http://www.youtube.com/watch?v=pqDRcfI_E1s



Alcune Statistiche• Il 34% delle aziende italiane effettua

test di disaster recovery una volta all'anno.

• Il 72% sostiene che i disastri naturali sono la loro principale fonte di preoccupazione nel momento in cui sviluppano piani di disaster recovery.

Fonte: report Symantec Disaster Recovery Research 2007 http://eval.symantec.com/mktginfo/enterprise/other_resources/b-symantec_disaster_recovery.08-2008.en-us.pdf

6

http://eval.symantec.com/mktginfo/enterprise/other_resources/b-symantec_disaster_recovery.08-2008.en-us.pdf

Alcune Statistiche• Le relazioni con i fornitori (78%), • la fedeltà dei clienti (74%), • i danni alla reputazione del marchio (64%), • la riduzione dei profitti (64%) • la produttività del personale (62%)

sono i primi 5 elementi di preoccupazione

associati al possibile verificarsi di un disastro.

Fonte: report Symantec Disaster Recovery Research 2007 http://eval.symantec.com/mktginfo/enterprise/other_resources/b-symantec_disaster_recovery.08-2008.en-us.pdf

7


8

COLLABORAZIONE UniMI Corso Laurea Informatica

● Anno Accademico 2005/2006 : Laboratorio Basi Dati I : Oracle

● Anni Accademici dal 2005/2006 fino al 2008/2009 : Laboratorio Basi Dati I : PostgreSQL

● Anni Accademici dal 2000/2001 fino al 2008/2009 : Corso Prestazioni e Tuning di Basi di Dati : Oracle

● Anni Accademici dal 2005/2006 fino a tuttora : Laboratorio Basi Dati II : Oracle

9

D&T : Oracle – PostgreSQL : le Tesi

Anno Accademico Oracle PostgreSQL

2000/2001 Replication by Log Miner --

2001/2002 Tuning Prestazioni --

2002/2003 Sicurezza Dati MySQL

2006/2007 Replication Replication

2006/2007 Backup / Recovery Backup / Recovery

2006/2007 Materialized Views --

2007/2008 DW: progettazione fisica DW: progettazione fisica

10


2008/2009 -- Load Balancing e VLDB

2008/2009 Disaster Recovery Disaster Recovery

2008/2009Strumenti di Tuning

PrestazionaleStrumenti di Tuning

Prestazionale

2009/2010Load Balancing, High

AvailabilityLoad Balancing, High

Availability

2010/2011 DW: Change Data Capture DW: Change Data Capture

2011/2012DB Auditing e Normative

Sicurezza--

D&T : Oracle – PostgreSQL : le Tesi


2013/2014 FlashBack FlashBack

2013/2014 Load Balancing Load Balancing

2014/2015 Dati strutturati JASONDati strutturati JASON e

JASONB

D&T : Oracle - PostgreSQL : le Tesi … in corso

11

12

Anno Accademico Argomento Giudizio

2002/2003 Sicurezza Dati Oracle usa RBAC e i criteri del System-R, MySQL solo la Connection Verification e Request Verification

2006/2007 Replication

Oracle unisce replica master/ master, sia sincrona che asincrona, con replica master/slave. PostgreSQL più package pgpool-II ( master/ master, sincrona) e Slony- I (master/slave). Oracle replica : tabelle, indici, package, funzioni, viste, sinonimi, ecc... PostgreSQL Slony- I : tabelle, sequenze

2007/2008 DW Progettazione fisica

PostgreSQL: No partizionamento composito, no indici bitmap, no parallelismo di processiPochi strumenti di amministrazione e analisi carico.benchmark TPC-H : La miglior ottimizzazione con PostgreSQL ha tempi di risposta16 volte peggiori rispetto alla miglior configurazione ottenuta con Oracle e 3 volte peggiori rispetto a Oracle in configurazione base senza alcuna ottimizzazione

D&T : Oracle – PostgreSQL: i Giudizi

Anno Accademico Argomento Giudizio

2008/2009 Load Balancing e VLDB

PGCluster realizza DB replicati in modo sincrono, garantendo la Business ContinuityScalabile, intervenendo con aggiunta di ClusterDB in modo dinamicoAlta affidabilità con continuo monitoring del sistema e eventuale esclusione dei ClusterDB inattivi e pianificazione del loro recupero

2008/2009 Disaster Recovery

Log Shipping in PostgreSQL a livello Transaction Log, in Oracle anche a livello transazione.PostgreSQL ha solo Redo Apply, Oracle anche SQL Apply.La proposta di PostgreSQL è efficace e robusta, economicamente più vantaggiosa.Oracle risponde alla necessità presente o futura di una granularità a livello di transazione e fosse indispensabile disporre immediatamente anche dell’ultima transazione committata.


13


Anno Accademico

Argomento Giudizio

2008/2009 Strumenti di Tuning Prestazionale

Confronto Oracle 11.1 e PostgreSQL 8.4Entrambi hanno Tool di stima e di consuntivoIn Oracle le stime sono 1/10 del consuntivo, il contrario in PostgreSQL.In query complesse e con strutture non adeguate i tempi sono simili, ma con strutture adeguate (partizionamento sul predicato di WHERE), i tempi di PostgreSQL sono 1/10 di Oracle

2010/2011 DW: Change Data Capture

Confronto tra Oracle Golden Gate (GG) e Slony-IGG è mono e bidirezionale, Slony-I solo monoSlony-I ha migliori performance del 10-20%

2014/2015Dati non strutturati o semistrutturati in Oracle e PostgreSQL in previsione dei BigData

Oracle e PostgreSQL per la capacità di estensibilità si inseriscono perfettamente dentro il panorama big data o NoSQL. PostgreSQL ha prestazioni migliori rispetto ad Oracle, per quanto riguarda i tipo di dato JSON, ovvero all`aumentare del numero di sessioni e del volume delle transazioni e dei dati presenti nel database, PostgreSQL mantiene un livello pressoché lineare dei tempi di esecuzione. 14

MIGRAZIONE da piattaforma commerciale a PostgreSQL: VINCOLI

● Mancata collaborazione dei fornitori degli applicativi aventi il Repository Dati su un RDBMS commerciale.

● Indifferenza da parte del Management aziendale a causa della presenza di strategie più critiche

● Spirito di conservazione degli attuali utenti

15

16

MIGRAZIONE da piattaforma commerciale a PostgreSQL: la

collaborazione D&T

● Verifica d'impatto sugli applicativi coinvolti nel cambio di Repository Dati

● Predisposizione solidale del Piano di Migrazione

● Verifica Mantenimento concordato in modi e tempi del Repository Dati precedente e versione precedente degli applicativi

● entro 3 mesi (default) dalla migrazione, si può decidere di rinunciare alla stessa. Lo smantellamento e il ripristino saranno a carico di D&T a titolo gratuito per i primi 5 giorni/uomo

17

● I DBMS “chiusi” (es: Oracle) sono molto costosi.

● Soffrono spesso di gravi problemi di sicurezza.

● Economicamente solo la società che lo sviluppa può trarne vantaggi e per questo motivo è raro vedere community interessate a questi prodotti.

● Inoltre lo studio di questi prodotti è ostacolato dalla segretezza del codice sorgente.

Fonte : Seminario UniBicocca 22/1/2007 DBMS a Confrontohttp://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp

Confronto tra DBMS : chiusi, semichiusi, aperti


18

● I DBMS “semi-aperti” (es: MySQL) offrono un elevato livello di sicurezza grazie alla duplice attenzione da parte di una community e da parte di un team di sviluppo ufficiale.

● Possono essere sfruttati economicamente da tutti, ma una sola azienda è posta in una posizione privilegiata.




19


● I DBMS “aperti” (es: PostgreSQL) non soffrono problematiche di mercato. La loro sicurezza è comunque alta. Tutti possono trarne liberamente profitto.

● Essendo il sorgente di pubblico dominio ed utilizzando licenze libere, sono predisposti per studi ed analisi; per questo sono consigliati in ambiti accademici.



20

PostgreSQL : cosa c'è ….. in giro …..

● EnterpriseDB è stata fondata nel 2004 col compito di rompere l'oligopolio in campo DBMS, con una tecnologia equivalente basata sull' open source. Fu scelto PostgreSQL perchè testato per più di 20 anni in applicazioni commerciali su larga scala, per la sua fiorente comunità di sviluppatori, per la reputazione di essere il più robusto open source database disponibile.

● tra i Servizi : Oracle Migration Assessment

Fonte : http://www.enterprisedb.com


21

PostgreSQL : cosa c'è ….. in giro …..

● In Italia, sperando di non far torto a nessuno, scegliamo 2ndquadrant, detentrice del sistema Barman (Backup e Recovery Manager presentato il 15/10/2012 a Prato in ambito di Business Continuity).

● il 22/1/2010 Bartolini, Principal Consultant in 2ndquadrant, fondatore e Presidente di ITPUG - Italian PostgreSQL Users Group, scriveva a proposito di MySQL e PostgreSQL : è la comunità che detiene il codice sorgente di PostgreSQL, prodotto a licenza BSD, che quindi non potrà mai essere detenuto da una singola azienda. La maggior diffusione di MySQL (nel 2010) sembra dovuta alla appartenenza di questi all'acronimo LAMP e ad un marketing più efficace rispetto a quello promosso da una comunità di sviluppatori come può essere quella di PostgreSQL e infine al fatto che PostgreSQL sia più giovane.

22

La funzionalità di TimeTravel (FlashBack) in PostgreSQL

● vedere stati precedenti di oggetti del database

● ripristinare oggetti allo stato precedente

PostgreSQL : ma ….. D&T ha fatto qualcosa ?

23


Business Continuity

DownTimeNon

Pianificato

DownTimePianificato

Media Failure

Data failure& Disaster

Human Error

System Maintenance

Backup / Restore-recoverCold-Warm

Data Guard – FailOver

FlashBack – repair error

Data Guard – SwitchOver

24


TimeTravel: A COSA SERVE?

Far tornare ad uno stato precedente un oggetto, cancellando a ritroso le

transazioni sull'oggetto stesso.

25


TimeTravel: COME FUNZIONA ?Questa funzionalità ricorda tutte le modifiche subìte dalle tabelle del DataBase e possiamo conservarle per un eventuale RollBack. Si estraggono tutti gli Statement inversi relativi ad ogni transazione

26


TimeTravel: CHI LA DOVREBBE USARE ? In caso la pubblicazione di una nuova applicazione

(RollUp) non vada a buon fine e si decida di rinunciarvi, se la soluzione fosse quella del Restore/Recovery costerebbe molto in termini di tempo (RTO = tempo massimo richiesto per il recovery).

Tornare al punto di partenza ma cercando di eseguire un “intervento chirurgico” cioè salvaguardando le modifiche al DataBase che nel frattempo fossero state corrette.

27


TimeTravel: QUANDO USARLA ?

Poco prima della pubblicazione di una nuova

applicazione (RollUp) e mantenerla finchè non si sia certi che sia andata a buon fine

28


TimeTravel: E' INVASIVA ?

Nessuna modifica al codice applicativoRichiesto solo l'uso delle attivazioni / disattivazioni proprie della funzionalità

29

Sede operativa Database & Technology s.r.l.Largo Promessi Sposi, 4 20142 Milano, Italy

Tel. +39 02 8950.0080Fax. +39 02 8954.9736

www.databtech.comwww.owb2odiconverter.com

www.remotedba.biz__________________________________________

______________Per ulteriori informazioni contattare:

Massimo Sposaro – Responsabile Marketingmobile: +39 348 6979791

email: [email protected] Mior – CEO D&T

mobile: +39 348 3036527email: [email protected]

http://www.owb2odiconverter.com/

mailto:[email protected]