Discussion :

[lamaison]

Bonjour,

j'ai une base de données qui grossit de plus en plus sur un serveur mutualisé.
La table la plus grosse dépasse les 180 megas ( il s'agit d'un historique ).
Mon fournisseur, questionné il y a un an m'avait conseillé de ne pas dépasser 20 megas mais il ne doit pas surveiller celà...
Bref ; les sauvegardes sont evidemment très problématiques et en cas de crash j'ai une semaine de boulot pour tout remettre en ordre.

L'application est utilisée par quelques centaines d'associations et j'envisage très sérieusement de dupliquer la base en n bases afin de limiter la casse en cas de crash ( ou de mauvaise manip ).
J'ai commencé à travailler sur la question et ça demande un travail énorme que j'ai presque terminé ( il faut prévoir des "aiguillages" en fonction des associations ) ; surtout du coté de mon backoffice.
Mias j'hésite à franchir le pas car ce n'est pas vraiment dans l'esprit des SGBD et ça me pose bien évidemment pas mal de problème techniques ( je dois me faire une sorte de phpmyadmin perso qui chapeaute un chapelet de bases identiques ).

Je me dis que l'exception confirme la règle et que le besoin est légitime mais au moment de franchir le pas je viens chercher quelques avis sur le forum.

Merci d'avance

[SQLpro]

Surtout pas de multibase : la remède serait pire que le mal. EN effet chaque base ouvrte consome plus qu'une seule base du fait des objest système....

En revanche intéressez vous au partitionnement, aux espaces de stockage (File Group, table Space...) et votre problème devrait se résoudre sans douleur.

A +

[vdumont]

Hum, la question que tu devrais te poser est plutôt pourquoi un stockage aussi limité? 180mb pour une base de données c'est très minime..

[lamaison]

Ok ; je laisse tomber le multibase....pour l'instant car le problème surviendra bien un jour ou l'autre.
Certes 180 Megas ce n'est pas une grosse base ... mais sur un hébergement mutualisé ca devient problématique.
Par exemple pour faire des sauvegardes nocturnes il ne faut pas dépasser les 10000 requêtes heures sinon l'hébergeur bloque les accès base.
Pas facile de jongler avec les limites de l'hébergement mutualisé quand on ne veut pas casser sa tirelire.

Concernant le partitionnement, les espaces de stockage (File Group, table Space...) je n'ai rien trouvé pour Mysql et je crains de ne pas avoir la main sur ce genre de choses si elles existaient ( toujours le problème du mutualisé ).
Bref je suis un peu coincé ...

[SQLpro]

Il faut adapter l'outil au problème et non l'inverse... Si votre demande est bien d'avoir 180 Go de data et plusieurs milliers d'utilisateurs simultané alors un hébergement mutualisé est une vaste utopie !

Commencez par dimensionner correctement votre projet et ses évolutions. Vous trouverez ensuite quel est la technique et l'outil le plus approprié à votre cas.

En d'autres termes : ne vous focalisez pas sur mySQL et un hébergement mutualisé. Prenez le temps de trouver la bonne solution. Etudiez votre modèle économique... Lhébergement mutualisé, même pour des outils soit-disant gratuit (mySQL n'est pas autant free qu'on le pense...) peut s'avérer plus coûteux que certains produits ayant des licences payantes !

A +

[lamaison]

Je comprends votre réponse.
Et je pense que vous avez raison sur le fond.
Je veux que le système soit gratuit et continue à profiter au plus grand nombre et ce n'est peut-être pas possible.
Le problème est qu'il n'y a pas de "solution intermédiaire".
Soit c'est du mutualisé soit c'est du dédié avec une SLA à toute épreuve, ce qui est vraiment hors de prix.
Au milieu ( et je ne parle même pas du low-cost genre Dedibox ) on n'est pas assez considéré par les provider pour espérer une qualité de service décente ( assurée paradoxalement sur le mutualisé pour cause de grand nombre de clients ).
Je part à la recherche d'un mécène !

[kedare]

Pensez a utiliser les different type de table de mysql aussi ... par exemple pour votre table d'historique , le transactionnel n'est pas tres utile (enfin c'est mon avis :p)

[orafrance]

la compression de données ou l'archivage ne sont pas possible ?