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 cette année son 80ème anniversaire, Michael Stonebraker poursuit son travail dans la recherche de bases de données, mais son impact sur l'industrie a été consolidé avec PostgreSQL., le système de base de données relationnelle open source qui, pour la première fois, est devenu le choix le plus populaire parmi les développeurs cette année, selon l'enquête Stack Overflow 2023. En plus d'être un SGBD open source populaire, les fournisseurs, y compris les géants du cloud, , CockroachDB et YugabyteDB proposent des services de base de données avec une interface compatible 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 d'Edgar Codd, un chercheur d'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 a reconnu que le code commercial d'Ingres était bien en avance sur le projet de recherche open source (d'autres chercheurs pouvaient obtenir le code pour une somme modique couvrant la bande nécessaire à son stockage et les frais de port). Son équipe a donc décidé de jeter le code. une falaise et recommencer. Qu’y a-t-il après Ingres ? Évidemment Postgres.
Une nouvelle ère En 1986, un document de 28 pages [PDF] — co-écrit avec Larry Rowe — a annoncé la conception de Postgres, comme on l'appelait alors, en définissant six ambitions directrices. Parmi ceux-ci, deux se sont révélés pertinents pour la longévité du système de base de données. L'une d'elles consistait à fournir une meilleure prise en charge des objets complexes. La seconde était de fournir une extensibilité utilisateur pour les types de données, les opérateurs et les méthodes d'accès.
Stonebraker nous dit qu'il savait, grâce à des conversations avec des clients d'Ingres, qu'être extensible serait important pour le succès d'une base de données à l'avenir. « Un client m'a appelé un jour et m'a dit : « Vous avez mal appliqué le timing » », a-t-il déclaré.
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 motivation pour rendre la base de données extensible venait également du désir de prendre en charge de nouveaux types de données.. Un premier projet avec Ingres cherchait à l'utiliser comme système d'information géographique, loin de son territoire de données d'entreprise. Cela a été « arbitrairement lent et insoluble », dit 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 fermées ne sont pas la voie du futur » Illustra a connu du succès pendant un certain temps. Il a finalement été vendu à Informix pour environ 400 millions de dollars en 1996, la participation de Stonebraker étant évaluée à 6,5 millions de dollars, écrivait Forbes en 1997. Stonebraker est devenu CTO 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 qui a donné une impulsion à l'open source PostgreSQL. Il a acheté MySQL open source, auquel une partie de la communauté ne faisait pas confiance au géant du logiciel propriétaire. Au même moment où Illustra et d'autres sociétés commercialisaient Postgres, Berkeley publiait le code de POSTGRES sous licence MIT, permettant à d'autres développeurs de travailler dessus.
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 veut pas dire qu’il est prêt à prendre sa retraite. Dans son dernier projet, Stonebraker est prêt à changer à nouveau le monde.
L'idée de DBOS, un système d'exploitation orienté base de données, est né d'une conversation avec Matei Zaharia, auteur d'Apache Spark, co-fondateur de la société d'analyse et d'apprentissage automatique Databricks et professeur agrégé à 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.
"À la base, le système d'exploitation est une application de base de données, et non l'inverse." il prétend.
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.
