Les raisons à la lenteur d’un moteur de base de données relationnelle

Du fait de l’abandon des cursus spécifiques à la formation des administrateurs de bases de données depuis le milieu des années 2000, le niveau de connaissances du fonctionnement des moteurs s’est complètement effondré. Il n’y a aujourd’hui pas grand intérêt à suivre une formation où la part consacrée aux SGBDR atteint péniblement 30% du temps global de la formation.

Les raisons à la lenteur d'un moteur de base de données relationnelleLa majorité des « bons » DBA sont aujourd’hui aux portes de la retraite et l’économie française – elle n’est pas la seule – est face à un grand désastre que les entreprises tentent péniblement de compenser par la mise à disposition de ressources matérielles de plus en plus importantes pour faire face à l’explosion de la volumétrie. En vain. Le rêve prométhéen d’un monde sans limites n’est qu’un mythe appartenant à la réalité virtuelle. L’augmentation de la volumétrie se heurte désormais à la seule bonne volonté des administrateurs système qui ont désormais en charge l’exploitation de bases, dont le mode de fonctionnement leur échappe en grande partie.

Ressources consommées par un moteur de base de données relationnelle

Les moteurs de bases de données relationnelles consomment, à titre principal, du disque et de la RAM. Les données lues sur disques sont mises en cache de manière à y accéder rapidement lors de requêtes suivantes. Tous les dispositifs logiciels qui consomment inutilement de la RAM – et donc du cache – ou bien ralentissent l’accès aux disque pénalisent lourdement le fonctionnement des bases de données relationnelles.

L’activité résidente

Un moteur de base de données relationnelle ne peut exprimer toute sa puissance sur un système d’exploitation à la condition qu’il lui soit dédié ! Scott McNealy, l’ancien PDG du Sun Microsystems depuis racheté par Oracle, nous expliquait en son temps qu’un système d’exploitation exécutant Oracle Database s’appelait Oracle. Il avait, de fait, totalement raison.

Sur les systèmes Windows, vous disposez du logiciel Autoruns, afin de désactiver les résidents qui seraient totalement inutiles. Sur Linux, j’utilise pour ma part ntsysv en environnement Red Hat/CentOS/Fedora, devenu parfaitement compatible avec systemd.

Dans le genre des pratiques imbéciles, il y a celle sous Windows, qui consiste à se connecter en RDP pour exécuter les outils d’administration graphiques des éditeurs (SSMS, PgAdmin, HeidiSQL, MySQL WorkBench, SQL Developer, etc).

L’antivirus

Si vous êtes contraint-e à maintenir un antivirus sur la machine exécutant un logiciel de base de données relationnelle, la seule chose à faire, c’est d’ajouter des exceptions sur les process liés au fonctionnement du moteur et au niveau des répertoires des fichiers de données et de transactions utilisés par ledit moteur. Par l’analyse des contenus écrits et lus sur le disque, l’antivirus pénalise les IO et la vitesse d’accès aux données ! La seule raison objective qui pourrait vous obliger à laisser l’antivirus effectuer sa sale besogne, c’est lorsque vous envoyez des binaires ou du contenu Html/Javascript susceptibles d’être infectés dans les champs de votre base de données !

Impact de la virtualisation

J’avais, il y a quelques années, fait une formation sur l’état de l’art en matière de virtualisation pour un salarié de Thalès. Nous avions deux machines. L’une était équipée de Windows Server 2008 R2 et l’autre de Vmware Vsphere 5.1. Avec Novabench, nous avons réalisé toute une série de benchmarks. En terme d’écriture sur disque, le logiciel exécuté dans des machines virtuelles Vsphere, Vmware Player, VirtualBox indiquait une baisse de la performance de 45% par rapport à la machine physique. Il n’était plus que de 25% sous HyperV, qui utilise un mécanisme dit de paravirtualisation, à l’image de Xen ou KVM sous Linux. En matière de bases de données, il ne faut pas stocker les données à l’intérieur de vos fichiers VMDK ou VHD, dès lors que la taille des bases excède les 100 Go. Mieux vaut attaquer une LUN de votre baie SAN ou votre serveur NAS à l’aide d’un poitn de montage NFS ou d’un initiator ISCSI géré directement par le système d’exploitation !

SELECT : un peu de SQL !

Compte tenu du faible niveau de connaissances en SQL, une grande majorité de développeurs n’ont pas acquis les bonnes pratiques. En voici quelques unes :

MySQL  / MariaDB : préférez InnoDB à MyISAM / Aria

Il n’y a aucun intérêt à choisir MyISAM ou Aria si vous faites des jointures au niveau de vos requêtes sous MySQL / MariaDB. Le temps d’exécution d’une requête sous MyISAM est 66% plus lent si vous utilisez l’opérateur INNER JOIN. En mono-table, MyISAM pulvérise très largement InnoDB.

 

 

 

Base de données  / Formateur Base de données Formateur SQL Moteur de base de données relationnelle Rdbms Sgbdr SQL 

Commentaires

Bonjour

Bon article mais pourquoi donc est-ce une pratique imbécile que de se connecter en RDP pour exécuter les outils d’administration graphiques ?

Cordialement

S’il s’agit de SSMS, il suffit de regarder la consommation mémoire et CPU au lancement du logiciel, alors qu’il suffit de l’exécuter à partir d’une station de travail. C’est donc totalement imbécile de l’exécuter sur le serveur.

Ok, merci d’avoir clarifié.

C’est vrai que pour de grosses requêtes, le SELECT * FROM n’est vraiment pas une bonne idée, pourtant c’est du déjà vu …

Laisser un commentaire

(requis)

(requis)