Ecco giunti al quarto appuntamento con la storia degli RDBMS.
Come sempre il mondo OpenSource non poteva non giocare un ruolo importante anche in questo settore del software. Anzi proprio gli RDBMS (dopo LINUX) sono la massima espressione del movimento, con diverse soluzioni disponibili, anche se, sostanzialmente, due di esse dominano incontrastate.
Si tratta, ovviamente, di MySQL e PostgreSQL, di cui ora tracceremo sinteticamente l’evoluzione.
MySQL è il database che si è imposto per la sua efficienza nello sviluppo di soluzioni WEB, creando un legame quasi inscindibile con PHP.
Il suo sviluppo ha inizio nel 1979 quando Michael “Monty” Widenius, comincia a lavorare ad una serie di tools noti come UNIREG, pensati per amministrare un piccolo database proprietario basato su un ISAM (Indexed Sequential Access Method) storage. La svolta arriva però nel 1994 quando la svedese TcX ataconsult, di cui Monty è uno dei pochi dipendenti, comincia a sviluppare web application e decide di usare UNIREG per la persistenza delle informazioni.
Michael Widenius
La scelta si rileva alquanto azzardata, visto l’alto overhead generato dal tool, e la società inizia a vagliare l’utilizzo di altre soluzioni, tra cui mSQL (mini SQL della Hughes Technologies). Questo database (che nel periodo di riferimento era disponibile nella versione 1.x), completamente open source, sembra una soluzione interessante ma ha un grandissimo difetto: non supporta l’indicizzazione.
Monty contatta così David Hughes, autore di mSQL, per proporgli di creare un ibrido che avesse le funzionalità di mSQL ma che sfruttasse le feauture di indicizzazione di UNIREG. Hughes è, però, già al lavoro ad una propria struttura di indicizzazione per la versione 2 del proprio RDBMS, e TcX decide di creare in proprio un nuovo RDBMS, prendendo a modello le API di mSQL (ovviamente le interfacce e non il codice) e il sistema di indicizzazione di UNIREG.
Nel 1995 nasce MySQL 3.11 che, grazie alla spinta di David Axmark della Detron HB (partner tecnologico di TcX), viene rilasciato su internet abbracciando prima una licenza molto “aperta” e poi sposando completamente quella GPL.
Un simpatico aneddoto è stato sollevato in merito al nome “MySQL” dallo stesso Monty:
“It is not perfectly clear where the name MySQL derives from. TcX’s base directory and a large amount of their libraries and tools have had the prefix ‘My’ for well over ten years. However, my daughter (some years younger) is also named My. So which of the two gave its name to MySQL is still a mystery.”
Qualche anno dopo TcX diventa MySQL AB e riesce a trasformare MySQL nel più noto RDBMS per il web, grazie anche alla forte integrazione con PHP, diventando la “M” nel pacchetto xAMP (Apache, MySQL, PHP, mentre la x varia secondo la piattaforma: L=Linux, W=Windows, ecc.)
Nel 2008 MySQL entra nella sfera di SUN con un’acquisizione del costo di circa 1 miliardo di dollari, mentre nel 2009 approda in Oracle, che acquista SUN.
Widenius però non si trova a suo agio con i nuovi proprietari e subito dopo l’acquisizione da parte di Oracle, fonda la Monty Program AB e da vita ad un fork di MySQL chiamandolo mariaDB, compatibile a livello di API con MySQL e che deve il suo nome all’Storage Engine Aria.
L’altro grande protagonista del mondo legato agli RDBMS opensource è PostgreSQL, la cui storia non è poi tanto più recente di quella di MySQL. Infatti siamo nel 1985 quando l’università di Berkeley, in California, comincia a lavorare ad un progetto chiamato Ingres che, nel 1989, si trasforma nel DB dell’elefantino. Dopo un anno il suo codice viene completamente riscritto e viene rilasciata la versione 2, seguita a rotazione dalla versione 3 che è frutto di una nuova riscrittura. Questa release aggiunge il supporto al “multiple storage managers” e migliora sostanzialmente il “query engine”. PostgreSQL è rilasciato sotto licenza BSD, cosa che permette alle aziende di effettuare modifiche sul codice senza l’obbligo di renderle parte del sistema stesso e quindi di doverle rilasciare gratuitamente (come nel caso della GPL)
Oggi PostgreSQL conta la più grande community che ruota attorno ad un RDBM con più di 30.000 iscritti (di cui 1.000 attivi nello sviluppo) ed è particolarmente apprezzato in ambito enterprise per la sua robustezza, le funzionalità avanzate di gestione delle transazioni, l’integrità dei dati garantita da una robusta gestione delle proprietà ACID (Atomic, Consistent, Isolated, Durable), la possibilità di controllare in modo granulare l’accesso ai dati (integrazione con LDAP e Kerberos) e l’utilizzo di SSL per lo scambio dei dati in modo sicuro.
Un’area dove, sostanzialmente, questo DB ha pochi rivali è il supporto alle estensioni GIS (PostGIS) che permettono di gestire in modo efficiente dati di tipo spaziale.
Tutto ciò lo inquadra in un ambito decisamente differente da quello di MySQL che è esplicitamente pensato per rendere quanto più efficienti la gestione dei dati annesse alle web application scegliendo il sistema di storage più opportuno: da MyISAM a InnoDB.
Prima di concludere un menzione speciale merita Derby, o JavaDB, progetto originariamente portato avanti dall’Apache Software Foundation, ormai parte integrante dell’SDK Java e pensato per offrire un discreto sistema di storage per le applicazioni java based.
Per completezza è doveroso ricordare che mSQL è sviluppato ancora oggi anche se, sostanzialmente, è ormai un sistema di nicchia scarsamente utilizzato.
Termina così il nostro 4 appuntamento dedicato alla storia dei DB. Arrivederci alla prossima settimana con uno sguardo al futuro.
> Nel 1998 MySQL entra nella sfera di SUN con un’acquisizione del >costo di circa 1 miliardo di dollari
1998? Non era il 2008??
Ciao,
Fabrizio
@Fabrizio: si si… era un typo che m’ero segnato ma che mi sono dimenticato di correggere.
Grazie
“MySQL è il database che si è imposto per la sua efficienza nello sviluppo di soluzioni WEB”
Ottimo articolo, come ormai ci hai abituati, ma non concordo con questa frase.
MySQL si è imposto e s’è diffuso semplicemente perché era un engine gratuito che permetteva di eseguire query SQL.
Sull’efficienza, infatti, ci sarebbe parecchio di che discutere, soprattutto riguardo ai tempi di sviluppo, visto che a MySQL sono mancante tantissime funzionalità per parecchio tempo, costringendo a sviluppare quelli che vengono chiamati “fat-client” (tante operazioni che su engine degni di questo nome erano a carico del server, su MySQL dovevano essere scritte a manina “emulandone”).
Mi spiace soltanto che non hai citato Firebird fra gli engine SQL open source (con licenza BSD), che offre delle pregevoli caratteristiche con un memory footprint molto ridotto e ottime prestazioni (grazie al suo engine multitransazionale. Qui http://www.slideshare.net/tomneko/firebird25-benchmarksenglish20091031 una presentazione che lo confronta proprio con MySQL e PostgreSQL).
Ho letto con curiosita’ e comunque sempre con piacere questi articoli, ma stavolta sono rimasto un po’ deluso. Senza offesa, eh, Felice, sempre comunque un ottimo lavoro, ma…
Onestamente, con quello che rappresentano i DB per l’informatica, piu’ che una lista di nomi e date (la sostanza di questi tre articoli poteva essere riassunta in una decina di righe al max senza tralasciare nessuna delle informazioni date) mi aspettavo una bella trattazione approfondita su tecnologie e caratteristiche dei vari DB. Sinceramente, tranne due cosette in quest’ultimo articolo, mancano completamente spiegazioni di cosa differenziasse davvero un DBE dall’altro (la differenza di memorizzazione dei record tra Oracle ed SQL, ad esempio, la gestione degli indici, i partizionamenti, il supporto agli standard, etc. etc. etc.)
Considera che questi articoli sono di carattere prettamente storico. Per lo meno, io li ho visti sempre così.
Per una trattazione dettagliata e tecnica servirebbe uno studio più approfondito, con gente che magari ha avuto modo di lavorare seriamente e professionalmente a diversi DB engine.
Personalmente ho avuto modo di apprezzare InterBase prima e Firebird dopo, proprio perché c’ho lavorato per diversi anni. E ho avuto modo di “apprezzare” MySQL per lo stesso motivo (anche se non ho approfondito engine diversi da InnoDB, perché in un database ho sempre ricercato solidità e affidabilità, che soltanto un engine ACID come minimo può garantire).
All’appello mi mancano grossi nome come DB2, Oracle, Sybase e MSSQL server, ma perché non ho lavorato a nessun progetto che li impiegasse.
Non dimentichiamoci di Firebird SQL, derivato da Interbase 6.0 della Borland. Ha tutt’ora molte frecce al suo arco ;)
Concordo. E’ il mio engine SQL preferito (mi trovo molto bene a svilupparci, anche in Python).
E aspetto con ansia la 3.0 per il prossimo anno, che rivoluzionerà ancora una volta l’engine, con un supporto ad SMP e multithreading nuovo di zecca (e ovviamente molto più prestazionale, anche se già adesso è uno degli engine ACID più veloci), oltre ad altre cosucce interessanti.
L’unica cosa che mi manca al momento è un sistema di mirroring di tipo master / slave “automatico” (cioè lo configuri semplicemente una volta, e pensa a tutto lui; Firebird style, insomma).
@Drittz, è esattamente come spiegato da Cesare. La mia “mission” è quella di raccontare l’evoluzione dei sistemi informatici. Una trattazione approfondita su un argomento complesso come quello degli RDBMS richiede tempo e competenze specifiche, per evitare strafalcioni.
Grazie a tutti per la lettura.