Google veut greffer un turbo analytique à 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 égallement son service Vertex AI à AlloyDB pour permettre aux utilisateurs d’utiliser le machine learning directement avec la base de données.

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 trait». 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 à exécuter des traitements distributes sur des bases de donne déployés 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, exp lique dans une demand interviewe des é cette 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 changes INSERT/UPDATE/DELETE) depuis l’instance principale du magasin un à faible late. 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 d’interagir 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 eponyme en 2019), qui a rejoint Azure for PostgreSQL, et qui propose à peu choses près les memes fonctionnalités. C’est égallement 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 opt ​​des requêtes ainsi que leur.

« Je pense que nous sommes bien partis, mais il ya 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.

Leave a Comment