mise a l'échelle (scaling) de mysql

Version imprimable

08/01/2009, 13h02
marseillai

mise a l'échelle (scaling) de mysql

Bonjour.
J'ai un probléme de performance sur notre serveur mysql que j'essai de résoudre depuis quelques temps mais je reste bloqué donc je viens le posé ici.

Notre architecture :
Nous utilisons mysql pour stocker les données des logiciels de notre société (suivi de production, relation client, facturation, commande, ... tout) dans des tables MyISAM qui sont quasiment toutes liées entre elles. Ces données sont lue par des programmes en c++. Nous avons une cinquantaine d'utilisateurs et une bonne centaine de programme. Chaque utilisateur fait tourner en moyenne 3 programmes. Ces programmes font a peu prés autant de lecture que d'écriture.
Au milieu de ces utilisateurs nous avons un automate qui exécute un programme de mise a jour toutes les 10 minutes.

Le serveur sql est un serveur dell d'il y a deux ans avec un xeon et deux giga de ram et des disque 15ktr en scsi et en raid5.
Depuis quelques temps nous remarquons que lors du calcul de l'automate il y a de fort ralentissement mais même en dehors de ce calcul le serveur commence a avoir du mal face a la monter en charge.

Je sais qu'une solution serait de changer de matériel pour prendre un serveur plus puissant avec des disques en SAS et plus de ram. Mais a vrai dire même si le changement de matériel est fermement envisagé je suis a la recherche d'une solution a plus long terme. En gros qu'est ce que nous avons a changer dans notre maniére de travailler avec mysql pour être scalable.

Je me doute que je ne suis pas trés clair. Mais en gros j'aimerais savoir qu'elle est la chose a faire pour que les performances de notre base de données ne soient plus jamais un probléme. J'ai pensé a découper la base de données sur plusieurs serveurs mais nos tables sont toutes trés liées et le moteur federated ne m'inspire pas confiance. J'ai pensé a un cluster mysql mais j'en ai pas entendu que du bien et sachant qu'on souhaite virtualiser notre infrastructure j'en entend encore plus de mal.

Bref selon vous comment doit fonctionner une architecture de base de données pour que les performances ne soient plus un problème et qu'on ait la solution "définitive" ?

Merci d'avance
16/01/2009, 19h26
Sivrît

Difficile de répondre dans la mesure où beaucoup de chose entrent en jeu.

Si les problèmes de performances viennent de l'automate, il faudrait voir ce qu'il fait. S'il lance une ou des grosses requêtes non optimisées qui mettent le serveur à genoux, un peu d'optimisation aiderait beaucoup.

Après, il faut aussi voir le facteur limitant. Par exemple il est possible que l'automate utilise de longues requêtes qui posent des verrous sur certaines tables et bloquent les autres clients. Un moteur avec un verrouillage plus fin (InnoDb) serait dans ce cas à considérer.

Généralement, la principale piste pour monter en charge avec MySQL est la réplication, avec une répartition des lectures sur les esclaves. Ce n'est pas forcément transparent pour les applications (même si certains outils peuvent aider, MySQL Proxy notamment). Le problème est que c'est d'autant moins efficace qu'il y a d'écritures. A voir suivant la charge.

Le moteur federated est généralement déconseillé en dehors des requêtes simple, donc pas vraiment une solution. MySQL cluster est une bête assez particulière, il n'est probablement pas approprié dans ce cas (cela dit je ne le connais pas bien).

La seule solution transparente pourrait être le partitionnement. Suivant les requêtes qui tournent et les volumes de données, il joue plus ou moins.

En terme de "scalabilité", pour vraiment pouvoir monter en charge sur les d'écritures, le sharding est la solution la plus extrême. Mais ça demande toute une infrastructure et des applicatifs qui en tiennent compte. L'idée est de répartir les données suivant un critère bien choisi (par exemple tout ce qui concerne un utilisateur, quelle que soit la table), ce qui permet de faire tourner simplement l'essentiel des requêtes sur une "shard" donnée. Par contre dès que l'on en sort (une jointure ou un compte inter-utilisateurs par exemple), c'est moins drôle. Lourd mais on peut dire "notre base de données n['est] plus jamais un problème".

Reste que ça me semble overkill dans ce cas. A vu de nez un serveur devrait pouvoir tenir (quitte peut-être à archiver les vielles données). Il y aurait peut-être besoin d'un peu d'optimisation, voir si les données tiennent (peuvent tenir) en RAM, si un peu plus de CPU peut aider, si la configuration du serveur ne peut pas être améliorée...

En espérant que ça fait avancer le schmilblique.
18/01/2009, 11h29
marseillai

Tout d'abord merci pour cette réponse.

Citation:

Envoyé par Sivrît

En terme de "scalabilité", pour vraiment pouvoir monter en charge sur les d'écritures, le sharding est la solution la plus extrême. Mais ça demande toute une infrastructure et des applicatifs qui en tiennent compte. L'idée est de répartir les données suivant un critère bien choisi (par exemple tout ce qui concerne un utilisateur, quelle que soit la table), ce qui permet de faire tourner simplement l'essentiel des requêtes sur une "shard" donnée. Par contre dès que l'on en sort (une jointure ou un compte inter-utilisateurs par exemple), c'est moins drôle. Lourd mais on peut dire "notre base de données n['est] plus jamais un problème".

Je suis trés intéressé par ca. J'y avais déja jeter un oeil mais ca me semblait pas vraiment possible du fait que quasiment toutes nos tables ont des jointures entre elles et sont trés difficilement découpable ...
Donc voila si c'est possible alors je suis ouvert a toute proposition de documentation sur le sujet les méthodes et autre.

Citation:

Envoyé par Sivrît

Reste que ça me semble overkill dans ce cas. A vu de nez un serveur devrait pouvoir tenir (quitte peut-être à archiver les vielles données). Il y aurait peut-être besoin d'un peu d'optimisation, voir si les données tiennent (peuvent tenir) en RAM, si un peu plus de CPU peut aider, si la configuration du serveur ne peut pas être améliorée...

C'est en prévision et oui ca doit tenir en ram mais disons qu'a la vitesse a laquelle nos données croissent. J'aimerais entrevoir une solution plus pérenne. et pouvoir me dire comme tu as dit : "notre base de données n['est] plus jamais un problème".

Citation:

Envoyé par Sivrît

En espérant que ça fait avancer le schmilblique.

ça a. :)
Merci beaucoup.
19/01/2009, 10h17
Sivrît

Citation:

Envoyé par marseillai

Je suis trés intéressé par ca. J'y avais déja jeter un oeil mais ca me semblait pas vraiment possible du fait que quasiment toutes nos tables ont des jointures entre elles et sont trés difficilement découpable ...
Donc voila si c'est possible alors je suis ouvert a toute proposition de documentation sur le sujet les méthodes et autre.

La principale ressource qui me vient à l'esprit est http://highscalability.com/unorthodo...n-coming-shard. Hibernate a aussi un framework pour ça.
Mais pour un système d'information d'entreprise c'est probablement overkill (ça sert plutôt pour les gros sites web, genre ebay, facebook, etc.)
A la louche (je ne suis pas consultant), archivage, optimisation et partitionnement seront plus rentables.

Citation:

Envoyé par marseillai

C'est en prévision et oui ca doit tenir en ram mais disons qu'a la vitesse a laquelle nos données croissent. J'aimerais entrevoir une solution plus pérenne. et pouvoir me dire comme tu as dit : "notre base de données n['est] plus jamais un problème".

Quelque part, il faudra toujours faire un minimum attention à la BDD. Une requête qui tue reste une requête qui tue, quels que soient la base, le schéma et le matériel.

Pour ce qui est des possibilités, il faut voir les objectifs que vous visez, et surtout les moyens et la marge de manœuvre. S'il y a tant d'applications existantes et qu'elles ne peuvent pas être modifiées, les possibilités sont très restreintes. Peut-être du partitionnement (et encore ça va dépendre du schéma)... A mon avis, une politique d'archivage pour s'assurer que les données "chaudes" tiennent toujours en mémoire serait la piste la plus viable. MySQL proxy est aussi avancé pour ce genre de situations, afin d'insérer des traitements / modifications indépendamment des applications.

Sinon, en termes de modifications, l'automate semble une cible tentante. S'il lit beaucoup de données, il pourrait peut-être le faire sur un esclave (via réplication).
19/01/2009, 13h50
marseillai

Citation:

Envoyé par Sivrît

Sinon, en termes de modifications, l'automate semble une cible tentante. S'il lit beaucoup de données, il pourrait peut-être le faire sur un esclave (via réplication).

ca je prends et je vais le mettre en place de suite.

Pour le reste j'avoue que j'aurais aimé trouvé un "truc" du genre de oracle RAC qui d'aprés ce que j'ai compris m'aurait permis de faire ce que je veux.
Tant pis on dira qu'une réplication + un peu de découpage de la base + du nouveau matériel devrait faire l'affaire jusqu'a une techno genre drizzle ou autre ...