Postgres partout | InfoMonde

SQLite est le moteur de base de données le plus largement déployé au monde. C’est dans votre téléphone, c’est dans votre navigateur, et si vous effectuez une recherche sur votre ordinateur, vous y trouverez également ses fichiers .db. SQLite a été inspiré par Postgres. Son auteur Richard Hipp a qualifié SQLite de “fork conceptuel” de Postgres. Il n’y a pas de code partagé, mais Postgres était l’étoile polaire sur laquelle il a aligné SQLite. Les deux sont complémentaires, a-t-il dit, des manières suivantes.

postgres SQLiteName
Dépôt de données d’entreprise Format du fichier de candidature
Serveur client Sans serveur
Augmenter Réduire

De nos jours, ces distinctions ont commencé à s’estomper. Par exemple, SQLite est considéré comme une base de données embarquée. Mais Postgres le devient aussi. Par exemple, nous disons que Steampipe embarque Postgres. Ce n’est pas techniquement vrai. Vous ne pouvez pas lier Postgres à une application binaire, mais vous pouvez (comme le fait Steampipe) fournir un binaire qui installe, exécute et coopère avec Postgres. Ou considérez Yugabyte, qui boulonne la couche de requête Postgres sur une couche de stockage distribuée. Pas techniquement une intégration de Postgres, peut-être, mais sans doute l’équivalent moral.

Steampipe et Yugabyte ne sont pas seulement compatibles avec Postgres ; ils en fait sont Postgres avec des fonctionnalités supplémentaires (encapsuleurs de données étrangères de Steampipe pour les API, stockage distribué de Yugabyte). Les utilisateurs peuvent se connecter à ces produits avec psql, la borne interactive de Postgres ; ils peuvent écrire les mêmes types de requêtes ; ils peuvent utiliser des extensions groupées ou tierces.

Nous ne verrons peut-être pas de sitôt des milliards de déploiements Postgres, comme c’est étonnamment vrai pour SQLite, mais vos appareils sont plus que capables d’exécuter Postgres et plus encore, pour une raison ou une autre, ils le feront. Que pourraient faire toutes ces instances de Postgres ?

Systèmes de fichiers améliorés

Extrait d’une chronique InfoWorld de 2003, A tale of two Cairos :

La conférence des développeurs professionnels (PDC) de Microsoft en 2003 a rappelé à certains observateurs le même événement en 1993, lorsque les sujets d’actualité étaient les API Win32, un brouillon de Windows 95 nommé Chicago et un aperçu d’un système de fichiers objet futuriste basé sur Le successeur de NT porte le nom de code Cairo. Les sujets d’actualité cette année étaient les API gérées par WinFX, un brouillon d’une future version de NT portant le nom de code Longhorn, et… Le Caire. Désormais appelée WinFS, cette vision du stockage enrichi de métadonnées et de la récupération basée sur les requêtes était et reste convaincante.

Aucune prédiction de la disparition du système de fichiers n’a résisté à l’épreuve du temps, et je n’en fais pas maintenant, mais j’observerai que les bases de données SQL d’aujourd’hui sont bien mieux équipées que leurs ancêtres pour enrichir le système de fichiers de manière plus complète que SQLite. sur une base par application. L’idée autrefois futuriste des objets en tant que citoyens de première classe de la base de données, par exemple, est maintenant concrétisée sous la forme de colonnes JSON. Et Postgres en particulier, grâce à ses API d’extension radicalement ouvertes, non seulement unit les données relationnelles aux objets JSON, mais englobe également les données clé-valeur, texte intégral, hiérarchiques, géospatiales, chronologiques et en colonnes.

Entre les deux extrêmes de Richard Hipp — base de données client/serveur et format de fichier d’application — il existe un juste milieu : une base de données locale. Lorsque vous installez Steampipe sur votre ordinateur Windows ou Mac, vous installez également Postgres. Pour moi, cela a été une expérience révélatrice. Steampipe regroupe Postgres afin d’interroger les API, d’exécuter des tests de conformité et de visualiser les données accessibles aux API. Mais une instance locale de la base de données peut également gérer toutes sortes de tâches de gestion de données à l’échelle du système plutôt qu’à l’échelle de l’application.

Le système de fichiers ne disparaît pas, mais une base de données locale peut puissamment le compléter. Pour le faire de manière omniprésente, une telle base de données doit être un produit open source. SQLite a montré la voie. Si Postgres emboîtait le pas, ce serait un hommage approprié à son protégé.

Synchronisation des données

Dans un monde où Postgres est partout, les instances devront se synchroniser avec d’autres instances de différentes manières. Postgres offre une multitude de mécanismes pour le faire. Lors de l’utilisation de la fonctionnalité de réplication en continu intégrée, un serveur principal transfère les données de manière synchrone vers un ou plusieurs récepteurs de secours. Une autre fonctionnalité intégrée, l’envoi de journaux, transfère de manière asynchrone des lots d’enregistrements de journaux d’un serveur principal à un serveur de secours.

Comme toujours, l’écosystème d’extension robuste de Postgres augmente les capacités intégrées. Une extension tierce, pglogical, implémente la réplication logique pour les éditeurs et abonnés non Postgres tels que Kafka et RabbitMQ. Vous pouvez trouver un certain nombre d’autres solutions dans cette catégorie en pleine expansion.

Pendant ce temps, l’extension postgres_fdw intégrée tire parti de Postgres wrapper de données étrangères mécanisme permettant de connecter des tables locales et distantes pour les opérations de lecture et d’écriture. D’une manière ou d’une autre, une instance Postgres exécutée sur vos appareils, ou dans vos clouds personnels et d’équipe, pourra se synchroniser avec des instances exécutées ailleurs.

Un environnement d’exécution d’application indépendant de la langue

Les deux exemples dominants de runtimes indépendants du langage sont la JVM (Java Virtual Machine) et le runtime .NET. Les deux activent les langages de programmation principaux – Java et C #, respectivement – mais les deux activent également d’autres langages qui utilisent les systèmes de type communs et les services d’exécution de ces moteurs. Pour la JVM, les langages notables incluent Groovy, Kotlin, Scala et Clojure. Pour .NET, ils incluent F# et VB.NET.

Bien qu’il ne soit pas largement connu ou apprécié, Postgres fournit également un système de type commun disponible dans de nombreuses langues. Par exemple, voici une fonction Postgres native qui renvoie un résultat booléen si son argument de chaîne correspond à l’un d’une liste énumérée de modèles d’expressions régulières.

create function matches_humanities(course_name text) returns boolean as $$
  select
    string ~* any(array[
      'psych',
      'religio',
      'soci'
    ]);
$$ language sql;

=> select matches_humanities('Religion 202');

 matches_humanities
--------------------
 t
(1 row)

Voici cette même fonction écrite en PL/Python, une extension Postgres qui fait de Python une autre façon d’implémenter les fonctions Postgres.

create function matches_humanities(course_name text) returns boolean as $$
  import re
  regexes = [
    'psych',
    'religio',
    'soci'
  ]
  matches = [r for r in regexes if re.search(r, course_name, re.I)]
  return len(matches)
$$ language plpython3u;

L’auteur d’une instruction SELECT qui appelle cette fonction ne sait pas ou ne se soucie pas que la fonction soit implémentée dans le langage natif de Postgres, ou en PL/Python, ou dans un autre des langages procéduraux disponibles.

Les programmeurs de bases de données d’un certain âge sont familiarisés avec l’utilisation de procédures stockées qui s’exécutent à l’intérieur de la base de données, à la vitesse de la base de données, avec un accès direct aux données. Avec le support de Postgres pour les procédures et les fonctions écrites dans des langages modernes, cette technique désormais démodée mérite un second regard. SQL a toujours été un langage hybride : un noyau relationnel augmenté d’une bibliothèque de fonctions. Lorsque vous pouvez étendre cette bibliothèque de fonctions en utilisant le langage de votre choix – Python, JavaScript, R – Postgres commence à ressembler à un autre type de serveur d’applications.

Les fonctions présentées ci-dessus, par exemple, forment l’ensemble des expressions régulières directement dans le code. Une version plus robuste les approvisionnerait à partir d’une table de base de données. Dans l’approche désormais conventionnelle, cela se produirait dans un processus séparé : connectez-vous à la base de données, envoyez-lui une requête SQL, décompressez le résultat. Quand Postgres est le serveur d’application, vous pouvez simplement réécrire la fonction pour utiliser une paire de tables.

select 
  *
from 
  course_names c
join
  humanities_patterns h
on c.course_name ~* h.pattern;

Comme précédemment, l’auteur de la requête select matches_humanities('Religion 202') ne saura pas faire la différence.

Notez également que les fonctions ne doivent pas uniquement renvoyer des valeurs simples comme le booléen dans ces exemples. Il peut également s’agir de fonctions renvoyant des ensembles qui génèrent des tables que vous pouvez interroger et joindre comme des tables conventionnelles, et qui sont éventuellement régies par des définitions de type indépendantes de la langue. Cette approche permet à SQL de se fondre avec d’autres langages d’une manière autrement impossible.

science des données

La littérature sur la science des données regorge de guides qui montrent comment réimplémenter les fonctionnalités de base de SQL dans des langages, tels que Python et R, qui sont populaires parmi les scientifiques des données. Une recette typique pour Python commence par l’importation de données d’une table SQL vers une base de données Pandas, la construction de base au cœur de la science des données à saveur Python, puis montre comment traduire les idiomes SQL en idiomes Pandas correspondants.

SQL Pandas
sélectionnez * des aéroports aéroports
sélectionnez * parmi les aéroports limite 3 aéroports.head(3)
sélectionnez l’identifiant des aéroports où ident=”KLAX” aéroports[airports.ident == ‘KLAX’].identifiant
sélectionner un type distinct de l’aéroport aéroports.type.unique()
sélectionnez * parmi les aéroports où iso_region = ‘US-CA’ et type=”seaplane_base” aéroports[(airports.iso_region == ‘US-CA’) & (airports.type == ‘seaplane_base’)]
sélectionnez l’identifiant, le nom, la municipalité des aéroports où iso_region = ‘US-CA’ et type=”large_airport” aéroports[(airports.iso_region == ‘US-CA’) & (airports.type == ‘large_airport’)][[‘ident’, ‘name’, ‘municipality’]]

Le même modèle apparaît souvent dans la littérature R : utilisez un adaptateur pour extraire les données d’une base de données SQL dans une construction de type table spécifique au langage, puis utilisez des idiomes spécifiques au langage pour répliquer les idiomes SQL de base pour l’interroger.

Pourquoi ne pas utiliser les données SQL et les idiomes de requête SQL standard sur place? Si Postgres vit sur votre machine locale et dans vos clouds personnels et d’équipe, et héberge Python ou R, vous pouvez interroger avec SQL et utiliser ces langages (et leurs vastes bibliothèques !) pour les pouvoirs spéciaux d’apprentissage automatique et statistiques qu’ils apportent au tableau.

Une plateforme omniprésente pour travailler avec les données

J’ai montré ailleurs comment Steampipe utilise les wrappers de données étrangères Postgres pour unifier l’accès aux API. C’est aussi un bel exemple de Postgres intégré qui s’exécute sur votre ordinateur Windows, Mac ou Linux, dans un conteneur ou dans le cloud. L’instance Steampipe de Postgres charge une extension qui implémente des wrappers de données étrangères pour les API, fournit un gestionnaire de plug-ins pour gérer la suite croissante d’adaptateurs qui communiquent avec les API et inclut un serveur de tableau de bord pour visualiser les requêtes de ces API. Et en tant qu’instance de Postgres, il peut également charger d’autres extensions qui étendent les pouvoirs de la base de données dans toutes les dimensions : types de données, langages, synchronisation, stockage.

Steampipe n’est qu’un des panneaux indiquant un monde dans lequel Postgres fonctionne partout. Nous appelons Postgres une base de données, et bien sûr c’en est une, mais il devient également une plate-forme qui donne accès à toutes sortes de données et apporte des styles de calcul modernes directement à ces données.

Jon Udell est le responsable de la communauté Steampipe chez Turbot.

Le New Tech Forum offre un lieu d’exploration approfondie et étendue des technologies d’entreprise émergentes. La sélection est subjective, basée sur notre sélection des technologies que nous pensons importantes et les plus intéressantes pour les lecteurs d’InfoWorld. InfoWorld n’accepte pas les supports marketing pour publication et se réserve le droit de modifier tout le contenu contribué. Envoyez toutes les demandes à newtechforum@infoworld.com.

Copyright © 2022 IDG Communications, Inc.

Leave a Comment