PostGreSQL vs Microsoft SQL Server - Partie 1 : performances des commandes pour le DBA

Citation:

---

Envoyé par FatAgnus

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 :



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.

---

J'ai un sérieux doute que beaucoup de professionnel s'amuse à mélanger des stacks Windows avec des stacks Linux.

Ce qui me fait dire que ce test est un peu un enfonçage de porte ouverte, mais qu'un comparatif SQL Server sur Windows vs PostgreSQL sur Linux aurait finalement le même intérêt vu que je trouve extrêmement réducteur de limiter le choix d'une stack sur une histoire de performance de DB.

Probablement que ce papier a une raison commerciale liée à une obligation de faire de la présence communautaire. C'est du même niveau que les intégrateurs qui organisent des ateliers sur un produit dont ils sont partenaires et je vois pas le problème considérant que developpez.com n'est pas un site de recherche universitaire et qu'à priori c'est accepté par la rédaction du site.

Citation:

---

Envoyé par sinople

je vois pas le problème considérant que developpez.com n'est pas un site de recherche universitaire et qu'à priori c'est accepté par la rédaction du site.

---

Tout à fait. Donc heureusement qu'il y a des messages comme ceux de FatAgnus pour expliciter la situation.

Enfin si, il y a quand même un problème : le risque que dvp finisse par avoir la même crédibilité technique que 4chan ou que blabla 15-18 sur JVC...

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.

Petit 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.

SQLPro il aurait été bien de proposé des solutions pour PostgreSQL dans votre benchmark car juste de dire c'est plus rapide sur SQL Server, au moins ça aurait permis de donner des conseils voir de l'info aux gens lisant votre post !

Edit: Les testes sont fait sur SSD ou HDD ?

Comme 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ésultats

Je me permet de déterrer ceci :

Citation:

---

Envoyé par SQLpro

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...).

---

Parce que j’ai appris depuis votre réponse que, contrairement à ce que vous avancez, PostgreSQL est bien une trademark et s’écrit donc bien sans « g » majuscule. En particulier, les conditions d’utilisation disent ceci (section How To Use Our Marks, premier point) :

Citation:

---

The marks should not be modified in any way without prior approval.

---

Citation:

---

Envoyé par RenardSpatial

Je me permet de déterrer ceci :

Parce que j’ai appris depuis votre réponse que, contrairement à ce que vous avancez, PostgreSQL est bien une trademark et s’écrit donc bien sans « g » majuscule. En particulier, les conditions d’utilisation disent ceci (section How To Use Our Marks, premier point) :

---

Déjà répondu ici : https://www.developpez.net/forums/d2.../#post11680155

Honnêtement on s'en fou ! Est-ce cela aura une influence sur les résultats désastreux de PostGreSQL en termes de performances ?

A +

Citation:

---

Envoyé par Waldar

J'ai l'impression qu'il manque un bout des résultats ; je n'ai que le chapitre "XII. Performances du COUNT sans aucun index", un tableau de résultat et ensuite des conclusions qui parlent d'index Btree & ColumnStore.

---

Tu as raison, il manque pas mal de bout d'article qui ont été perdu dans la nature. L'article original est sur mon site :
En VF : http://mssqlserver.fr/postgresql-vs-...es-avec-count/
En anglais : http://mssqlserver.fr/postgresql-vs-...-performances/

Je lance la rectif des choses perdues

A +

Citation:

---

Envoyé par chrtophe

Comme 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ésultats

---

Je dispose de deux serveurs physique HP DL 385 avec 8 disques SAS 300 Go, l'un avec Linux l'autre avec Windows.
Je les met à disposition de qui veut s'en occuper car n'étant pas spécialiste Linux, j'ai peur de ne pas être au top, et donc d'être à nouveau victime de critiques acerbes des ayatollah du pingouin !

A +

Citation:

---

Envoyé par SQLpro

Déjà répondu ici : [url]https://www.developpez.net/forums/d2101921/bases-donnees/decisions-sgbd/debuter/postgresql-vs-microsoft-sql-server-partie-1-performances-commandes-dba/#post11680155[/url

---

Vous ne répondez pas à grand-chose, puisque vous vous contentez de renvoyer vers le message que je citais en en-tête et pour lequel je réfutais le point principal (à savoir : que l’on pourrait écrire « PostgreSQL » comme on veut puisque le terme ne serait pas protégé, hors il l’est).

Notez bien qu’on ne parle pas de performances ici mais de droit des marques, et que ce message s’adresse autant à developpez.[com|net] en tant qu’éditeur qu’à vous en tant qu’auteur, puisqu’en maintenant ces publications sur les articles vous vous rendez coupable de violation de propriété intellectuelle. Après on peut partir du principe que probablement PostgreSQL n’attaquera personne ici : on est surtout dans une question d’image de sérieux et de professionnalisme pour developpez.[com|net] et de ses auteurs.

Citation:

---

Envoyé par FatAgnus

Pourquoi s'entêter à mesurer les performances de PostgreSQL alors que personne n'utilise PostgreSQL sous Windows en production

---

Ce qui est bien évidemment totalement faux.... mais il est vrai que le nombre de serveur PG sous Windows diminue au fil du temps...

Citation:

---

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 ...

---

C'est probable et notez que c'est la même chose avec SQL Server dans les tests que nous avons effectué dans cette étude :
https://sqlpro.developpez.com/tutori...windows-linux/
Néanmoins, ces gains de performance sont marginaux par rapport à des écarts de plus de 1000 fois !

Citation:

---

J'ai bien peur que ce test n'est que peu d'intérêts.

---

Ah oui ? Allez donc dire à des clients qui passent de l'un à l'autre et constatent que leurs requêtes de comptage sont mille fois plus lente mais que cela n'a aucun intérêt....

Citation:

---

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,

---

Ce que ne font pas, bien entendu les tenants du libre dans des articles bidons farcis d'erreurs comme celui-ci qui est une honte pour EnterpriseDB et que je démolirais pièce par pièce dans la 3e partie de ma série d'articles :
https://www.enterprisedb.com/blog/mi...at-differences

Citation:

---

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).

---

Lesquelles ? Au lieu de dénigrer, donnez quelques exemples des erreurs que j'ai commises !


A +

Citation:

---

Envoyé par RenardSpatial

Vous ne répondez pas à grand-chose, puisque vous vous contentez de renvoyer vers le message que je citais en en-tête et pour lequel je réfutais le point principal (à savoir : que l’on pourrait écrire « PostgreSQL » comme on veut puisque le terme ne serait pas protégé, hors il l’est).

Notez bien qu’on ne parle pas de performances ici mais de droit des marques, et que ce message s’adresse autant à developpez.[com|net] en tant qu’éditeur qu’à vous en tant qu’auteur, puisqu’en maintenant ces publications sur les articles vous vous rendez coupable de violation de propriété intellectuelle. Après on peut partir du principe que probablement PostgreSQL n’attaquera personne ici : on est surtout dans une question d’image de sérieux et de professionnalisme pour developpez.[com|net] et de ses auteurs.

---

Visiblement vous ne savez pas lire. Il est protégé au niveau du fond, pas de la forme. Si vous ne faites pas la différence entre les deux concepts, bien des choses s'expliquent !

A +

Citation:

---

Envoyé par SQLpro

Visiblement vous ne savez pas lire. Il est protégé au niveau du fond, pas de la forme. Si vous ne faites pas la différence entre les deux concepts, bien des choses s'expliquent !

---

J’ai peur que la page que j’ai cité dans mon premier message à ce sujet parle bien de la forme :

Citation:

---

The marks should not be modified in any way without prior approval.

---

Et le terme mark désigne bien les mots « Postgres » ou « PostgreSQL » comme c’est dit au début de la même page :

Citation:

---

TSpecifically, the terms Postgres and PostgreSQL and the Elephant Logo (Slonik) are all registered trademarks

---

---

Pour qui voudrait des références de droit international sur ce que je raconte :

Citation:

---

(1) A trademark shall protect a sign which may be represented graphically and which is
capable of distinguishing the goods or services of one undertaking from those of other
undertakings.
(2) Trademarks may protect signs, in particular: words, letters, numerals, abbreviations,
graphical representations, combinations of colours and the tints thereof, three-dimensional forms,
shapes of the goods or the packaging thereof, provided that they are distinctive, as well as the
combinations of all the above indicated signs.
(3) A seal, a stamp and a hallmark (official mark identifying precious metals, measures,
etc.) shall not, under this Law, be considered to be trademarks.

---

Source : TRADEMARK LAW, Part One, BASIC PROVISIONS : The Concept of a Trademark sur le site officiel de l’Organisation Mondiale du Commerce, donc l’instance internationale chargée de s'assurer que les règles commerciales (dont le droit des marques) est harmonisé autant que possible internationalement. On retrouve des dispositions similaires à ce texte tant en droit US qu'en Europe.

PS : la transcription en droit européen :

Citation:

---

TITRE II

DROIT DES MARQUES

SECTION 1

Définition et acquisition de la marque communautaire

Article 4

Signes susceptibles de constituer une marque communautaire

Peuvent constituer des marques communautaires tous les signes susceptibles d'une représentation graphique, notamment les mots, y compris les noms de personnes, les dessins, les lettres, les chiffres, la forme du produit ou de son conditionnement, à condition que de tels signes soient propres à distinguer les produits ou les services d'une entreprise de ceux d'autres entreprises.

---

Source : Le journal officiel de l’Union Européenne

Citation:

---

Envoyé par RenardSpatial

Pour qui voudrait des références de droit international sur ce que je raconte :

Pour qui voudrait des références de droit international sur ce que je raconte :

Citation:

---

(1) A trademark shall protect a sign which may be represented graphically and which is
capable of distinguishing the goods or services of one undertaking from those of other
undertakings.
(2) Trademarks may protect signs, in particular: words, letters, numerals, abbreviations,
graphical representations, combinations of colours and the tints thereof, three-dimensional forms,
shapes of the goods or the packaging thereof, provided that they are distinctive, as well as the
combinations of all the above indicated signs.
(3) A seal, a stamp and a hallmark (official mark identifying precious metals, measures,
etc.) shall not, under this Law, be considered to be trademarks.

---

---

Pour votre information une marque graphique est un logo. Or le ! 1) ne concerne pas le littéral.
le 2) concerne les littéraux et il n'est pas fait mention, ni de la casse, ni de la police, ni du gras, du souligné ni de l'italique...
Rien dans le dépôt de marque de PostgreSQL ne parle ni de la casse ni de la police, ni du gras, du souligné ni de l'italique...
Pour information, le dépôt de marque de la compagnie IBM, précise bien que :
"Do not misspell or use lower case letters when using the name IBM in text."
https://www.ibm.com/legal/copytrade

Donc, j'ai parfaitement le droit de mettre des majuscules et minuscules ou je veut dans le nom de PoStGrEsQl !

Il faut savoir lire !

A +

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).

Salut,

En fait, je ne voulais pas rentrer dans ce sempiternel thread : m$ vs le reste du monde mais ...

Citation:

---

Envoyé par SQLpro

Croire que PostGreSQL est aussi bon que SQL Server est une vaste fumisterie tant ses bugs et errement fonctionnels sont nombreux.

---

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 mienne :mouarf:

Le débat parle ici d'un comparatif entre PostGreSQL vs MS-SQL, pas de logos ni de trademarks. Ceci n'apporte absolument rien au débat. Si vous n'êtes pas d'accord, c'est tout à fait votre droit. Mais donnez de vrais arguments.

Il serait intéressant de tester sous Linux pour l'écart que cela représente.

Et il faut comparer ce qui est comparable, avec les mêmes options d'optimisations sur les deux plateformes, ce qui peut être très difficile (options/fonctionnement différent). Le fait de ne pas être sur le même FS peut aussi biaiser les résultats.

Citation:

---

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.

---

Pour SQL-Pro c'est clairement MS-SQL, et il ne s'en cache pas. Mais d'un autre coté c'est un expert du produit. Quelle que soit l'utilisation, il pourra très facilement faire en sorte d'avoir la meilleure optimisation possible. Si maintenant il est forcé de faire un projet avec PostGreSQL, maitrisant moins le produit, il est logique qu'il puisse moins bien l'optimiser, mais dans ce cas là il serait malhonnête de dire que PostGreSQL est moins bon.

Si maintenant, on se place du coté d'un responsable financier, celui-ci pourra très bien considérer PostGreSQL comme plus intéressant par sa gratuité du produit. Mais ce ne sera pas forcément le cas pour le responsable informatique, pour qui de son point de vue verra qu'il est plus facile de trouver des compétences MS-SQL que PostGReSQL.

Citation:

---

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.

---

Ceci peut être également reproductible avec MS-SQL je pense.

Ensuite je pense que pour faire un test juste et impartial, il faut connaitre à minima les deux produits.

Mais tout ça c'est un peu comme comparer un moteur essence et un moteur Diesel :

Citation:

---

A puissance égale, un moteur essence et son alter ego diesel délivrent des performances brutes similaires. Mais selon la plage d’exploitation, l’agrément de conduite est bien différent.

---

Peut-être hors de propos, mais j'ai pris une base Oracle sur un Exadata, la même base passée à la moulinette ora2pg. A chaque fois que je teste une requête, PostgreSQL va plus vite. Imaginez un peu si sqlpro faisait un comparatif sqlserver vs oracle exadata !!

Encore une fois il faut comparer ce qui est comparable. Ta solution c'est du cloud (du moins je pense), mais tu n’indiques pas les infos sur l'infra : machine dédiée ou mutualisée, type de disque, RAM, etc.

Ton comparatif est donc biaisé.

Imaginez un peu si frost242 faisait un comparatif PostGres vs oracle exadata !! :)

Citation:

---

Envoyé par chrtophe

Encore une fois il faut comparer ce qui est comparable. Ta solution c'est du cloud (du moins je pense), mais tu n’indiques pas les infos sur l'infra : machine dédiée ou mutualisée, type de disque, RAM, etc.

Ton comparatif est donc biaisé.

Imaginez un peu si frost242 faisait un comparatif PostGres vs oracle exadata !! :)

---

Aucun cloud par ici. L'exadata, c'est du hardware dédié (Exadata X7) avec tout leur bordel propriétaire et leurs algorithmes hyper secrets - je te laisse chercher le détail du hardware. L'Exa est découpé en VM, et la VM sur laquelle j'ai fait des tests était dédiée (au moins 64 ou 128 Go de RAM, 8 CPU) Le PostgreSQL est hébergé sur une pauvre VM sur une avec 2 VCPU et 8Go RAM avec un stockage SSD sur une baie SAN, sur une infra pas dédiée aux BDD et assez active par ailleurs. Je savais que PostgreSQL irait plus vite sur certaines requêtes, mais je ne m'attendais pas ce que PostgreSQL aille plus vite sur la requête qui faisait des jointures de plusieurs tables sans appliquer le moindre prédicat (genre 27 min pour Oracle, 16 pour PostgreSQL).

La VM t'es dédiée mais peut-être pas la machine, ce qui pourrait justifier cet écart important.

Par ailleurs, une recherche google Exadata me retourne tout de suite sur Exadata cloud service. Donc on ne sait pas :
- si tu étais sur un service cloud, avec une VM dédiée, avec un niveau de priorisation de ton activité non connue
- sur un hardware mutualisée avec une VM t'étant dédié, mais avec peut-être d'autres VM chargées

On ne peut pas faire de comparaison fiable dans ses conditions.

Citation:

---

Envoyé par pokap

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

---

Nous n'en somme qu'a la partie 2 de cette série qui va en comporter au moins 6. Donc c'est très prématuré de dire qu'il ne s'agit que de temps de réponse, même si les deux premiers article de la ,série compare les temps de réponse de PostGreSQL et Mictosoft SQL Server.

Citation:

---

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.

---

Bien évidemment que les temps de réponse sont un critère majeur de décision dans le choix d'un SGBDR pour l'entreprise ! Si votre chaine de traitement pour calculer la paye met 10minutes sur un système et plus de 48 heures sur un autre système, je n'ose même pas imaginer la gueule des salariés qui vont recevoir leur paye avec 2 jours de retard parce que la DSI a choisit PostGreSQL !

Le temps c'est de l'argent et en matière économique cela compte pour beaucoup!

Citation:

---

Et comme on est dans une rubrique débutante,

---

Visiblemment vous nêtes pas au courant que developpez.com est un site pour les professionnels de l'informatique....

Citation:

---

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.

---

Pour gérer votre cave à vin ou votre collection de CD ok... Mais pour les besoins de l'entreprise votre affirmation est stupide !

Citation:

---

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.

---

Vous n'avez pas tort, mais tous les critères doivent rentrer en compte... Les performance étant souvent un critère très important pour les entreprises. Ainsi, de nombreuses entreprises ont été obligé de se débarrasser de MySQL par exemple au profit notamment de SQL Server compte tenu de ses performances catastrophique...

Citation:

---

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).

---

Cela va venir dans les articles suivants.... Et contrairement à ce que vous pensez en disant "sans aucun cache" oui, vous avez du cache... mais probablement ne le savez vous pas.... ce qui expliquerais vos à peu près (pour ne pas parler d'inculture) au sujet des SGBDR !

A +

Citation:

---

Envoyé par destroyedlolo

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", ...

---

Il est évident qu'avec une telle expérience limité à un seul SGBDR et un seul applicatif, vous pouvez donnez un argument pesant et optimal !!!!

Moi je dois être un con, puisqu'à ce jour j'ai du voir plus de 400 solutions différentes utilisant différents SGBDR allant de IBM DB2 à MySQL en passant par Oracle, RDB, Sybase, Gupta SQL, Interbase, Ingres, PostGreSQL... ce qui, selon vous, ne me donerais pas le droit de faire des tests comparatif qui montrent à l'évidence que PostGreSQl à des performances désastreuses pour certaines requêtes !

Citation:

---

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.

---

Vous dites vraiment n'importe quoi car il est prouvé, aussi bien par le NIST que par les statistiques de StackOverflow, que les produits MS sont probablement les moins buggués !

Citation:

---

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 !

---

Enclonclusion vous dites que c'est de la merde mais vous ne l'avez jamais testé !

Citation:

---

Dire que "PostgreSQL est plus buggé" laisse juste entrevoir une mauvaise fois presque aussi forte que la mienne :mouarf:

---

Encore une fois ce n'est pas mois qui le dite mais le NIST agence américaine de surveillances des vulnérabilités ainsi que les statistiques de stackoverflow.....

A +

Citation:

---

Envoyé par SQLpro

Ce qui est bien évidemment totalement faux.... mais il est vrai que le nombre de serveur PG sous Windows diminue au fil du temps..

---

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 ?

Citation:

---

Envoyé par SQLpro

C'est probable et notez que c'est la même chose avec SQL Server dans les tests que nous avons effectué dans cette étude :
https://sqlpro.developpez.com/tutori...windows-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é.

Citation:

---

Envoyé par SQLpro

Néanmoins, ces gains de performance sont marginaux par rapport à des écarts de plus de 1000 fois !

---

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.

Citation:

---

Envoyé par SQLpro

Ah oui ? Allez donc dire à des clients qui passent de l'un à l'autre et constatent que leurs requêtes de comptage sont mille fois plus lente mais que cela n'a aucun intérêt....

---

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.

Citation:

---

Envoyé par SQLpro

Ce que ne font pas, bien entendu les tenants du libre dans des articles bidons farcis d'erreurs comme celui-ci qui est une honte pour EnterpriseDB et que je démolirais pièce par pièce dans la 3e partie de ma série d'articles :
https://www.enterprisedb.com/blog/mi...at-differences

---

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.

Citation:

---

Envoyé par SQLpro

Lesquelles ? Au lieu de dénigrer, donnez quelques exemples des erreurs que j'ai commises !

---

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.

Citation:

---

Envoyé par SQLpro

il est prouvé, aussi bien par le NIST que par les statistiques de StackOverflow, que les produits MS sont probablement les moins buggués !

---

Peut-on avoir les URL vers ces "preuves" ?

Bonsoir,

3 tests réalisés par mes soins . Os Windows 8 , pc icore 5 .

Test 1 réalisé, une requête pour trouver une date min ou max rattaché à un code unique , répétés plusieurs fois :

6 millions de lignes pour 2 colonnes

> MySQL 5 avec "group_concat" : prés de 9h d’exécutions
> SAS Guide Enterprise 9.4 avec "proc tree "et "proc transpose ": 30 secondes
> Access 2013 avec "transform" et "pivot" : 2 minutes

Test 2 de chargement des données à partir de fichier text : 80 millions de lignes , pour 70 colonnes, sur 80 fichiers , pour 20 Go de data

> SAS Guide Enterprise 9.4 : 3 à 5 minutes de chargement
> MySQL 5 : 1h à 1h30 de chargement
> Access 2013 : 30 minutes

A noter pour Access et SAS j'utilise en supplement du SQL , du VBA et du code SAS.

Je n'ai pas l'infra à dispo pour faire le test sur Oracle.

Test 3 : avoir un très gros volume de données dans une table (70 colonnes)

> SAS Guide Enterprise 9.4 peine au de la de 200 millions
> Access 2013 : peine entre 50 et 75 millions de lignes
> MySQL 5 : 600 millions de lignes en mode "archive"

De ces test de perf , j'en déduis bel et bien que MySQL est bon a stocker de la data en masse , sans trop de requetage pointu . Les outils SQL comme Access , (SQL Server donc aussi), SAS, sont bon pour faire du traitement de masse. On est pas du tout dans le même philo.

Pour les tests de SQLpro j'ajouterai un critère : besoin de stocker en masse ou de traiter en masse ? Au quel cas le besoin est différent ...

Il suffit de se rendre sur le site du NIST :

https://www.cvedetails.com/product/5...?vendor_id=336
=> 112 vulnérabilités pour un volume de code installé de 1,3 Go (incluant PostGis et l'Agent)

https://www.cvedetails.com/product/2...l?vendor_id=26
=> 86 vulnérabilités pour un volume de code de 12,4 Go (et je ne compte pas les autres moteurs de SQL Server que sont SSIS, SSAS et SSRS dans ce volume de code !)

Le ratio brut est donc 57% de vulnérabilités dans PostGreSQL contre 43 % pour SQL Server.

Rapporté au volume de code de l'installation du moteur SQL, cela fait :

• 112 / 1.3 = 86.2 pour PostGreSQL
• 86 / 12,4 = 6,9 pour SQL Server

En d'autres termes, rapporté au volume de code, le ratio devient dont de 93% de vulnérabilités pour PostGreSQL contre 7 % pour SQL Server...


Cette étude de hubspotnet, montre aussi les dangers inhérent aux expositions publiques des SGBDR. Les serveurs exploitant PostGreSQL ont beaucoup plus de ports et de services exposés sur l'Internet public que les serveurs exploitant SQL Server :
Pièce jointe 594435

Bref, PostGreSQL est 4,7 fois plus exposé à des attaques par ports ou service ouverts au public sur Internet que Microsoft SQL Server.

A +

Citation:

---

Envoyé par SQLpro

Il suffit de se rendre sur le site du NIST : https://www.cvedetails.com/product/5...?vendor_id=336
...

---

Merci, je n'aurais jamais deviné que le site du nist était cvedetails.com.

Donc 112 pour pg comparé à 86 pour sqlserver, ça fait que pg est "4,7 fois plus exposé à des attaques".
Bon bah, je crois que ça se passe de commentaire..

Citation:

---

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é.

---

Les tests de SQLPro ne sont peut-être pas partiaux, mais qui, avec des compétences en base de données, se propose de faire une étude comparative impartiale ou non avec Linux ? Personne.

Citation:

---

Vous avez des statistiques d’utilisation de PostgreSQL sous Microsoft Windows et GNU/Linux ?

---

Je travaille avec les TPE, PME et assos. Sur Windows je n'ai vu que quasiment MS-SQLServer ou SQLExpress pour des applis en client lourd, exclusivement MySQL pour le Web (en hébergement externe), et une seule fois PostGRESQL sous Windows pour une appli métier avec client lourd, mais à mon niveau aucune différence pour l'utilisation et impossible de faire un éventuel comparatif dans le contexte.

Citation:

---

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

---

Pas besoin, ils connaissent le nombre de licences qu'ils vendent, sauf pour SQLExpress.

De ce que je peux comprendre/déduire avec mes compétences sur certaines différences entre SQL server et la concurrence :

Citation:

---

Les opérations de lecture et d'écriture physique bénéficient aussi du parallélisme systématiquement du fait que les opérations d'IO sont effectuées directement par SQL Server et non à travers la couche système comme c'est le cas de PostGreSQL ou MySQL.

---

Sur cet aspect, ça peut être à l'aventage de Linux si (je ne peux pas juger) ses FS sont plus efficaces que ceux de Windows pour les opérations I/O, et dans ce cas les SGBDR sous Linux ont tout intérêt à déléguer ça au système avec des FS haute performances comme XFS.

Une chose en faveur d'SQL-server :

Citation:

---

Par rapport à ses concurrents que sont Oracle, MySQL ou PostgreSQL, SQL Server se distingue par le fait que c'est un SGBDR(Système de Gestion de Bases de Données Relationnelles) originellement multibase et multischéma. Il est possible de faire des requêtes nativement interbases. Par exemple la requête suivante lie deux tables de deux bases de données différentes :

SELECT *
FROM BASE_A.dbo.TABLE1 AS T1
INNER JOIN BASE_B.dbo.TABLE2 AS T2
ON T1.ID = T2.ID;

L'optimiseur étant capable de faire un plan de requête parfaitement optimisé même si la requête consulte des données de plusieurs bases...
Bien que PostGreSQL soit multibase et multischéma, cette possibilité d'interrogation simultanée n'est pas native et il faut passer par le truchement de "dblink" qui interdit les jointures et donc toute possibilité d'optimisation... Oracle avec sa version 12 tente d'intégrer ce même concept de multibase (appelé multi-tenant) mais souffre du même problème que PostGreSQL. MySQL est mono schéma, multibase.

---

Mais en cherchant

Par contre j'ai trouvé ça en googlelisant :

Citation:

---

A simple but non-obvious one-line change (ANY(ARRAY[...]) to ANY(VALUES(...))) in a (bad) PostgreSQL 9.0 query cuts query time from 20s to 0.2s. Starting with low-level metrics we make our way to your best friend: EXPLAIN ANALYZE. The amount of time invested will pay off a hundred times over. The Postgres community is your second best friend.

---

Je ne suis pas spécialiste en bases de données, et ne comprend pas vraiment si ça change quelque chose en dehors de l'écriture de la requête, mais ceci est une démonstration qu'Il faut donc bien maitriser son SGBD pour l'optimiser, pas uniquement maitriser les bases de données, et que pour comparer 2 SGBD il faut les comparer en les maitrisant tous les deux, sinon il est facile de biaiser des tests que ce soit volontaire ou non.

Le fait qu'il y ai plus de CVE déclarés sur PostGresSQL ne veut pas forcément dire qu'il est plus vulnérable que SQL-Server. Les sources PosGresSQL sont libre et donc consultables, il est donc plus facile d'y trouver des failles que sur un code fermé.

Citation:

---

es serveurs exploitant PostGreSQL ont beaucoup plus de ports et de services exposés sur l'Internet public que les serveurs exploitant SQL Server :

---

Sauf que si je voulais péter un sql server, j'attaquerais plutôt par RDP, ou dernièrement les failles Exchange et là on inverse complètement la situation.

Bonsoir,

Tiens justement connait on la part de serveur avec BDD sur d'autres systèmes que MySQL ? Genre postgre , MS Server, Oracle et j'en passe ?

J'ai trouvé ça sur JDN datant de 2017 :
https://www.journaldunet.com/solutio...rce-a-la-cote/ :

- Oracle
- MySQL
- MS-SQL
- MongoDB
- PostgreSQL
- DB2

Ca me parait cohérent. Pour moi Oracle est le plus répandu dans les bases énormes. MySQL est très bien placé vu que c'est la base de données la plus utilisée pour le web, SQL Server est très répandu dans les logiciels métier tout fait utilisant une base de données, les logiciels de compta PME.
MongoDB est un cas particulier, c'est du NoSQL. PostgreSQL, que personnellement je n'ai vu qu'une fois dans un logiciel tout fait sous Windows est mieux placé que je le pensais.

Reste à voir si la source est fiable.

Citation:

---

Envoyé par SimonDecoline

Merci, je n'aurais jamais deviné que le site du nist était cvedetails.com.

Donc 112 pour pg comparé à 86 pour sqlserver, ça fait que pg est "4,7 fois plus exposé à des attaques".
Bon bah, je crois que ça se passe de commentaire..

---

Le nombre de bug (car les vulnérabilités exposées sont des bugs) sont proportionnelles au nombre de ligne de code, donc au volume en octet des exécutables.
En effet, le nombre de vulnérabilités brut n'a aucun sens. Un peu comme si quelqu'un qui faisait 1 000 km par an avec sa voiture et avait 2 accrochage en moyenne pas an serait qualifié de meilleur conducteur que quelqu'un qui en aurait 3 par an en faisant en moyenne 20 000 km dans ce même laps de temps....

Donc,

• PostGreSQL avec 112 vulnérabilités et seulement 1,3 Go de code cela fait une moyenne de 86 vulnérabilités par Go de code
• MS SQL Server avec 112 vulnérabilités et 12,4 Go de code cela fait une moyenne de 9 vulnérabilités par Go de code

86/9 = 9,555555555.... Donc PostGreSQL est 9,6 fois plus vulnérable que MS SQL Server tout en offrant beaucoup moins de services !

A +

Citation:

---

Envoyé par SQLpro

le nombre de bug (car les vulnérabilités exposées sont des bugs) sont proportionnelles au nombre de ligne de code, donc au volume en octet des exécutables...

---

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...

Citation:

---

Envoyé par FatAgnus

Pourquoi s'entêter à mesurer les performances de PostgreSQL alors que personne n'utilise PostgreSQL sous Windows en production
J'ai bien peur que ce test n'est que peu d'intérêts.

---

J'ai bien des postgresQL en production sous Windows. Et je sais bien que Mysql/MariaDB et postgresql sont plus lents que MsSQL, sauf à travailler correctement les modèles de données.

J'utilise MsSQL depuis des années et le connait assez bien. Il a des avantages certains:

• Il est très performant sur des modèles mal conçus
• il est très parmétrable au besoin
• il est très performant "out of the box"

MAIS: SQL Server est un logiciel spécial qui utilise des appels systèmes et un mode de fonctionnement pour lequel Windows a été "customisé": gestion mémoire à part, gestion cache disque à part, écriture en mode non standard sur le disque (mise à jour des dates de modification différées par exemple)...

Les logiciels comme postgres et mariadb sous Windows ne disposent pas de ce genre de fonctionnement particulier, notamment concernant l'écriture des fichiers qu'ils font en flux "standard". Leurs écritures sont très couteuses.
Par contre, ils cohabitent infiniment mieux avec des logiciels comme IIS (IIS+SQL Server sur le même server = tuning de base à réaliser obligatoirement - car les deux fonctionnent selon les mêmes "modes" de gestion mémoire, et c'est un peu un mode "highlander":il ne peut en rester qu'un).


Ceci dit, le test est peu représentatif, car il se base sur de petits jeux de données ridicules. SQL Server a souvent dans ses statistiques tout ce qu'il faut pour des count ou des count distincts, et si les données de la table sont couvertes intégralement par les statistiques, c'est un peu facile pour lui.

Quand on traite 1,5M de lignes, on voit bien que SQL Server est plus rapide que Mysql ou postgresql, mais pas dans ces proportions du tout...

J'interviens rarement dans ce genre de débats mais aller ... un peu de sarcasme ... quand je vois justement des articles qui font exactement la même chose mais dans l'autre sens .. article souvent très détaillé sur l'implémentation de PostgreSQL et aucune ligne sur une quelconque configuration de SQL Server ... voir pire un environnement dédié physique pour la dite base de données open source et environnent virtualisé pour SQL Server ... alors je me dis .. c'est de bonne guerre :)

En tout cas je trouve intéressant d'avoir ce genre d'articles d'un point de vue différent (certes avec un parti pris SQL Server) mais ca change un peu et il faut souligner que dans l'autre sens c'est également le cas. Je trouve toujours aussi intéressant de découvrir les subtilités de chaque moteur pour essayer d'atteindre la meilleure performance possible en fonction d'un protocole de test donné (du moins pour les articles les plus sérieux) :) Il faut, je pense, souligner une certaine passion des auteurs pour défendre leur SGBD favori et cela reste bénéfique pour le tout le monde :)

++

Citation:

---

Envoyé par chrtophe

Le fait qu'il y ai plus de CVE déclarés sur PostGresSQL ne veut pas forcément dire qu'il est plus vulnérable que SQL-Server. Les sources PosGresSQL sont libre et donc consultables, il est donc plus facile d'y trouver des failles que sur un code fermé..

---

C'est intéressant de dire cela car justement c'est un argument que j'entends souvent ... parce que le code est ouvert alors on a plus de rapidité à fixer les bugs ... c'est vrai mais on aussi plus de facilité à exploiter les failles .. ca reste un point de vue viable.

Là où je te rejoins avoir plus de CVE ne veut pas dire forcément moins sûr (tout dépend la CVE) mais il faut reconnaître que cela laisse plus de portes d'entrées aux exploitations de failles.

++

En avant première et en anglais la partie 3 de cette série d'article :

https://sqlpro.developpez.com/tutori...ed-comparison/

Une comparaison extrêmement détaillé de PostGreSQL vs SQL Server...

Il s'agit d'une réponse à cet article qui compare ces deux SGBDR, et donne de fausses informations :
https://www.enterprisedb.com/blog/mi...at-differences

Bientôt en français sur ce site...

A +

Citation:

---

Envoyé par steel-finger

SQLPro il aurait été bien de proposé des solutions pour PostgreSQL dans votre benchmark car juste de dire c'est plus rapide sur SQL Server, au moins ça aurait permis de donner des conseils voir de l'info aux gens lisant votre post !
Edit: Les testes sont fait sur SSD ou HDD ?

---

Ne vous inquiétez pas il y aura au moins 5 articles, voir plus sur le sujet.
La 3e partie parlera de comparatifs fonctionnel, des manques des uns et des autres...
La 4e proposera des passerelles de SQL Server vers PG
La 5e aussi !

Disque HD, mais cela n'a aucun intérêt vu que les requêtes sont faites exlusivement en cache quand c'est de la lecture et principalement en cache (sauf journalisation) pour les écritures. Pour rappel les écritures des données dans les fichiers (tables et index) sont asynchrones et donc, les temps d'écriture ne peuvent pas être comptés dans les temps mesurés.

A +