Discussion :

[seal3]

Bonjour à tous.

En vu de realiser un gros projet qui va necessiter de traiter des milliers de requettes par secondes, j'envisage un systeme sur lequel il nous suffira d'ajouter de nouveaux serveurs au fur et à mesure que le besoin s'en ressent.

MySQL cluster me semble à priorie correspondre mais je me pose quelque questions.

Nos besoins vont porter sur beaucoup de SELECT biensur, mais aussi beaucoup d'UPDATE et INSERT avec parfois des verouillages.

Je ne sais pas comment le cluster repartit la charge sur les differants serveurs. Je me dit que si il se contentait de faire une copie sur chaque serveur alors le select devrait etre dirigé vers un serveur ou un autre en fonction de la charge. Mais dans ce cas si je fais beaucoup d'update/insert, alors tous les serveurs doivent le traiter et finalement tous les serveurs vont ramer. Je me dit alors que cela ne doit surement pas etre comme ça que c'est geré.

Voila comment j'envisage de traiter une operation necessitant un verou (simplement en php) :
-> Verouillage de la table LOCK TABLE
-> lecture d'une infos
-> verification et traitement de l'info
-> update d'un enregistrement
-> UNLOCK

Le but etant biensur de s'assurer qu'aucun autre process de change la donnée avant la fain du traitement du process.

Du coup, à quoi s'attendre si on envisage de poser des verous dans une session sur une table, est-ce que tous les serveurs cluster se trouvent bloqués ?


Est-ce que de se trouver avec 10, 20 voir 100 serveurs reste une solution ? Et est-ce possible ? Autre strategie ?


Si quelq'un pouvait m'eclairer..

Merci beaucoup.

[StephaneC.]

Nos besoins vont porter sur beaucoup de SELECT biensur, mais aussi beaucoup d'UPDATE et INSERT avec parfois des verouillages.

La question est surtout de savoir si tu comptes faire des jointures ou pas.
Si oui, alors MySQL Cluster n'est probablement pas la bonne solution.

Ok, c'est un peu rapide comme réponse, mais il est finalement assez rare que MySQL Cluster soit le bon choix pour des applications classiques.

Stéphane

[seal3]

Bonjour,

Oui en effet il risque d'y avoir pas mal de jointures. En fait je pense pas mal sous diviser mes tables afin d'eviter de verouiller tout une table en ecriture dont certaines données devraient toujours etre accessibles par d'autres processus. Du coup cela implique des jointures.

Dans ce cas, si c'est problematique, quelle pourrait etre la solution ? Comment font des gros comme facebook par exemple ? Ils doivent bien avoir un gros paquet de jointures aussi non ?

[Sivrît]

Je ne sais pas comment le cluster repartit la charge sur les differants serveurs. Je me dit que si il se contentait de faire une copie sur chaque serveur alors le select devrait etre dirigé vers un serveur ou un autre en fonction de la charge. Mais dans ce cas si je fais beaucoup d'update/insert, alors tous les serveurs doivent le traiter et finalement tous les serveurs vont ramer. Je me dit alors que cela ne doit surement pas etre comme ça que c'est geré.

Il y a une redondance des données à des fin de résistance aux pannes, mais elle n'est pas totale. Les données sont aussi distribuées sur les différents noeuds. Cela implique que les requêtes qui accèdent à plusieurs enregistrements (bref tout ce qui ne porte pas sur une clef primaire) vont impliquer plusieurs noeuds.

Bref tout ça pour en venir au même point que StephaneC., MySQL cluster n'est (généralement) pas la solution.

Voila comment j'envisage de traiter une operation necessitant un verou (simplement en php) :
-> Verouillage de la table LOCK TABLE
-> lecture d'une infos
-> verification et traitement de l'info
-> update d'un enregistrement
-> UNLOCK

Le but etant biensur de s'assurer qu'aucun autre process de change la donnée avant la fain du traitement du process.

A moins que ce soit totalement et absolument exceptionnel, c'est à éviter complètement. Un LOCK TABLE tue toute concurrence. Pour tenir ce genre de débit il faut obligatoirement un verrouillage plus fin (par enregistrement, donc utiliser InnoDB), ou alors relâcher certaines contraintes de cohérence.

Oui en effet il risque d'y avoir pas mal de jointures. En fait je pense pas mal sous diviser mes tables afin d'eviter de verouiller tout une table en ecriture dont certaines données devraient toujours etre accessibles par d'autres processus. Du coup cela implique des jointures.

Idem, je pense qu'il vaut mieux s'appuyer pour ça sur InnoDB et son verrouillage par enregistrement plutôt que de monter une usine à gaz.

Est-ce que de se trouver avec 10, 20 voir 100 serveurs reste une solution ? Et est-ce possible ? Autre strategie ?

Dans ce cas, si c'est problematique, quelle pourrait etre la solution ? Comment font des gros comme facebook par exemple ? Ils doivent bien avoir un gros paquet de jointures aussi non ?

Généralement, on commence avec un serveur et on optimise. Après, quand ça ne suffit plus, on utilise la réplication et on répartie les SELECT sur les esclaves. En parallèle, pour alléger la charge de la BDD, on met en place un cache (facebook a, à ce qu'il me semble, des centaines d'instances de memcached). Là, pour que ça sature, il faut déjà une très grosse charge.

Ensuite, quand on est un gros, GROS site, genre facebook, Flickr et al, on en vient généralement au sharding. Le principe est de répartir les données sur plusieurs serveurs. Tous le schéma est présent sur tous les serveurs, mais chacun contient, par exemple, toutes les données relatives à un sous-ensemble des utilisateurs. Les jointures sont encore possibles... tant qu'elles concernent des données relatives à un utilisateur donné (pour suivre cet exemple) donc sur le même serveur. Au delà ça devient plus compliqué. Tout ça nécessite une infrastructure conséquente, mais permet d'ajouter des serveurs au fur et à mesure (encore faut-il avoir veillé à ce que la répartition entre les serveurs puisse évoluer pour s'accommoder des serveurs en plus).

Une source d'information sur le sujet serait http://highscalability.com/. On y trouve notemment des liens vers des récits de start-ups qui ont du faire face à une montée en charge et faire suivre leur infrastructure en conséquence.


Sinon, l'alternative est d'utiliser un SGBD qui peut tirer profit de très gros serveurs. Ce n'est pas répandu dans le domaine du web et la main d'œuvre économisée sur le développement pour mettre en place du sharding sera dépensée en licences Oracle et serveurs surpuissants.

[seal3]

Salut !

Merci beaucoup d'avoir pris le temps de m'expliquer, c'est tres gentil de votre part.. Je vais donc lacher l'idée de mysql cluster.

Je deteste avoir des limites. Je ne veux pas avoir à regreter plus tard une archi de base en me disant que le seul moyen de regler le soucis c'est de tout refaire.

Je pense que je vais donc essayer de repartir les données le plus intelligement possible sur plusieurs serveurs suivant une regle simple.
Par exemple en enregistrant suivant le modulo du ID afin de savoir directement sur quel serveur il est enregistré.

Apres effectivement ça complique pas mal.. Par ex si on doit mettre en place un forum et afficher une liste de post cela necesessitera d'appeller plusieurs serveurs pour avoir toutes les infos des membres qui ont postés. Surtout en php, qui sera pas multi thread.

Enfin c'est ptet pas la bonne solution , Je vais y reflechir.