Discussion :

[Oimbart]

Bonjour,

J'ai dernièrement eu besoin de migrer une base de données en MySQL vers un MySQL cluster. J'ai adapté mon schéma pour correspondre au spécificité et limite de l'engine NDBCLUSTER sans trop de problème. Par contre il réside un problème qui est de taille. Tous les indexs sont totalement innopérant. Pourtant, quand je fais "SHOW INDEX FROM nom_de_la_table;" je vois bien les index mais ne fonctionne pas.

Pour exemple sur une table on ne peut plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TABLE `nom_de_la_table` (
  `id` INTEGER UNSIGNED NOT NULL auto_increment,
  `code` VARCHAR(8),
  `libelle` VARCHAR(64),
  PRIMARY KEY (`id`)
)
ENGINE = NDBCLUSTER
CHARACTER SET utf8 COLLATE utf8_general_ci;

j'enregistre 1.10^6 enregistrement dans ma table pour faire un test d'écriture, puis je fais deux requêtes presque similaires pour avoir un résultat avec un écart de performance important.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT COUNT(id) FROM nom_de_la_table;

résultat assez rapide, inférieur à une seconde.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT COUNT(DISTINCT id) FROM nom_de_la_table;

résultat totalement lent, supérieur à vingt secondes.


Je commence à regarder ce qu'il ne va pas, en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXPLAIN SELECT COUNT(DISTINCT id) FROM nom_de_la_table;

Je vois que la requête n'utilise pas d'index.

Je test la même requête sur une table identique mis à part que ENGINE en INNODB et je vois avec EXPLAIN l'utilisation de ma clé primaire et un résultat sensiblement identique sans l'utilisation du DISTINCT dans mon COUNT.

quand je regarde de plus pret ma table de test sur le MYSQL en CLUSTER je vois bien ma PRIMARY KEY, mais "index length = 0" jusque la rien d'anormal par rapport a INNODB.
Je rajoute un champ INTEGER ou je place un index dessus et là en INNODB "index length > 0" si je fais un EXPLAIN sur ma requête en DISTINCT je vois bien l'utilisation de l'INDEX PRIMARY KEY. En NDBCLUSTER non rien, "index length = 0" et pas d'utilisation de la PRIMARY KEY.

Je fais un autre test sur requête avec une jointure entre deux tables en NDBCLUSTER liaison MANY_TO_ONE je vois bien l'utilisation d'INDEX entre les deux tables.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
EXPLAIN SELECT COUNT(DISTINCT ta.id)
FROM table_a ta, table_b tb
WHERE ta.id_table_b = tb.id

MAIS un SHOW INDEX FROM table_a ou SHOW INDEX FROM table_b le nombre de cardinality = 0 même si plusieurs occurrences différentes et les performance sur la requête une catastrophe.

En gros l'index non alimenté, mais uniquement en NDB car en INNODB aucun problème.

J'ai testé la commande OPTIMIZE sur les tables et tous que j'ai pu trouver sur le net pour corriger cela et rien ne marche.

J'ai revu les fichiers de configuration du cluster et rien ne cloche.

Mes questions sont :
- est ce que le NDBCLUSTER gère bien les INDEX?
- comment?
- y a t'il une manipulation (commande ou configuration) particulière pour vérifier sur le serveur?

Donc la pour le moment le MySQL en cluster et totalement inexploitable car les performances sont abominables sur des requêtes complexes.

90 secondes pour une requête au lieu de 0.03 en INNODB qui gére bien les index.


J'ai regardé tous ce que j'ai pu au niveau de la configuration, des ressources alloués, du réseau entre les différents éléments de mon cluster. Mais étant un peu novice dans l'utilisation d'un cluster j'ai certainement due passer à côté de quelque chose au niveau compréhension de ce système. Donc si quelqu'un pourrait m'éclairer sur le sujet ça m'aiderait grandement.

PS : je n'ai pas la main ces jours ci sur les serveurs pour vous donner la conf exacte dès que possible je vous envois cela si besoin

[Sivrît]

Je n'ai pas d'expérience avec MySQL cluster, donc je ne peux offrir que des théories.

Les moteurs de MySQL influent sur les types d'index disponibles et sur l'exécution des requêtes. C'est le cas par exemple pour le "count(*)" avec MyIsam, ou encore les index "hash" du moteur "memory" qui ne peuvent servir à retrouver une plage de valeurs. Du coup, il me semble possible que les index utilisés en cluster ne puissent servir pour optimiser un "count(distinct xxx)". Je vois bien le côté distribué et redondant des données poser problème pour ce genre de requêtes.

Est-ce que les index fonctionnent au moins pour un "WHERE id=xxx" ? Ça montrerait qu'ils sont bien là et sont opérationnels.

J'ai dernièrement eu besoin de migrer une base de données en MySQL vers un MySQL cluster.

Qu'est-ce qui a motivé cette migration ? Vous vous êtes peut-être penchés sur la question, mais il est généralement dit que MySQL cluster n'est "pas ce que l'on pense". C'est une bête totalement différente, et non un MySQL plus gros et plus rapide.

C'est plutôt du ouïe-dire, mais je crois qu'il n'est justement pas adapté aux requêtes complexes. Il est là pour la disponibilité et faire de l'OLTP très concurrent et très réactif, pas du reporting.

En espérant que ce sera utile...