Da Oracle a PostgreSQL: l'evoluzione dei RDBMS
1 like859 views
Il documento analizza l'evoluzione dei sistemi di gestione dei database relazionali, focalizzandosi su PostgreSQL e le sue funzionalità di alta disponibilità, bilanciamento del carico e recupero dai disastri. Viene presentata un'analisi comparativa tra Oracle e PostgreSQL in termini di sicurezza, performance e costo, evidenziando i vantaggi di PostgreSQL come soluzione open source. Infine, viene discussa la migrazione da piattaforme commerciali a PostgreSQL, evidenziando le sfide e le opportunità di implementazione.
Da Oracle a PostgreSQL: l'evoluzione dei RDBMS
- 1. 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 ICT 1
- 2. Sergio Mior CEO di Database & Technology Esperienza informatica dal 1970 Laurea Economia indirizzo statistico 1972 Oracle – PostgreSQL DBA 1998-2015 Correlatore Tesi UniMI Informatica 2001-2013 Prof. a Contratto UniMI 2
- 3. Business Continuity 3 DownTime Non Pianificato DownTime Pianificato Media Failure Data failure & Disaster Human Error System Maintenance Backup / Restore-recover Cold-Warm Data Guard – FailOver FlashBack – repair error Data Guard – SwitchOver
- 4. Disaster « Se qualcosa può andar male, andrà male » Legge di Murphy 4
- 5. Disaster Fonte: Quorum Q1 2013 Disaster Recovery Report http://www.youtube.com/watch?v=pqDRcfI_E1s 5
- 6. 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
- 7. 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. 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. 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. 10 Anno Accademico Oracle PostgreSQL 2008/2009 -- Load Balancing e VLDB 2008/2009 Disaster Recovery Disaster Recovery 2008/2009 Strumenti di Tuning Prestazionale Strumenti di Tuning Prestazionale 2009/2010 Load Balancing, High Availability Load Balancing, High Availability 2010/2011 DW: Change Data Capture DW: Change Data Capture 2011/2012 DB Auditing e Normative Sicurezza -- D&T : Oracle – PostgreSQL : le Tesi
- 11. Anno Accademico Oracle PostgreSQL 2013/2014 FlashBack FlashBack 2013/2014 Load Balancing Load Balancing 2014/2015 Dati strutturati JASON Dati strutturati JASON e JASONB D&T : Oracle - PostgreSQL : le Tesi … in corso 11
- 12. 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 processi Pochi 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
- 13. Anno Accademico Argomento Giudizio 2008/2009 Load Balancing e VLDB PGCluster realizza DB replicati in modo sincrono, garantendo la Business Continuity Scalabile, intervenendo con aggiunta di ClusterDB in modo dinamico Alta 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
- 14. D&T : Oracle – PostgreSQL: i Giudizi Anno Accademico Argomento Giudizio 2008/2009 Strumenti di Tuning Prestazionale Confronto Oracle 11.1 e PostgreSQL 8.4 Entrambi hanno Tool di stima e di consuntivo In 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-I GG è mono e bidirezionale, Slony-I solo mono Slony-I ha migliori performance del 10-20% 2014/2015 Dati 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
- 15. 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. 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. 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 Confronto http://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp Confronto tra DBMS : chiusi, semichiusi, aperti
- 18. 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 Confronto http://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp Confronto tra DBMS : chiusi, semichiusi, aperti
- 19. 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 Confronto http://geekplace.org/download/DBMS%20a%20confronto%20-%20NeCoSi%2001.odp
- 20. 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. 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. 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. 23 PostgreSQL : ma ….. D&T ha fatto qualcosa ? Business Continuity DownTime Non Pianificato DownTime Pianificato Media Failure Data failure & Disaster Human Error System Maintenance Backup / Restore-recover Cold-Warm Data Guard – FailOver FlashBack – repair error Data Guard – SwitchOver
- 24. 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. 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. 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. 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. 28 PostgreSQL : ma ….. D&T ha fatto qualcosa ? TimeTravel: E' INVASIVA ? Nessuna modifica al codice applicativo Richiesto solo l'uso delle attivazioni / disattivazioni proprie della funzionalità
- 29. 29 Sede operativa Database & Technology s.r.l. Largo Promessi Sposi, 4 20142 Milano, Italy Tel. +39 02 8950.0080 Fax. +39 02 8954.9736 www.databtech.com www.owb2odiconverter.com www.remotedba.biz __________________________________________ ______________ Per ulteriori informazioni contattare: Massimo Sposaro – Responsabile Marketing mobile: +39 348 6979791 email: [email protected] Sergio Mior – CEO D&T mobile: +39 348 3036527 email: [email protected]