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

Version imprimable

Voir 40 message(s) de cette discussion en une page

26/03/2021, 20h30
frost242

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).
26/03/2021, 21h04
chrtophe

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.
27/03/2021, 13h33
SQLpro

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 +
27/03/2021, 13h43
SQLpro

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 +
27/03/2021, 15h11
FatAgnus

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.
27/03/2021, 17h27
Invité

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" ?
27/03/2021, 18h41
tanaka59

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 ...
27/03/2021, 19h10
SQLpro

1 pièce(s) jointe(s)
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 +
27/03/2021, 19h46
Invité

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..
27/03/2021, 20h01
chrtophe

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.
27/03/2021, 20h13
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é.

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.
27/03/2021, 21h13
tanaka59

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 ?
28/03/2021, 10h05
chrtophe

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.
29/03/2021, 19h31
SQLpro
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 +
31/03/2021, 17h24
Invité

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...
01/04/2021, 08h45
Rep.Movs
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...
03/04/2021, 16h37
mikedavem

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

++
03/04/2021, 16h42
mikedavem

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.

++
03/04/2021, 19h28
SQLpro

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 +
14/04/2021, 17h34
SQLpro

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 +

Voir 40 message(s) de cette discussion en une page