Google a annoncé aujourd’hui le lancement de AlliageDB, un nouveau service de base de données entièrement géré compatible PostgreSQL que la société prétend être deux fois plus rapide pour les charges de travail transactionnelles que le service comparable d’AWS Aurora PostgreSQL (et quatre fois plus rapide que PostgreSQL standard pour les mêmes charges de travail et jusqu’à 100 fois plus rapide pour les requêtes analytiques).

Si vous êtes profondément dans l’écosystème Google Cloud, un service de base de données PostgreSQL entièrement géré peut sembler familier. La société, après tout, propose déjà CloudSQL pour PostgreSQL et Spanner, le service de base de données relationnelle entièrement géré de Google Cloud offre également un Interface PostgreSQL. Mais ce sont des services qui offrent une interface compatible avec PostgreSQL pour permettre aux développeurs ayant ces compétences d’utiliser ces services. AlloyDB est la base de données PostgreSQL standard à la base, bien que l’équipe ait modifié le noyau pour lui permettre d’utiliser au maximum l’infrastructure de Google, tout en permettant à l’équipe de rester à jour avec les nouvelles versions au fur et à mesure de leur lancement.

Crédits d’image: Google (en anglais seulement

Andi Gutmans, qui a rejoint Google en tant que directeur général et vice-président de l’ingénierie pour ses produits de base de données en 2020 après un long passage chez AWS, m’a dit que l’une des raisons pour lesquelles la société lance ce nouveau produit est que, bien que Google ait bien réussi à aider les entreprises clientes à déplacer leurs serveurs MySQL et PostgreSQL vers le cloud à l’aide de services tels que CloudSQL, la société n’avait pas nécessairement les bonnes offres pour les clients qui voulaient déplacer leurs bases de données héritées (Gutmans ne l’a pas dit explicitement, mais je pense que vous pouvez insérer en toute sécurité « Oracle » ici) vers un service open source.

« Il y a différentes raisons à cela », m’a-t-il dit. « Tout d’abord, ils utilisent en fait plus d’un fournisseur de cloud, ils veulent donc avoir la flexibilité nécessaire pour fonctionner partout. Il y a beaucoup de gadgets de licence hostiles, traditionnellement. Les clients détestent vraiment, vraiment cela et, je dirais, alors qu’il y a probablement deux ou trois ans, les clients s’en plaignaient, ce que je remarque maintenant, c’est que les clients sont vraiment prêts à investir des ressources pour simplement sortir de ces bases de données héritées. Ils en ont marre d’être attachés et enfermés. »

Ajoutez à cela l’ascension de Postgres pour devenir en quelque sorte un standard de facto pour les bases de données open source relationnelles (et le déclin de MySQL) et il devient clair pourquoi Google a décidé qu’il voulait être en mesure d’offrir un service PostgreSQL dédié haute performance.

Crédits d’image: Google (en anglais seulement

Gutmans a également noté que de nombreux clients de Google souhaitent désormais utiliser leurs bases de données relationnelles pour des cas d’utilisation analytiques, de sorte que l’équipe a consacré beaucoup d’efforts à améliorer les performances de Postgres pour ces utilisateurs. Compte tenu de l’expérience de Gutmans chez AWS, où il était le propriétaire de l’ingénierie pour un certain nombre de services d’analyse AWS, ce n’est probablement pas une surprise.

« Lorsque j’ai rejoint AWS, c’était l’occasion de rester dans l’espace des développeurs, mais de vraiment travailler sur des bases de données », a-t-il expliqué.  « C’est à ce moment-là que j’ai travaillé sur des choses comme les bases de données de graphes et [Amazon] ElastiCache et, bien sûr, a eu l’occasion de voir à quel point les données sont importantes et critiques pour les clients. [ … ] Ce type d’audience était vraiment un public de développeurs principalement, car ce sont des développeurs qui utilisent des bases de données pour créer leurs applications. Ensuite, je suis allé dans l’espace d’analyse chez AWS, et j’ai en quelque sorte découvert l’autre côté de la médaille. D’une part, les gens à qui je parlais n’étaient plus nécessairement des développeurs – beaucoup d’entre eux étaient du côté des affaires ou des analystes – mais j’ai aussi vu que ces mondes convergent vraiment. » Ces utilisateurs souhaitaient obtenir des informations en temps réel à partir de leurs données, exécuter des algorithmes de détection de fraude ou effectuer une personnalisation ou une gestion des stocks en temps réel à grande échelle.

Crédits d’image: Goolge

Sur le plan technique, l’équipe AlloyDB s’est appuyée sur l’infrastructure existante de Google, qui désagrège le calcul et le stockage. C’est la même couche d’infrastructure qui exécute Spanner, BigQuery et essentiellement tous les services de Google. Ceci, a fait valoir Gutmans, donne déjà au service une longueur d’avance sur ses concurrents, en plus du fait qu’AlloyDB se concentre spécifiquement sur PostgreSQL et rien d’autre. « Vous n’avez pas toujours l’occasion d’optimiser autant lorsque vous devez prendre en charge plus d’un [database engine and query language]. Nous avons décidé que ce que les entreprises nous demandent [is] Postgres pour ces migrations de bases de données héritées, alors faisons de notre mieux dans Postgres. »

Les modifications apportées par l’équipe au noyau Postgres, par exemple, lui permettent désormais de faire évoluer le système de manière linéaire vers plus de 64 cœurs virtuels, tandis que du côté analytique, l’équipe a construit un m personnalisé.Service de mise en cache basé sur l’apprentissage achine pour connaître les modèles d’accès d’un client, puis convertir le format de ligne de Postgres en un format en colonnes en mémoire qui peut être analysé beaucoup plus rapidement.