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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

PostgreSQL 15 est disponible, elle améliore de l'ordre de 25 % à 400 % ses algorithmes de tri en mémoire


Sujet :

PostgreSQL

  1. #1
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Mai 2019
    Messages
    1 952
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2019
    Messages : 1 952
    Points : 37 967
    Points
    37 967
    Par défaut PostgreSQL 15 est disponible, elle améliore de l'ordre de 25 % à 400 % ses algorithmes de tri en mémoire
    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 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. »

    Nom : PostgreSQLB.jpg
Affichages : 152246
Taille : 17,7 Ko

    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.

    Nom : joinB.png
Affichages : 10154
Taille : 72,0 Ko

    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.

    Nom : filterB.png
Affichages : 10097
Taille : 34,4 Ko
    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.

    Nom : RDS.jpg
Affichages : 10088
Taille : 64,0 Ko

    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

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 924
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 924
    Points : 51 724
    Points
    51 724
    Billets dans le blog
    6
    Par défaut PostGreSQL 15
    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/enterprise/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 !

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    Mars 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2013
    Messages : 13
    Points : 26
    Points
    26
    Par défaut
    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

  4. #4
    Membre régulier
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    40
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 40
    Points : 87
    Points
    87
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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...

    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/enterprise/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 !
    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 ?

  5. #5
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut
    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 ?

  6. #6
    Membre averti Avatar de goldbergg
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2014
    Messages
    125
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2014
    Messages : 125
    Points : 402
    Points
    402
    Par défaut
    • À 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.

  7. #7
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    913
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 913
    Points : 2 607
    Points
    2 607
    Par défaut
    j'ai l'impression que certains utilisent des système monolithique......

    ça fait un bon moment avec les microservice que la complexité des bd s'est effondré...

    il doit encore en avoir qui sont attristé que les applications ne se construisent pu autour de la bd...

  8. #8
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut
    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

  9. #9
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 363
    Points : 4 428
    Points
    4 428
    Par défaut
    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.

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 924
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 924
    Points : 51 724
    Points
    51 724
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par epsilon68 Voir le message
    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 ?
    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... !

    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

    A +

  11. #11
    Membre éprouvé

    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    734
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 734
    Points : 1 120
    Points
    1 120
    Par défaut
    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.

  12. #12
    Membre chevronné
    Avatar de kedare
    Homme Profil pro
    SRE
    Inscrit en
    Juillet 2005
    Messages
    1 548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Espagne

    Informations professionnelles :
    Activité : SRE

    Informations forums :
    Inscription : Juillet 2005
    Messages : 1 548
    Points : 1 865
    Points
    1 865
    Par défaut
    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 )

  13. #13
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut
    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/functions-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 ?

  14. #14
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 924
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 924
    Points : 51 724
    Points
    51 724
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par epsilon68 Voir le message
    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 +

Discussions similaires

  1. Réponses: 5
    Dernier message: 07/04/2022, 19h17
  2. Réponses: 0
    Dernier message: 09/02/2022, 16h38
  3. Réponses: 0
    Dernier message: 16/06/2021, 18h14
  4. Réponses: 40
    Dernier message: 19/01/2011, 08h14
  5. Réponses: 21
    Dernier message: 24/12/2010, 04h02

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo