Optimisation, est-ce prejudiciable de regrouper 2 bases en une (200 tables environ)

[escteban]

Bonjour,

Je reprends un site avec bcp de données sql, principalement un gros forum (3M posts) et beaucoup de modules moins importants à coté.
Anciennement, il y avait quasi autant de bases de données que de rubriques, et chaque rubrique disposait de son système de login propre etc...
Je regroupe actuellement tout ceci, et une seule et même identification sera valable pour la totalité du site .
Initialement, j'avais prévu 3 bases de données, mais le fait que les tables users soient principalement dans une m'occasionne dans certaines occasions pas mal de switch de base de donnée, car je ne suis pas pour avoir des données redondantes.
En totalité je dois avoir 220 tables et je m interroge au sujet des conséquences sur le server MySQL du regroupement de la totalité de mes tables dans une base de données.
(j'ai 3 apache derriere un load balancer en front, et MySql possède son propre server -> 3Go RAM, Intel Core2Duo -, ce qui n'est pas de trop pour l'activité que je lui demande ^^).

Tout conseil et info est la bienvenue, sur la façon la meilleure de résoudre la problématique que je viens de vous exposer.

Cordialement

[Alain Defrance]

Un expert MySQL aurait peut-être une autre avis mais en ce qui me concerne je n'y voit aucun inconvénient.

Je pense qu'il est même préférable de procéder ainsi, ça ne sera que plus commode pour le contrôle de l'intégrité et la programmation stocké.

[escteban]

Ok, bêtement j'aurais pensé que d'avoir 250 tables sur une base saturerait beaucoup plus un server MySQL que 250 tables réparties sur trois bases.

Merci bcp pour ta réponse.

++

[Alain Defrance]

Envoyé par escteban

Ok, bêtement j'aurais pensé que d'avoir 250 tables sur une base saturerait beaucoup plus un server MySQL que 250 tables réparties sur trois bases.

Merci bcp pour ta réponse.

++

Ca sera je pense plus lourd, mais il ne faut pas oublier que c'est le travail du SGBD de gérer ça, et il parait qu'il s'en sort très bien
En tout cas tout dépend de ton trafique et de ta machine.

[escteban]

Re Kazou,

Pour le serveur MySQL il tourne actuellement dans sa version 5.0.45 sur un Mac Mini Core2Duo (proc Intel) avec 3G de ram. Le site est plutôt beaucoup fréquenté et a, durant environ six heures dans la journée une moyenne de 600 connectés simultanément.

Mais de toute façon, la question que je me pose est : est-ce que ca handicapera la productivité de MySQL de regrouper toutes les tables dans une base par rapport à dans 3 différentes, CE AVEC LA CONFIG ACTUELLE, dont je cherche à tirer le meilleur parti sans en changer (pas de moyens).

Si un expert dans le domaine peut m'eclairer de ses lumières , ce serait top

++

[wiztricks]

Bonsoir,

Ca dépend des opérations select/insert que vous effectuez sur vos tables.
En les regroupant, vous risquez d'augmenter les contentions pour vérouiller les bouts de tables mis à jour.

Cela ne signifie pas que ce soit impossible seulement qu'il faut étudier les accès aux tables existantes pour éviter des problèmes de performances le jour ou vous les aurez consolidées.

-W

[escteban]

Excuses moi mais je ne suis vraiment pas sûr de ce que tu entends par "étudier les accès aux tables existantes", peux tu développer un peu plus stp ?

[wiztricks]

Si, par exemple, vous êtiez sûr que vos accès n'étaient qu'en lecture, vous pourriez fusionner vos tables sans vous poser de questions.

Ce qui va être pénalisant sont les écritures puisqu'à priori deux utilisateurs qui voudront mettre à jour le même enregistrement devront le faire un après l'autre (sérialisée). "L'un après l'autre", signifie que le premier va poser un vérrou pour signaler aux suivants qu'ils devront attendre.

Ces "écritures" sont en général masquées dans des opérations plus globales de types select, join,... et les verrous ne seront pas toujours posés sur un enregistrement mais sur une partie plus ou moins importante de la table.

=> A la limite, si vous vérouillez l'ensemble de la table, vous comprennez qu'il est préférable d'en avoir plusieurs 'petites'.

Est ce plus clair?

- W

[escteban]

C'est bien ce que je pensais , on ne s'est pas tout a fait compris, ma question était :
est-ce préjudiciable nivo perf d'avoir 250 tables dans une base de données MySQL par rapport à avoir ces 250 tables réparties dans 3 bases de données ?
En gros je ne projettes pas de fusionner des tables, mais de les regrouper dans une seule base de données, qui à l'issu de ce regroupement contiendrait environ 250 tables.

Merci ++

[wiztricks]

Excusez moi, mais effectivement je ne vous ai pas compris.

En fait ce qui me fait tiquer, c'est le 250...

C'est beaucoup de tables et je comprendrais que vous souhaitiez réduire ce nombre.
Si ce n'est pas le cas, je ne pense pas que cela pose un problème particulier mais j'ai quelques difficultés en en comprendre l'intérêt.
Cordialement
- W

[escteban]

Merci pour votre réponse.
Le but est d'éviter dans les scripts serveurs de changer de db lors de l'execution d'un seul et meme script (php).

Si d'autres usagers expérimentés de MySQL veulent s'exprimer sur le sujet , je reste preneur, car les deux réponses que je viens d'avoir de wiztricks et kazou (pour lesquelles je les remercie, je préfère clarifier ^^) ne sont pas très catégoriques, et donc un doute subsiste ...

[kaymak]

Envoyé par wiztricks

Excusez moi, mais effectivement je ne vous ai pas compris.

En fait ce qui me fait tiquer, c'est le 250...

C'est beaucoup de tables et je comprendrais que vous souhaitiez réduire ce nombre.
Si ce n'est pas le cas, je ne pense pas que cela pose un problème particulier mais j'ai quelques difficultés en en comprendre l'intérêt.
Cordialement
- W

Salut,

Ça fait tiquer.
Mais bon l'intérêt se situe au niveau du code de l'application.
Apparemment les appels sont fait de cette forme
SELECT * FROM matable
et non de celle ci
SELECT * FROM ma_base.ma_table.
Ce qui dans son cas posent quelques problèmes puisqu'il est dès lors obliger d'ouvrir une connexion par bdd et de changer de connexion courante très souvent dans ces scripts.... Bref c'est vraiment galère.

Donc l'idée ici n'est pas tellement de revoir la conception, des tables, mais juste leur appartenance à tel ou tel db.

Sinon, moi je ne connais pas beaucoup mieux que la doc :
http://dev.mysql.com/doc/refman/5.0/...structure.html
http://dev.mysql.com/doc/refman/5.0/...ny-tables.html

On en revient à ceci :

Envoyé par wiztricks

=> A la limite, si vous vérouillez l'ensemble de la table, vous comprenez qu'il est préférable d'en avoir plusieurs 'petites'.

Sauf qu'en fait tu ne dois pas avoir beaucoup de jointure qui lie des tables de différentes dbs
Donc pour ce point ci l'impact devrait être limité.

bye