PostGreSQL vs Microsoft SQL Server - Partie 2 : performances des requêtes avec COUNT
Par Frédéric BROUARD (SQLpro)
Le 2021-03-20 22:33:18, par Malick, Community Manager
Chers membres du club,
J'ai le plaisir de vous présenter la deuxième partie de cet article de SQLpro :
Bonne lecture
Retrouvez les meilleurs cours et tutoriels pour apprendre les SGBD et SQL
.
J'ai le plaisir de vous présenter la deuxième partie de cet article de SQLpro :
Ce second article compare PostGreSQL à SQL Server et met en avant les différences de performances des requêtes d’agrégation qui utilisent la fonction COUNT.
Notre premier article comparait les temps de réponse entre PostGreSQL et SQL Server des requêtes administratives que les DBA doivent ordinairement exécuter.
Notre premier article comparait les temps de réponse entre PostGreSQL et SQL Server des requêtes administratives que les DBA doivent ordinairement exécuter.
.
-
FatAgnusMembre chevronné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.le 23/03/2021 à 10:43
-
FatAgnusMembre chevronné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.
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.le 23/03/2021 à 20:14 -
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.le 23/03/2021 à 20:13
-
CinePhilModérateurMê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.le 24/03/2021 à 14:37 -
destroyedloloMembre actifSalut,
En fait, je ne voulais pas rentrer dans ce sempiternel thread : m$ vs le reste du monde mais ...
Ca fait bientôt 15 ans que que j'ai une base qui emmagasine tous plein de données environnementales, avec évidemment des upgrades successifs et j'utilise pgsql pour pleins de projets que ce soit en hobby comme en PRO. En 15 ans, j'ai eu en tout et pour tout : 1 BUG, ouai, 1 seul bug, liée a pg_dump uniquement lorsqu'on l'utilise en mode texte. Un bug qui a été corrigé rapidement.
Et que ce soit pour cette base, ou pour les autres projets sur lesquels j'ai été amener a bosser : JAMAIS aucune perte de donnée, JAMAIS aucune corruption, JAMAIS une requete qui faisait autre chose que ce qui lui était demandé. J'ai eu certe des pb de perfs, mais jamais la moindre données n'a été perdue (hors erreur humaine bien sur ou disque HS).
Alors évidement, ma propre expérience ne peut pas etre érigée comme "une vérité vraie", mais je n'ai JAMAIS eu la même expérience avec le moindre outils microsoft : car niveau bugs, on peut difficilement mettre cette boite en avant vu l'histoire plus que chaotiques de leurs produits a commencer par ms-windows.
Je n'utilise pas Sqlserver, car je n'ai simplement pas confiance. Peut etre un très bon produit, mais je ne prendrais pas le risque !
Dire que "PostgreSQL est plus buggé" laisse juste entrevoir une mauvaise fois presque aussi forte que la miennele 26/03/2021 à 2:32 -
FatAgnusMembre chevronnéVous avez des statistiques d’utilisation de PostgreSQL sous Microsoft Windows et GNU/Linux ? Si effectivement la société Microsoft peut prétendre connaître le nombre d'instances de Microsoft SQL Server (avec des techniques de télémétrie ou de pistage de ses utilisateurs), PostgreSQL ne piste pas ses utilisateurs. Expliquez nous l'intérêt de payer une licence Microsoft Windows Server pour exécuter PostgreSQL qui sera beaucoup moins rapide sur sur la même serveur sous GNU/Linux ?
Vous mélangez tout, et bien sûr recherche de la vérité n'est pas votre objectif. Comme, vous le savez sûrement depuis longtemps, le développeur Magnus Hagander affirme que PostgreSQL est conçu pour une architecture de style Unix, et n'a pas du tout été optimisé pour Microsoft Windows. Ce n'est un secret pour personne. On peut supposer que le portage de Microsoft SQL Server pour GNU/Linux est de meilleure qualité.
Comme le dit justement une personne dans le reportage sur ARTE La fabrique de l'ignorance, on peut fait dire ce qu'on veut à une étude, il suffit de trouver le protocole de test qui vous arrange.
Vous faites cette étude pour vos clients ou pour les lecteurs de Developpez.com ? Si vos clients sont la société Microsoft, je comprends mieux vos résultats.
Tout le monde aura compris que vous êtes là, je vous cite pour « démolir » les bases de données open source et libres et non pour publier des tests impartiaux. Ce que vous faites très bien depuis des années, je le concède.
En terme de dénigrement, vous n'avez rien à apprendre. J'ai déjà publié un commentaire pointant vos grossiers mensonges : dénigrement du nom « MySQL » qui signiferait « mon petit business », utilisation de benchmarks mesurant les performance de MySQL 5.6 sorti en février 2013 dans un article de 2019 ; peur, incertitude et doute sur des mesures RGPD de sociétés dont rien ne dit qu'elles utilisent MySQL, tromperie sur la taille du code et la taille d'installation ; confusion volontaire entre l'outil de suivi de de problèmes de MySQL avec un outil de feedback des utilisateurs de Microsoft SQL Server ; assimilation trompeuse du nombre de bugs ouverts de MySQL avec la qualité du produit...
Quand on s'attaque à une comparaison des performances, ou autres, entre deux logiciels, les principales qualités sont l'exactitude, la rigueur, l'impartialité et la courtoisie. Qualités qui malheureusement vous semblez dépourvues.le 27/03/2021 à 15:11 -
pokapMembre régulierBonjour,
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).le 25/03/2021 à 21:07 -
WaldarModérateurPetit rappel, le code et la configuration utilisés par SQLPro lors de ces benchmarks sont disponibles, libre à tout-à-chacun de faire ses propres benchs, et je vous l'annonce, les résultats seront différents.
Entre les versions d'OS, des logiciels et les différentes configurations matérielles et logicielles il y a un nombre suffisamment grand de combinaison possible qui font qu'il n'y aura jamais de comparatif empirique.
SQLPro défini un benchmark, pose une brique et tire les conclusions sur ce bench.
Le titre fait venir les lecteurs - et provoque les débats - c'est discutable mais ce n'est pas comme si c'était le seul au monde à utiliser cette technique.le 24/03/2021 à 15:33 -
chrtopheResponsable SystèmesComme dit par d'autres membres, il aurait été intéressant d'avoir un bench avec une version Linux, ça me parait un minimum pour un bench avec une vraie valeur.
Je ne suis pas spécialiste en base de données, mais l'écart étant tellement important, je me demande si il n'y a pas des optimisations à appliquer sur chaque SGBD pour pouvoir faire une vraie comparaison.
Il se peut également que SQL-Server soit meilleur en certain point et moins bon sur d'autres par rapport à PostGres. Ne montrer ces points spécifiques biaise les résultatsle 25/03/2021 à 11:58 -
D'un côté, tu nous dis que l'open-source expose naturellement à plus de vulnérabilités, du fait de la disponibilité du code. Et d'un autre côté, tu nous dis que les failles découvertes sont proportionnelles au nombre de lignes de code...le 31/03/2021 à 17:24