AlloyDB : Google veut greffer un turbo analytique à PostgreSQL
Le géant du cloud élargit son portefeuille de DBaaS avec un nouveau service voué à l’accélération des performances et des requêtes analytiques de la base de données PostgreSQL.
Google a encore ajouté une base de données en cloud à son portefeuille. Il a présenté la préversion d’AlloyDB lors de la conférence virtuelle Google I/O se déroulant le 11 et 12 mai.
Le groupe américain n’a pas encore communiqué de date pour la disponibilité générale.
AlloyDB est une base de données managée à la demande qui repose sur le SGBDR open source PostgreSQL. Google dispose déjà de plusieurs services cloud supportant PostgreSQL, dont Cloud Spanner et Cloud SQL for PostgreSQL.
« AlloyDB comble une lacune importante dans l’offre de bases de données de Google », assure Carl Olofson, analyste chez IDC. « Il s’agit d’un SGBD entièrement relationnel capable d’effectuer à la fois des analyses et des transactions, ainsi que des opérations mixtes que nous appelons traitement transactionnel analytique, chez IDC ».
Google intègre également son service Vertex AI à AlloyDB pour permettre aux utilisateurs d’utiliser le machine learning directement avec la base de données.
« Il s’agit d’un SGBD [AlloyDB] entièrement relationnel, capable d’effectuer à la fois des analyses et des transactions, ainsi que des opérations mixtes que nous appelons traitement transactionnel analytique, chez IDC »
Carl OlofsonAnalyste chez IDC
Combiner les traitements analytiques et transactionnels
Les fournisseurs adoptent cette tendance depuis quelques années. Alors qu’IDC parle de cette capacité sous le nom d’ATP, Forrester Research évoque le principe de bases de données translytiques, tandis que des éditeurs comme PingCAP la désignent sous l’appellation « traitement transactionnel et analytique hybride ». Google Cloud utilise le diminutif HTAP.
Carl Olofson considère que les fonctionnalités d’AlloyDB se distinguent des autres offres de bases de données de Google, notamment Cloud Spanner et BigQuery. Il estime que BigQuery est idéale pour effectuer des requêtes sur de grandes tables. Spanner, vise à proposer d’exécuter des traitements distribués sur des bases de données déployées dans de multiples régions cloud. Enfin, AlloyDB est taillé pour l’approche HTAP.
Quant à savoir pourquoi Google a décidé de construire une énième base de données prenant en charge PostgreSQL, Andi Gutmans, directeur général et VP de l’ingénierie, bases de données chez Google Cloud, explique dans une interview que cette offre émane de la demande des clients. Un discours que l’on a déjà entendu de la part du responsable quand il travaillait chez AWS.
Selon Andi Gutmans, les clients de Cloud SQL for Potgres sont satisfaits du service, mais qu’ils ont besoin de plus de sécurité, de performance, de scalabilité et de disponibilité.
Pour répondre à ces besoins, le responsable évoque le fait qu’AlloyDB est compatible avec la version open source de PostgreSQL. Selon Andy Gutmans, cela permettra aux clients de l’adopter et de migrer leurs workloads plus facilement.
Toujours d’après le responsable, Google se concentre sur la qualité du service, ses performances et son évolutivité.
Outre l’architecture distribuée, AlloyDB bénéficie du système de fichier à l’échelle d’un cluster, Colossus. Or celui-ci propulse déjà Spanner, Cloud SQL ou encore FireStore.
Les mécanismes pour différencier AlloyDB
Bien qu’il semble commun à un bon nombre de services, le découplage du calcul et du stockage ainsi que le système de réplication multizone sont spécifiques à AlloyDB. C’est le moyen choisi par le géant du cloud pour parer la grosse limitation de PostgreSQL. À savoir qu’à un moment donné, pour étendre l’implémentation du SGBD, les administrateurs créent des copies de la base en lecture seule. Bien que standard, cette technique allonge le temps de failover et provoque des latences.
Au lieu de copier la base de données, Google Cloud propose d’ajouter plusieurs instances de réplique en lecture seule en soutien de l’instance principale du SGBD en charge des traitements de requêtes.
Cette architecture repose sur une couche de stockage distribuée à travers une région cloud comprenant un service pour écrire les WAL (write ahead logs ou les informations sur l’ensemble des changements INSERT/UPDATE/DELETE) depuis l’instance principale du SGBD vers un magasin à faible latence.
Depuis ce log store, des services de traitement des logs WAL produisent des « blocs » de base de données placés dans un espace de stockage régional et shardé. Ces blocs représentent l’état du contenu du SGBD à un instant T. Ces opérations sont rejouées très rapidement à chaque modification de données. En cas de plantage du nœud primaire ou de la chute d’un bloc de données, ceux-ci peuvent être « resservis » au nœud principal et aux répliques, afin d’éviter les pertes d’information. Selon GCP, cela optimise les chemins I/O, la création des répliques sans multiplier les copies inutilement.
Pour lire les données dans PostgreSQL, l’instance primaire et les répliques emploient un buffer in-memory, partagé entre les différents processus pour stocker les tables, les index et les plans d’exécution. Avec son architecture, GCP affirme qu’il n’y a pas besoin que la base de données interagisse avec la couche de stockage, tant qu’un bloc de stockage n’est pas tombé. Et si les requêtes sont trop lourdes pour ce buffer, Google Cloud a ajouté une couche de cache supplémentaire au niveau du SGBD.
Cette architecture censée être plus performante ne règle pas tous les inconvénients de PostgreSQL. Par défaut, le SGBD stocke les données en ligne. Or le stockage de données orienté colonnes demeure plus performant pour les usages analytiques. Il doit accélérer les requêtes et compresser les données, là où le SGBDR open source peine à tenir la charge en cas d’usage intensif s’il n’est pas supporté par une infrastructure bien plus coûteuse.
Heureusement, PostgreSQL endure efficacement les extensions. GCP a développé un accélérateur (ou moteur) orienté colonnes. Celui-ci comprend un espace de stockage et un moteur de requête optimisé qui promet des performances « jusqu’à 100 fois » supérieures à un Postgres standard. C’est ce dispositif qui permet d’obtenir des capacités HTAP et de concurrencer les services d’AWS, d’Oracle et de Microsoft. Par exemple, la firme de Redmond soutient le projet Citus (depuis le rachat de la startup éponyme en 2019), qui a rejoint Azure for PostgreSQL, et qui propose à peu choses près les mêmes fonctionnalités. C’est également la spécialité de Swarm64, acquis par ServiceNow.
Pour ce qui est de l’avenir, Andy Gutmans a déclaré que l’équipe de développement d’AlloyDB de Google avait de nombreuses idées sur la manière de continuer à améliorer le traitement des requêtes ainsi que leur optimisation.
« Je pense que nous sommes bien partis, mais il y a beaucoup d’autres idées sur les choses que nous pourrions faire pour rendre l’expérience du client encore plus facile », affirme-t-il.
