PostgreSQL 17 renforce la prise en charge de JSON

Des gains de performance un peu partout

Avec PostgreSQL 17, le groupe (450 contributeurs actifs) a souhaité apporter des gains de performance, une révision complète du système de gestion de la mémoire pour le nettoyage (vacuum), des optimisations de l’accès au stockage, des charges de travail concurrentes, du chargement et de l’export de données batch via Copy. De plus, l’option On-Error autorise la poursuite des imports malgré des erreurs.

La mise à jour accélère également les recherches de plusieurs valeurs dans l’index B-tree et permet la création d’index BRIN en employant plusieurs workers en parallèle.

Le fameux nettoyage (ou vacuuming) est une opération de maintenance périodique pour récupérer de l’espace disque et améliorer les performances de la base de données. Elle sert notamment à réorganiser ou à supprimer les « tuples morts », des versions de lignes dans une table un temps exploitée pour manier les transactions concurrentes qui ne sont plus à jour. Le processus est donc critique pour les tables dont les données sont fréquemment actualisées.

Elle implique d’utiliser un certain pourcentage de CPU et de mémoire. Une « nouvelle structure interne de la mémoire » permet de réduire par 20 la quantité de RAM nécessaire à l’intervention. Le vacuuming serait ainsi plus rapide et laisserait plus de ressources disponibles pour les autres charges de travail.

Un autre processus essentiel de PostgreSQL est le WAL (Write-Ahead Logging). Cette méthode de journalisation garantit que toutes les modifications de données sont enregistrées avant d’être réellement écrites dans la base de données. Le traitement WAL a été revu grâce à une révision de la couche I/O, ce qui permettrait de multiplier par deux le débit d’écriture des charges de travail « hautement concurrentes ».

« En outre, la nouvelle interface d’I/O en continu accélère les balayages séquentiels (lecture de toutes les données d’une table) et la vitesse à laquelle ANALYZE peut mettre à jour les statistiques du planificateur », précisent les contributeurs.

Pour rappel, ANALYZE est la commande gérant la bonne planification des requêtes. Justement, d’autres modifications ont été effectuées afin d’optimiser des requêtes courantes.

Par ailleurs, le groupe indique que le SGBDR prend en charge davantage d’instructions SIMD, « dont AVX-512 pour la fonction bit_count » (introduite avec PG 14), ce qui permettrait une amélioration générale des calculs.

La réplication logique, un moyen de créer des flux de données en temps réel de type Pub/Sub était déjà un sujet d’attention de PostgreSQL 16. Cette technique bénéficie désormais d’un moyen de contrôler le failover et de deux outils pour convertir des répliques physiques en répliques logiques (pg_createsuscriber), ainsi que de conserver les slots de réplications des éditeurs (Pub) et des abonnés (Sub). « Avant cette version, les utilisateurs qui souhaitaient effectuer une mise à niveau de version majeure devaient abandonner les slots de réplication logique, ce qui nécessitait de resynchroniser les données vers les abonnés après une mise à niveau », expliquent les contributeurs principaux.

À noter qu’une nouvelle option TLS permet d’exécuter un handshake direct à partir du répertoire ALPN, tandis qu’il est plus facile de déléguer les opérations de maintenance avec des rôles prédéfinis. Enfin, PG 17 prend en charge les backups incrémentiels, avec une commande (pg_combinebackup) pour reconstruire une sauvegarde complète.

JSON_TABLE, un coup de pouce pour les développeurs

Un volet majeur d’investissement de la communauté PostgreSQL n’est autre que le traitement des fichiers JSON, un format très utile pour les développeurs. N’en déplaise à Oracle, le PostgreSQL Global Development Group rappelle que Postgres est « la première base de données relationnelle à prendre en charge JSON » en 2012.

Or la communauté a pris un certain retard concernant une fonctionnalité présente dans MySQL, SQL Server et (plus récemment) Oracle.

PostgreSQL 17 vient rattraper ce retard en prenant en charge les JSON_TABLE, déjà sur la feuille de route du projet il y a deux ans.

Elle est accompagnée de constructeurs (JSON, JSON_SCALAR, JSON_SERIALIZE), de fonctions de requêtes (JSON_EXISTS, JSON_QUERY, JSON_VALUE) et d’expressions jsonpath pour convertir les données JSON en types de données natifs à PostgreSQL (numérique, booléen, string, date/heure, etc.).

Selon Abhina Anand, ingénieur logiciel dans la branche indienne de R&D de Mercedes-Benz, JSON_Table doit grandement améliorer la prise en charge des types de colonnes JSON et JSONB dans PostgreSQL. Sans cette option, il fallait écrire des requêtes SQL « qui peuvent devenir très complexes, voire illisibles ».

« Un bon cas d’usage de JSON_TABLE est celui où vous devez travailler avec des données structurées stockées dans un document JSON, mais où vous souhaitez interagir avec elles à l’aide d’opérations SQL traditionnelles », explique-t-il, dans un billet de blog. « En mappant des parties du document JSON en lignes et en colonnes, JSON_TABLE crée une table virtuelle qui vous permet de traiter les données JSON comme n’importe quelle autre table relationnelle », poursuit-il. « Cela peut s’avérer particulièrement utile quand vous devez insérer des données extraites dans une table de base de données existante ou lorsque vous voulez interroger les données JSON dans le cadre d’une jointure, d’un filtre ou d’une agrégation SQL ».

PostgreSQL 17 apporte par ailleurs des améliorations à la commande MERGE, comme la clause RETURNING et la possibilité de mettre à jour des vues. Les nouvelles fonctionnalités incluent le support des colonnes d’identité et des contraintes d’exclusion sur les tables partitionnées, ainsi qu’une meilleure exécution des sous-requêtes EXISTS et IN avec postgres_fdw. Enfin, une collation immuable basée sur UTF-8 est intégrée pour garantir des résultats de tri cohérents sur toutes les plateformes.

Des préversions disponibles chez les fournisseurs cloud, PostgreSQL 18 en préparation

EDB s’est engagé à supporter commercialement PostgreSQL 17. Microsoft Azure a présenté la préversion du SGBDR depuis Azure Database for PostgreSQL Flexible Server, en commençant par la région cloud East-Asia. De même, AWS propose cette version dans un mode préliminaire dans Amazon RDS for PostgreSQL. L’image de la base est déjà disponible depuis Docker Hub.

Il y a trois mois, lors de la PGConf.dev 2024 à Vancouver, la communauté a évoqué les évolutions du SGBD. Si la feuille de route concernant PostgreSQL 18 demeure en cours d’élaboration, plusieurs améliorations des réplications logiques, des exécuteurs, du partitionnement ainsi que la parallélisation de certains traitements (vacuum, index GIN, sous requêtes corrélées, etc.) sont en réflexion.

« Comme vous le voyez, nous ne nous concentrons pas seulement sur l’optimisation d’une fonctionnalité par mise à jour », déclare Amit Kapila, contributeur majeur de PostgreSQL et directeur senior chez Fujitsu, lors de la conférence. « L’objectif est de rendre PostgreSQL de plus en plus exploitable par les entreprises et les fournisseurs ».