PostgreSQL 18 dynamise les performances OLTP

L’arrivée prochaine de PostgreSQL 18 divise les experts quant à son contenu. En effet, la dernière version de la base de données open source introduit des fonctionnalités qui améliorent les performances avec des gains significatif pour les charges de traitement transactionnel en ligne (OLTP). Mais elle fait l’impasse sur deux thèmes très tendances : le support des charges de travail hybride mêlant transactionnel et analytique (OLAP), et les agents IA. PostgreSQL est devenue une base de données incontournable pour les développeurs, en particulier pour créer des applications modernes de manière rentable en raison de la richesse de ses fonctionnalités, d’une extensibilité et d’une licence permissive qui favorise son adoption par les entreprises.

Cependant, PostgreSQL a un talon d'Achille : elle n'est pas efficace pour le traitement analytique, ce qui entrave sa compatibilité avec l’IA. En effet, le traitement hybride fournit aux agents IA davantage de contexte pour une meilleure prise de décision en fournissant des analyses en temps réel sur les données transactionnelles et opérationnelles en direct. « …PostgreSQL 18 ne propose aucune fonctionnalité spécifiquement adaptée aux charges de travail analytiques et d'IA », a expliqué Alastair Turner, évangéliste technologique chez Percona, fournisseur de PostgreSQL et d'autres bases de données.

Le traitement analytique en débat

Le manque de fonctionnalités pour les performances OLAP est si évident que Sam Lambert, cofondateur et CEO de PlanetScale, estime qu'il vaut mieux dissocier les problèmes et choisir une base de données OLTP dédiée (PostgreSQL) et ajouter des bases de données analytiques telles que ClickHouse, BigQuery, etc. « Le fait de séparer les ressources de calcul et de stockage dédiées à chaque usage réduit le risque que les conflits (concurrence entre les charges de travail pour les ressources partagées, telles que le CPU) deviennent problématiques et aient un impact négatif sur les performances des applications », explique le dirigeant de PlanetScale qui propose également une version gérée de PostgreSQL.

Mais, contrairement à Alistair Turner et à Sam Lambert, Tom Kincaid, vice-président senior des serveurs et outils de base de données chez EDB, un fournisseur de bases de données basées sur PostgreSQL, est un peu plus optimiste quant aux capacités analytiques de PostgreSQL 18, car il affirme que chaque version élargit son éventail de cas d’usage analytiques. « Par exemple, cette version (PostgreSQL 18) prend en charge la lecture asynchrone des données et de nombreuses améliorations de l'optimiseur. Ces évolutions accélèrent les performances pour les grands ensembles de données et les requêtes impliquant de nombreuses tables, soit exactement le type de charges de travail fréquemment impliquées dans l’analytique », a fait valoir M. Kincaid. Selon lui, des fonctionnalités comme les Foreign Data Wrappers (FDW) et la Table Access Method (TAM), ajoutées dans les versions précédentes, rendent possibles un plus grand nombre de charges de travail analytiques. Alors que les FDW agissent comme un pont dans PostgreSQL pour envoyer des requêtes à une source de données distante et d'en recevoir le résultat, la TAM permet aux utilisateurs de modifier les paramètres d'accès aux données et de les configurer pour l’analytique : notamment pour la lecture intensive, impliquant souvent des agrégations complexes sur de grands ensembles de données.

Gains de performances pour l'OLTP

Même si elle n’est pas prête pour l'IA, PostgreSQL 18 introduit quelques fonctionnalités qui, selon les experts, devraient se traduire par des gains de performances significatifs pour les charges de travail OLTP. C’est le cas, selon Sam Lambert, de la fonctionnalité Asynchronous I/O, ou AIO en abrégé. « L'utilisation de l’Asynchronous I/O via l'interface Linux « io_uring » devrait vraiment contribuer à améliorer les performances d'entrée/sortie ce qui se traduira par une réduction des latences. C'est un avantage considérable pour le transactionnel, où le temps est primordial… Cela devrait se traduire par des gains particulièrement importants dans les environnements équipés d'un NAS », a avancé le responsable. Selon M. Turner de Percona, l'E/S asynchrone permet aux opérateurs de bases de données d'émettre plusieurs instructions d'E/S sans attendre que les instructions précédentes soient terminées, ce qui améliore les performances en ne bloquant pas le traitement pendant l'attente du démarrage des opérations d'E/S suivantes. Cependant, les experts font remarquer qu'AIO prend actuellement en charge les lectures intensives sur disque, mais pas les écritures, ajoutant que des travaux sont en cours pour améliorer les écritures en masse et les écritures de points de contrôle. Parmi les exemples de charges de travail OLTP intensives en écriture, on peut citer la télémétrie des véhicules, les réseaux sociaux et les plateformes de jeux en ligne.

Une autre fonctionnalité qui améliorera les performances de PostgreSQL 18 dans l'indexation et la mise en cache est la mise à niveau de l'identifiant unique universel (Universally Unique Identifier, UUID) qui passe de la version 4 à la version 7. L'UUID est une valeur de 128 bits utilisée dans PostgreSQL pour fournir un identifiant unique au niveau mondial pour les enregistrements. Selon M. Turner, la version 7 diffère de la 4 dans la manière dont il stocke la valeur 128 bits. « Contrairement à l'UUID 4, qui est entièrement aléatoire, l'UUID 7 commence par un horodatage, ce qui signifie que les valeurs récentes de l'UUID 7 sont proches les unes des autres dans l'ordre de tri, et sont donc stockées sur un nombre réduit de pages d'index consécutives », a précisé le dirigeant, ajoutant que ce processus améliore l'efficacité de la mise en cache, car les données actives sont plus susceptibles de rester en mémoire. « Comparativement, l'UUID 4 disperse les valeurs récentes sur de nombreuses pages, ce qui rend la mise en cache moins efficace. »

Autres fonctionnalités notables

PostgreSQL offre également d'autres fonctionnalités intéressantes, notamment l'amélioration de Explain et OAuth. Selon M. Kincaid d'EDB, la commande Explain améliorée devrait aider les administrateurs de bases de données et les développeurs à identifier les situations dans lesquelles une requête doit être ajustée et la manière dont elle doit l'être, ce qui se traduira par un dépannage plus rapide, des systèmes optimisés et de meilleures performances. « Plus on dispose d'informations sur la manière dont le planificateur de requêtes a exécuté ou exécutera la requête, plus on a d'informations pour ajuster les statistiques, les index, les paramètres de configuration et la requête elle-même », a expliqué le responsable.

Quant à la fonctionnalité OAuth, elle améliorera considérablement la sécurité, selon les experts. « Elle devrait permettre à Postgres de s'intégrer beaucoup plus facilement aux systèmes de gestion des identités d'entreprise et contribuera à supprimer une grande partie des doublons et des processus potentiellement sources d'erreurs, tout en renforçant la sécurité en alignant Postgres sur les mêmes contrôles d'identité et d'accès utilisés dans toute l'entreprise », a ajouté M. Kincaid. La liste complète des modifications apportées à PostgreSQL est disponible dans les notes de mise à jour.