Footcow BlogFootcow Blog

Les bases de données et le machine learning... Deux mondes fascinants qui, jusqu'à récemment, semblaient évoluer sur des chemins parallèles. Mais que diriez-vous si je vous disais qu'il est désormais possible de marier ces deux univers directement au sein de votre base de données PostgreSQL ? Laissez-moi vous présenter PostgresML, la fusion parfaite entre stockage de données robuste et intelligence artificielle avancée.

PostgreSQL intègre depuis la version 9.4 un système de réplication logique, elle l'a rendu accessible à tous véritablement depuis la version 10 avec les fonctions de publication et d'abonnement. Mais avant tout, qu'est-ce que la réplication logique ?

Toujours dans les nouvelles syntaxes apparues dans la release 14 de PostgreSQL autour de la récursivité et après avoir vu la clause CYCLE dans un précédent article, nous allons étudier la clause SEARCH.

Le LATERAL JOIN est une extension puissante de la clause JOIN standard dans PostgreSQL. Contrairement à un JOIN normal, qui combine les lignes de deux tables en fonction d'une condition de jointure, un LATERAL JOIN permet de combiner les lignes d'une table avec les résultats d'une requête sur une autre table.

Chaque release majeure de PostgreSQL (passage de la version 9.6 à la 10 par exemple) nécessite d'effectuer un dump et un restore de la base de données. Le travail n'est pas si fastidieux, mais nécessite quelques manipulations. Debian propose une migration plus simplifiée, destinées, à mon avis, aux bases de données de petites tailles, pour une migration rapide. Si vous travaillez sur des bases de plusieurs Go, cela fonctionnera, bien sur, mais l'interruption de service pourra être longue. Il existe d'autres moyens pour faire ce genre de chose avec des serveurs de réplication par exemple. Je vais donc vous décrire le process simple à mettre en place.

Suite à un vieux billet concernant l'espace disque de vos bases de données PostgreSQL, il m'a souvent été demandé comment trouver la taille engloutie par les différents schémas qui composent votre base de données.

L'un des principal problème lié aux évolutions de PostgreSQL reste la migration des données. Changer de version va souvent de paire avec, une nouvelle installation de PostgreSQL, un dump complet de la base de données, puis un ré-import des données ... Dès que l'on a en place des bases de données de plusieurs centaines de giga-octets cela implique des interruptions de services longues, et donc de l'insatisfaction client. Heureuses la communauté de PostgreSQL est très active et s'est donc mis en tête de trouver des solutions à ce problème. La sortie de la version 8.4 de PostgreSQL fait donc apparaître une nouvelle option : la restauration en parallèle ... compatible également avec les versions précédentes de PostgreSQL (8.2 et 8.3) ! Un must have !

Je ne vais pas chercher à rentrer dans un débat sans fin sur le choix de la meilleure base de données open source ... Mais comme un de mes lecteurs me l'a demandé voilà déjà quelques temps je vais essayer objectivement de présenter chacune des bases et vous expliquer pourquoi j'ai porté mon choix sur l'une plus que sur l'autre.

Voilà une fonction peut-être mal connue de PostgreSQL, mais qui permet de réaliser des listes automatiques de données en quelques secondes.

generate_series(start, stop)

Son utilisation peut vous rendre bien des services, tant pour des générations de tableaux rapides, que pour avoir des cohérences de données parfaites sur des données séquentielles manquantes, ou encore pour générer des listes avancées de données comme des dates par exemple.

Mais les exemples sont souvent plus parlant que de longs discours ...

Qui n'a pas eu le besoin un jour de ressortir un listing contenant le détail de toutes les dernières commandes de ses clients ?

Jusque là ... il fallait souvent passer par des sous SELECT, un MAX et une vitesse de calcul pas souvent au rendez-vous ...
Du genre :

SELECT c.id, c.nom, f.id, f.date, f.total 
  FROM (clients c INNER JOIN factures f ON c.id = f.id)
       INNER JOIN
       (SELECT MAX(date) AS date_derniere_facture, id 
          FROM factures 
         GROUP BY id) AS mf ON mf.date_derniere_facture = f.date AND mf.id = c.id

Si vous êtes un utilisateur de PostgreSQL, vous pouvez vous simplifier la vie en utilisant la fonction DISTINCT ON, de la façon suivante :

SELECT DISTINCT ON (c.id) c.id, c.nom, f.id, f.date, f.total
  FROM clients c LEFT JOIN factures f ON c.id = f.id
 ORDER BY c.id, f.date DESC, f.id DESC;

Et le tour est joué, dans un temps record.