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
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
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
Anno Accademico Oracle PostgreSQL
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
Anno Accademico Oracle PostgreSQL
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.
D&T : Oracle – PostgreSQL: i Giudizi
13
D&T : Oracle – PostgreSQL: i Giudizi
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.
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
19
Confronto tra DBMS : chiusi, semichiusi, aperti
● 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.
Fonte : Seminario UniBicocca 22/1/2007 DBMS a Confrontohttp://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp
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
PostgreSQL : ma ….. D&T ha fatto qualcosa ?
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
PostgreSQL : ma ….. D&T ha fatto qualcosa ?
TimeTravel: A COSA SERVE?
Far tornare ad uno stato precedente un oggetto, cancellando a ritroso le
transazioni sull'oggetto stesso.
25
PostgreSQL : ma ….. D&T ha fatto qualcosa ?
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
PostgreSQL : ma ….. D&T ha fatto qualcosa ?
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
PostgreSQL : ma ….. D&T ha fatto qualcosa ?
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
PostgreSQL : ma ….. D&T ha fatto qualcosa ?
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]
Top Related