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 vs Microsoft SQL Server - Partie 1 : performances des commandes pour le DBA
Par Frédéric BROUARD (SQLpro)

Le , par SQLpro

11PARTAGES

13  8 
Chers membres du club,

J'ai le plaisir de vous présenter cet article :

PostGreSQL vs Microsoft SQL Server
Partie 1 : performances des commandes pour le DBA
Ce premier papier parle de quelques comparaisons entre PostGreSQL et SQL Server et pointe les différences en termes de performances pour quelques-unes des requêtes et commandes administratives qu’un DBA ordinaire doit exécuter.

Bonne lecture

Retrouvez les meilleurs cours et tutoriels pour apprendre les SGBD et SQL
.

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

Avatar de frost242
Membre régulier https://www.developpez.com
Le 05/02/2021 à 9:34
Bonjour,

Comme l'auteur de ce bench ne daigne pas en parler ici de ce qu'il ressort sur le forum postgresql.fr, je mets un lien vers la "discussion": https://forums.postgresql.fr/viewtopic.php?id=5931.

Outre le fait que PostgreSQL s'en sorte mieux sous Linux, le benchmark réalisé par SqlPro démontre encore une fois sa mauvaise connaissance de PostgreSQL : REINDEX inutile après VACUUM FULL, paramétrage pas optimal sur les opérations de maintenance (maintenance_work_mem, maintenance_parallel_worker), et quand un résultat ne lui convient pas, c'est qu'on n'a pas bien fait le test.

Enfin, à l'attention toute spéciale de SqlPro (ben quoi, je peux l'écrire comme ça, il n'y a pas de trademark), la lecture de cette page va s'avérer très intéressante : https://www.postgresql.org/about/policies/trademarks/.
16  2 
Avatar de RenardSpatial
Membre régulier https://www.developpez.com
Le 02/02/2021 à 19:15
Bonjour,

Merci pour cette analyse.

Pour commencer, je n’ai pas réussi à télécharger les requêtes mentionnées au point IX : le premier lien en 1drv.ms me demande un mot de passe, le second interne à developper.com me demande d’être connecté alors que je le suis déjà.

J’essaie de comprendre ce que je pourrais en déduire quant aux choix des futures bases de données de mes projets, et à cet effet j’aurais quelques questions. Je précise que je fais du devops mais ne suis pas DBA professionnel, ce qui pourrait expliquer quelques naïvetés dans mes questions.

  1. Il me semble que PostgreSQL est plutôt utilisé sous Linux que sous Windows. Ne serait-il pas plus pertinent de comparer les deux SGBD sur leurs OS de prédilection ?
  2. Qu’est-ce qui justifie d’avoir une configuration spécifique pour PostgreSQL mais pas pour SQL Server ?
  3. Serait-il possible de savoir ce qui a guidé le choix des valeurs de configuration pour PostgreSQL (dans la logique plus que dans le détail)
  4. Je vois que PostgreSQL a un encodage en UTF8 mais une collation et un type de caractères qui me semble être liée à Windows (1252), ça ne pose pas de problèmes ?
  5. Je ne comprends pas la pertinence de l’argument suivant : « Nous avons dû créer une collation pour PostGreSQL pour la deuxième table, car PostGreSQL possède très peu de collations internes contrairement à SQL Server qui en a plus de 5500. », puisque PostgreSQL gère nativement à peu près toutes les collations possibles en utilisant les collations ICU tel que défini aux chapitre 23.2.2.2 et 23.2.2.3 de la documentation – ce qui rends sa quantité de collations virtuellement infinie, ce qui est plus que les 5500 internes à SQL Server.
  6. Vous donnez des moyennes mais aucune autre information, en particulier pas l’écart-type des mesures. Est-ce que les mesures sont stables ou est-ce que les temps trouvés peuvent varier d’un gros facteur (ce qui pourrait changer la conclusion) ?

Et surtout, je ne vois aucune tentative d’analyse de l’écart.

Pourtant, ce que vous montrez là est intéressant : il semblerait que MS SQL soit sensiblement plus performant que PostgreSQL, mais sans que l’on sache quelle est la cause de cet écart. Pourtant un facteur 20 ou 30 est quelque chose d’assez énorme qui mériterait de s’y intéresser : est-ce dû aux SGBD eux-mêmes ? À un défaut de configuration ? Quels sont les facteurs limitants dans les deux cas (limitation par le CPU, mauvaise parallélisation par le SGBD, limitation par les I/O, par la bande passante mémoire, de la collation spécifique PostgreSQL…). En particulier on ne sait pas sur quel type de disques sont stockées les données, si ce sont des disques durs, l’écart est-il le même avec des SSD ? Etc.

C’est dommage que votre article se soit arrêté aux chiffres bruts, sans aucune analyse ni aucune recherche de détail. En l’état, il est difficile d’en tirer quoi que ce soit de probant, et il me donne plutôt l’impression que vous vous êtes arrêté dès que vous avez obtenu des chiffres qui montrent que SQL Server est plus rapide que PostgreSQL. J’espère me tromper et que votre réponse me montrera que vous étiez de bonne foi en créant ce test. Cela me semble d’autant plus important que, puisque vous êtes « Microsoft® Most Valuable Professional », on pourrait vite croire que vous êtes là plus pour vendre les solutions de Microsoft – à qui vous êtes affiliés – que pour faire des tests neutres et impartiaux.

Enfin je me permet de signaler une erreur récurrente, la typographie nominale est « PostgreSQL » et non « PostGreSQL » (le g central n’est pas en majuscule).
11  1 
Avatar de FatAgnus
Membre expérimenté https://www.developpez.com
Le 23/03/2021 à 10:43
Pourquoi s'entêter à mesurer les performances de PostgreSQL alors que personne n'utilise PostgreSQL sous Windows en production et que PostgreSQL fonctionnera certainement plus vite sous Linux que sous Windows comme l'affirme Magnus Hagander l'une des personnes qui a porté PostgreSQL sous Windows sur Stack Exchange · Server Fault :

PostgreSQL fonctionnera certainement plus vite sous Linux que sous Windows (et je dis cela en tant que l'un des gars qui a écrit le portage Windows de celui-ci...) Il est conçu pour une architecture de style Unix, et implémente cette même architecture sous Windows, ce qui signifie qu'il fait un certain nombre de choses que Windows n'est pas conçu pour faire correctement. Il fonctionne bien, mais il n'est pas aussi performant.
J'ai bien peur que ce test n'est que peu d'intérêts. Mais bon L'auteur (un MVP Microsoft) est bien connu pour s'être donné comme mission de faire de la propagande SQL Server au détriment des bases de données open source, et il fait ça depuis très longtemps (voir par exemple son article Découvrez les dangers de MySQL et MariaDB truffés d'erreurs). J'ignore pourquoi l'auteur s'est donnée cette mission, il ne serait pas surprenant qu'il en tire quelques avantages en coulisses.
15  6 
Avatar de FatAgnus
Membre expérimenté https://www.developpez.com
Le 23/03/2021 à 20:14
Citation Envoyé par tanaka59 Voir le message

En dehors de toute considération pour un parti ou un logiciel. Concernant les perfs SQL, la question de fond avoir est la suivante : "en terme d’exécution qu'elle est le SGBD le plus "rapide" ?".
Justement comme l'atteste ces nombreux articles ou commentaires l'auteur Frédéric Brouard a un parti pris contre les bases de données open source depuis des années, donc l'impartialité de Frédéric Brouard porte à suspicion. Mesurer les performances de PostGreSQL sur Windows est juste un moyen de baiser les résultats puisque le port Windows de PostgreSQL n'est pas aussi performant que la version Linux. Et surtout personne n'utilise PostGreSQL sous Windows en production, donc l'intérêt de ce test est sans intérêt, sauf si on veut dénigrer PostGreSQL. On peut faire confiance aux compétences reconnues de Frédéric Brouard pour trouver les tests qui désavantageront PostgreSQL, comme exécuter PostgreSQL sur un système d'exploitation où il est moins performant. Mais l'auteur a sûrement d'autres astuces dans son sac.

Citation Envoyé par tanaka59 Voir le message

Sur l'aspect vitesse d’exécution ou vitesse de traitement, bien évidement qu'un Oracle, MS Server, SAS, Access seront plus rapide ... La gratuité se "paye" . Comment ? Un Wamp ou un MySQL est bon a faire une base d'archive ...
Votre esprit embrumé, confond deux choses. Votre première confusion est la gratuité et l'open source. Un logiciel gratuit n'est pas forcément open source. Ensuite votre deuxième confusion vient de la licence d'un logiciel et de sa performance. À vous croire le fait de publier un logiciel sous licence open source le rendrait moins rapide ? Je ne sais pas si vous êtes conscient de l'absurdité de votre raisonnement. La performance et la licence d'un logiciel sont deux choses distinctes.
12  3 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 02/02/2021 à 20:38
Bonjour,

Citation Envoyé par RenardSpatial Voir le message
Bonjour,

Merci pour cette analyse.

...

Enfin je me permet de signaler une erreur récurrente, la typographie nominale est « PostgreSQL » et non « PostGreSQL » (le g central n’est pas en majuscule).
J'assume parfaitement ce qui vous apparait comme une erreur typographique et qui est ma signature de tout temps au sujet de PostGreSQL. Sachez que les noms n'ont pas d'orthographe précise et que PostGreSQL n'est visiblement pas une "trademark". On n'est donc pas obligé de respecter la typologie de la communauté (ou serait donc la liberté si on me l'imposait comme semble vouloir me le faire remarquer les intégristes de PG...). De plus PostGreSQL c'est la suite de InGreSQL (notez là aussi le G majuscule, que je n'utilise en principe jamais pour Ingres....) un simple jeu de mot ayant guidé le choix de PostGreSQL à l'origine PostGres (sans le SQL) qui signifie après "gres" alors qu'avant c'était dans "gres". C'est là sans doute mon aspect vieux con qui après 34 ans passé dans les SGBDR m'en a fait connaître l'histoire et les principaux (DB2, Oracle, Sybase SQL Server, Watcom, RDB, Gupta SQL, Informix, InterBase et bien d'autres....) pour ne plus me consacrer qu'à quelques uns (MS SQL Server, Oracle, PostGreSQL...).
Ne pas oublier le pourquoi du "Ingres"... C'est tout simplement lié à la naissance du free... En effet, Eugene Wong et Michael Stonebraker ont démarré le développement de Ingres à temps perdu (perruque) et dont décidé de la baptisé du nom d'Ingres à cause de son violon...

Citation Envoyé par RenardSpatial Voir le message
Pour commencer, je n’ai pas réussi à télécharger les requêtes mentionnées au point IX : le premier lien en 1drv.ms me demande un mot de passe, le second interne à developper.com me demande d’être connecté alors que je le suis déjà.
Je viens de réinitialiser le lien OneDrive, mais je ne puis tester :
https://1drv.ms/u/s!AqvZfiQYoNpBihI4...hRZec?e=nwpcaM
Pour DVP je n'y suis pour rien, je vois avec les responsables...

Citation Envoyé par RenardSpatial Voir le message
J’essaie de comprendre ce que je pourrais en déduire quant aux choix des futures bases de données de mes projets, et à cet effet j’aurais quelques questions. Je précise que je fais du devops mais ne suis pas DBA professionnel, ce qui pourrait expliquer quelques naïvetés dans mes questions.

Il me semble que PostgreSQL est plutôt utilisé sous Linux que sous Windows. Ne serait-il pas plus pertinent de comparer les deux SGBD sur leurs OS de prédilection ?
Cela n'aurait pas fait de remarquables différences l'écart étant déjà très important et SQL Server marchant un peu mieux (de l'ordre de 5 à 8 %) sous Linux.... Et il me semble qu'il y a pas mal de PG sous Windows...

Citation Envoyé par RenardSpatial Voir le message
Qu’est-ce qui justifie d’avoir une configuration spécifique pour PostgreSQL mais pas pour SQL Server ?
PG est réglé lors de son installation avec des paramètres qui sous-utilisent les ressources. Les laisser tels quelle pour faire les tests aurait sévèrement handicapé PostGreSQL. SQL Server, est auto paramétré. D'une part lors de son installation avec les valeurs par défaut, d'autre part dynamiquement dans son exploitation. En particulier dans les toutes dernières versions, aucun réglage n'est strictement nécessaire pour les performances, sauf le paramétrage du "optimize for adhoc workload" qu'il aurait été judicieux d'activer pour économiser du cache pour les requêtes unitaires. Mais avec 128 Go de RAM, c'était parfaitement inutile.

Citation Envoyé par RenardSpatial Voir le message
Serait-il possible de savoir ce qui a guidé le choix des valeurs de configuration pour PostgreSQL (dans la logique plus que dans le détail)
Mon expérience et les documents de référence suivant :
https://wiki.postgresql.org/wiki/Tun...tgreSQL_Server
https://pgtune.leopard.in.ua/#/
...

Citation Envoyé par RenardSpatial Voir le message
Je vois que PostgreSQL a un encodage en UTF8 mais une collation et un type de caractères qui me semble être liée à Windows (1252), ça ne pose pas de problèmes ?
Pour des requêtes de DBA, n'importe quel type de données et n'importe quel collation aurait permis la comparaison. Charge à vous de prouver le contraire, raison pour laquelle j'ai laissé les fichiers et les requêtes en libre disposition...

Citation Envoyé par RenardSpatial Voir le message
Je ne comprends pas la pertinence de l’argument suivant : « Nous avons dû créer une collation pour PostGreSQL pour la deuxième table, car PostGreSQL possède très peu de collations internes contrairement à SQL Server qui en a plus de 5500. », puisque PostgreSQL gère nativement à peu près toutes les collations possibles en utilisant les collations ICU tel que défini aux chapitre 23.2.2.2 et 23.2.2.3 de la documentation – ce qui rends sa quantité de collations virtuellement infinie, ce qui est plus que les 5500 internes à SQL Server.
Oui, mais il faut les créer. Cette étape n'existe pas dans SQL Server qui les gèrent directement. De plus les collations ICU sont inexploitable comme le montre cet article car buguées...

Citation Envoyé par RenardSpatial Voir le message
Vous donnez des moyennes mais aucune autre information, en particulier pas l’écart-type des mesures. Est-ce que les mesures sont stables ou est-ce que les temps trouvés peuvent varier d’un gros facteur (ce qui pourrait changer la conclusion) ?
Et surtout, je ne vois aucune tentative d’analyse de l’écart.
À part une seule requête pour laquelle il y a eut un écart important pour PostGreSQL, la variance est très ramassée. Je ne me souviens plus de laquelle, mais je pourrais la retrouver. Mais elle n'était pas significative dans la comparaison finale, raison pour laquelle je ne l'ai pas mentionnée dans l'article.

Citation Envoyé par RenardSpatial Voir le message
Pourtant, ce que vous montrez là est intéressant : il semblerait que MS SQL soit sensiblement plus performant que PostgreSQL, mais sans que l’on sache quelle est la cause de cet écart. Pourtant un facteur 20 ou 30 est quelque chose d’assez énorme qui mériterait de s’y intéresser : est-ce dû aux SGBD eux-mêmes ? À un défaut de configuration ? Quels sont les facteurs limitants dans les deux cas (limitation par le CPU, mauvaise parallélisation par le SGBD, limitation par les I/O, par la bande passante mémoire, de la collation spécifique PostgreSQL…). En particulier on ne sait pas sur quel type de disques sont stockées les données, si ce sont des disques durs, l’écart est-il le même avec des SSD ? Etc.
Ces opérations sont à 95% des opérations logiques ayant très peu d'IO physiques. L'influence des disques est donc très peu significative et utiliser tel ou tel type de stockage n'aurait pas montré de différence.
Défaut de configuration, à moins que je n'ai fait une grossière erreur pour PG, je ne voit pas... (pour info j'ai mis parallel_workers à 48 mais aucune requête ne m'a montré un plan parallélisé)
Bande passante, c'est le même PC...
Ce qui est clair c'est que le parallélisme intervient pour la part la plus importante dans cette différence de performances. Depuis la version 7 datant de 1998 (22 ans donc), SQL Server fait du parallélisme massivement et de manière automatique dans toutes ses tâches, pas uniquement pour les requêtes (aucun réglage particulier à entreprendre). Les tris et donc les créations d'index sont parallélisés et peuvent utiliser tous les cœurs soit 48 dans notre test. Alors que PostGreSQL semble n'utiliser qu'un seul thread... De plus, même en paramétrant PG pour utiliser 48 cœurs, celui-ci m'a montré qu'il n'en utilisait jamais plus que 4 qui semble être actuellement une limite interne par conception...
Enfin, la R&D de Microsoft a réalisé des algorithmes internes qui semble plus efficace que ceux bien connus que l'on trouve dans la littérature des SGBDR. Ce qui explique d'autres différences... Ce sont les petits secrets jalousement gardé par les grand éditeurs de SGBDR ! Mais rassurez-vous, certains experts de MS en matière de développement de moteurs de bases de données travaillent aussi pour la version free de PostGreSQL ! (Core team : Andres Freund, Major contributor : David Rowley...)

Citation Envoyé par RenardSpatial Voir le message
C’est dommage que votre article se soit arrêté aux chiffres bruts, sans aucune analyse ni aucune recherche de détail. En l’état, il est difficile d’en tirer quoi que ce soit de probant, et il me donne plutôt l’impression que vous vous êtes arrêté dès que vous avez obtenu des chiffres qui montrent que SQL Server est plus rapide que PostgreSQL. J’espère me tromper et que votre réponse me montrera que vous étiez de bonne foi en créant ce test.
La bonne fois, la mauvaise foi... Tout est question d’appréciation. Moi je me contente de faits. Je les rends reproductible à tout un chacun, qui peut les analyser plus en profondeur, les disséquer et en publier une analyse. mais une analyse vaut ce qu'elle vaut : c'est un point de vue d'après des faits !

Cependant ce forum est là pour effectivement compléter efficacement et intelligemment l'article que j'ai écrit... Et vos questions sont intéressantes !

A +
8  0 
Avatar de
https://www.developpez.com
Le 23/03/2021 à 20:13
Citation Envoyé par tanaka59 Voir le message
Tu casses les pieds a toujours intervenir inutilement.

Quand je dis la "gratuité se paye", sur le fond, c'est qu'un produit gratuit se sera toujours moins aboutit qu'un produit payant ...
Désolé mais j'ai autant le droit que toi de m'exprimer. Je pense que ce que tu racontes est du grand n'importe quoi bien plus inutile. Mais je ne te reproche pas de le dire alors merci d'en faire autant.
10  2 
Avatar de Grulim
Membre actif https://www.developpez.com
Le 04/02/2021 à 21:53
Bonsoir,

Je ne sais pas si la réponse de SQL-Pro s'adresse à moi, mais si c'est le cas, mon message n'avait pas pour but de vous discréditer ou de diminuer la valeur votre benchmark.

Je me suis juste étonné du manque de comparatifs chiffrés des performances entre les différents SGBD, et je trouve ça dommage.

Pour revenir sur MSSQL, le seul site important que je connaisse et que j'utilise est stackoverflow, preuve s'il en est que MSSQL peut être (très) performant. Il faut dire aussi que ce site emploie des pointures comme Marc Gravell.

Cordialement.

PS
Et je remarque que c'est le genre d'arguments que me sortent systématiquement les ayatollah du libre pour me mettre en garde de na pas publier mes benchmarks.......
Pourtant, ni le GIGN, ni le SWAT, ni le RAID ni la gendarmerie et même pas la police municipale ne sont venue me trouvé chez moi pour me placer en prison sous prétexte d'un benchmark illicite....
Mais peut être, personnellement, avez vous peur, êtes vous terrorisé, à la simple idée de vous servir de vos droits d'expression et publier de tels benchmarks ?
Je trouve ce genre de remarques déplacées, un peu too much, peut-on s'en tenir aux faits et discuter de manière plus constructive ?
8  1 
Avatar de ddaime
Membre éclairé https://www.developpez.com
Le 05/02/2021 à 13:15
Citation Envoyé par Grulim Voir le message
Je trouve ce genre de remarques déplacées, un peu too much, peut-on s'en tenir aux faits et discuter de manière plus constructive ?
Vous avez l'air étonné ? N'avez-vous jamais lu les commentaires de SQLPro ?
7  0 
Avatar de CinePhil
Modérateur https://www.developpez.com
Le 24/03/2021 à 14:37
Même si le ton de FatAgnus, et ensuite les propos de quelques autres, sont quelque peu désagréables à lire (et, en tant que modérateur, j'aimerais bien que la discussion se calme), FatAgnus pose quand même incidemment une question intéressante à laquelle SQLPro pourrait peut-être répondre :

Serait-il possible qu'il fasse les même tests avec les deux SGBD en environnement Linux ?

Comme il avait déclaré lui-même - et il me semble que ça a été confirmé par d'autre tests - que SQL Server est plus rapide sous Linux que sous Windows, ça pourrait être intéressant de voir si les écarts se réduisent ou se creusent.
7  0 
Avatar de pokap
Membre du Club https://www.developpez.com
Le 25/03/2021 à 21:07
Bonjour,

Merci pour le "Tutoriel", je met entre guillemet parce que c'est plutôt un comparatif de temps de réponse.

Je voulais ajouter mon grain de sel à la discussion car on parle de pur performance mais il faut bien comprendre (pour ceux qui vont me lire) que ça n'a aucune valeur de qualité pour le choix d'une base de donnée.
Et comme on est dans une rubrique débutante, je voudrais signaler aux développeur.ses qui cherchent une base de donnée de considérer la performance comme tertiaire à votre choix, si vous prenez une bdd uniquement sur ces performances vous allez planter votre projet c'est garanti.

Ensuite je ne veux pas remettre en doute l'écart affiché de 1000x, en admettant que c'est vrai on est en train de comparer la perf d'une formule 1 à un 2CV en gros, et là c'est problématique car on a l'impression qu'il "suffit" de changer de bdd et hop c'est mieux, hors c'est tout le contraire le choix de la bdd va avec le reste de l'infrastructure, de la compétence des devs et des sys admin, des licences, la communauté, etc. Le choix final repose surtout sur le type de projet qui va avec la bdd. Ça me rappelle l'époque où certaine utilisait des bdd no-sql orienté document ou colonne pour stocker des data de blogs.

Pour finir j'aurais quand même préféré voir un tutoriel sur SQL server pour savoir dans quel cas il serait plus sage de l'utiliser par rapport à d'autres usages. Dans mon cas j'utilise bien Postgresql sur un projet en production avec des tables de + de 10M de row et je n'ai aucun soucis de temps de réponse avec (~40ms pour les plus lourd avec plusieurs jointures - sans aucun cache - 8 cores 64 Go - debian).
8  1