IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

PostgreSQL 15 est disponible, elle améliore de l'ordre de 25 % à 400 % ses algorithmes de tri en mémoire et sur disque,
Et apporte la populaire commande MERGE

Le , par Bruno

69PARTAGES

7  0 
Le PostgreSQL Global Development Group annonce le 13 octobre la sortie de PostgreSQL 15, elle s'appuie sur les améliorations de performance des versions récentes avec des gains notables pour la gestion des charges de travail dans les déploiements locaux et distribués, notamment un tri amélioré. Cette version améliore l'expérience du développeur avec l'ajout de la populaire commande MERGE, et ajoute plus de capacités pour observer l'état de la base de données.

« La communauté des développeurs PostgreSQL continue de construire des fonctionnalités qui simplifient l'exécution des charges de travail de données à haute performance tout en améliorant l'expérience des développeurs », a déclaré Jonathan Katz, membre de la Core Team PostgreSQL. « PostgreSQL 15 montre comment, grâce au développement de logiciels ouverts, nous pouvons offrir à nos utilisateurs une base de données idéale pour le développement d'applications et sûre pour leurs données critiques. »


PostgreSQL, un système de gestion de données connu pour sa fiabilité et sa robustesse, bénéficie de plus de 25 ans de développement open source par une communauté mondiale de développeurs. Il s’agit de l'un des systèmes de gestion des bases de données open source les plus avancés. Il est riche en fonctionnalités, avec des types de données robustes, une indexation puissante et un large éventail de fonctions intégrées que peuvent être utilisé pour simplifier la pile de données et permettre aux développeurs de se concentrer sur la création de son application. Postgres dispose de :

  • une base de données relationnelle ;
  • une base de données documentaire avec un support JSON complet ;
  • un support géospatial ;
  • partitionnement pour les données de séries chronologiques.

Voici, ci-dessous, les améliorations apportées à la cersion 15 de PostgreSQL

Amélioration des performances de tri et de la compression

Dans cette dernière version, PostgreSQL améliore ses algorithmes de tri en mémoire et sur disque, avec des benchmarks montrant des accélérations de 25 % à 400 % en fonction des types de données triées. L'utilisation de row_number(), rank(), dense_rank() et count() comme fonctions de fenêtre présente également des avantages en termes de performances dans PostgreSQL 15. Les requêtes utilisant SELECT DISTINCT peuvent maintenant être exécutées en parallèle.

En se basant sur le travail de la version précédente de PostgreSQL pour permettre les requêtes distantes asynchrones, le wrapper de données étrangères de PostgreSQL, postgres_fdw, supporte maintenant les commits asynchrones.

Les améliorations de performance de PostgreSQL 15 s'étendent à ses fonctions d'archivage et de sauvegarde. PostgreSQL 15 intègre le support de la compression LZ4 et Zstandard (zstd) aux fichiers WAL (write-ahead log), ce qui peut avoir des avantages en termes d'espace et de performance pour certaines charges de travail. Sur certains systèmes d'exploitation, PostgreSQL 15 intègre le support de la préextraction des pages référencées dans WAL pour aider à accélérer les temps de récupération. La commande de sauvegarde intégrée de PostgreSQL, pg_basebackup, supporte maintenant la compression côté serveur des fichiers de sauvegarde avec un choix de gzip, LZ4 et zstd.

La version 15 de PostgreSQL inclut la possibilité d'utiliser des modules personnalisés pour l'archivage, ce qui élimine la surcharge liée à l'utilisation d'une commande shell.

Fonctionnalités expressives pour les développeurs

PostgreSQL 15 inclut la commande standard SQL MERGE. Elle permet d'écrire des instructions SQL conditionnelles qui peuvent inclure des actions INSERT, UPDATE et DELETE dans une seule instruction. Le graphique ci-dessous est une représentation simple de cette opération.


La logique métier, qui aurait autrement nécessité de nombreuses lignes de code (LOC), est simplifiée par cette instruction conditionnelle. En réduisant le nombre de LOC, on réduit également les coûts de maintenance à long terme. MERGE existe depuis un certain temps dans Oracle et SQL Server, et un avantage intéressant de l'implémentation dans PostgreSQL est qu'elle facilite le transfert du code SQL d'Oracle à PostgreSQL.

Cette dernière version ajoute de nouvelles fonctions permettant d'utiliser des expressions régulières pour inspecter les chaînes de caractères : regexp_count(), regexp_instr() regexp_like() et regexp_substr(). Elle étend également la fonction range_agg pour agréger les types de données à plages multiples, qui ont été introduits dans la version précédente.

La version 15 de PostgreSQL permet aux utilisateurs de créer des vues qui interrogent les données en utilisant les permissions de l'appelant, et non du créateur de la vue. Cette option, appelée security_invoker, ajoute une couche supplémentaire de protection pour s'assurer que les appelants de la vue ont les permissions correctes pour travailler avec les données sous-jacentes.

Amélioration de la réplication logique

La réplication logique a été ajoutée au noyau de PostgreSQL dans la version 10. Depuis lors, elle a progressé à grands pas et a ajouté de nombreuses améliorations et fonctionnalités au noyau. Avant la version 10, la réplication logique ne pouvait être réalisée qu'avec l'aide de l'extension pglogical. PostgreSQL 15 offre plus de flexibilité pour gérer la réplication logique. Cette version introduit le filtrage des lignes et les listes de colonnes pour les éditeurs, permettant aux utilisateurs de choisir de répliquer un sous-ensemble de données d'une table.

PostgreSQL 15 intègre des fonctionnalités pour simplifier la gestion des conflits, notamment la possibilité de ne pas rejouer une transaction conflictuelle et de désactiver automatiquement un abonnement si une erreur est détectée. Cette version inclut également la prise en charge de l'utilisation du commit à deux phases (2PC) avec la réplication logique. Avec la version 15 de PostgreSQL, la réplication logique ajoute la fonctionnalité tant attendue des filtres de niveau ligne et colonne.

Réplication logique - Filtre de lignes et de colonnes


Améliorations de la journalisation et de la configuration

PostgreSQL 15 introduit un nouveau format de journalisation : jsonlog. Ce nouveau format produit des données de journalisation en utilisant une structure JSON définie, ce qui permet aux journaux PostgreSQL d'être traités dans des systèmes de journalisation structurés. Cette version donne aux administrateurs de bases de données plus de flexibilité dans la manière dont les utilisateurs peuvent gérer la configuration de PostgreSQL, en ajoutant la possibilité d'accorder aux utilisateurs la permission de modifier les paramètres de configuration au niveau du serveur. De plus, les utilisateurs peuvent maintenant rechercher des informations sur la configuration en utilisant la commande \dconfig à partir de l'outil de ligne de commande psql.

Autres changements notables

Les statistiques de niveau serveur de PostgreSQL sont désormais collectées dans la mémoire partagée, éliminant à la fois le processus de collecte des statistiques et l'écriture périodique de ces données sur le disque. La version 15 de PostgreSQL permet de faire d'une collation ICU (Le service de collation ICU permet de comparer des chaînes de caractères et prend en charge les ordres de tri appropriés pour chacune des zones dont l’utilisateur a besoin) la collation par défaut pour un cluster ou une base de données individuelle.


Cette version ajoute également une nouvelle extension intégrée, pg_walinspect, qui permet aux utilisateurs d'inspecter le contenu des fichiers journaux en écriture directement depuis une interface SQL.

PostgreSQL 15 révoque également la permission CREATE de tous les utilisateurs, à l'exception du propriétaire de la base de données du schéma public (ou par défaut). Elle supprime à la fois le mode « sauvegarde exclusive », longtemps décrié, et le support de Python 2 dans PL/Python. Si la version 15 de PostgreSQL apporte des améliorations notables, il n’en reste pas moins vrai que certaines attentes ne sont toujours pas comblées. À l’instar d’Amazon RDS (Amazon Relational Database Service) qui ne supporte pas la version 15 de PostgreSQL.


Amazon RDS est un service de base de données relationnelle distribuée proposé par Amazon Web Services (AWS). Il s'agit d'un service web fonctionnant « dans le cloud » et conçu pour simplifier la configuration, l'exploitation et la mise à l'échelle d'une base de données relationnelle destinée à être utilisée dans des applications. Les processus d'administration tels que l'application de correctifs au logiciel de base de données, la sauvegarde des bases de données et l'activation de la récupération ponctuelle sont gérés automatiquement.

Amazon RDS pour PostgreSQL prend en charge de nombreuses extensions pour le moteur de base de données PostgreSQL. La communauté PostgreSQL les appelle parfois des modules. Les extensions étendent la fonctionnalité fournie par le moteur PostgreSQL. Les utilisateurs du service de base de données d’Amazon devront encore attendre que Postgres intègre cette modification dans son noyau.

Source : PostgreSQL Global Development Group

Et vous ?

Quelles améliorations de PostgreSQL 15 vous intéresse le plus ?

Quels manquements souhaiteriez-vous voir corriger sur PostgreSQL ?

À votre avis, PostgreSQL 15 peut-elle mieux apporter satisfaction que ses concurrents : Oracle, Microsoft SQL Server, MySQL ou encore Amazon Aurora ?

Quel SGBD preferez-vous le plus ? Pourquoi ?

Voir ausssi :

La majorité des serveurs PostgreSQL sur Internet ne seraient pas sécurisés, selon Jonathan Mortensen, alors qu'il est souvent considéré comme un système plus fiable et plus robuste que MySQL

PostgreSQL : Supabase annone la mise en libre accès de Postgres-wasm, un serveur PostgreSQL qui fonctionne dans un navigateur

PostgreSQL aurait commencé à travailler sur le support de la compression Zstandard, pour compléter toutes les possibilités de LZ4 que l'on trouve actuellement dans PostgreSQL 14

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de spl33n
Nouveau membre du Club https://www.developpez.com
Le 15/10/2022 à 16:12
Que du bon.

Quelles améliorations de PostgreSQL 15 vous intéresse le plus ?
Pour ceux que ça interpellent, la compatibilité avec des services type Amazon du coup.

À votre avis, PostgreSQL 15 peut-elle mieux apporter satisfaction que ses concurrents : Oracle, Microsoft SQL Server, MySQL ou encore Amazon Aurora ?
A chaque usage, son outil. Les utilisateurs d'outils open Source se débrouilleront, c'est pour ça qu'on carbure en Open source, pour avoir les mains pleine de cambouis

Quel SGBD preferez-vous le plus ? Pourquoi ?
Postgres, au top pour le SIG.

Quand aux tests de perf, pour une représentativité pertinente :
  • les réaliser sous distribution Linux (base Debian ou RedHat)
  • les réaliser sous MacOs
  • 10 points de mesure ne sont pas représentatifs, ils en faudrait, au grand minimum syndical, 100 mesures (donc 100+ queries par OS)
  • utiliser des versions plus récentes
  • comparer sur des tâches spécifiques : des données géospatiales ne sont pas des données textes, etc..
  • le coût
7  0 
Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 15/10/2022 à 21:40
au boulot on a sqlserver 2014 et postgres 11.

postgres est très rapide dans presque toutes les situations, et la gestion des champs json est superbe. Le merge est facilement remplaçable par un insert on conflict.

Sqlserver provoque énormément de lock (on ne peut pas activer le RCSI). Pas de json, les champs XML sont hyper lents, le mode snapshot est capricieux dans les insert ou update. Le TSQL est cool par contre, les stored procedures sont pas mal. Les server links sont vraiment un atout. Le mode read uncommited est un vrai fléaut.
Toujours pas de regexp, ils ont attendu combien de temps pour faire un string aggregat ?
9  3 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 16/10/2022 à 21:09
Pour avoir fait 2 entreprise qui utilisaient Oracle, des bugs remontés n'étaient jamais corrigés malgré les relances (depuis 3-4 ans). La dernière entreprise avait commencé par faire une migration isofonctionnelle quand je suis parti (les tests n'étaient pas terminés).

En tout cas pour du gratuit, je trouve Postgres très bien. Il n'est pas parfait mais aucun SGBDR ne l'est.
5  0 
Avatar de Tarul
Membre éprouvé https://www.developpez.com
Le 18/10/2022 à 11:07
Citation Envoyé par yannickt Voir le message
Je n'ai jamais eu l'occasion d'utiliser PostgreSQL, je ne savais pas qu'il avait ce genre de lacune. Merci pour ton commentaire très informatif. Moi qui pensais qu'il aurait pu remplacer un SQL Server, c'est une douche froide. Du coup, je suppose que la comparaison PostgreSQL / MySQL donne des résultats du même tonneau ?
Bonjour,
Il ne faut pas forcément condamner postgresql pour ces lacunes (qui existent). Le nerf de la guerre, c'est toujours l'argent. Par rapport à mon budget et mes besoins/compétences disponibles est-ce que tel produit y réponds ? De ce que je vois dans mon environnement pro, postgresql dans sa version libre sans module supplémentaire suffit très largement. Cela représente une économie sur les licences non négligeable. Pour information, on a nous imposé à mon service des produits parce que soit disant, pg ne suffit pas. J'attends toujours le benchmark qui le prouve. Attention, je ne dis pas qu'il n'y a pas de problème de performance avec pg, mais que dans le contexte de mon organisation et de ses applications, je n'ai pas vu de benchmark le prouver. Pour la simple raison, qu'ils n'existent pas. XD
Cela peut avoir un gros impact financier. Entre se contenter d'un pg, et se voir imposer un replicaset mongodb (premier contact avec le produit) qui nécessite au minimum 6 machines (3 pour le replicaset applicatif, 3 pour ops manager/mongodb d'ops manager). Et je ne parle pas du coût de formation de l'équipe sur un nouveau produit. En passant, bravo pour microsoft qui affiche les prix de leurs licences, les mongodb/elastic/neo4j me sortent par les yeux a ne pas mettre un prix sur leurs licences on premise.

Bref tout ça pour dire, postgresql est un produit libre qui continue a se bonifier qui rend bien des services. A envisager si on a un budget contraint et/ou pas de besoin de fonctionnalités avancées. C'est bête à dire, mais c'est quelque chose que l'on oublie trop, l'adéquation du produit par rapport à la finalité/aux besoins/moyens financiers.
3  0 
Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 18/10/2022 à 23:04
Citation Envoyé par SQLpro Voir le message
La version 2014 cela fait 8 ans et c'est obsolète... En comparaison PG 11 date de 2018. Tu compare donc deux produits qui ont 4 ans d'écart et dont l'un est obsolète... En 2014 PG ne gérait pas le JSON... !
si postgres gerait le json en version 9.3 sorti en septembre 2013

https://www.postgresql.org/support/versioning/
https://www.postgresql.org/docs/9.3/...ions-json.html

Citation Envoyé par SQLpro Voir le message
Le REGEX existe depuis la version 2005 sous la forme d'une DLL SQL CLR, plugable, comme le sont les extensions PG...
https://learn.microsoft.com/en-us/ar...t-sql-querying
ok on peut mettre des fonctions CLR dans sql server, mais combien le font réellement ? dans postgres c'est natif, pas de question à se poser et on aura le meme code pour tous les postgres.

Veut-on vraiment risquer de faire du code qui utilise des regex CLR non standards ?
1  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 15/10/2022 à 11:31
La fonctionnalité la plus importante introduite pas cette version est sans aucun doute la commande MERGE... Notons que la norme SQL l'a introduite dans sa version de 2003 (ISO - ISO/IEC 9075-1:2003)... Il aura donc fallu près de 20 ans pour que PostGreSQL qui s’auto-proclame le SGBDR le plus respectueux de la norme, accepte enfin cette commande normalisée au lieu de la rustine "UPSERT" (en fait INSERT ... ON CONFLICT). En comparaison, Microsoft SQL Server l'a introduite depuis la version 2005...

Quand aux améliorations de performances en matière de tri et fonction fenêtrées, 25 à 400 % c'est très faible, vu de quelles performances catastrophiques PostGreSQL est doté en la matière... Pour rappel PostGreSQL reste jusqu'à 1500 fois moins rapide que Microsoft SQL Server sur un simple COUNT(DISTINCT ...) alors ce n'est pas avec un gain de 1,25 à 4 que ce problème sera résolu...
A lire : PostGreSQL vs Microsoft SQL Server (comparaison) – Partie 2 : performances des requêtes avec COUNT

Quand à la réplication logique avec possibilité de filtrage vertical et/ou horizontale, Microsoft SQL Server la pratique depuis la version 7... PostGreSQL a donc 25 ans de retard sur la concurrence sur le sujet...

Mais notons les manques les plus cruciaux :
  • PostGreSQL n'a toujours pas d'index verticaux columnar (Microsoft SQL Server en dispose depuis la version 2012 donc, depuis 10 ans avec les "columnstore" index) malgré l’extension cstore_fdw dont les performances sont ridicules et les limitations nombreuses ce qui les rend inexploitables...
  • PostGreSQL n'a toujours pas de tables "in memory" (Microsoft SQL Server en dispose depuis la version 2012 donc, depuis 10 ans avec les tables et index optimisés en mémoire). Il existe néanmoins des version payantes pour cela (https://postgrespro.com/docs/enterpr...e/10/in-memory)
  • PostGreSQL n'a toujours pas de tables de graphes (Microsoft SQL Server dispose de tables de nœuds et d'arêtes depuis la version 2017 et d'un sous ensemble du langage GQL)
  • PostGreSQL ne dispose pas de ce que la norme SQL de 2003 appelle le DATALINK (https://wiki.postgresql.org/wiki/DATALINK) et qui est implémenté dans SQL Server pour stocker des fichiers sous le contrôle du serveur SQL depuis la version 2005, sous deux formes : le FILESTREAM et le FILETABLE
  • PostGreSQL n'est toujours pas capable de faire des mises à jour à travers les vues incorporant des jointures
  • Quand à l'optimiseur de PostGreSQL ils se vautre royalement dès que le nombre de jointures dépasse un certain seuil (par défaut de 12) ce qui oblige les DBA à osciller entre la peste GEQO et le choléra (augmenter ce seuil qui à avoir des plan d'exécution long à calculer ou des requêtes aux performances lamentables...)
  • ...


Bref, y'a encore du boulot !
7  7 
Avatar de goldbergg
Membre averti https://www.developpez.com
Le 15/10/2022 à 22:49
  • À votre avis, PostgreSQL 15 peut-elle mieux apporter satisfaction que ses concurrents : Oracle, Microsoft SQL Server, MySQL ou encore Amazon Aurora ?


Apres des années a gérer des base sous SQL Server/Azure, je me suis retrouver sur un projet avec une grosse BDD sous oracle 19c d'environ 1To (~300 tables dont certaine avec plusieurs dizaines de millions de ligne.).
Autant dire que le passage sous oracle a été difficile, je pourrais citer une longue liste de problème, mais je me contenterais de citer la principale SQL/Loader, pour faire des insertion de gros volume on est obligé sous oracle de passer par un outils externe et des CSV...

Mon riche client étant radin, ils ont décidé de passer sous pgaas afin d'économiser les licence Oracle, j'étais tout content de me débarrasser d'oracle, jusqu'à ce que j'entame les test de migration...

Ce SGBD est lent, très lent, un simple count qui répond en moins d'une seconde sous oracle ou SQL server peut prendre plusieurs dizaine de seconde pour des tables avec 4 fois moins de donnée...

Ensuite l'absence de MERGE INTO..., obliger de passer par des INSERT ON CONFLIT, qui eux aussi sont lent... Géniale quand on a des milliards de ligne à migrer :/

Bref, j'ai pas encore migrer toute ma BDD que je me rends déjà compte du fossé qu'il y a avec Oracle malgré ces défaut

Et je précise que j'ai passé du temps avec des DBA senior PGSQL afin d'être sûr que tout était optimisé de mon côté tellement je pensais que je faisais les chose mal, mais non, au contraire.

Bref, pour répondre à la question, pour moi PGSQL est très loin des solutions payante, il propose des truc sympa comme le JSON ou les tableau (même si pour ces besoin le NO SQL est préférable), mais ça ne comble pas les problèmes de perf ou de fonctionnalité de base manquante (le MERGE n'arrive que maintenant en 2022...)

  • Quel SGBD preferez-vous le plus ? Pourquoi ?

J'aime pas trop jouer les fanboy, mais pour moi SQL server est en tête et de très loin, il a le langage (transact) SQL le moins chiant, il est performent, il a une excellente doc (msdn), j'ai toujours réussie à faire ce que je voulais avec sans problème.
4  4 
Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 16/10/2022 à 12:00
Citation Envoyé par goldbergg Voir le message

... je me contenterais de citer la principale SQL/Loader, pour faire des insertion de gros volume on est obligé sous oracle de passer par un outils externe et des CSV...
OracleBulkCopy ? https://stackoverflow.com/a/46556274
0  0 
Avatar de kedare
Membre chevronné https://www.developpez.com
Le 18/10/2022 à 14:00
De notre coté, PostgreSQL 10 (géré via Stolon dans un cluster k8s), on a une migration prévu vers PostgreSQL 14 d'ici la fin de l'année (et migration vers un service managé).
La base fait a peu pret 1.5TB avec une croissance de 100GB par mois (bientôt plus), ça commence a être relativement complexe a optimiser (gros monolithe) sans équipe de DBA.
La migration devrait heureusement faciliter tout ca par la suite. (J'aurais bien poussé pour une migration vers sqlserver mais je dois être le seul de la boite a aime cette base )
0  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 20/10/2022 à 17:58
Citation Envoyé par epsilon68 Voir le message
si postgres gerait le json en version 9.3 sorti en septembre 2013

https://www.postgresql.org/support/versioning/
https://www.postgresql.org/docs/9.3/...ions-json.html

C'était embryonnaire et inexploitable en version 9... Il a fallut attendre la 10 pour avoir des choses acceptables !


ok on peut mettre des fonctions CLR dans sql server, mais combien le font réellement ? dans postgres c'est natif, pas de question à se poser et on aura le meme code pour tous les postgres.

Faudra que tu m'explique la différence entre une extension PG et une DLL Microsoft faite pour une assembly SQL Server !


Veut-on vraiment risquer de faire du code qui utilise des regex CLR non standards ?
Encore une fois il s'agit d'une assembly Microsoft donc, prévue pour cet effet et sans aucun risque.
Mais tu a raison de te poser la question de combien le font réellement... EN fait peu, puisque le LIKE dans SQL Server accepte une partie de la syntaxe du REGEX en général suffisante pour des recherches de motifs classiques adaptées aux bases de données.

Exemples - vérification qu'un patronyme est composé exclusivement de lettres :
CHECK (PATRONYME LIKE REPLICATE('[A-Z]', LEN(PATRONYME)))
- vérification qu'un patronyme est composé exclusivement de lettres en majuscules :
CHECK (PATRONYME COLLATE French_CS_AI LIKE REPLICATE('[A-Z]', LEN(PATRONYME)))
Ce que PostGreSQL est incapable de faire avec ses collations ICU buguées !
https://dba.stackexchange.com/questi...orted-for-like

A +

A +
0  0