Il vincitore del Turing Award, la cui ricerca e le startup hanno segnato il settore per cinque decenni, rivela a The Reg di avere ancora delle novità in serbo.
E se costruissimo il sistema operativo sopra il database invece che il contrario?
Sembra un’idea di uno studente universitario dopo una microdose di troppo, ma non lo è. È un’idea seria di qualcuno che ha già rivoluzionato l’industria informatica e la cui influenza si è diffusa in prodotti noti di Microsoft e Oracle.
Celebrando il suo 80° compleanno quest’anno, Michael Stonebraker prosegue il suo lavoro nella ricerca sui database, ma il suo impatto sull’industria è stato cementato con PostgreSQL, il sistema di database relazionale open source che, per la prima volta, quest’anno è diventato la scelta più popolare tra gli sviluppatori, secondo il sondaggio Stack Overflow 2023. Oltre ad essere un DBMS open source popolare, fornitori tra cui i colossi del cloud, CockroachDB e YugabyteDB offrono servizi di database con un’interfaccia compatibile con PostgreSQL.
Il primo lavoro influente di Stonebraker iniziò con Ingres, il primo sistema di database relazionale, che nacque come suo argomento di ricerca dopo essere stato nominato assistente professore all’UC Berkeley nel 1971.
Parlando con The Register, dice:
La mia tesi di dottorato era su un aspetto delle catene di Markov, e mi resi conto che non aveva alcun valore pratico. Andai a Berkeley, e avevo cinque anni per fare un contributo e ottenere la tenure. Sapevo che non sarebbe stato il mio argomento di tesi. Poi Eugene Wong, un altro membro del corpo docente a Berkeley, disse: ‘Perché non guardiamo ai database?’
I due lessero una recente proposta sui database relazionali di Edgar Codd, ricercatore IBM, chiamata “Un modello relazionale di dati per grandi banche dati condivise.”
Stonebraker e Wong trovarono l’idea dell’inglese elegante e semplice.
La domanda ovvia era provare a costruire un sistema di database relazionale. Entrambi Eugene e io non avevamo esperienza nella costruzione di software di sistema ma, come accademici, pensammo, proviamoci e vediamo cosa succede. Così, basandoci su nessuna esperienza, iniziammo a costruire Ingres. E questo mi ha fatto ottenere la mia cattedra.
Ingres aveva dei concorrenti. Il System R di IBM fu il primo a dimostrare che l’approccio relazionale poteva fornire prestazioni transazionali operative e fu il primo ad implementare l’ormai onnipresente SQL. Oracle iniziò il suo sistema relazionale alla fine degli anni ’70. Ingres dovette anche affrontare un problema di piattaforma.
Abbiamo ricevuto molte visite a Berkeley e ci chiedevano chi fosse il più grande utilizzatore di Ingres. Poi l’Arizona State University voleva usarlo per un database di record di 35.000 studenti ma non potevano superare il fatto che dovevano ottenere un sistema operativo non supportato da questi ragazzi ai Bell Labs, ovvero Unix
Il targeting di Ingres sui sistemi di fascia media, nei quali Unix era appena emerso, significava anche che non supportava COBOL, il linguaggio dominante per il computing aziendale di quel tempo. L’unica soluzione era avviare un’azienda.
dice Stonebraker.
Fondò Relational Technology per commercializzare Ingres. Fu in seguito rinominata Ingres Corporation e poi acquistata da ASK Corporation nel 1990, che a sua volta fu acquistata da Computer Associates nel 1994. Un altro membro del team di Berkeley Ingres, Robert Epstein, fondò Sybase, che per un decennio fu seconda a Oracle nel mercato dei database relazionali. Nel 1992, la sua linea di prodotti fu concessa in licenza a Microsoft, che la utilizzò per le prime versioni di SQL Server.
Ma Stonebraker riconosce che il codice commerciale di Ingres era molto avanti rispetto al progetto di ricerca open source — altri ricercatori potevano ottenere il codice per una tariffa nominale che copriva il nastro richiesto per memorizzarlo e i costi postali — quindi il suo team decise di gettare il codice oltre una scogliera e ricominciare da capo. Cosa viene dopo Ingres? Ovviamente Postgres.
Una nuova era Nel 1986, un documento di 28 pagine [PDF] — co-scritto con Larry Rowe — annunciò la progettazione di Postgres, come era allora noto, stabilendo sei ambizioni guida. Tra queste, due si sono rivelate pertinenti per la longevità del sistema di database. Una era fornire un migliore supporto per oggetti complessi. La seconda era fornire estendibilità all’utente per tipi di dati, operatori e metodi di accesso.
Stonebraker ci dice di aver saputo dalle conversazioni con i clienti di Ingres che essere estensibile sarebbe stato importante per un database di successo in futuro. “Una volta un cliente mi chiamò e disse, ‘Hai implementato il tempo tutto sbagliato’,” disse.
Il professore di Berkeley era perplesso perché il suo team aveva fatto di tutto per assicurarsi di implementare correttamente il calendario Giuliano, anni bisestili inclusi. Ma alcune obbligazioni finanziarie vengono pagate in 12 mesi uguali in un anno di 360 giorni, cosa che non puoi implementare in Ingres ma puoi in PostgreSQL, dice.
La motivazione per rendere il database estensibile venne anche dal voler supportare nuovi tipi di dati. Un primo progetto con Ingres cercò di usarlo come un sistema di informazioni geografiche, lontano dal suo terreno di casa dei dati aziendali. Era “arbitrariamente lento e irrisolvibile,” dice Stonebraker.
La visione ha pagato nell’ultimo decennio. Dieci anni fa, PostgreSQL ha aggiunto il supporto per i documenti Json, il formato di file attorno al quale si basano il database NoSQL MongoDB e Couchbase.
Stonebraker è stato critico in passato nei confronti del movimento NoSQL. Dice a The Register che stava convergendo con i database relazionali perché adottavano SQL o linguaggi simili a SQL e accettavano la necessità di coerenza.
La più grande buona idea di NoSQL era l’esperienza out of box, perché con i database SQL, devi costruire il database, e poi devi definire il cursore. Sono difficili da usare. Questa è una delle critiche molto valide fatte contro i database SQL: l’esperienza out-of-the-box fa schifo. Dovresti essere in grado di accenderlo e dire, ‘Ecco dei dati’.
I vari servizi disponibili per fornire database PostgreSQL e database compatibili con PostgreSQL vanno in qualche modo a indirizzare questo, ma l’emergere del DBMS come sistema open source popolare è stato un felice incidente, e uno di cui Stonebraker ha avuto poco a che fare.
Sebbene il codice di ricerca per il database fosse – e rimane – open source, costruire un’azienda di database attorno ad esso era, al tempo, impossibile, come Stonebraker scoprì fondando Illustra nel 1992. “Quando abbiamo ottenuto finanziamenti di capitale di rischio sia per Ingres che per Postgres, i VC non volevano avere nulla a che fare con l’open source, quello era un fenomeno successivo,” dice.
Nel 2005, Stonebraker fondò Vertica basata su un DBMS column-oriented condiviso per il data warehousing, che ora dice “avrebbe tratto immenso beneficio dall’essere open source ma la vitalità del codice open source e della comunità VC è un fenomeno relativamente recente.”
‘I database closed source non sono l’onda del futuro’ Illustra ebbe successo per un periodo. Alla fine fu venduta a Informix per circa 400 milioni di dollari nel 1996, con la quota di Stonebraker del valore di 6,5 milioni di dollari, scrisse Forbes nel 1997. Stonebraker divenne CTO dell’azienda madre per quattro anni.
È una somma confortevole, ma briciole di pollo rispetto al patrimonio netto stimato di Larry Ellison di 145 miliardi di dollari. Inutile dire che Stonebraker è sprezzante nei confronti di Oracle, un altro adottante precoce del modello relazionale. “Ingres è sempre stato tecnicamente migliore e Postgres è praticamente migliore. È più flessibile, ed è open source. E oggi, PostgreSQL è generalmente paragonabile in termini di prestazioni. In generale, i database closed source non sono l’onda del futuro e penso che Oracle sia molto costoso e non molto flessibile,” dice Stonebraker.
Tuttavia fu Oracle a prendere una decisione che fornì un impulso a PostgreSQL open source. Ha acquistato MySQL open source, che parte della comunità non si fidava nelle mani del gigante del software proprietario. Allo stesso tempo, Illustra e altre aziende commercializzarono Postgres, Berkeley rilasciò il codice per POSTGRES sotto la licenza MIT, permettendo ad altri sviluppatori di lavorarci su.
Nel 1994, Andrew Yu e Jolly Chen, entrambi laureati a Berkeley, sostituirono il linguaggio delle query POSTQUEL con SQL. Il risultante Postgres95 fu reso liberamente disponibile e modificabile sotto una licenza più permissiva e rinominato PostgreSQL.
Quello che è finito per accadere è stato Illustra che stava guadagnando terreno, ma il grande colpo è stato quando questo gruppo di persone totalmente non correlate che nemmeno conoscevo, raccolse il codice open source di Postgres, che era ancora in giro, e corse con esso, totalmente all’insaputa mia. È stato un meraviglioso incidente. Quando MySQL è stata acquistata da Oracle, gli sviluppatori si sono insospettiti a frotte e sono passati a PostgreSQL. È stato un altro felice incidente. Il suo successo commerciale è meraviglioso, ma è stato in gran parte serendipitario.
aggiunge Stonebraker.
Nel frattempo, i servizi di database sono cresciuti attorno a PostgreSQL. È diventato l’interfaccia frontale più dominante per sistemi compatibili, o quasi compatibili, disponibili da Google (AlloyDB e CloudSQL), Microsoft (Azure PostgreSQL), AWS (Aurora e RDS), CockcroachDB, YugabyteDB, EDB e Avien.
Il mondo intero si sta spostando verso il cloud e Google, Amazon e Microsoft stanno tutti scommettendo sul ranch sulla compatibilità con PostgreSQL. Penso che sia un’ottima idea. CockroachDB è compatibile con PostgreSQL. Puoi prendere un’applicazione PostgreSQL e farla cadere su CockroachDB. PostgreSQL non ha alcuna capacità di database distribuito ma sia YugabyteDB che CockroachDB le hanno.
L’influenza di Stonebraker raggiunge anche il portfolio del rivale Oracle. Il suo database federato Mariposa divenne la base per Cohera, una società di database acquistata da PeopleSoft nel 2001, prima di diventare parte di Oracle nel 2004. Nel 2014, Stonebraker è stato riconosciuto per l’influenza del suo lavoro su Ingres e Posgres con il Premio Turing, guadagnando 1 milione di dollari da Google nel processo.
Nonostante molte delle sue idee siano così ampiamente utilizzate nell’industria dei database, che Gartner ha detto valeva 91 miliardi di dollari nel 2022, Stonebraker è rilassato riguardo ad altre persone che usano le sue idee.
Ho fatto bene finanziariamente. Conoscevo Ted Codd, che era molto magnanimo nel dire che tutti voi dovreste correre con le [idee]. Vuoi cambiare il mondo; ogni persona in particolare ne è solo una parte. Ho sempre fatto codice open source e condiviso codice con chiunque lo volesse. Nel processo, ho fatto bene finanziariamente quindi sì, non ho rimpianti affatto.
Ma questo non vuol dire che sia pronto a ritirarsi. Nel suo ultimo progetto, Stonebraker è pronto a cambiare il mondo di nuovo.
L’idea per DBOS, un Sistema Operativo Orientato ai Database, è nata da una conversazione con Matei Zaharia, autore di Apache Spark, cofondatore della società di analisi e machine learning Databricks e professore associato presso Berkeley.
Spark e Databricks si occupano di gestire istanze di Spark nel cloud. Zaharia ha spiegato che, in un dato momento, Databricks gestisce spesso circa un milione di sotto-compiti di Spark per vari utenti. Non era possibile farlo utilizzando le tecniche tradizionali di programmazione dei sistemi operativi: era necessario qualcosa che potesse scalare. La soluzione evidente era inserire tutte le informazioni di pianificazione in un database. Ed è esattamente ciò che hanno fatto i ragazzi di Databricks: hanno inserito tutto in un database PostgreSQL, per poi lamentarsi delle prestazioni di Postgres.
racconta Stonebraker.
Mai uno che evita una sfida, Stonebraker ha pensato: “Beh, posso fare meglio di così.”
Il nuovo progetto ha sostituito Linux e Kubernetes con un nuovo stack di sistema operativo alla base del quale si trova un sistema di database, il prototipo multi-nodo multi-core, transazionale, altamente disponibile VoltDB, che Stonebraker ha avviato.
“Di base, il sistema operativo è un’applicazione per il database, piuttosto che il contrario” afferma.
Un articolo coautore di Stonebraker e Zaharia tra gli altri spiega:
Tutto lo stato del sistema operativo dovrebbe essere rappresentato uniformemente come tabelle di database, e le operazioni su questo stato dovrebbero essere effettuate tramite query da compiti altrimenti senza stato. Questo design facilita la scalabilità ed evoluzione del SO senza dover rifattorizzare l’intero sistema, ispezionare e correggere lo stato del sistema, aggiornare i componenti senza tempi di inattività, gestire decisioni utilizzando l’apprendimento automatico e implementare funzionalità di sicurezza sofisticate.
Indipendentemente dal successo o meno, l’idea dell’applicazione OS-come-database è improbabile che sia l’ultima di Stonebraker. Dopo aver compiuto 80 anni a ottobre, dice a The Register che non ha intenzione di rallentare.
