MySQL Cluster est beaucoup plus lent que InnoDB

Question

J'ai une table dénormalisée product avec environ 6 millions de lignes (~ 2 Go) principalement pour les recherches. Les champs comprennent price, color, unitprice, weight, ...

Je index btree sur color etc. Les conditions de requêtes sont générées dynamiquement à partir du Web, tels que

select count(*) 
from product 
where color = 1 and price > 5 and price < 100 and weight > 30 ... etc 

et

select * 
from product 
where color = 2 and price > 35 and unitprice < 110 
order by weight 
limit 25; 

je l'habitude d'utiliser InnoDB et essayé tables MEMORY , et commuté au NDB en espérant que plus de requêtes simultanées peuvent être faites plus rapidement. J'ai 2 tables avec le même schéma, les index et les données. L'un est InnoDB tandis que l'autre est NDB. Mais les résultats sont très décevants: pour les requêtes mentionnées plus haut, InnoDB est 50 fois plus rapide que le NDB. C'est comme 0.8 seocond vs 40 secondes. Pour ce test, je n'exécutais qu'une seule requête select de manière répétée. Les requêtes InnoDB et NDB utilisent le même index sur color. J'utilise mysql-5.1.47 ndb-7.1.5 sur un double Xeon 5506 (8 cœurs au total), 32 Go de mémoire sous CentOS 5. J'ai mis en place 2 nœuds de données NDB, un nœud MGM et un nœud MYSQL sur la même boîte. Pour chaque nœud que j'ai alloué comme 9 Go de mémoire, et aussi essayé MaxNoOfExecutionThreads=8, LockPagesInMainMemory, LockExecuteThreadToCPU et de nombreux autres paramètres de configuration, mais pas de chance. Pendant que le NDB exécute la requête, mon pic de charge CPU était seulement de 200%, c'est-à-dire que seulement 2 des 8 cœurs étaient occupés. La plupart du temps c'était comme 100%. J'utilisais ndbmtd, et vérifié dans le journal de noeud de données et les threads LQH étaient en effet engendrés. J'ai également essayé d'expliquer, le profilage - il montre juste que Sending data consommait la plupart du temps. Je suis également allé à travers quelques documents de réglage Mysql Cluster disponibles en ligne, pas très utile dans mon cas.

Quelqu'un peut-il faire la lumière là-dessus? Existe-t-il une meilleure façon d'accorder une base de données NDB? Appréciez-le!

Answer 1

Vous devez choisir le bon moteur de stockage pour votre application. MyISAM - lire fréquemment/écrire rarement. Idéal pour les recherches de données dans les grandes tables. Fait raisonnablement bien avec des index complexes et est assez bon pour les rechargements par lots.

MEMOIRE - bonne pour un accès rapide à des tables relativement petites et simples.

InnoDB - bon pour le traitement des transactions. Aussi bien pour une charge de travail mixte en lecture/écriture.

NDB - relativement moins mature. Bon pour la tolérance aux pannes.

Le serveur mySQL n'est pas intrinsèquement un logiciel multiprocesseur. L'ajout de cœurs ne va donc pas forcément améliorer les performances. Un bon hôte pour mySQL est un système décent à deux cœurs avec beaucoup de RAM et les canaux et les disques d'E/S les plus rapides que vous pouvez vous permettre. Ne placez PAS vos fichiers de données mySQL sur un système de fichiers en réseau ou partagé, à moins que vous ne vous souciez pas des performances de la requête.

Si vous utilisez sur la version Linux de ces deux commandes (sur la machine exécutant le serveur mySQL) pour voir si vous brûlez tout votre cpu, ou brûler tout votre disque IO:

sar -u 1 10 
sar -d 1 10 

Votre l'application sonne comme un candidat pour myISAM. On dirait que vous avez beaucoup de matériel. Dans ce cas, vous pouvez créer un serveur maître et un serveur esclave répliqué automatiquement. Mais vous pouvez avoir un seul serveur.Ce sera plus facile à maintenir.