Le blog de SQLpro » comparaison

Modèle générique vs modèle spécifique

SQLpro — Fri, 10 Aug 2018 08:04:43 +0000

Dans le cadre d’un héritage de données ayant de multiples enfants aux caractéristiques très diverses, est-il préférable de concevoir un modèle de données générique ou un modèle de données spécifique ? De nombreux jeunes développeurs pensent naïvement qu’un modèle générique est plus facile… Mais c’est souvent une erreur qu’il faudra payer au prix fort une fois l’application fonctionnelle. Démonstration…

Je suis partit initialement de ce post :

Avis sur l’architecture de ma base de données (choix de l’option)

La demande étant la suivante :

J’ai 30 familles de critères. Chaque famille comporte un nombre variable de critères pour un total d’environ 600 critères.
Chaque critère appartient à une seule famille de sorte que les 600 sont à répartir dans les 30 familles.
Ma question:
– devrais-je créer une table par famille et insérer dans chaque table les critères qui lui appartiennent; (solution 1)
ou alors:
– créer une table contenant les 30 familles et une autre contenant les 600 critères. Ensuite, créer les relations qui lient chaque famille à ses critères et/ou inversement. (solution 2)

et ma réponse :

Pour qu’une base réponde bien en terme de performances, on doit tout faire pour minimiser les IO.
– Dans votre solution 1, les performances seront bonne si la plupart des requêtes portent sur plusieurs critères d’une même famille
– Dans votre solution 2, les performances seront bonne si la plupart des requêtes portent sur un seul critère.

Cependant un jeune internaute peu avisé, affirmait avec force que :

pour moi la solution 2 est la + simple à mettre en place.
et le nombre d’enregistrements ne justifie pas la solution 1..
tout dépend de votre SGBD (pas précisé..), mais dans tous les cas, il suffit de mettre des ID numérique pour que les requêtes soient optimisées. Créez vos tables avec des id uniques (sous Oracle on peux utiliser les séquences) et vous aurez des traitements optimisées au mieux… mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb..
si je vois bien, vous aurez donc 3 tables avec les clef suivante :
– FAMILLE (Pk : ID_FAMILLE)
– FAMILLE_CRITERE (Pk : ID_FAMILLE, ID_CRITERE)
– CRITERE (Pk : ID_CRITERE)
Relations :
¤ Famille –> FAMILLE_CRITERES <— CRITERE
famille_critere ne contenant que le couple ID_FAMILLE, ID_CRITERE (on parle de table intermédiaire)

Ce à quoi je répondais :

La solution 2 est correcte si vous ne requêtez JAMAIS plus d’un critère à la fois. Elle est déjà moins performante à l’insertion/la mise à jour des données…
La solution 2 est imbécile, complexe et peu performantes si vous avez plusieurs critères a rechercher…
En sus, elle ne permet pas facilement de typer les informations, donc, vous aurez beaucoup de problématique de contrôle de qualité… et des performances catastrophiques

DÉMONSTRATION

Partons d’une table d’animaux :

CREATE TABLE T_ANIMAL_ANM
(ANM_ID INT PRIMARY KEY,
ANM_DATA CHAR(8000) NOT NULL);
GO

INSERT INTO T_ANIMAL_ANM VALUES (1, 'Mytilus Edulis')

█ █ █ 1ere solution : une seule table pour toute une même famille :

CREATE TABLE T_MOLUSQUE_MSQ
(ANM_ID INT PRIMARY KEY REFERENCES T_ANIMAL_ANM (ANM_ID),
MSQ_CARAPACE VARCHAR(32),
MSQ_SYMETRIE VARCHAR(32),
MSQ_COULEUR VARCHAR(32),
MSQ_DIAMETRE_MM FLOAT);

█ █ █ 2e solution (pour toutes familles), des tables « génériques » :

CREATE TABLE T_CARATERISTIQUE_CRT
(CRT_ID INT PRIMARY KEY,
CRT_LIBELLE VARCHAR(256));

CREATE TABLE T_VALEUR_VLR
(ANM_ID INT NOT NULL REFERENCES T_ANIMAL_ANM (ANM_ID),
CRT_ID INT NOT NULL REFERENCES T_CARATERISTIQUE_CRT(CRT_ID),
VLR_VALEUR VARCHAR(256),
PRIMARY KEY (ANM_ID, CRT_ID));

Ajoutons les caractéristiques identiques à celle de la solution 1

INSERT INTO T_CARATERISTIQUE_CRT VALUES (111, 'Carapace');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (222, 'Symétrie');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (333, 'Couleur');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (444, 'Diamètre mm');

█ █ █ Voici maintenant les insertions :

Pour la solution 1 :

INSERT INTO T_MOLUSQUE_MSQ (ANM_ID, MSQ_CARAPACE, MSQ_SYMETRIE, MSQ_COULEUR, MSQ_DIAMETRE_MM)
VALUES (1, 'Creatine', 'Mono', 'Bleu', '82.5')

Notez que nous n’avons fait qu’une seule requête d’insertion avec correspondance caractéristique / valeur et typage des données

Pour la solution 2 :

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Creatine' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Carapace';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Mono' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Symétrie';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Bleu' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Couleur';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, '82,5' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Diamètre mm';

Pour stocker les mêmes informations, nous avons fait 4 requêtes au lieu d’une seule….

█ Comparons maintenant le coût des 2 solutions au niveau de l’insertion :

Y’a pas à tortiller 4 requêtes coutant deux fois plus cher qu’une seule et unique requête cela est donc 8 fois plus couteux…

█ █ █ Voyons maintenant la facilité de requêtage :

interrogation multicritères ET avec solution 1

SELECT *
FROM T_ANIMAL_ANM AS A
JOIN T_MOLUSQUE_MSQ AS M
ON A.ANM_ID = M.ANM_ID
WHERE MSQ_CARAPACE = 'Creatine'
AND MSQ_SYMETRIE IN ('Mono', 'Double')
AND MSQ_COULEUR LIKE 'Bleu%' --> peut être Bleue, Bleu-marine...
AND MSQ_DIAMETRE_MM BETWEEN 75 AND 92;

la requête fait 8 lignes et 1 jointure. Elle en fera une de plus pour chaque critère supplémentaire avec juste quelques chose à rajouter à la clause WHERE…

interrogation multicritères ET avec solution 2

SELECT *
FROM T_ANIMAL_ANM AS A
JOIN T_VALEUR_VLR AS V1
ON A.ANM_ID = V1.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C1
ON V1.CRT_ID = C1.CRT_ID
JOIN T_VALEUR_VLR AS V2
ON A.ANM_ID = V2.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C2
ON V2.CRT_ID = C2.CRT_ID
JOIN T_VALEUR_VLR AS V3
ON A.ANM_ID = V3.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C3
ON V3.CRT_ID = C3.CRT_ID
JOIN T_VALEUR_VLR AS V4
ON A.ANM_ID = V4.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C4
ON V4.CRT_ID = C4.CRT_ID
WHERE C1.CRT_LIBELLE = 'Carapace'
AND V1.VLR_VALEUR = 'Creatine'
AND C2.CRT_LIBELLE = 'Symétrie'
AND V2.VLR_VALEUR IN ('Mono', 'Double')
AND C3.CRT_LIBELLE = 'Couleur'
AND V3.VLR_VALEUR LIKE 'Bleu%'
AND C4.CRT_LIBELLE = 'Diamètre mm'
AND V4.VLR_VALEUR BETWEEN '75' AND '92'

La requête fait 26 lignes avec 8 jointures… Il faudra rajouter 6 lignes à chaque critère supplémentaire, dont 4 dans la clause FROM et 2 dans le WHERE, et encore, on ne sait pas dans la clause SELECT à quelle caractéristique se réfère chacune des valeurs… Il faudrait aussi customiser la clause SELECT…

Y’a pas à tortiller la solution 1 est bien plus simple en matière d’écriture…

█ Quelles sont les performances des requêtes de recherches des deux solutions ?

Évidemment la première solution est 4,5 fois moins couteuse…

Mais il y a pire… J’ai du mettre des chiffres en chaine de caractères pour le diamètre (AND V4.VLR_VALEUR BETWEEN ’75’ AND ’92’). Si je tente de les typer en entier ou réel (AND V4.VLR_VALEUR BETWEEN 75 AND 92), cela provoque une erreur d’exécution (SQL Server) :
Msg*245, Niveau*16, État*1, Ligne*75
Échec de la conversion de la valeur varchar ‘Creatine’ en type de données int.
Logique car pour effectuer une comparaison avec une valeur numérique, il faut convertir la colonne en numérique, mais comme il y a autres chose que de purs nombres (chaines de caractères) cela se passe mal.
Bref certaines requêtes seront impossible à faire !

Plus catastrophique encore… mettre des index ne servira quasiment à rien ! En effet un index sur une chaine de caractères n’ordonne pas les valeurs de la même façon que s’il s’agissait de nombre…

En sus rien n’interdira à quelqu’un de saisir 8,2 au lieu de 8.2 (une virgule au lieu d’une point) comme diamètre, dans ce modèle inepte, alors qu’avec le bon modèle les types sont respectés…. Si tel était le cas, la valeur ne pourra pas être retrouvée !!! Il existe bien évidemment une solution pour contourner, un tout petit peu, ce modèle pourri, pour le typage. Il consiste à rajouter autant de tables de valeurs que de type… Mais il n’est pas possible de rajouter des contraintes spécifique à chaque type (par exemple vérifier qu’une pourcentage est bien entre 0 et 100 – notion de domaine SQL), ni, bien entendu, de rajouter des contraintes multicritères (une valeur dépendant d’une autre) comme c’est le cas par exemple de la chronologie des temporels de type « début » et « fin ».
Et dans tous les cas, les requêtes seront encore plus complexes à élaborer et les performances encore plus lamentables…

En guise de conclusion

Nous vous avons démontré les performances lamentable et la complexité horrifiante d’un tel modèle….

Complexité d’insertion des données

Mauvaise performances à l’insertion des données

Complexité d’écriture des recherches

Mauvaise performances pour la recherches de données

Impossibilité de typer finement (notion de domaine)

Impossibilité de placer des contraintes multicritères

Difficultés pour l’indexation

Mais comment se fait-il que des internautes osent affirmer de pareilles stupidités ?

Il est amusant de voir que certains développeur incultes affirment n’importe quoi, par ignorance, ou par bêtise, ne prenant même pas la peine de tester ce qu’ils disent… Ensuite ces mêmes développeurs, sans aucune expérience, iront vous raconter que les SGBDR c’est pas performant… Ils vous vendrons alors du NoSQL, ce qui, dans beaucoup de cas, sera pire encore !

Comme disent les américains : « garbage in, garbage out » qui peut se traduire si tu fais de la merde en entrée, tu auras de la merde en sortie ! Autrement dit, si le modèle de données est inepte, la qualité des données sera pourrie et les performances lamentables…

Décortiquons d’ailleurs les affirmations de l’internate que nous avons cité :
« tout dépend de votre SGBD (pas précisé..), mais dans tous les cas, il suffit de mettre des ID numérique pour que les requêtes soient optimisées. Créez vos tables avec des id uniques (sous Oracle on peux utiliser les séquences) et vous aurez des traitements optimisées au mieux… mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb.. »

Première affirmation stupide : « tout dépend de votre SGBD (pas précisé..) »
Comme nous sommes dans un forum sur les SGBDR, sachez cher monsieur, que tout les SGBDR fonctionnent de la même façon. Certains allant plus vite que d’autre (une Ferrari va généralement plus vite qu’une Peugeot), certains avec plus de qualité que d’autres (une Rolls-Royce est généralement de meilleure qualité qu’une Dacia).

Seconde affirmation stupide : « il suffit de mettre des ID numérique pour que les requêtes soient optimisées »
Si c’était le cas alors, pas besoin d’index ni de contraintes… On se demande donc pourquoi les éditeurs de SGBDR font de tels effort en R&D pour trouver de nouvelles formes d’index toujours plus performant… Et la plupart des informaticiens ignorent que les contraintes permettent de mieux optimiser les plans de requête… Hélas ceci est très rarement enseigné par les professeurs des universités et encore moins ceux des écoles d’ingénieurs… (je le sais pertinemment puisque j’en étais un…).

Troisième affirmation stupide : « mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar »
Et bien, non, plus une clef est longue en nombre d’octets, plus ses performances décroissent. Pour avoir la même longueur qu’un entier auto incrémenté il faudrait se limiter à 4 caractères… En sus certaines phénomènes apparaissent avec des clefs non numériques et en particulier pour des clefs littérales :

distribution peu aléatoire (parce que concentrées sur les 26 lettres et 10 chiffres parmi les 256 caractères disponibles) induisant des statistiques d’optimisation mal réparties (histogrammes erratiques)

extra-overhead lié à la gestion de la collation (sensibilité ou non à la casse, aux accents…)

façon de stocker physiquement les VARCHAR induisant des octets suplementaires et de la fragmentaion en cas d’UPDATE

Quatrième affirmation stupide : « sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb.. »
Nous avons déjà dit précédemment que les clef littérales (VARCHAR) étaient une plaie… Mais ce qui ne va pas dans cette phrase est le terme « enregistrement« … Cet internaute sait-il au moins que les SGBDR ne travaillent pas avec des « enregistrement » propre aux bases de données de type « fichier » comme c’était las cas dans les années 50 à 70 ? Les SGBDR structurent les lignes des tables dans des pages qui sont modifiées en mémoire et non pas directement sur le disque (notion physique d’enregistrement). Les pages étant physiquement écrites de temps à autres quand il y en a suffisamment à écrire par un processus asynchrone travaillant en tâche de fond.

Bref voici q’un internaute ne connaissant ni la modélisation des données ni les technologies des SGDB, vient donner des conseils stupides hélas parfois repris dans certaines applications….

CQFD

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

Oracle vs SQL Server : les options payantes qui font la différence…

SQLpro — Fri, 26 Feb 2016 09:06:50 +0000

Le monde des utilisateurs de bases de données d’Oracle commence à se faire du soucis, car la firme ayant besoin d’argent (le cours de son action baisse inexorablement depuis de nombreux mois) elle cherche par tous les moyens à racler les fonds de tiroir auprès de ses clients. L’une de ses stratégies consiste à jouer sur les options payantes… Or il se trouve que chez SQL Server le concept d’option payantes n’existe pas… Cet article fait le point sur la pratique agressive d’Oracle et compare les tarifs appliqués à Oracle à son principal adversaire, SQL Server de Microsoft.

1 – Le problème
Dans un article de « Business Insider » , un client se plaignait qu’Oracle menaçait de lui faire payer des sommes exorbitantes sauf s’il se décidait a aller dans le cloud d’Oracle. Pour arriver à faire cracher un volume exorbitant de licences, Oracle utilise une technique particulièrement tordue qui consiste à faire payer de nombreuses options, même si elles n’ont jamais été utilisées en production…
Explication :
La base de données Oracle est dotée de nombreuses options, autrefois toutes payantes. Au fil du temps et des versions, certaines options sont devenues des fonctionnalités gratuites, sans que développeurs ni dba ne sachent vraiment lesquelles le sont et, celles qui ne le sont pas. Dans la pratique certains utilisateurs activent soit volontairement pour test, soit par inadvertance, des fonctionnalités dont quelques unes sont payantes. Malheureusement ceci est tracé et l’activation d’une telle fonctionnalité ouvre immédiatement droit au paiement supplémentaire même si on ne l’utilise pas, Oracle arguant qu’il ne lui est pas possible rétrospectivement de savoir si la fonctionnalité a été réellement utilisée, simplement testée voir même totalement inutilisée. De plus, au moment de l’activation d’une fonctionnalité payante, aucun message préventif n’indique que l’option fera l’objet d’une licence complémentaire ouvrant droit à subsides au profit d’Oracle.
Une fois le temps de l’audit venu, Oracle n’a plus qu’a interroger les traces indélébiles de l’activation de ces options et envoyer la note !

2 – Pourquoi ?
Nous avons dit que la firme Oracle a besoin d’argent… Il suffit de regarder les cours de bourse d’Oracle pour constater son inexorable déclin. Dans le même temps, comparer ceux de son principal challenger Microsoft…

Comment Oracle en est-il arrivé là ? Il n’y a pas que le prix exorbitant des licences qui font reculer les clients… D’autres éléments clefs font rétrécir la part de marché d’Oracle. Cela a commencé il y a plus de 10 ans, lorsqu’est sortit la version 2005 de SQL Server de Microsoft. À l’époque, Oracle se croyait « unbreakable ». Hélas plusieurs analystes montraient que sur le plan de la sécurité Oracle était bien moins bonne que celle de SQL Server, avec des bogues récurrents et un temps de correction anormalement lent (voir notamment l’étude de David Litchfield de 2006). Sécurité qui ne s’est pas améliorée hélas au fil du temps ou les comparaisons basées sur les failles (CVE : Common Vulnerabilities and Exposures) recensées par le NIST (National Institute of Standards and Technology) donne un avantage de plus en plus grand à SQL Server au détriment d’Oracle sur le plan des failles de sécurité ! (voire l’étude Edison de 2013)

Etude Litchfield – comparatif de sécurité entre Oracle et SQL Server de 2000 à 2006

Etude Edison – CVE NIST historique des vulnérabilités Oracle vs SQL Server

Enfin, les enquêtes de satisfaction donnent un réel avantage à SQL Server (voir les enquêtes « State on Database Technology » d’Information Week ou encore les différentes études ITC).

Bases de données les plus utilisées pour les missions critiques (source Information Week – State of Database Technologie 2016)

Quant au cout global d’utilisation, il est depuis bien longtemps en faveur de SQL Server (simplicité des commandes, facilité de l’IHM, documentation exceptionnelle…) malgré les nombreux papiers dont Oracle inonde le web afin de tenter de prouver le contraire ! Il suffit de demander à des dba ayant la double casquette ce qu’ils en pense… (voire par exemple l’étude Alinean de 2015).

Outre ces éléments il y a un facteur majeur qui rentre en ligne de compte sur le long terme. Le cloud (infonuagique) !… Larry Ellison y a longtemps été peu favorable et indécis. Le résultat est sans appel. Microsoft y existe et s’en trouve être un des leader derrière Amazon. Oracle n’existe pas sur ce marché. Les enquêtes du Gartner Group (Magic Quadrant pour le cloud) le montre bien…

Gartner Magic Quadrant 2014 for Cloud Infrastructure as a Service

Gartner Magic Quadrant 2015 for Cloud Infrastructure as a Service

2 – Des pratiques scandaleuses
Dans l’article de Business Insider une pratique s’apparente à du chantage. Oracle consent à réduire l’addition, si le client passe dans le cloud. Or nous venons de le voir, les clients sont loin de se précipiter dans l’infonuagique à la sauce Oracle, lui préférant de loin Amazon lorsqu’ils restent Oracleur ou Azure lorsqu’ils passent à SQL Server.
Un autre article (« Comment se déroule un audit logiciel avec Oracle… » du Monde Informatique) montrent à quel point les pratiques d’Oracle sont scandaleuses et frisent le hors la Loi… « Oracle réclame des informations qu’elle n’est pas supposée demander contractuellement sur les serveurs sur lesquels ne tournent pas de logiciel Oracle et sur le personnel de Mars qui n’utilise pas les logiciels d’Oracle« . Imaginez quelles sont les implications d’une telle intrusion dans vos serveurs ou auprès de vos employés !
D’où les conseils distillés par certains juriste et économistes, d’intégrer les risques de coûts associés aux audits d’Oracle comme charges supplémentaire aux offres commerciales, ce qui a pour effet de gonfler la note finale d’acquisition des licences Oracle !

3 – les options payantes
Je me suis livré à une comparaisons des options payantes dans oracle et gratuites dans SQL Server. Microsoft n’offre d’ailleurs pas d’options payantes, mais les fonctionnalités dépendant des versions (comme dans Oracle d’ailleurs). De plus, il existe de nombreux outils complémentaires gratuits pour SQL Server disponible sur le site web communautaire codeplex.
Voici un tableau résumant la chose :

Comparaison des fonctionnalités Oracle (payantes) et SQL Server (gratuites)

4 – Le prix…
De la même manière, j’ai étudié le montant comparatif des licences à payer pour l’équivalence d’Oracle avec SQL Server, basé sur la version Enterprise. Le résultat est édifiant…
Prix des options Oracle (21 juin 2016) « Processor Licence » :

Active Data Guard 11 500 $
Database In-Memory 23 000 $
Diagnostics Pack 7 500 $
Tuning Pack 5 000 $
Partitionning 11 500 $
Advanced compression 11 500 $
OLAP 23 000 $
Advanced Analytics 23 000 $
Spatial 17 500 $
Multitenant 17 500 $
TOTAL : 139 500 $

Prix des licences Oracle édition Enterprise : 47 500 $
Le prix des licences Oracle s’établie pour 2 processeurs. Par exemple sur une machine quadriprocesseur ayant des CPU comportant 12 coeurs, le facteur de licence est donc de 24 (4 x 12 / 2).

Prix des licences SQL Server édition Enterprise : 27 496 $
Le prix des licences SQL Server s’établie pour 4 processeurs. Par exemple sur une machine quadriprocesseur ayant des CPU comportant 12 coeurs, le facteur de licence est donc de 12 (4 x 12 / 4).

Comparaison basé sur le prix au processeur : (47 500 / 2) / (27 496 / 4) = 4
Oracle, sans aucune option payante, est donc naturellement 4 fois plus cher que SQL Server

Avec notre machine exemple (quadriprocesseur ayant des CPU comportant 12 coeurs) et toutes les options, nous arrivons à la différence suivante :
Oracle : 24 x ( 47 500 + 139 500 ) = 4 488 000 $
SQL Server : 12 x 27 496 = 329 952 $
À ce stade, Oracle est 13,6 fois plus cher…

Mais vous pouvez négocier !

les remises maximales chez Oracle vont jusqu’à 70%, vous passez donc à : 1 346 400 $
les remises maximales chez Microsoft vont jusqu’à 40%, vous passez donc à : 197 971 $

De plus si vous avez misé sur des serveur dotés de processeurs OPTERON d’AMD, alors Microsoft accorde un facteur de réfaction supplémentaire de 25%. La note passe donc à 148 478 $
Après négociation et utilisation de processeurs Opteron d’AMD, au final, Oracle s’avère 9 fois plus cher…

En conclusion

Comme je le mentionnait dans un article précédent « le déclin d’Oracle » la firme de Redwood Shores est en sérieuse perte de vitesse. Elle n’est même plus le champion de l’avancée technologique. Par exemple elle s’est faite grillée sur le « In Memory » par SAP avec HanaDB, puis par SQL Server…
Sur les performances la plupart des benchmarks effectués par les utilisateurs montre quelle est plus gourmande à performances équivalente que la plupart de ses challengers ou si l’on prend l’autre bout de la lorgnette, qu’elle est moins performantes sur une même machine. Mais Oracle interdisant de publier le moindre benchmark concernant le produit, vous ne trouverez pas d’étude sérieuses sur le sujet. Reste les benchmarks officiels du TPC, mais là c’est une autre histoire… Oracle ne publie que les résultats du TCP-C datant de 1992 donc sur une base de données datée de 23 ans comportant en tout et pour tout 8 tables et des jointures limitées à 2 tables sans aucune sous requête ! Et même dans ce cas, SQL AnyWhere de SAP (anciennement Syabse) la bât sur le coût…
En revanche SQL Server se sert du TPC-E plus récent (2007) et plus réaliste, comportant 33 tables des jointures avec 7 tables et de multiples sous requêtes. Et là curieusement, Oracle n’y a jamais présenté un seul résultat de benchmark !
Et ce déclin est bien constaté par d’inexorables chiffres. Par exemple celui comparant, pour un organisme de formation bien connu pour son indépendance, le nombre de stagiaires formés sur chacune des deux plateformes…

Formation professionnelle – évolution 2005-2015 Oracle vs SQL Server

Pas la peine de vous faire un dessin !

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 !

***

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

Le coût d’exploitation d’un SGBDR.. Oracle vs Microsoft SQL Server

SQLpro — Sat, 09 Mar 2013 10:03:40 +0000

La sté Alinean a effectuée une étude comparant le coût d’exploitation des serveurs de bases de données Oracle et Microsoft SQL Server.
Le résultat est sans appel… Avec ses licences aux tarifs exorbitant et du fait de sa complexité d’administration, Oracle est 4,6 fois plus cher à solutions comparables.

Les gains de productivité sont aussi énormes. Ainsi l’étude montre qu’un DBA SQL Server peut administrer en moyenne 214 bases tandis que son confrère en Oraclien n’en administre que 31 (à volumétrie égale sur le plan transactionnel comme sur le plan données)
Le temps de déploiement d’une base de données a aussi été mesuré. Avec Oracle on est en moyenne à 357 minutes par base. Avec SQL Server à 88. Soit 4 fois plus rapide…
Les temps passés sont aussi très intéressants : un DBA Oracle passe presque deux fois plus de temps en résolution des problèmes et en tuning que son confrère sur SQL Server. De même les temps des tâches de sécurité et de sauvegarde sont de plus d’un tiers plus longues à effectuer sous Oracle que sous MS SQL Server…

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