Le lauréat du prix Turing, dont les recherches et les startups ont façonné l'industrie pendant cinq décennies, a déclaré à The Reg qu'il avait encore beaucoup à faire.
Et si nous construisions le système d’exploitation au-dessus de la base de données au lieu de l’inverse ?
Cela ressemble à une idée d’étudiant après une microdose de trop, mais ce n’est pas le cas. C'est une idée sérieuse de la part de quelqu'un qui a déjà révolutionné l'industrie informatique et dont l'influence s'est étendue aux produits bien connus de Microsoft et d'Oracle.
Célébrant ses 80 ans cette année, Michael Stonebraker poursuit ses travaux de recherche sur les bases de données, mais son influence sur le secteur a été incontestablement marquée par PostgreSQL , le système de gestion de bases de données relationnelles open source qui, pour la première fois, est devenu le choix préféré des développeurs cette année, d'après l'enquête Stack Overflow 2023. Outre sa popularité en tant que SGBD open source, des fournisseurs tels que les géants du cloud CockroachDB et YugabyteDB proposent des services de bases de données dotés d'une interface compatible avec PostgreSQL.
Les premiers travaux influents de Stonebraker ont commencé avec Ingres, le premier système de base de données relationnelle, qui est devenu son sujet de recherche après avoir été nommé professeur adjoint à l'UC Berkeley en 1971.
S'adressant à The Register, il déclare :
Ma thèse de doctorat portait sur un aspect des chaînes de Markov, et j'ai réalisé qu'elle n'avait aucune valeur pratique. Je suis allé à Berkeley et j'avais cinq ans pour apporter ma contribution et obtenir la titularisation. Je savais que ce ne serait pas mon sujet de thèse. Ensuite, Eugene Wong, un autre membre du corps professoral de Berkeley, a déclaré : « Pourquoi ne regardons-nous pas les bases de données ? »
Les deux hommes ont lu une proposition récente sur les bases de données relationnelles, rédigée par Edgar Codd, chercheur chez IBM, intitulée « Un modèle de données relationnel pour les grandes bases de données partagées » .
Stonebraker et Wong ont trouvé l'idée de l'anglais élégante et simple.
La question évidente était d’essayer de construire un système de base de données relationnelle. Eugene et moi n'avions aucune expérience dans la création de logiciels système, mais, en tant qu'universitaires, nous avons pensé : essayons et voyons ce qui se passe. Ainsi, sans aucune expérience, nous avons commencé à créer Ingres. Et cela m’a valu mon poste de professeur.
Ingres avait des concurrents. Le System R d'IBM a été le premier à démontrer que l'approche relationnelle pouvait fournir des performances opérationnelles en matière de transactions et a été le premier à implémenter le SQL désormais omniprésent. Oracle a lancé son système relationnel à la fin des années 70. Ingres a également été confronté à un problème de plate-forme.
De nombreux visiteurs à Berkeley nous ont demandé qui était le plus gros utilisateur d’Ingres. Ensuite, l'Arizona State University a voulu l'utiliser pour une base de données de 35.000 XNUMX dossiers d'étudiants, mais elle n'a pas pu ignorer le fait qu'elle devait se procurer un système d'exploitation qui n'était pas pris en charge par ces gars des Bell Labs, qui était Unix.
Le ciblage d'Ingres sur les systèmes de milieu de gamme, dans lesquels Unix venait d'émerger, signifiait également qu'il ne prenait pas en charge COBOL, le langage dominant pour l'informatique d'entreprise à l'époque. La seule solution était de créer une entreprise.
dit Stonebraker.
Il a fondé Relational Technology pour commercialiser Ingres. Elle a ensuite été rebaptisée Ingres Corporation, puis rachetée par ASK Corporation en 1990, qui à son tour a été rachetée par Computer Associates en 1994. Un autre membre de l'équipe Berkeley Ingres, Robert Epstein, a fondé Sybase, qui pendant une décennie a été le deuxième derrière Oracle dans le domaine. marché des bases de données relationnelles. En 1992, sa gamme de produits a été concédée sous licence à Microsoft, qui l'a utilisée pour les premières versions de SQL Server.
Mais Stonebraker reconnaît que le code commercial d'Ingres était bien plus avancé que le projet de recherche open source — d'autres chercheurs pouvaient se le procurer pour une somme modique couvrant le coût du support de stockage et les frais d'envoi —, si bien que son équipe a décidé de tout abandonner et de repartir de zéro. Qui succédera à Ingres ? Postgres, bien sûr.
Une nouvelle ère. En 1986, un document de 28 pages [PDF] – co-écrit avec Larry Rowe – annonçait la conception de Postgres, son nom d'alors, et définissait six objectifs principaux. Deux d'entre eux se sont avérés essentiels à la pérennité du système de base de données : une meilleure prise en charge des objets complexes et une plus grande flexibilité pour les utilisateurs en matière de types de données, d'opérateurs et de méthodes d'accès.
Stonebraker nous explique avoir appris, lors de ses échanges avec les clients d'Ingres, que l'extensibilité serait essentielle au succès futur d'une base de données. « Un client m'a appelé un jour et m'a dit : "Vous avez complètement mal implémenté la gestion du temps" », raconte-t-il.
Le professeur de Berkeley était perplexe car son équipe avait fait de grands efforts pour s'assurer d'appliquer correctement le calendrier julien, y compris les années bissextiles. Mais certaines obligations financières sont payées en 12 mois égaux sur une année de 360 jours, ce qui n'est pas possible dans Ingres mais dans PostgreSQL, dit-il.
La volonté de rendre la base de données extensible était également motivée par le désir de prendre en charge de nouveaux types de données . Un projet initial avec Ingres tentait de l'utiliser comme système d'information géographique, loin de son domaine de prédilection : les données d'entreprise. « Il était d'une lenteur arbitraire et impossible à résoudre », explique Stonebraker.
Cette vision a porté ses fruits au cours de la dernière décennie. Il y a dix ans, PostgreSQL a ajouté la prise en charge des documents Json, le format de fichier sur lequel sont basées les bases de données NoSQL MongoDB et Couchbase.
Stonebraker a critiqué le mouvement NoSQL dans le passé. Il raconte à The Register qu'il convergeait vers les bases de données relationnelles parce qu'elles adoptaient SQL ou des langages de type SQL et acceptaient le besoin de cohérence.
La plus grande bonne idée de NoSQL était l'expérience prête à l'emploi, car avec les bases de données SQL, vous devez créer la base de données, puis définir le curseur. Ils sont difficiles à utiliser. C’est l’une des critiques les plus valables adressées aux bases de données SQL : l’expérience prête à l’emploi est nulle. Vous devriez pouvoir l'allumer et dire : "Voici quelques données".
Les différents services disponibles pour fournir des bases de données PostgreSQL et des bases de données compatibles PostgreSQL contribuent dans une certaine mesure à résoudre ce problème, mais l'émergence du SGBD en tant que système open source populaire était un heureux accident, et avec lequel Stonebraker n'avait pas grand-chose à voir.
Même si le code de recherche de la base de données était – et reste – open source, construire une société de bases de données autour de ce code était, à l'époque, impossible, comme Stonebraker l'a découvert en fondant Illustra en 1992. « Lorsque nous avons obtenu un financement en capital-risque à la fois pour Ingres et pour Postgres, les sociétés de capital-risque ne voulaient rien avoir à faire avec l'open source, c'était un phénomène ultérieur », dit-il.
En 2005, Stonebraker a fondé Vertica sur la base d'un SGBD partagé orienté colonnes pour l'entreposage de données, qui, selon lui, « aurait énormément bénéficié d'être open source, mais la vitalité du code open source et de la communauté VC est un phénomène relativement récent ».
« Les bases de données propriétaires ne représentent pas l'avenir. » Illustra a connu un certain succès pendant un temps. Elle a finalement été vendue à Informix pour environ 400 millions de dollars en 1996, la participation de Stonebraker étant évaluée à 6,5 millions de dollars, comme l'écrivait Forbes en 1997. Stonebraker a occupé le poste de directeur technique de la société mère pendant quatre ans.
C'est une somme confortable, mais ce n'est que des miettes de poulet comparée à la valeur nette estimée de Larry Ellison à 145 milliards de dollars. Il va sans dire que Stonebraker se montre dédaigneux à l'égard d'Oracle, un autre adepte précoce du modèle relationnel. « Ingres a toujours été techniquement meilleur et Postgres est pratiquement meilleur. C'est plus flexible et c'est open source. Et aujourd’hui, PostgreSQL est globalement comparable en termes de performances. En général, les bases de données fermées ne sont pas la voie de l'avenir et je pense qu'Oracle est très cher et peu flexible », déclare Stonebraker.
Cependant, c'est Oracle qui a pris une décision déterminante pour l'essor de PostgreSQL open source. L'entreprise a racheté MySQL, un logiciel libre dont certains membres de la communauté se méfiaient, le jugeant trop risqué de le confier à ce géant des logiciels propriétaires. Parallèlement, Illustra et d'autres sociétés ont commercialisé PostgreSQL, et Berkeley a publié le code source sous licence MIT, permettant ainsi à d'autres développeurs de l'utiliser.
En 1994, Andrew Yu et Jolly Chen, tous deux diplômés de Berkeley, ont remplacé le langage de requête POSTQUEL par SQL. Le Postgres95 résultant a été rendu disponible gratuitement et modifiable sous une licence plus permissive et renommé PostgreSQL.
Ce qui s'est finalement passé, c'est qu'Illustra gagnait du terrain, mais le grand coup a été lorsque ce groupe de personnes totalement indépendantes que je ne connaissais même pas, a récupéré le code open source Postgres, qui existait toujours, et l'a utilisé, totalement sans ma connaissance. C'était un merveilleux accident. Lorsque MySQL a été acheté par Oracle, les développeurs sont devenus méfiants en masse et sont passés à PostgreSQL. C'était un autre heureux accident. Son succès commercial est merveilleux, mais il est en grande partie dû au hasard.
ajoute Stonebraker.
Pendant ce temps, les services de bases de données se sont développés autour de PostgreSQL. Elle est devenue l'interface frontale la plus dominante pour les systèmes compatibles ou presque compatibles disponibles auprès de Google (AlloyDB et CloudSQL), Microsoft (Azure PostgreSQL), AWS (Aurora et RDS), CockcroachDB, YugabyteDB, EDB et Avien.
Le monde entier migre vers le cloud, et Google, Amazon et Microsoft misent tous sur la compatibilité PostgreSQL. Je pense que c'est une excellente idée. CockroachDB est compatible avec PostgreSQL. Vous pouvez prendre une application PostgreSQL et la déposer sur CockroachDB. PostgreSQL n'a pas de fonctionnalités de base de données distribuées, contrairement à YugabyteDB et CockroachDB.
L'influence de Stonebraker s'étend également au portefeuille de son rival Oracle. Sa base de données fédérée Mariposa est devenue la base de Cohera, une société de bases de données rachetée par PeopleSoft en 2001, avant de devenir partie intégrante d'Oracle en 2004. En 2014, Stonebraker a été reconnu pour l'influence de son travail sur Ingres et Posgres avec le Turing Award, ce qui a valu à Google 1 million de dollars dans le processus.
Bien que bon nombre de ses idées soient si largement utilisées dans l’industrie des bases de données, qui, selon Gartner, valait 91 milliards de dollars en 2022, Stonebraker se montre détendu à l’idée que d’autres personnes utilisent ses idées.
J’ai bien réussi financièrement. Je connaissais Ted Codd, qui était très magnanime en disant que vous devriez tous courir avec [des idées]. Vous voulez changer le monde ; chaque personne en particulier n’en est qu’une partie. J'ai toujours créé du code open source et partagé du code avec tous ceux qui le souhaitaient. Dans le processus, je me suis bien débrouillé financièrement donc oui, je n’ai aucun regret.
Mais cela ne signifie pas qu'il est prêt à prendre sa retraite. Dans son dernier projet, Stonebraker est prêt à changer le monde une fois de plus.
L'idée de DBOS, un système d'exploitation orienté base de données , est née d'une conversation avec Matei Zaharia, l'auteur d'Apache Spark, cofondateur de la société d'analyse et d'apprentissage automatique Databricks, et professeur associé à Berkeley.
Spark et Databricks gèrent les instances Spark dans le cloud. Zaharia a expliqué qu'à tout moment, Databricks gère souvent environ un million de sous-tâches Spark pour différents utilisateurs. Il n'était pas possible de réaliser cela avec les techniques traditionnelles de programmation du système d'exploitation : il fallait quelque chose qui puisse évoluer. La solution évidente consistait à mettre toutes les informations de planification dans une base de données. Et c'est exactement ce que les gars de Databricks ont fait : ils ont tout mis dans une base de données PostgreSQL, puis se sont plaints des performances de Postgres.
dit Stonebraker.
Jamais du genre à craindre les défis, Stonebraker pensa : « Eh bien, je peux faire mieux que ça. »
Le nouveau projet a remplacé Linux et Kubernetes par une nouvelle pile de système d'exploitation sous-jacente à un système de base de données, le prototype multi-nœuds multicœur, transactionnel et hautement disponible VoltDB, lancé par Stonebraker.
« Au fond, le système d'exploitation est une application de la base de données, et non l'inverse », explique-t-il.
Un article co-écrit par Stonebraker et Zaharia, entre autres, explique :
Tous les états du système d'exploitation doivent être représentés uniformément sous forme de tables de base de données, et les opérations sur cet état doivent être effectuées via des requêtes provenant de tâches autrement sans état. Cette conception facilite l'évolutivité et l'évolutivité du système d'exploitation sans avoir à refactoriser l'ensemble du système, à inspecter et à corriger l'état du système, à mettre à jour les composants sans temps d'arrêt, à gérer les décisions à l'aide de l'apprentissage automatique et à mettre en œuvre des fonctionnalités de sécurité sophistiquées.
Qu'elle réussisse ou non, l'idée d'une application de système d'exploitation en tant que base de données ne sera probablement pas la dernière de Stonebraker. Après avoir eu 80 ans en octobre, il déclare à The Register qu'il n'a pas l'intention de ralentir.
