Une base ou n bases ?

lamaison · 21/12/2007, 18h48

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 · 23/12/2007, 22h36

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 · 25/12/2007, 06h26

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 · 27/12/2007, 20h44

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 · 28/12/2007, 14h12

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 · 03/01/2008, 16h43

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 · 05/01/2008, 00h37

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 · 11/01/2008, 09h17

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

21/12/2007, 18h48	#1
lamaison Invité de passage Inscription : mars 2006 Messages : 17 Détails du profil Informations forums : Inscription : mars 2006 Messages : 17 Points : 4 Points : 4	Une base ou n bases ? 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
	00

23/12/2007, 22h36	#2
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 793 Points : 17 793	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 + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

28/12/2007, 14h12	#5
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 793 Points : 17 793	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 + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

11/01/2008, 09h17	#8
orafrance Rédacteur/Modérateur Inscription : janvier 2004 Messages : 15 861 Détails du profil Informations personnelles : Âge : 35 Informations forums : Inscription : janvier 2004 Messages : 15 861 Points : 16 212 Points : 16 212	la compression de données ou l'archivage ne sont pas possible ? __________________ Règles et liens du forum Oracle Guide Oracle Pense-bête du DBA Oracle : Exemple
	00

25/12/2007, 06h26	#3
vdumont Membre éclairé Étudiant Inscription : février 2006 Messages : 510 Détails du profil Informations personnelles : Âge : 26 Informations professionnelles : Activité : Étudiant Informations forums : Inscription : février 2006 Messages : 510 Points : 317 Points : 317	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..
	00

27/12/2007, 20h44	#4
lamaison Invité de passage Inscription : mars 2006 Messages : 17 Détails du profil Informations forums : Inscription : mars 2006 Messages : 17 Points : 4 Points : 4	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é ...
	00

03/01/2008, 16h43	#6
lamaison Invité de passage Inscription : mars 2006 Messages : 17 Détails du profil Informations forums : Inscription : mars 2006 Messages : 17 Points : 4 Points : 4	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 !
	00

05/01/2008, 00h37	#7
kedare Membre extrêmement actif Mathieu Administrateur systèmes et réseaux Inscription : juillet 2005 Messages : 1 476 Détails du profil Informations personnelles : Nom : Mathieu Localisation : France Informations professionnelles : Activité : Administrateur systèmes et réseaux Informations forums : Inscription : juillet 2005 Messages : 1 476 Points : 1 260 Points : 1 260	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)
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email