je vais mettre en place un site mutualisé qui devra pouvoir en accueillir 300 à terme.
La question que je pose à ceux qui ont des connaissances sur les serveurs MySQL :
- soit j'utilise la même base pour les 300 sites (soit 300 x 40 = 1200 tables dans la même base)
- soit je crée une base par site.
Dans le premier cas, est-ce que le fait d'avoir 1200 tables dans la même base risque de ralentir les requètes sur les tables MySQL ?
Ou est-ce que cela est aussi rapide pour les 2 solutions ?
Merci pour les éclairages de ceux qui ont déjà testé.
je vais mettre en place un site mutualisé qui devra pouvoir en
accueillir 300 à terme.
La question que je pose à ceux qui ont des connaissances sur les
serveurs MySQL :
- soit j'utilise la même base pour les 300 sites (soit 300 x 40 = 1200
tables dans la même base)
- soit je crée une base par site.
Dans le premier cas, est-ce que le fait d'avoir 1200 tables dans la même
base risque de ralentir les requètes sur les tables MySQL ?
Ou est-ce que cela est aussi rapide pour les 2 solutions ?
Merci pour les éclairages de ceux qui ont déjà testé.
pas de réponse toute faite ... je suppose que l'une et l'autre des solutions
a des avantages et inconvénient .
en tout cas à ce moment où j'ecris, http://grml.eu contient 2584
tables dans une
base et se porte bien (mais le trafic est quasi nul)
Le 30/01/08, Olivier Gautier<olivier.gautier@ac-rouen.fr> a écrit :
La question que je pose à ceux qui ont des connaissances sur les
serveurs MySQL :
- soit j'utilise la même base pour les 300 sites (soit 300 x 40 = 1200
tables dans la même base)
- soit je crée une base par site.
Pour les perfs je ne sais pas
Une base par site me semble plus simple à gérer... Par exemple, cela
permettra éventuellement d'isoler les bases grosses consommatrices (ça
arrive !) sur un autre serveur si besoin... avec les tables ça va être
galère...
- soit j'utilise la même base pour les 300 sites (soit 300 x 40 = 1200 tables dans la même base)
- soit je crée une base par site.
comme il n'y aura pas mutualisation des *données* (pas de tables transversales), autant créer des bases séparées.
en terme de sécurité, si une base tombe, ce ne sera jamais que pour un site.
pour la maintenance (nettoyage, sauvegarde...), ton serveur travaillera en parallèle avec, pourquoi pas, des configurations différentes en fonction des utilisations : base trés souvent modifiée -> optimize régulier, dump quotidien..., base peu souvent modifiée -> intervalle de maintenance plus long.
à terme tu pourra aussi répartir les bases sur des serveurs différents.
je vais mettre en place un site mutualisé qui devra pouvoir en
accueillir 300 à terme.
La question que je pose à ceux qui ont des connaissances sur les
serveurs MySQL :
soit j’utilise la même base pour les 300 sites (soit 300 x 40 = 1200
tables dans la même base)
soit je crée une base par site.
actuellement on gère une 30 de spip plus ou moins gros (mais sans la mutualisation on n’est pas en svn , bientôt Ben , bientot , enfin j’espère , ) sur des tables distinctes ça me semble plus souple à gérer.
si tu as des scripts de maintenance il n’y a que le nom de la base qui va changer et pas un paramètre de préfixe à chaque table
en cas de pépin tu pourras couper ta base , l’isoler …
pour faire un dump tu n’a pas à lister les tables …
et puis ça me semble plus propre pour isoler les donner (les grants sont plus simples, les ficheirs de bases sont distincts)
pour de l’industrialisation je pense qu’il n’a pas photos
Pour les perfs je ne sais pas, je n’ai pas testé des gros sites sur une même base.
Je pense que le choix est assez clair : 1 base par site pour faciliter la maintenance.
Cordialement,
Olivier Gautier.
Arnaud Ventre a écrit :
Le 30/01/08, *Olivier Gautier* <olivier.gautier@ac-rouen.fr <mailto:olivier.gautier@ac-rouen.fr>> a écrit :
Bonjour,
je vais mettre en place un site mutualisé qui devra pouvoir en
accueillir 300 à terme.
La question que je pose à ceux qui ont des connaissances sur les
serveurs MySQL :
- soit j'utilise la même base pour les 300 sites (soit 300 x 40 = 1200
tables dans la même base)
- soit je crée une base par site.
actuellement on gère une 30 de spip plus ou moins gros (mais sans la mutualisation on n'est pas en svn , bientôt Ben , bientot , enfin j'espère , ) sur des tables distinctes ça me semble plus souple à gérer.
si tu as des scripts de maintenance il n'y a que le nom de la base qui va changer et pas un paramètre de préfixe à chaque table
en cas de pépin tu pourras couper ta base , l'isoler ...
pour faire un dump tu n'a pas à lister les tables ...
et puis ça me semble plus propre pour isoler les donner (les grants sont plus simples, les ficheirs de bases sont distincts)
pour de l'industrialisation je pense qu'il n'a pas photos
Pour les perfs je ne sais pas, je n'ai pas testé des gros sites sur une même base.
Outre les aspects de facilité de maintenance et de performance privilégiant l'utilisation de x bases, l'aspect sécurité m'amène à penser que l'utilisation d'une seule base ne se justifie UNIQUEMENT lorsque les différents sites mutualisés appartiennent au même et unique propriétaire.
Sinon c'est la cata : un accès à phpMyAdmin ou quelques lignes de php dans un squelette permet de faire n'importe quoi sur les tables des différents sites.
A+
Philippe
denisb a écrit :
James wrote:
si je connais le préfix des tables d'un site voisin, j'accède aux données ?
<BOUCLE(TOTO_ARTICLES)...> ou mieux <BOUCLE(TOTO_MESSAGES)...> pour les messages privés, ça marcherait ?
hmmm... pas sûr :
normalement ça fait un select sur base.préfixe_toto_messages
avec par défaut préfixe = spip
Sinon c'est la cata : un accès à phpMyAdmin ou quelques lignes de php dans un squelette permet de faire n'importe quoi sur les tables des différents sites.
oui.
mais dans ce cas là (une seule base, plusieurs préfixes) tu attribues des droits spécifiques à tes utilisateurs en fonction des préfixes de table : GRANT SELECT ON site1_spip_auteurs TO admin_site1@...
Sinon c’est la cata : un accès à phpMyAdmin ou quelques lignes de php
dans un squelette permet de faire n’importe quoi sur les tables des
différents sites.
oui.
mais dans ce cas là (une seule base, plusieurs préfixes) tu attribues
des droits spécifiques à tes utilisateurs en fonction des préfixes de
table : GRANT SELECT ON site1_spip_auteurs TO admin_site1@…
Ce qui est fastidieux c’est que tu dois granter table par table et ça peux poser des problèmes quand tu as un plugin qui dois créer une nouvelle table par exemple , alors que si tu grantes la base en global tu n’a pas besoin de le gérer au fil de l’eau.
si je connais le préfix des tables d'un site voisin, j'accède aux données ?
<BOUCLE(TOTO_ARTICLES)...> ou mieux <BOUCLE(TOTO_MESSAGES)...> pour les messages privés, ça marcherait ?
suite à une remarque de James, je corrige la réponse
que j'ai donnée à 08:50
je viens de tester.
dans ma base je crée une copie de spip_messages que je nomme toto_messages ;
la boucle
<BOUCLE_estula(MESSAGES) {tout> #ID_MESSAGE - #TITRE<br>
</BOUCLE_estula>
-> me renvoie sur ma 404.html
normal : la table n'est *pas* déclarée.
les boucles
<BOUCLE_estula(TOTO_MESSAGES) {tout> #ID_MESSAGE - #TITRE<br>
</BOUCLE_estula>
ou
<BOUCLE_estula(SPIP_MESSAGES) {tout> #ID_MESSAGE - #TITRE<br>
</BOUCLE_estula>
-> me renvoient les données.
normal : les tables sont *explicitement* appelées par les boucles.
je crée maintenant une copie de spip_auteurs que je nomme toto_auteurs ;
la boucle
<BOUCLE_estula(AUTEURS) {tout> #ID_AUTEUR - #NOM<br>
</BOUCLE_estula>
-> me renvoie les données de spip_auteurs.
normal : la table *est* déclarée *et* son préfixe est bien $table_prefix
la boucle
<BOUCLE_estula(TOTO_AUTEURS) {tout> #ID_AUTEUR - #NOM<br>
</BOUCLE_estula>
-> me renvoie les données de toto_auteurs.
normal : la table est *explicitement* appelée par la boucle.
donc :
sans limitation propre à mysql (droits grant), les tables de différents
sites appartenant à une *même* base sont consultables depuis l'un
quelconque de ces sites.
) sur des tables distinctes ça me semble plus souple à gérer.