Les tests ont été exécutés sur un serveur Linux Mageia 6 disposant de 4 Go et de MariaDB 10.1, s’exécutant dans VirtualBox 5.1.28 sous Windows Server 2016.
Oui, bon, c'est toujours un test. Mais enfin, en prod, on fait pas ça.
Tu commences par paramétrer les trois moteurs avec des valeurs arbitraires sans vérifier qu'ils ont les mêmes besoins.
Tu fais des requêtes sur des tables dont on ne sait rien (volumétrie, index…) sauf à aller fouiller un lien externe.
Tu ne t'intéresses absolument pas à ce qui fait que ces requêtes sont lentes (CPU ? Accès disque ?) – or c'est important pour pouvoir extrapoler les résultats à quoi que ce soit d'autre.
Surtout, tu en tires des conclusions sur les différences entre les noteur alors que le vrai choix d'un moteur se fait sur ses fonctionnalités d'abord et avant tout.
En résumé, tu testes un cas particulier et tu te permet d'en tirer des conclusions qui sont de la pure spéculation.
Enfin, ta dernière remarque me laisse penser que tu hébergeais du WordPress sur du MySQL avec autre chose que InnoDB comme moteur, mais tu ne dis pas lequel. Si c'était MyISAM, tu ne garantissais pas la cohérence des données.
Tout ça me fait penser que je ne suis pas certain de vouloir suivre tes formations sur le sujet.
Non, c'est le même moteur avec trois bases contenant les mêmes données. La seule différence est que MyISAM et Aria n'ont pas de FK. ;+)
J'ai déterminé deux requêtes. La requête mono-table tape dans une base de 130 Mo. J'ai donné le lien de la base.
Comme je l'ai indiqué dans le billet, j'ai regardé, comme ça au doigt mouillé, en prod si le résultat était conforme au test en mettant en oeuvre performance_schema et j'ai pu constater que InnoDB était plus rapide que Aria qui était la motorisation que j'avais choisie auparavant, du fait de l'utilisation massive des JOIN et des INNER JOIN dans le CMS. Cette information est un complément et n'est pas représentative du test qui lui a été sérieusement effectué, dans des conditions strictement identiques pour les trois motorisations.
Comme je l'ai indiqué par commentaire, j'aurais pu faire d'autres tests notamment avec des clauses WHERE portant sur les clés primaires.
NB Je fais de la base de données depuis 1988, date à laquelle j'ai suivi une formation DBA. Je travaille sur Oracle (depuis la version 6.0), PostgreSQL (depuis la version 7.3), MySQL (depuis la version 3.23), MariaDB (depuis la 5.5).
NB Je fais de la base de données depuis 1988, date à laquelle j'ai suivi une formation DBA. Je travaille sur Oracle (depuis la version 6.0), PostgreSQL (depuis la version 7.3), MySQL (depuis la version 3.23), MariaDB (depuis la 5.5).
Argument d’auto-autorité ?
Ton test est loin d’être complet (tu n’as pas prétendu qu’il l’était) mais comme tu dis, tu t’es intéressé aux valeurs relatives. Je ne vois pas de problème de méthode à ce niveau là. Par contre, ce qui explique la mauvaise note de ton billet de blog c’est, à mon avis, le fait de faire tourner une VM Maegia sous Windows :
1) Comme déjà dit, c’est une configuration qui ne correspond à rien qui ressemble à ce que l’on peut trouver dans une production informatique.
2) Pourquoi utiliser VirtualBox avec un hôte Windows pour faire tourner Maegia alors que tu pourrais utiliser du GNU/Linux et KVM ? (on est sur linuxfr.org ici ;)
J’en profite pour t’adresser mes sincères salutations car je t’ai eu comme prof et je garde un bon souvenir de ton enseignement. J’espère que tout roule pour toi.
Le fait que je ne sois pas en prod n'est pas un argument. Concernant Windows, tu dois te souvenir que je ne suis pas un ayatollah du libre. ;+)
J'ai, en effet, oublié de tester en MyISAM et en Aria des index sur les colonnes pivot des tables enfants. Un des commentateurs de mon blog me l'a fait remarqué. Je vais prendre le temps de refaire le test ce WE. Et je le rappelle, ce qui compte, ce sont les valeurs relatives. Ton objection en saurait être un argument. D'ailleurs, je ne vois pas en quoi ce serait un argument !
NB Sinon, tout va bien, à part une grippe et un manque de soleil en Normandie. Beaucoup de PostgreSQL, de MariaDB, de Linux, de GLPI et de sécurité informatique. Mais aussi beaucoup de PowerShell et de SQL Server.
# Pas vraiment représentatif
Posté par Glandos . Évalué à 6.
Oui, bon, c'est toujours un test. Mais enfin, en prod, on fait pas ça.
# Pas d'accord
Posté par Denis Szalkowski . Évalué à -5.
Ce qui est intéressant, ce sont les valeurs relatives.
NB En général, on évite de faire des tests pour pénaliser la prod. ;+)
# Pas représentatif du tout, en fait.
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 8.
Donc si je résume ta « procédure de test » :
En résumé, tu testes un cas particulier et tu te permet d'en tirer des conclusions qui sont de la pure spéculation.
Enfin, ta dernière remarque me laisse penser que tu hébergeais du WordPress sur du MySQL avec autre chose que InnoDB comme moteur, mais tu ne dis pas lequel. Si c'était MyISAM, tu ne garantissais pas la cohérence des données.
Tout ça me fait penser que je ne suis pas certain de vouloir suivre tes formations sur le sujet.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas représentatif du tout, en fait.
Posté par Denis Szalkowski . Évalué à -1.
Non, c'est le même moteur avec trois bases contenant les mêmes données. La seule différence est que MyISAM et Aria n'ont pas de FK. ;+)
J'ai déterminé deux requêtes. La requête mono-table tape dans une base de 130 Mo. J'ai donné le lien de la base.
Comme je l'ai indiqué dans le billet, j'ai regardé, comme ça au doigt mouillé, en prod si le résultat était conforme au test en mettant en oeuvre performance_schema et j'ai pu constater que InnoDB était plus rapide que Aria qui était la motorisation que j'avais choisie auparavant, du fait de l'utilisation massive des JOIN et des INNER JOIN dans le CMS. Cette information est un complément et n'est pas représentative du test qui lui a été sérieusement effectué, dans des conditions strictement identiques pour les trois motorisations.
Comme je l'ai indiqué par commentaire, j'aurais pu faire d'autres tests notamment avec des clauses WHERE portant sur les clés primaires.
NB Je fais de la base de données depuis 1988, date à laquelle j'ai suivi une formation DBA. Je travaille sur Oracle (depuis la version 6.0), PostgreSQL (depuis la version 7.3), MySQL (depuis la version 3.23), MariaDB (depuis la 5.5).
[^] # Re: Pas représentatif du tout, en fait.
Posté par Marotte ⛧ . Évalué à 5.
Argument d’auto-autorité ?
Ton test est loin d’être complet (tu n’as pas prétendu qu’il l’était) mais comme tu dis, tu t’es intéressé aux valeurs relatives. Je ne vois pas de problème de méthode à ce niveau là. Par contre, ce qui explique la mauvaise note de ton billet de blog c’est, à mon avis, le fait de faire tourner une VM Maegia sous Windows :
1) Comme déjà dit, c’est une configuration qui ne correspond à rien qui ressemble à ce que l’on peut trouver dans une production informatique.
2) Pourquoi utiliser VirtualBox avec un hôte Windows pour faire tourner Maegia alors que tu pourrais utiliser du GNU/Linux et KVM ? (on est sur linuxfr.org ici ;)
J’en profite pour t’adresser mes sincères salutations car je t’ai eu comme prof et je garde un bon souvenir de ton enseignement. J’espère que tout roule pour toi.
[^] # Re: Pas représentatif du tout, en fait.
Posté par Denis Szalkowski . Évalué à -2.
Le fait que je ne sois pas en prod n'est pas un argument. Concernant Windows, tu dois te souvenir que je ne suis pas un ayatollah du libre. ;+)
J'ai, en effet, oublié de tester en MyISAM et en Aria des index sur les colonnes pivot des tables enfants. Un des commentateurs de mon blog me l'a fait remarqué. Je vais prendre le temps de refaire le test ce WE. Et je le rappelle, ce qui compte, ce sont les valeurs relatives. Ton objection en saurait être un argument. D'ailleurs, je ne vois pas en quoi ce serait un argument !
NB Sinon, tout va bien, à part une grippe et un manque de soleil en Normandie. Beaucoup de PostgreSQL, de MariaDB, de Linux, de GLPI et de sécurité informatique. Mais aussi beaucoup de PowerShell et de SQL Server.
[^] # Re: Pas représentatif du tout, en fait.
Posté par Denis Szalkowski . Évalué à -2.
Excuse-moi pour le commentaire précédent. Je suis grippé et je manque quelque peu de "lucidité". En fait, tu allais dans mon sens.
J'ai regardé dans les bases et la table salaries de chaque base possède bien un index sur emp_no. Je confirme mes résultats.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.