Le blog de SQLpro » Langage SQL (norme)

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

Une peste nommée NOLOCK… et comment l’éviter

SQLpro — Sun, 08 Jul 2018 14:55:07 +0000

L’utilisation du tag de table NOLOCK, hélas largement prisé par de nombreux développeurs, est, la plupart du temps, une absurdité conduisant à des résultats potentiellement faux. Est-il possible de faire autrement pour minimiser les blocages induit par les verrouillages dans SQL Server ? Réponse OUI !

À la suite de cette remarque :
« …je passe aussi sur le NOLOCK qui est une véritable connerie en production et donne des valeurs fausses ! »
Publiée ici :

Mon interlocuteur me répondais :
« Merci pour cette précision. Comme vous abordez le sujet du NOLOCK effectivement j’ai constaté certaines fois en production on avait des valeurs totalement erronées, mais je n’arrivais pas à me l’expliquer. J’ai maintenant une piste et je vais creuser du côté du NOLOCK que nous utilisons beaucoup en production sur une base de données CRM 2013. Aussi par quoi pouvons nous remplacer le NOLOCK ?? »

Je lui donnais donc l’explication suivante…

Le « NOLOCK » peut parfaitement se remplacer par le niveau d’isolation SNAPSHOT par exemple…

NOLOCK ne signifie pas « je ne pose pas de verrou« , mais plus précisément : « j’ignore qu’il y a des verrous et je lit ce que je peut » (ceci est plus connu dans la littérature professionnelle sous le nom de lecture dans le chaos…). Vous pouvez donc lire plusieurs fois les mêmes données ou encore ne pas lire certaines.

Quid du mode SNAPSHOT ?

SNAPSHOT fait du verrouillage optimiste pour les lectures. Par défaut SQL Server fait du verrouillage pessimiste, c’est à dire que les lectures posent des verrous qui permettent d’autres lectures concurrentes (verrous partagés, mode « SHARE »), mais empêchent les écritures des autres utilisateurs. Conceptuellement, le verrouillage optimiste (donc via le mode d’isolation SNAPSHOT) fait une copie (si besoin) des données avant de permettre leurs lectures. Comme vous travaillez sur une copie, les utilisateurs concurrent peuvent modifier les vraies ligne sans que cela vous concerne. Bien entendu il peut toujours y avoir des conflits, mais cela réduit considérablement le nombre de verrous bloquants tout en gardant l’intégrité et la consistante de la base, ce qui n’est pas du tout le cas du NOLOCK.

Alors, à quoi sert le NOLOCK ?

Cela peut servir pour certains cas ou l’on désire des résultats dont on se fout de l’intégrité ou de la précision. Souvent dans le domaine de la statistique.
par exemple si vous voulez savoir combien les français ont d’enfant par foyer et scrutez donc, pour ce faire, une table de 60 millions de lignes (population française), je ne suis pas sûr que dans un camembert représentant la chose, on fasse la distinction des quelques pixels de l’imprécision de la 6e décimale du résultat liées à quelques mauvaises lectures de lignes !
On utilise d’ailleurs très souvent le NOLOCK pour des tâches d’administration systèmes dans SQL Server afin d’éviter tout blocage au risque de perdre quelques lignes, ce qui n’a pas toujours une importance capitale lorsque l’on veut remonter quelques informations concernant les 20% de requêtes les moins performantes !

Mais alors, le SNAPSHOT fait la même chose en mieux ?

Oui et non… Certes il permet de garantir l’intégrité, la consistance, etc… mais son mécanisme est plus lourd (un peu moins rapide) et consomme des ressources pour générer les copies (SNAPSHOT). Rassurez-vous il est assez malin pour ne faire ces copies qui s’il a besoin de les faire… En d’autres termes si aucun utilisateur concurrent veut faire des modif sur le jeu de lignes que vous manipulez en mode SNAPSHOT, aucune copie ne sera générée. Mais si, lorsque vous avez démarré une lecture en mode SNAPSHOT, un utilisateur concurrent veut modifier des lignes, et bien la copie sera réalisée au cours de votre lecture sans que vous vous en aperceviez… En quelque sorte le système fonctionne à l’envers… Bien évidemment il faut un espace de stockage pour ces copies et c’est la base tempdb qui s’y colle. Il faut donc, la dimensionner correctement…
Tiens, à nouveau un travail de DBA !

Des conflits ! Quels conflits ?

J’ai précédemment parlé de conflits possible avec l’utilisation du mode SNAPSHOT. En effet, si vous voulez modifier des données lors d’une transaction en mode d’isolation SNAPSHOT, c’est possible, mais ces modifications seront faites sur la copie, et non sur la base originale, et seront reportées sur la base originale au moment du COMMIT. Deux hypothèses se font alors jour :
■ soit aucune ligne visée par vos modifications faites en mode SNAPSHOT n’a été modifié dans une autre session directement sur la base, alors la mise à jour est appliquée.
Ou alors :
■ s’il existe au moins une ligne qui a été modifiée par une autre session entre temps sur la base originale, alors vos modifications ne pourront être appliquées aux données originales et vont êtres abandonnées.
Dans ce dernier cas vous obtiendrez une message d’erreur (3960) assez abscons, qui indique :
« La transaction d’isolement d’instantané a été abandonnée en raison d’un conflit de mise à jour. … »

Notez qu’il existe un autre tag plus intéressant que le NOLOCK…. Le READPAST !… Qui fait presque la même chose, mais ignore tout ce qui est verrouillé !

Les modes d’isolation selon la norme SQL

Sachez que le mode d’isolation SNAPSHOT ne fait pas partie de la norme SQL qui n’autorise que les modes d’isolation suivants :
0 – READ UNCOMMITTED : lecture des données invalides (non « committées »)
1 – READ COMMITTED : lecture de données valides (ce qui n’empêche pas certaines anomalies transactionnelles comme la lecture non répétable, ou l’apparition de lignes fantômes)
2 – REPEATABLE READ : lecture répétable de données (ce qui n’empêche pas certaines anomalies transactionnelles comme l’apparition de lignes fantômes)
3 – SERIALIZABLE : lecture en mode série (aucun accès concurrent aux tables lors des mises à jour, ce qui empêche toute anomalies)
Évidemment plus on monte le niveau d’isolation, plus le verrouillage est important et moins les accès concurrents peuvent travailler.
La norme SQL considère que les manipulation des données doivent porter sur des valeurs « vivantes ». Hors, en utilisant le mode SNAPSHOT et son versionnement des lignes, ont est appelé à lire potentiellement des valeurs antérieurs des données, ce n’est donc pas une lecture de l’état actuel des valeurs dans la base…

Pour informations, des SGBRD comme Oracle, ou PostGreSQL fonctionnent nativement en mode d’isolation SNAPSHOT, autrement dit utilisent systématiquement le verrouillage optimiste et ne savent pas faire autres choses (verrouillage pessimiste en particulier) voir ne savent même pas utiliser certains autres niveau d’isolation. Par exemple PostGreSQL ne permet pas de faires des transaction en mode READ UNCOMMITTED et Oracle ne permettent pas d’utiliser le niveau d’isolation REPEATABLE READ…

Activer le mode s’isolation SNAPSHOT

Pour permettre ce mode d’isolation, vous devez d’abord autoriser la base à utiliser le mode SNAPSHOT. Ce paramétrage est à deux niveaux :

ALTER DATABASE { CURRENT | nom_base } SET ALLOW_SNAPSHOT_ISOLATION ON;

permet d’utiliser à tout moment le mode d’isolation SNAPSHOT qui doit être introduit préalablement par la commande SET TRANSACTION ISOLATION SNAPSHOT ou par un tag de table (SNAPSHOT)
… et :

ALTER DATABASE { CURRENT | nom_base } SET READ_COMMITTED_SNAPSHOT ON;

qui place d’office toutes les lectures en mode SNAPSHOT (comme le fait Oracle ou PostGreSQL);
ATTENTION : pour assurer le versionnement des lignes, SQL Server rajoute à toutes les lignes de toutes les tables une information de version qui est codé sur 14 octets. Ceci peut prendre du temps à mettre en œuvre, en particulier sur de grosses bases.

Appendice :

Pour une démonstration des effets du NOLOCK : http://mssqlserver.fr/les-dangers-du-nolock/

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

Comparer deux requêtes aux résultats identiques

SQLpro — Mon, 28 May 2018 07:25:44 +0000

Comment savoir si deux requêtes donnent le même résultat ?

Il suffit d’une simple équation ensembliste pour ce faire. Sachant que la requête 1 donne comme résultat l’ensemble A et que la requête 2 donne comme résultat l’ensemble B, prouver que ces deux requêtes donnent le même résultat, nécessite d’appliquer l’équation :

A – B U B – A = Ø

Autrement dit que l’union de la soustraction des éléments de B à l’ensemble A et de la soustraction des éléments de A à l’ensemble B ne donne aucun résultat (ensemble vide).

Ceci s’exprime en SQL de la sorte :

WITH
TA AS (SELECT ....), -- requête 1
TB AS (SELECT ....) -- requête 2
SELECT * FROM TA
EXCEPT
SELECT * FROM TB
UNION ALL
SELECT * FROM TB
EXCEPT
SELECT * FROM TA;

Ne donne aucun résultat… CQFD

PS : pour oracle utilisez MINUS au lieu de EXCEPT….

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

SQL Server 2017 comparatif performances Linux vs Windows

SQLpro — Tue, 27 Mar 2018 09:38:20 +0000

Le but de cet article est de comparer les performances de Microsoft SQL Server 2017 sous Linux par rapport à Windows. Il a été élaboré sur des machines physiques strictement identiques pour ôter tout biais lié a l’utilisation de machines virtuelles.

Vous trouverez les détails de cet article dans le fichier pdf suivant :
sqlpro.developpez.com/article/sql_server_2017_linux_vs_windows/Benchmark_SQL_Server_2017_Linux_vs_Windows.pdf

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

BENCHMARK SIG : PostGreSQL vs MS SQL Server

SQLpro — Mon, 01 May 2017 14:54:34 +0000

La présent article compare les performances de requêtes basiques du système d’information géographique de PostGreSQL (v 9.6.1) et de SQL Server (version 2016).

Comparaison des performances de SIG
PostGreSQL/PostGIS vs SQL Server Spatial

Les tables temporelles avec SQL Server (présentation)

SQLpro — Wed, 25 Jan 2017 14:00:36 +0000

Arrivée avec la norme SQL 2011, le concept de tables temporelles permet une historisation automatique des données et propose des opérateurs temporels pour « voir » vos données telles qu’elles étaient à un point ou une période du temps passé. Paradoxe : plus besoin de faire des sauvegardes ! Cette présentation montré au Microsoft Cloud Summit 2017 à paris le 24 janvier 2017, vous montre l’essentiel sur le sujet, avec SQL Server 2016 et est assortie de nombreux exemples.

La présentation PowerPoint sous forme PDF est téléchargeable ici : SQL Server et les tables temporelles

Les exemples l’accompagnant, sont téléchargeable ici :

DEMO 001 – table temporelles sans historique (fichier SQL)
DEMO 002 – table temporelles avec historique (fichier SQL)
DEMO 003 – stockage (fichier SQL)
DEMO 004 – Récupération (fichier SQL)
DEMO 005 – Purge (fichier SQL)
DEMO 005b – Purge métadonnées blocage (fichier SQL)
DEMO 006 – interrogation (fichier SQL)
DEMO 007 – In Memory (fichier SQL)
DEMO ANNEXE temporal tables (fichier SQL)

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES
Expert S.G.B.D relationnelles et langage S.Q.L
Most 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

Développez et administrez pour la performance avec SQL Server 2014

LIKE ‘%mot%’ ou les index rotatifs….

SQLpro — Thu, 05 Jan 2017 20:01:44 +0000

Qui n’a jamais rêvé d’obtenir des performances pour rechercher des mots partiels contenus dans d’autres mots, comme par exemple tous les mots contenant « bolo » ? Dans un dictionnaire de 128 918 mots, une telle recherche met moins de 50 millisecondes à l’aide des index rotatifs, contre ??? pour le LIKE ‘%bolo%’… Explications…

diabolos, hyperboloïde, bolonaise, bolomètre, diabolo, bolométriques, amphibologie, bolonais, paraboloïde, amphibologique, bolométrique… Tels sont les mots du dictionnaire LEXIQUE du CNRS contenant la chaine de caractères « boblo ».

LE PROBLÈME

Les index des bases de données relationnelles, de type BTree (arbre équilibrés) trient les chaines de caractères par rapport à l’ordre orthographique des chaines de caractères au regard du classement des lettres de l’alphabet et de la collation choisie, cette dernière pouvant être sensible ou non, à la casse, aux accents…. Du fait de cet ordre, il est donc possible de rechercher par intervalle comme c’est le cas de la recherche d’un mot commençant par… En effet, si nous recherchons les mots commençant par « fass » ils sont regroupés les uns à la suite des autres dans l’index, ce qui permet un accès immédiat et la solution est, par exemple la suivante :

fasse

fassent

fasses

fassiez

fassions

Pour ce qui est des mots finissant par, l’index ne nous est d’aucune utilité, mais une astuce consiste à créer les mots inversés (par exemple à l’aide d’une colonne calculée), les indexer et rechercher par le même type de LIKE sur l’inverse de la terminaison souhaitée. Par exemple, rechercher tous les mots se terminant par « aide’, il suffit de faire la recherche suivante :

LIKE 'edia%'

et de renvoyer le mot correspondant !
Bien entendu pour rechercher un mot commençant par… et finissant par…, il suffit de combiner les deux recherches !
Un exemple est apporté par l’extrait de requête suivant :

WHERE MOT_MOT LIKE 'enta%' AND MOT_INVERSE LIKE CONCAT(REVERSE('aient'), '%')

Mais comment être efficace lorsque l’on recherche une chaine à l’intérieur d’un mot ? C’est là qu’intervient la notion d’index « rotatif »…

LE CONCEPT

Un index « rotatif » est en fait une liste de mots pour laquelle on supprime successivement la lettre du début à chaque tour, d’où le nom d’index « rotatif ».
Par exemple le mot « locomotive » sera ainsi décliné :

locomotive

ocomotive

comotive

omotive

motive

otive

tive

ive

On numérote alors chaque rotation, y compris le mot racine dont par convention on attribuera l’indice 0 comme niveau de rotation. Par exemple le « sous-mot » « motive » aura un indice de rotation de 4 parce qu’on lui aura retiré les 4 premières lettres.
Une fois ces mots Ajoutés dans une table de mots, il suffit de les indexer et d’ajouter une table des références croisées entre les mots racine et les rotations. La recherche peut désormais se faire via un LIKE ‘mot%’ qui permet d’exploiter l’index ! Mais il faut ensuite remonter au mot racine par une jointure à l’aide de la table des références croisées.

LA MÉCANIQUE

Afin de bien distinguer ces objets techniques de votre base, objets qui n’ont rien à voir avec les objets fonctionnels de votre application, je vous conseille de créer un schéma SQL spécifique pour les y stocker logiquement

CREATE SCHEMA S_XRT;

Les tables pour ce faire.

Deux tables suffisent : la table des mots, et la table des références croisées.

CREATE TABLE S_XRT.T_MOT
(MOT_ID INT IDENTITY PRIMARY KEY,
--> doit être sensible aux accents mais pas à la casse ! Exemple maïs et
-- mais, sur et sûr, retraite et retraité, congres et congrès !
MOT_MOT VARCHAR(32) COLLATE French_BIN NOT NULL UNIQUE);

CREATE TABLE S_XRT.T_MOT_ROTATION_MRT
(MRT_ID INT IDENTITY PRIMARY KEY,
-- pointe vers la rotation du mot
MOT_ID INT NOT NULL REFERENCES S_XRT.T_MOT (MOT_ID),
-- pointe vers la racine du mot
MOT_ID_RACINE INT NOT NULL REFERENCES S_XRT.T_MOT (MOT_ID),
-- indice de rotation
MRT_ROTATION TINYINT NOT NULL,
UNIQUE (MOT_ID, MOT_ID_RACINE, MRT_ROTATION));

Les routines

Une procédure va permettre d’indexer un mot. En voici le code en Transact SQL :

CREATE PROCEDURE S_XRT.P_INDEXATION_ROTATIVE @MOT VARCHAR(32)
AS

SET NOCOUNT ON;

SET @MOT = LOWER(LTRIM(RTRIM(@MOT)));

DECLARE @L TINYINT = LEN(@MOT), @ID_MOT INT;

DECLARE @ROTATIONS TABLE
(MOT VARCHAR(32) COLLATE French_BIN,
ROT TINYINT);

-- calcul des rotations, racine comprise (0)
WITH T AS
(SELECT @MOT AS M, 0 AS I
UNION ALL
SELECT RIGHT(M, @L-I - 1), I + 1
FROM T
WHERE I < @L - 1
)
INSERT INTO @ROTATIONS
SELECT * FROM T;

-- insertions des mots manquants
INSERT INTO S_XRT.T_MOT
SELECT MOT
FROM @ROTATIONS
WHERE MOT NOT IN (SELECT MOT_MOT
FROM S_XRT.T_MOT);

-- récupération de l'ID du mot racine
SELECT @ID_MOT = MOT_ID
FROM S_XRT.T_MOT
WHERE MOT_MOT = @MOT;

-- insertions des rotations manquantes
INSERT INTO S_XRT.T_MOT_ROTATION_MRT
SELECT M.MOT_ID, @ID_MOT, R.ROT
FROM @ROTATIONS AS R
JOIN S_XRT.T_MOT AS M
ON R.MOT = M.MOT_MOT
WHERE NOT EXISTS(SELECT *
FROM S_XRT.T_MOT_ROTATION_MRT AS MR
WHERE MR.MOT_ID = M.MOT_ID
AND MR.MOT_ID_RACINE = @ID_MOT
AND MR.MRT_ROTATION = R.ROT);

Enfin, une fonction table constituée d’une simple requête paramétrée, va permettre de retrouver les mots racine à partir des partiels :

CREATE FUNCTION S_XRT.F_SUPER_LIKE (@MOT VARCHAR(32))
RETURNS TABLE
AS
RETURN (SELECT MR.MOT_ID, MR.MOT_MOT
FROM S_XRT.T_MOT AS M
JOIN [S_XRT].[T_MOT_ROTATION_MRT] AS R
ON M.MOT_ID = R.MOT_ID
JOIN S_XRT.T_MOT AS MR
ON R.MOT_ID_RACINE = MR.MOT_ID
WHERE M.MOT_MOT LIKE LOWER(RTRIM(LTRIM(@MOT))) + '%');

QUELQUES TESTS

Nous sommes partis d’une base contenant le dictionnaire LEXIQUE du CNRS, comportant 128 918 mots.
Notre méthode pour les indexer tous a été d’utiliser un curseur pour connaitre le temps moyen mis par la procédure d’indexation. Ce traitement a été effectué sur une machine ayant les caractéristiques suivantes : 2 processeurs XEON, 48 cœurs , 128 Go de RAM, 8 disques SAS en RAID 10 avec SQL Server 2016.
Le temps de traitement a été de 26 minutes et 21 secondes, soit, pour 128 918 mots, 12 ms par mot.
Le traitement a généré :
* 376 567 entrées de mots dans la table S_XRT.T_MOT (représentant 24 Mo)
* 1 168 547 lignes dans la table S_XRT.T_MOT_ROTATION_MRT (représentant 62 Mo)
À noter qu’après réindexation, on observe une diminution du volume des données : 22 et 57 Ko respectivement.

Voici le batch que nous avons utilisé (la table du dictionnaire LEXIQUE du CNRS est dbo.TS_MOT_MOT :

DECLARE @T DATETIME = GETDATE();

DECLARE C CURSOR
LOCAL FORWARD_ONLY STATIC READ_ONLY
FOR
SELECT MOT_MOT
FROM dbo.TS_MOT_MOT
WHERE MOT_LONGUEUR > 1;

DECLARE @MOT VARCHAR(32);

OPEN C;

FETCH C INTO @MOT;

WHILE @@FETCH_STATUS = 0
BEGIN

EXEC S_XRT.P_INDEXATION_ROTATIVE @MOT;
FETCH C INTO @MOT;

END;

CLOSE C;

DEALLOCATE C;

SELECT DATEDIFF(ms, @T, GETDATE());

L’utilisation de la fonction table en ligne S_XRT.F_SUPER_LIKE, met en moyenne 50 ms quelques soit la racine cherchée si elle est constituée d’au moins 3 caractères. Exemple :

SELECT * FROM S_XRT.F_SUPER_LIKE('moti');

Pour la pire des recherches, le système met moins d’une seconde à trouver les 130 162 mots contenant la lettre e !

Pour comparaison, la recherche des mots comprenant les caractères « eta », d’une part directement dans le dictionnaire à l’aide d’un LIKE ‘%eta%’ et d’autres part dans l’index rotatif donne les métriques suivantes :
* Dictionnaire, LIKE’%eta%’ : temps UC = 652 ms, temps écoulé = 430 ms.
* Index rotatif, S_XRT.F_SUPER_LIKE (‘eta’) : Temps UC = 265 ms, temps écoulé = 50 ms.

Paradoxalement les plans de requête ne reflètent pas vraiment cette différence. les couts des plans apparaissent ainsi :
* Index rotatif, S_XRT.F_SUPER_LIKE (‘eta’) : 3,79 (soit 86 % de l’ensemble
* Dictionnaire, LIKE’%eta%’ : 0,61 (soit 14% de l’ensemble)

Plan de requête SQL Server utilisant une fonction table en ligne et l’index rotatif

Utilisation directe du LIKE ‘%toto%’

UN PEU D’ASTUCE

Au fur et à mesure de son utilisation, les index rotatifs grandissent de moins en moins, car ils contiennent déjà des rotations utilisables pour d’autres mots. On peut donc prévoir certaines manœuvres pour les rendre plus efficaces encore, comme le précalcul de certaines données, la compression des index ou encore l’utilisation de vues matérialisées (ou indexées sur SQL Server).

À titre d’exemple, nous avons obtenus la métrique suivante : temps UC = 63 ms, temps écoulé = 67 ms, à l’aide de l’une de ces techniques !

LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE
Le code SQL

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

Développez et administrez pour la performance avec SQL Server 2014

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

Lister les bases système de SQL Server

SQLpro — Fri, 27 Mar 2015 09:58:38 +0000

Voici une requête permettant de lister toutes ls bases systèmes de MS SQL Server.

SELECT name AS database_name, database_id,
CAST(CASE
WHEN name IN ('master','model','msdb','tempdb')
THEN 1
WHEN is_distributor = 1
THEN 1
ELSE 0
END AS bit) AS system_database
FROM sys.DATABASES;

Le livre sur Microsoft SQL Server 2014 : développez et administrez pour la performance – éditions Eyrolles

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

Calcules de durée en jour avec des mois comptables de 30 jours

SQLpro — Mon, 23 Mar 2015 22:55:56 +0000

À la suite d’une demande du forum, je me suis penché sur le calcul de durée en jour avec des mois comptables de 30 jours. Comme d’habitude il faut passer par une table de date !

La demande originale est postée ici :
www.developpez.net/forums/d1508019/bases-donnees/ms-sql-server/developpement/

Nous sommes partit de la table suivante :

CREATE TABLE T_DAT
(DAT_DATE DATE PRIMARY KEY,
DAT_AN AS CAST(YEAR(DAT_DATE) AS SMALLINT) PERSISTED,
DAT_MOIS AS CAST(MONTH(DAT_DATE) AS TINYINT) PERSISTED,
DAT_JOUR AS CAST(DAY(DAT_DATE) AS TINYINT) PERSISTED,
DAT_NB_JOUR_FIN_MOIS TINYINT ,
DAT_JOUR_FIN_MOIS TINYINT
);

Que nous avons rempli avec les 3 requêtes suivantes :

SET NOCOUNT ON;
DECLARE @D DATE
SET @D = '2000-01-01'
WHILE @D < '2100-12-31'
BEGIN
INSERT INTO T_DAT (DAT_DATE) VALUES (@D);
SET @D = DATEADD(DAY, 1, @D)
END;
GO

WITH T0 AS
(
SELECT DAT_DATE, ROW_NUMBER() OVER(PARTITION BY DAT_AN, DAT_MOIS ORDER BY DAT_JOUR DESC) - 1 AS NB_JOUR_FIN_MOIS
FROM T_DAT
)
UPDATE T
SET DAT_NB_JOUR_FIN_MOIS = NB_JOUR_FIN_MOIS
FROM T_DAT AS T
INNER JOIN T0
ON T.DAT_DATE = T0.DAT_DATE;
GO

UPDATE T
SET DAT_JOUR_FIN_MOIS = T2.DAT_JOUR
FROM T_DAT AS T
INNER JOIN T_DAT AS T2
ON T.DAT_AN = T2.DAT_AN
AND T.DAT_MOIS = T2.DAT_MOIS
AND T2.DAT_NB_JOUR_FIN_MOIS = 0
GO

Nous avons ensuite créé la fonction de calcul :

CREATE FUNCTION F_MOIS30 (@D1 DATE, @D2 DATE)
RETURNS INT
AS
BEGIN
DECLARE @AN INT, @MOIS INT, @JFM INT

SELECT @AN = DAT_AN, @MOIS = DAT_MOIS, @JFM = DAT_NB_JOUR_FIN_MOIS
FROM T_DAT
WHERE DAT_DATE = @D1;

SELECT @AN = DAT_AN - @AN, @MOIS = DAT_MOIS - @MOIS, @JFM = @JFM + DAT_JOUR
FROM T_DAT
WHERE DAT_DATE = @D2;

RETURN (@AN * 12 + @MOIS - 1) * 30 + @JFM
END;
GO

Il ne restait plus qu'à la tester :

SELECT dbo.F_MOIS30('2014-03-20', '2015-02-01')

Ce qui donne 312 résultat escompté !

CQFD

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