bonjour,
 
j'ai une table de plus de 7000 entées qui commence à devenir un peu lourde (donc qui ralentit, et qui devient pénible à sauvegarder) : pres de 5MO.
 
Y-a-t'il des méthodes pour la "dégraisser", ou pour optimiser sa taille ?
j'ai utilisé la fonction optimize table qui n'a apparemment pas changé grand chose...  
 
merci de vos conseils  

et si tu donnais la structure ? 7000 lignes et 5Mo ça fait pas mal d'octets par ligne

passer sous sql server

Avant de construire une table il faut essayer de reflechir à une structure robuste, cohérente et qui empeche la duplication des données.
 
Si tu vois que ta table contient énormement de colonnes et que les données se repètent, alors tu as un problème de structure, et tu dois essayer de la séparer en plusieurs tables.
 
Je suis pas convaincu que passer sous sql server change quoi que ce soit à ce problème, c'est pas un probleme de langage ou de logiciel, c'est un probleme de gestion de base de données en général.

j'avais essaye de refléchir avant, je ne pense pas qu'il y ait des données dupliquées, mais c'est ne base dans laquelle les champs sont souvent des champs de type txt (base de données pour accueillir des critiques de livres, les littéraires sont des verbeux )
 
je ne crois pas que ce soit la structure qui soit en cause. c'est la base elle meme qui fait 5MO, pas une table particulière.
 
Donc pas de méthode "code" pour un nettoyage quelconque ou une compression des données inutilisées ... ?

c'est un peu incohérent ton histoire..
 
c'est une table ou la somme des tables qui fait 5Mo ?
 
tu as des données "inutilisées" ? tu peux pas les mettre à part ou séparer un peu plus tes infos ?

c'est la base, le fichier base.sql si tu veux, qui fait pres de 5MO
Non, je ne pense pas avoir de données inutilisées. ma question etait : y a-t-il des methodes de compression par exemple.
Si c'est non, tant pis, mais je ne vois pas ce qu'il y a d'incohérent dans cette question ...

la base et le dump c'est pas tout à fait la même chose (surtout si c'est un dump avec un INSERT pour chaque ligne)
 
donc en fait le problème c'est que c'est long à restaurer / sauvegarder c'est ça ? et tu utilise phpmyadmin pour faire tout ça ?
 
non, pas de compression disponible autre que la compression du dump une fois généré
 
par contre il est possible de sauvegarder structure d'un coté et contenu dans un CSV, c'est moins lourd (mais faut avoir pris ses précautions avant, surtout si t'as des textes, ou bien choisir ses délimiteurs)
 

merci de ta reponse
oui et non pour la sauvegarde :  
j'utilise aussi un script php que j'ai fait, et qui se lance automatiquement tous le soirs avec un cron; et justement le pb c'est qu'il met maintenant plus de 30sec à s'executer (limitation PHP de mon serveur...), et du coup il faut faire ces sauvegardes "à la main" avec PHPmyadmin...
Je n'avais pas pensé à gérer à part la structure et les données, mais je crains que ce ne soit pas la structure qui soit lourde???
 
je vais sinon voir du cote d'une 2eme base à partir de l'enregistrement 10 000 par exemple, mais ca va etre lourd en code :-/ ...

si tu veux séparer facilement tes données, regarde du coté du type MERGE (marrant, ça fait déjà 2 fois aujourd'hui que j'arrive à  le caler celui là)
 
et tu devrais aussi refaire / vérifier ton script et les index
 
pour le CSV, c'est la méthode de chargement qui est plus efficace, le dump SQL c'est lourd comme tout

ma solution avec sql server n'etait pas idiote

 
certes, mais un poil plus onéreuse

c'est plus leger ?
quels sont les avantages ? je ne me suis jamais posé la question, au fond...

 
euh... que veux tu dire concretement pas là ??? je suis    , dsl, mais je ne vois pas ?

La méthode la plus rapide pour faire une sauvegarde mysql, c'est un 'select into outfile "nom du fichier" ' et son acolite "load data infile".
Là où je bosse on arrive à sauvegarder 7 Go de données en moins de 30 minutes soit 3.8 Mo/s si je me trompe pas.
Par contre, il faut avoir le droit pour faire ça et il faut aussi avoir un serveur pas trop saturé. Le notre est puissant avec des disques SCSI et le nombre de requettes par secondes est assez faible à l'heure où on fait la sauvegarde.
Avec cette méthode, il faut pas oublier de faire en plus une requette pour obtenir une sauvegarde de la structure de la base.

la manière d'insérer les données n'est pas la même
 
sinon tu peux utiliser du INSERT DELAYED aussi

IMHO si ça rame avec 7000 lignes ( ce qui n'est vraiment pas grand chose même pour mysql) je pencheraiss plus pour une absence d'indexes qui vont bien et/ou a des requêtes mal ecrites...
 
edit: question par ailleurs ta table tu lui a mis quel type? MyISAM?

OK Sh@rdar merci. J'ai fait un test "manuel" d'exportation de la base en CSV et non plus MySQL, effectivement les poind du fichier est divisé par deux.
 
Reste plus qu'à trouver un nouveau script pho ou autre pour exporter ca automatiquement (c'est le but final...)
 
> anapajari : ce n'est pas l'utilisationde la base qui rame... ce qui doit etre indexe l'est, c'est la sauvegarde...

c'est pas grand chose tout court une base qui rame c'est une base mal conçue, pas trop peuplée

 
 
fait attention avec tes champs textes, ils doivent être bourrés de \r\n et la réimportation n'est pas gagnée

 
 
vi... je me posais la question...

7000 entrées, 5Mo moi je trouve ca léger
si le problème est un problème de performances, je pense que, comme le dit anapajari ca doit être des tables qui n'ont pas de bons indexes
pour la sauvegarde, si tu as la main sur le serveur, ne fais pas tes scripts de backups en PHP

merci couak, je ne pense pas que ce soit un pb de table ou d'index, ca doit etre correct sur ce plan là. Un table qui content des livres entier ce n'ets pas la meme chose q'une table de forum...  
 
par contre je suis effectivement en train de voir une solution pour récuperer la base compressee avec un script shell qui ne sera pas limité par la limite du php.ini (30 sec. d'execution.. c'ets court!)
Ca devrait marcher... il ne me manque que 20 sec. au plus.

tu veux vraiment pas la filer ta structure ?

pourquoi tu ne fais pas un dump de la base avec mysqldump ?

 
c'est ce que je vais faire, effectivement    
 
> Sh@rdar : je ne vois pas l'interet, c'est long il y a 15 tables, et je sais tres bien qu'il n'y a pas de pb de structure à priori    
 
Merci à tous de votre aide, c'est réglé avec un sauvegarde par shell

 
le dump (*.sql) est un ensemble de requetes d'insertion qui prend beaucoup plus de place que la base. avant transfert tu peux faire une compression de celui-ci (gzip).

comme annoncé, si tu peux faire un mysqldump, ca reglera tes problemes. Pour un ordre d'idée, j'ai 40Mo de base, 500 000 enregistrements. Et le dump se fait en 20 seconde sur une vieille becane avec un disque merdique.

Le probleme des portails c'est que tout est stoqué en base de données, ta base n'à pas fini de grossir, la ce que tu as c'est rien ca va devenir énorme avec le temps.
 
Il va soit falloir en tenir compte dans ton hébergement, soit revenir à des méthodes "anciennes", c'est à dire avoir des ressources en pages "statiques", pages statiques que tu référence dans ton portail. Le portail ne devrais te servir qu'à référencer des ressources, pas à stoquer des ressources.
 
Mais si tu stoque tout dans ton logiciel de portail, ta base va continuer à grossir, et les perfs vont se dégrader, à moins d'avoir un serveur dédié très puissant avec beaucoup de RAM.
 
Plusieurs sites important on du finir par fermer à cause de ce problême. Il faut soit passer en serveur dédié, soit revenir à du statique (même partiellement)

 
euh... concrètement, tu fais quoi ? Comment fais tu pour compresser dynamiquement ce fichier ? je ne vois pas trop ...
 

 
Pour le statique.. je ne vois vraiment pas comment faire avec une boutique de 10 000 produits évolutifs ... le dédié, peut etre, mais pas le statique

D'un autre côté, de trés nombreux sites dont certain assez gros continuent à grossir sans être sur du dédiés. Mais c'est vrai qu'ils ne sont pas resté, par exemple, chez free.
Le dédiés, c'est vraiment quand on en a besoin, il y a aussi de trés bons mutualisés qui arrivent à garder de bonnes performance.
En fait, avant de passer au dédié, il faut d'abord vérifier l'analyse de la base et entre autre les index pour être sur de ne pas perdre 95% du temps sur des bétises du à un mauvais index ou un index oublié. Il faut aussi vérifier si on a codé le site intélligement. (on a déjà vu sur ce forum des personnes qui cherchaient la liste des messages et qui ensuite refaisaient une requette par message pour avoir les infos du posteur)
 
Comme quoi, il faut pas généralisés à la va vite surtout sur ce genre de sujet.

Pour le serveur, je suis sur du "tres bon mutualisé", chez Quetzal Network : ils ont leur propre salle blanche, et des BP non sur-bookées, en principe effectivement le pb ne vient pas de là...

 
Pas de compression dynamique. Le dump n'est qu'une copie textuelle du contenu de la base. Ce n'est pas les fichiers propres à la base. . une fois le dump, je compresse par gzip.
 
Mais ca ne compresse pas la base.

ah! alors ok

mais j'ai du mal à cerner ton probleme. C'est bien le dump qui te gene?

oui, je le lance dynamiquement par un cron, et depuis script PHP.
Le pb venait du fait que le script met plus de 30 sec. à s'éxécuter, et donc le serveur l'empeche de se terminer puisque le php.ini impose cette limitation de 30 sec. Comme je suis sur du mutualisé, et que l'admin ne veut pas toucher à cette limitation (pour des pb de saturation en cas de scripts en boucle par exemple, je peux le comprendre), du coup ... je ne peux plus faire ce dump dynamiquement.
 
Sauf avec un shell, puisque dans ce cas je ne suis pas limité par le temps, c'ets ce que m'a proposé l'admin du serveur, et ca marche.
 

ca me parait plus coherent. C'est ton script qui faisait l'extraction des données?

oui

et pourquoi ne pas appeler la commande mysqldump depuis le script.

euh ... je ne me suis pas pose la question qd j'ai cree celui la... C'est plus efficace et / ou rapide que mon script ?