Choix d'un SGBDR.

[ortolojf]

Tout est dans le titre.

Jusqu'à présent pour mon site j'utilisais MariaDB comme SGBDR.

J'ai une bdd allant de 2010 jusqu'à hier.

J'envisage de la dégraisser 2015 -2025.

J'ai un besoin de requêtes MySQL sur trois colonnes indexées.

J'ai entendu dire que PostgreSQL gère bien les index.

Je suis sur Debian 12.

Quel SGBDR choisir ?

Merci beaucoup.

 

[pomination]

Bonjour,

Qu'est-ce qui motive le changement au juste ?

 

[ortolojf]

Bonjour pomination

Jusqu'à présent je n'utilisais que des requêtes MySQL d'après des critère de sélection sur 2 colonnes ( avec index multiple sur les deux ).

J'ai l'intention de tenir compte aussi des performances des jockeys.

La requête suivante : "SELECT AVG(RANG) FROM COURSES WHERE ID<$ID_MIN AND NUMJO IN ( $NUMJO1, $NUMJO2, etc... ) GROUP BY NUMJO;"

me prend plus de 400ms et encore sur mon ordinateur.

Cependant les colonnes ID, NUMJO et RANG sont indexées par :

CREATE INDEX IX_ID_NUMHO_RANG _COURSES ON COURSES(ID, NUMJO, RANG);

avec ID = BIGINT, NUMJO=INTEGER et RANG=INTEGER.

J'ai essayé deux autres requêtes MySQL Mais c'était encore pire, car il y avait les critères :

ID>$ID_MIN , RANG<6 et NUMJO IN ( etc...)

Est-ce un problème d'indexation, ou de SGBDR ?

Merci beaucoup d ton aide.

 

[spout]

Tu as tenté d'analyser avec des scripts genre :
https://github.com/major/MySQLTuner-perl
https://github.com/BMDan/tuning-primer.sh

Tu peux faire un EXPLAIN devant tes requêtes pour analyser ce qu'il se passe : https://dev.mysql.com/blog-archive/mysql-explain-analyze/

 

[colonies]

La requête suivante : "SELECT AVG(RANG) FROM COURSES WHERE ID<$ID_MIN AND NUMJO IN ( $NUMJO1, $NUMJO2, etc... ) GROUP BY NUMJO;"
me prend plus de 400ms et encore sur mon ordinateur.
(...)
Cependant les colonnes ID, NUMJO et RANG sont indexées par :
CREATE INDEX IX_ID_NUMHO_RANG _COURSES ON COURSES(ID, NUMJO, RANG);
(...)
Est-ce un problème d'indexation, ou de SGBDR ?

C'est au moins un problème d'indexation. La clé que tu as créée ne sert à rien. Une clé composite ne sert que dans l'ordre des colonnes indiqué lors de sa création.
Ta clé permet donc d'accéder rapidement à des lignes en les filtrant : par id, puis par numjo, puis par rang.
Par rang, ça ne sert dans ton exemple puisque c'est ce que tu récupères.
Ensuite il commence par les id, et il est vrai que tu as des id, mais est-ce que c'est vraiment ça qui compte dans ta requête ? Non, ton facteur principal de sélection, c'est numjo. On peut croire que plus on met de colonnes dans l'index et mieux c'est, mais ça n'est vrai que pour des choses assez directes, qui permettent d'avoir des ensembles assez significatifs et comme l'id est (normalement) unique, ça produit plein d'"ensembles" sans intérêt.

Bref, ne met qu'un index sur numjo, ça devrait améliorer nettement tes perfs (vérifie quels indexes sont utilisés avec EXPLAIN comme l'indique spout)

Et si ça n'est pas le cas, alors il faut effectivement voir s'il y a assez de mémoire pour les indexes, les jointures etc donc comme l'indique aussi spout : MySQLTuner

 

[ortolojf]

Bonjour colonies et Spout

Effectivement l'index utilisé d'après EXPLAIN n'est pas IX_ID_NUMJO_RANG, mais IX_NUMJO.

Pour forcer l'utilisation de IX_D_NUMJO_RANG, j'ai dropé l'index IX_NUMJO.

Maintenant la requête met 100 ms à s'exécuter ( au lieu de 4 secondes avant ).

L'index utilisé est IX_ID_NUMJO_RANG.

C'est la solution.

Merci beaucoup à Spout, pomination et colonies.

Maintenant je vais voir si d'autres requêtes légèrement plus complexes pourraient me donner un marqueur plus fiable que l'avg
sur la performance des jockeys.

Amicalement.