Le blog de SQLpro » PostGreSQL

Benchmark PostgreSQL vs SQL Server… comment biaiser !

SQLpro — Tue, 17 Nov 2015 22:25:52 +0000

La mauvaise foi règne encore chez les aficionados de PostGreSQL… L’entreprise Red Hat, que je croyais sérieuse, à effectué un benchmark entre PostGreSQL et SQL Server stupéfiant de mauvaise foi… Voici mes remarques. À noter, ce comparatif porte sur une version payante de PostGreSQL !

On trouvera le benchmark dont je parle « Comparing BenchmarkSQL Performance on Red Hat® Enterprise Linux 5 to Windows Server Enterprise » à l’URL :
https://www.redhat.com/pdf/rhel/bmsql-postgres-sqlsrvr-v1.0-1.pdf

Passons sur le choix du benchmark : le TPC-C qui date de 1992 (soit 23 ans…) est constitué d’une base de données qui comporte 9 tables et dont on peut trouver le détail à l’URL :
http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5-11.pdf. Qui aujourd’hui utilise en production une base composée au plus de 9 tables ? En revanche il existe un benchmark plus moderne, le TPC-E composé de 33 tables nettement plus réaliste !

TUNING DES OS

À la page 10 dudit benchmark on trouve le paragraphe 3.3.1 (Operating System) qui montre comment à été optimisé Linux.

On y voit clairement que seul l’OS Linux a été optimisé. Quelles optimisations ont été faites pour Windows ? Aucune !

Or il est bien évident qu’une installation standard de Windows pour héberger SQL Server n’est pas optimale sans certains réglages :
– désactivation des services inutiles (ce qui a été fait pour Linux et pas pour Windows)
– désactivation du système d’économie d’énergie (qui n’existe pas sous Linux.. pas écolo les linuxiens !)
– activation de Turbo Boost
– activation de l’Instant File Initialization pour le service SQL Server
– activation du Lock Page in Memory pour SQL Server
…

TUNING DES SGBDR

À la page 11 figure le paragraphe 3.3.3 (Database) qui montre comment a été optimisé PostGreSQL.

On y voit clairement que seul PostGreSQL a été optimisé. Red Hat revendique même sa tromperie : « …no specific SQL Server tuning was performed » !

Or il est bien évident que plusieurs optimisations sont nécessaires :
– la ventilation du stockage des fichiers de données de la base tempdb (objets temporaires) en autant de fichiers d’égales longueur que de CPU (donc au moins 2);
– le dimensionnement correct des fichiers de la base de données à 40 Go pour les données et 10 Go pour les transactions avec à nouveau au moins 2 fichiers pour les données
– la limitation de la RAM utilisée par SQL Server à au moins 44 Go (max server memory);
– la limitation du parallélisme des requêtes à 4 (du fait que le serveur présente 2 CPU Quad Core et 4 LUN par agrégats RAID) et hausse du seuil de déclenchement à 12 (cost threshold for parallelism);
– le positionnement du paramètre « optimize for ad hoc workloads » à 1 sinon les plans de requête ne sont pas mis en cache !
– l’élévation du délai de report des écritures physique de données (checkpoint), paramètre « recovery interval », à 60 minutes pour coller au paramètre « checkpoint_timeout » positionné à 1 heure dans PostGreSQL (un délai tout à fait anormal entre nous, car cela pourrait s’avérer dangereux en production…)
…

POSTGRESQL PLUS

Très discrètement, le document montre que la version testée de PostGreSQL n’est pas la version gratuite Open Source, mais la version payante fabriquée par EntrepriseDB et nommée « PostGreSQL PLUS.
Nous n’avons pas pu obtenir le prix d’une telle version directement sur le site d’EntrepriseDB, mais sur un autre document, provenant probablement du gouvernement britannique ce prix apparait être 3 265 £ par CPU (socket), soit environ 4 700 €…
En comparaison, SQL Server 2008 R2 version Web, suffisante pour ce benchmark, coute 4 246,41…

LES RÉSULTATS

Comme on s’y attendait, avec un tel paramétrage, PostGreSQL bât haut la main SQL Server ! haut la main ? pas si sûr…

Il faut vraiment y aller à la loupe pour voir la différence. En mesurant après impression avec une règle, j’ai constaté un écart relatif de 3 à 5 % mesuré sur les entrées 40 et 140 de l’histogramme…

Bref, il est très probable qu’avec les réglages manquants pour Windows et SQL Server, Red Hat n’aurait jamais publié un tel benchmark tant il aurait été défavorable à PostGreSQL fût-il PLUS !

Ce qui me navre c’est que je croyais naïvement que Red Hat était une entreprise sérieuse !

***

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES
Expert S.G.B.D relationnelles et langage S.Q.L
Moste Valuable Professionnal Microsoft SQL Server
Société SQLspot : modélisation, conseil, formation,
optimisation, audit, tuning, administration SGBDR
Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Communautés PostGreSQL… entre auto satisfaction et mauvaise foi ?

SQLpro — Tue, 10 Nov 2015 11:02:29 +0000

J’ai récemment posté un commentaire à un article de ce blog :
expert-postgresql.fr
malheureusement ma réponse a rapidement été modérée sous la forme d’un poubellisation !
Elle n’avait cependant aucune remarque diffamatoire ni désobligeante, mais rétablissait certaines vérités.
Comme ce n’est pas la première fois que mes propos critiques dérangent je pense que la communautés PosGreSQL est beaucoup moins libre qu’on ne le pense….
Voici donc mon commentaire accompagné d’une reprise de cet article…

1 – cycle de production de PostGreSQL

»
PostgreSQL stabilise et distribue une nouvelle version majeure de sa base de données chaque année.
[..]
Bien sûr, très peu de projets industriels peuvent se permettre de revoir leur architecture, leurs procédures et leur intégration SQL chaque année, et même dans le milieu très dynamique des services web cela n’arrive quasiment pas.Aussi les versions de PostgreSQL sont-elles maintenues pendant au moins cinq ans, les versions courantes de PostgreSQL sont donc au nombre de 5 à 7 selon les moments de l’année.
»

Mon commentaire sur ce point :

Vous affirmez que le rythme des versions de PostGreSQL est très élevé… Une toutes les 6 mois à vous lire…
Faisons la comparaison…

Rythmes des versions de SQL Server

Vers. majeure Vers. mineure Date
-------------- ------------- ------------
2008 RTM 10.00.1600 07/08/2008
2008 SP1 10.00.2531 07/04/2009
2008 SP2 10.00.4000 29/09/2010
2008 SP3 10.00.5538 04/07/2015
2008 SP4 10.00.6000 30/09/2014

2008 R2 RTM 10.50.1617 14/06/2010
2008 R2 SP1 10.50.2500 09/10/2012
2008 R2 SP2 10.50.4000 26/06/2012
2008 R2 SP3 10.50.6000 26/09/2014

2012 RTM 11.00.2100 06/03/2012
2012 SP1 11.00.3000 06/11/2013
2012 SP2 11.00.5343 14/07/2014

2014 RTM 12.00.2000 01/01/2014
2014 SP1 12.00.4100 14/05/2015

Soit 14 versions en 6 ans, plus de 2 par an dont 4 versions majeures… Rien à envier donc à PostGreSQL !
PostgreSQL n’a eu dans cette même période que :
2 versions majeures : la 8 en 2005 et la 9 en 2010
En tout, de 2008 à 2015 il y a eu 7 versions mineures/majeures, soit 2 fois moins que SQL Server…

En sus les versions de SQL Server sont maintenues par le support Microsoft de manière publique avec un décalage de 2 versions majeures (soit 6 ans) et de manière payante (support étendue) près du double…

Fin du support étendu des différentes versions :

SQL Server 2000 : Le 09 Avril 2013 soit 13 ans
SQL Server 2005 : Le 12 Avril 2016 soit 11 ans
SQL Server 2008 : Le 09 Juillet 2019 soit 11 ans
SQL Server 2008 R2 : Le 09 Juillet 2019 soit 9 ans
SQL Server 2012 : Le 12 Juillet 2022 soit 10 ans

2) Avancées technologiques

»
Il existe ensuite de nombreux points techniques donnant un avantage très net à PostgreSQL, soit qu’il s’agisse d’innovations technologiques issues de la recherche, telles les « Serializable snapshot isolation » (ou SSI)…
»

Mon commentaires sur ce point :

Vous parlez du niveau d’isolation en invoquant le « Serializable snapshot isolation »
Mais PostGreSQL est toujours incapable d’utiliser le niveau d’isolation normatif READ UNCOMMITTED qui permet d’éviter tout verrou.
SQL Server dispose depuis la version 2005 du niveau d’isolation SNAPSHOT en 2 modes différents :
SNAPSHOT et READ COMMITTED SNAPSHOT
En sus dans SQL Server il est possible de changer le niveau d’isolation à tout moment, y compris au sein même d’une transaction, ce qui n’est pas le cas dans PostGreSQL. Ainsi, le code suivant marche sous SQL Server et provoque une erreur dans PostGreSQL :

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

BEGIN TRANSACTION;

UPDATE TEST_STATS
SET C2 = UPPER(C2) WHERE c1 = 181092;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

UPDATE TEST_STATS
SET C2 = UPPER(C2) WHERE c1 = 181099;

COMMIT;

3) Facilité de codage

»
Bénéficier de PostgreSQL pour résoudre cet ensemble de problème permet de ne pas avoir à les résoudre à nouveau dans votre application (quel jour serons-nous dans trois mois ? SELECT to_char(date ‘today’ + 3 * interval ‘1 month’, ‘Day’); est sûrement plus facile à utiliser que n’importe quel autre code, les développeurs lisant cela seront sûrement d’accord).
»

Et mon commentaire

Vous pensez sincèrement que la requête suivante (SQL Server) :

SELECT DATENAME(weekday, DATEADD(month, 3, GETDATE()))

est nettement plus compliquée que celle-ci (PostGreSQL) ?

SELECT to_char(date 'today' + 3 * interval '1 month', 'Day');

…pour reprendre votre exemple !

En sus PostGreSQL donne un résultat en anglais, même si l’installation a été faite avec une locale française, alors que SQL Server la donne dans la langue de Victor Hugo si l’utilisateur a été déclaré comme Français (avec la cédille sans les tables système…) !

4) Coût des licences

»
Bien évidemment, tout cela sans s’acquitter de coûts de licence appliqués par serveur ou qui dépendent de la capacité et du nombre d’installations dont vous avez besoin pour déployer une architecture.
»

Et mon commentaire :

Vous invoquez le coût inexistant des licences PostGreSQL… Vous avez bien raison. mais ça c’est la bidouille. MS SQL Server présente aussi une version gratuite, mais qui l’utilise de manière industrielle ?
Les entreprises prennent des assurances en achetant fort cher des contrats d’assistance auprès de boîtes comme 2ndQuadrant, Smile ou Dalibo en France… Qui ne font jamais du 24h/24 ni du 7j/7 !
Et ces mêmes entreprises ont souvent besoin de recourir à des prestataires PostGreSQL pour régler certains problèmes…
Alors que lorsque vous payez une licence SQL Server, vous avez droit au support 24/24 7/7…

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Comparatif des fonctionnalités PostGreSQL 9.2 SQL Server 2012

SQLpro — Tue, 26 Mar 2013 09:24:49 +0000

Voici une étude comparant les fonctionnalités de Microsoft SQL Server version 2012 et de PostGreSQL version 9.2.
Dans ce comparatif des fonctionnalités de nombreuses sources et explication sont fournies.
Comparaison PostGreSQL 9.2 Microsoft SQL Server 2012 fonctionnalités

Le site web sur le SQL et les SGBDR


Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot

Où et comment sont stockées mes données avec PostGreSQL ?

SQLpro — Thu, 07 Mar 2013 10:46:25 +0000

Comme tous les SGBD relationnel, PostGreSQL stocke les données des tables et des index dans des fichiers organisés sous forme de pages. Que les données soient dans le cache (donc en mémoire vive), ou bien sur le disque, ces pages sont structurées d’une manière bien particulière afin d’exploiter au mieux les lectures et écritures physiques et logiques ainsi que la gestion des versions de ligne.
L’ensemble des pages figurent dans des fichiers.
Cet article a pour but de vous présenter comment et où PostGreSQL stocke les données et compare sa façon de faire aux autres SGBDR que sont Oracle et MS SQL Server.
Mais contrairement à ses grands frères, PostGreSQL ne dispose pas d’une gestion des espaces de stockage… Voyons ce que cela induit notamment sur le plan des performances et de la volumétrie.

L’étude est disponible sous format PDF à l’URL suivante : Ou sont stockées mes données avec PostGreSQL

Le site web sur le SQL et les SGBDR


Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot