Google a annoncé aujourd’hui le lancement d’AlloyDB, un nouveau service de base de données compatible avec PostgreSQL entièrement géré qui, selon la société, est deux fois plus rapide pour les charges de travail transactionnelles que l’Aurora PostgreSQL comparable d’AWS (et quatre fois plus rapide que le 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 ancré dans l’écosystème Google Cloud, un service de base de données PostgreSQL entièrement géré peut vous sembler familier. Après tout, la société propose déjà CloudSQL pour PostgreSQL et Spanner, le service de base de données relationnelle entièrement géré de Google Cloud, propose également une interface PostgreSQL. Mais ce sont des services qui proposent 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 pleinement l’infrastructure de Google, tout en permettant à l’équipe de rester à jour avec les nouvelles versions lors de leur lancement.
Crédits image : Google
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 l’entreprise lance ce nouveau produit est que si Google a bien réussi à aider les entreprises clients déplacent leurs serveurs MySQL et PostgreSQL vers le cloud à l’aide de services tels que CloudSQL, l’entreprise n’avait pas nécessairement les bonnes offres pour les clients qui souhaitaient déplacer leurs anciennes bases de données (Gutmans ne l’a pas dit explicitement, mais je pense vous pouvez insérer en toute sécurité « Oracle » ici) à un service open source.
« Il y a différentes raisons à cela », m’a-t-il dit. « Premièrement, ils utilisent en fait plus d’un fournisseur de cloud, ils veulent donc avoir la flexibilité de fonctionner partout. Il y a beaucoup de gadgets de licence peu amicaux, 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 se débarrasser de ces bases de données héritées. Ils en ont assez d’être attachés et enfermés.
Ajoutez à cela la montée en puissance de Postgres pour devenir en quelque sorte une norme de facto pour les bases de données relationnelles open source (et le déclin de MySQL) et vous comprendrez pourquoi Google a décidé de pouvoir proposer un service PostgreSQL hautes performances dédié.
Crédits image : Google
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. L’équipe a donc 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.
« Quand j’ai rejoint AWS, c’était l’occasion de rester dans l’espace développeur mais de vraiment travailler sur les 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, ont eu l’occasion de voir à quel point les données sont importantes et critiques pour les clients. [ … ] Ce type de public était principalement un public de développeurs, car ce sont des développeurs qui utilisent des bases de données pour créer leurs applications. Ensuite, je suis entré dans l’espace d’analyse chez AWS, et j’ai en quelque sorte découvert l’autre côté de celui-ci. D’une part, les gens à qui je parlais n’étaient plus nécessairement des développeurs – beaucoup d’entre eux étaient du côté commercial ou des analystes – mais j’ai aussi vu que ces mondes convergeaient vraiment. Ces utilisateurs voulaient obtenir des informations en temps réel à partir de leurs données, exécuter des algorithmes de détection de fraude dessus ou effectuer une personnalisation en temps réel ou une gestion des stocks à grande échelle.
Crédits image : Google
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. Cela, selon 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’arrivez pas toujours à 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 avec Postgres.
Les modifications apportées par l’équipe au noyau Postgres, par exemple, lui permettent désormais d’adapter le système de manière linéaire à plus de 64 cœurs virtuels, tandis que du côté analytique, l’équipe a créé un service de mise en cache personnalisé basé sur l’apprentissage automatique pour apprendre les modèles d’accès d’un client et puis convertissez le format de ligne de Postgres en un format de colonne en mémoire qui peut être analysé beaucoup plus rapidement.
