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.

PostgreSQL comme toutes les bases de données modernes, permet de lier une table à une autre pour valider son intégrité. Ainsi vous n'aurez pas une table qui s'appuie sur les données d'une autre table sans cohérence. Vous ne pourrez donc écrire dans le champ utilisé en référence d'une autre table que des données qui existent bien dans la table de référence. Cette possibilité est pratique, rassurante et surtout preuve d'une conception cohérente du modèle de données. Mais, elle n'est pas sans impacte sur la vitesse de la base de données si les bons index ne sont pas placés sur ces champs. PostgreSQL vous laisse cette liberté. Cela peut donc engendrer parfois des surprises, en particulier quand on efface des données de la table de référence. L'absence d'index va engendrer un ralentissement considérable au moment du DELETE et donc vous pénaliser.

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 !

Un très bon article pour réaliser une migration de PostgreSQL v8.2 vers PostgreSQL v8.3 ... 9h sur le papier par un processus "classique", 2h30 au final ... joli travail !

Tous les détails sont à lire sur Speeding up dump/restore process

Vous devez le savoir, je suis plutôt un inconditionnel de la base de données PostgreSQL, robuste, stable, et plutôt rapide.
J'utilise PostgreSQL dans le cadre de mon activité professionnelle avec des bases de plusieurs millions d'utilisateurs, et des tables pouvant atteindre plusieurs dizaines de millions d'enregistrements ... Mais bon, l'une de nos plus grosse base doit être dans les alentours de 450 Go.
Il existe des bases en production avec des volumes de données bien plus importants ... et se sont fait connaître il y a peu de temps des utilisateurs de PostgreSQL comme Yahoo! et la NASA.