Spanner en préparation : l’objectif n’est pas une compatibilité à 100 %, selon Google à propos de l’interface PostgreSQL

Google a clarifié les détails de l’interface entre son populaire service de gestion de base de données SQL distribué et de stockage Spanner et le SGBDR open source PostgreSQL.

Selon un blog publié cette semaine, l’interface PostgreSQL de Spanner utilise “la familiarité et la portabilité de PostgreSQL” pour faciliter la vie des développeurs.

« Les équipes peuvent être assurées que les schémas et les requêtes qu’elles construisent sur l’interface Spanner PostgreSQL peuvent être facilement transférés vers un autre environnement PostgreSQL, ce qui leur offre flexibilité et tranquillité d’esprit », a déclaré Justin Makeig, chef de produit pour Cloud Spanner.

L’article explique que l’interface PostgreSQL de Spanner est conçue pour compiler les requêtes PostgreSQL sur les primitives de traitement et de stockage des requêtes distribuées existantes de Spanner. “Il prend également en charge le protocole filaire PostgreSQL, le canal de communication utilisé pour connecter les clients. Pour un développeur créant une application, cela est pratiquement transparent. Le provisionnement et la surveillance des bases de données utilisent Spanner et les outils existants de Google Cloud, tandis que l’interaction avec les données ressemble à PostgreSQL. Le la mise en œuvre touche chaque couche de la base de données pour assurer une expérience unifiée », a déclaré Makeig.

Mais pour ceux qui veulent une base de données distribuée avec un peu plus que “la familiarité et la portabilité” avec PostgreSQL, il existe des options.

Fondé par d’anciens ingénieurs de Facebook, Yugabyte s’inspire de Spanner en termes de base de données distribuée, mais revendique une compatibilité totale avec PostgreSQL depuis 2019. Sans surprise, il avait quelque chose à dire sur l’actualité de Google.

Karthik Ranganathan, co-fondateur et CTO de Yugabyte, a déclaré Le registre: “Cet effort de Google Spanner met en évidence l’importance de l’API PostgreSQL et de l’ensemble de fonctionnalités lorsqu’il s’agit de créer des applications cloud natives. Pour être pratiques, les bases de données doivent aller au-delà de la compatibilité filaire et prendre en charge les fonctionnalités PostgreSQL couramment utilisées telles que les procédures stockées, déclencheurs et fonctions définies par l’utilisateur. YugabyteDB y parvient en réutilisant le code de la couche de requête de PostgreSQL plutôt que de le réécrire à partir de zéro.”

Néanmoins, Sid Nag, Gartner veep des technologies cloud et de pointe, a déclaré que l’interface PostgreSQL de Google « bénéficierait à une adoption accrue de Spanner, car les développeurs et les administrateurs de bases de données qui connaissent déjà et maîtrisent PostgresSQL seront en mesure d’utiliser Spanner sans avoir à apprendre le langage natif. Interfaces Spanner, mécanismes de requête et API, etc., ouvrant ainsi l’utilisation de Spanner à un tout nouveau monde de développement d’applications.”

Cette semaine, l’équipe de technologie des données de Google a également déclaré qu’elle jouait bien avec d’autres outils populaires sur le terrain.

La Chocolaterie a annoncé l’intégration entre Tableau – l’outil de visualisation et d’analyse de données acheté par Salesforce pour 15,7 milliards de dollars en 2019 – et son propre outil sur le même marché, Looker.

L’intégration signifie que les clients de Tableau pourraient utiliser le modèle sémantique de Looker pour accéder aux données dans toute l’organisation, « permettant de nouveaux niveaux de gouvernance des données tout en démocratisant l’accès aux données ».

Le développement est également conçu pour associer la couche sémantique d’entreprise de Looker à la plate-forme d’analyse de Tableau.

Looker peut être utilisé à la fois comme outil d’analyse et de visualisation et comme plate-forme de données d’entreprise. L’intégration de Google avec Tableau est un signe qu’il découple les deux technologies, a déclaré Nag.

“L’idée est d’ouvrir Looker à de nouvelles technologies et interfaces basées sur l’analyse telles que Tableau. Avec ce développement, la plupart des organisations choisiront l’une ou l’autre, cependant, certaines peuvent avoir besoin à la fois de Looker et de Tableau – en fonction de leurs besoins variables en matière d’application et de charge de travail. et sur la base des préférences et des préjugés des développeurs. Google aidera les deux constituants grâce à cette nouvelle capacité. ” ®