[MySQL] une ou deux tables...

6 réponses

Auteur	Message
Rano \| Modérateur Inscrit le : 13/04/2005	# Le 30/01/2006 à 19:45 Salut Si jamais vous avez déjà testé pour savoir lequel est le plus efficace en rapport rapidité / ressouces consommées. J'ai une table de 500.000 enregistrements. Elle est très sollicitée et les requetes dessus sont faite par coup de 200 à 1000 à la suite. Il faut moins d'une seconde pour que toutes les requetes soient traitées. La table est très peu mise à jour, il n'y a quasiment que des SELECT. Bon maintenant, je dois ajouter une version UK au site. A votre avis, je rajoute un index à cette table et fait passer donc le tout à environ 1.000.000 d'enregistrements ou je duplique la table pour en avoir deux de 500.000 ? Au niveau du code, se sera plus simple si le tout est dans une même table, ce qui me permettrait de faire mon developpeur "faignillant " (oui oui, c'est comme ca), mais si vous avez une expérience qui montre clairement qu'avec ce nombre d'enregistrement ca commence à bien ralentir je diviserai en deux tables. Merci de partager vos expériences PS : Le lien c'est juste pour voir quand Google l'aura ajouté à son dictionnaire Chambres d'hote tavel Séjours en provence Forum mariage
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 30/01/2006 à 20:08 Ton risque c'est de voir s'alonger la liste de smots et donc de voir augmenter le nombre d'enregistrements deux fois plus vite Peut etre que tu devrais te tourner vers les tables "HEAP" de MySQL, elles sont TRES efficaces en terme de performance, mais limités par certains aspects (pas de type BLOB ou TEXT, pas de sauvegarde lorsque le serveur est coupé). Par contre, ca te rajoute une couche de gestion, avoir une table de sauvegarde du contenu, et tout mettre dans la table HEAP pour travailler dessus. Perso, je pencherais pour plusieurs tables HEAP, une par langue, et une seule table de stockage des infos (de toute facon, elle sera peu utilisée, seulement a chaque démarrage et mise a jour). Voila pour ma petite contribution
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 30/01/2006 à 21:40 Une autre solution, depuis MySQL 5 : le partionnement. Cela te permet d'avoir une seule table et donc tu as tous les avantages qui y sont liés ; sauf que physiquement MySQL créer une zone de stockage pour chaque langue, et donc les requetes pour une seule langue ne seront pas pénalisées d'un point de vue perf. Telaxo : si tu fous une table d'un million d'enregistrement en HEAP, je ne veux pas avoir à gèrer ton serveur MySQL moi daevel : infogérance et conseil \|\| moi
erwinol \| Erwin Membre Inscrit le : 09/05/2005	# Le 30/01/2006 à 22:00 Bool a dit : Telaxo : si tu fous une table d'un million d'enregistrement en HEAP, je ne veux pas avoir à gèrer ton serveur MySQL moi Ouais j'allais le dire ... tu peux pas mettre autant en mémoire
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 30/01/2006 à 22:00 Ok, merci pour ces réponses. Le heap, je vais éviter aussi Je avis aller voir le partitionnement. Chambres d'hote tavel Séjours en provence Forum mariage
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 31/01/2006 à 00:21 ca depends des donnees, mais si c'est une liste de mots cles, ca pose pas de souci. Par exemple, j'ai une table de 250 000 mails qui prend 25 Mo, si ton serveur SQL a pas ca de libre, c'est la deche
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 31/01/2006 à 09:17 bah perso meme avec 2Go de mémoire sur le serveur, cette mémoire est utilisée : sinon c'est que ton serveur est mal configuré. Les 25Mo en "rabe", je préfère les utiliser pour les caches internes de MySQL. Si lui juge pertinant de charger intégralement cette table en mémoire, il le fera. Et d'un autre coté s'il a besoin de mémoire ailleurs, il déchargera cette table. Au moins le code coté client n'est pas plus complexe, et tu ne risques pas de saturer inutilement la machine. daevel : infogérance et conseil \|\| moi

Auteur

Message

Rano |
Modérateur

Inscrit le : 13/04/2005

# Le 30/01/2006 à 19:45

Salut

Si jamais vous avez déjà testé pour savoir lequel est le plus efficace en rapport rapidité / ressouces consommées.

J'ai une table de 500.000 enregistrements. Elle est très sollicitée et les requetes dessus sont faite par coup de 200 à 1000 à la suite.

Il faut moins d'une seconde pour que toutes les requetes soient traitées. La table est très peu mise à jour, il n'y a quasiment que des SELECT.

Bon maintenant, je dois ajouter une version UK au site. A votre avis, je rajoute un index à cette table et fait passer donc le tout à environ 1.000.000 d'enregistrements ou je duplique la table pour en avoir deux de 500.000 ?

Au niveau du code, se sera plus simple si le tout est dans une même table, ce qui me permettrait de faire mon developpeur "faignillant " (oui oui, c'est comme ca), mais si vous avez une expérience qui montre clairement qu'avec ce nombre d'enregistrement ca commence à bien ralentir je diviserai en deux tables.

Merci de partager vos expériences

PS : Le lien c'est juste pour voir quand Google l'aura ajouté à son dictionnaire

Chambres d'hote tavel
Séjours en provence
Forum mariage

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 30/01/2006 à 20:08

Ton risque c'est de voir s'alonger la liste de smots et donc de voir augmenter le nombre d'enregistrements deux fois plus vite

Peut etre que tu devrais te tourner vers les tables "HEAP" de MySQL, elles sont TRES efficaces en terme de performance, mais limités par certains aspects (pas de type BLOB ou TEXT, pas de sauvegarde lorsque le serveur est coupé). Par contre, ca te rajoute une couche de gestion, avoir une table de sauvegarde du contenu, et tout mettre dans la table HEAP pour travailler dessus.

Perso, je pencherais pour plusieurs tables HEAP, une par langue, et une seule table de stockage des infos (de toute facon, elle sera peu utilisée, seulement a chaque démarrage et mise a jour).

Voila pour ma petite contribution

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 30/01/2006 à 21:40

Une autre solution, depuis MySQL 5 : le partionnement. Cela te permet d'avoir une seule table et donc tu as tous les avantages qui y sont liés ; sauf que physiquement MySQL créer une zone de stockage pour chaque langue, et donc les requetes pour une seule langue ne seront pas pénalisées d'un point de vue perf.

Telaxo : si tu fous une table d'un million d'enregistrement en HEAP, je ne veux pas avoir à gèrer ton serveur MySQL moi

daevel : infogérance et conseil || moi

erwinol | Erwin
Membre

Inscrit le : 09/05/2005

# Le 30/01/2006 à 22:00

Bool a dit :
Telaxo : si tu fous une table d'un million d'enregistrement en HEAP, je ne veux pas avoir à gèrer ton serveur MySQL moi

Ouais j'allais le dire ... tu peux pas mettre autant en mémoire

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 30/01/2006 à 22:00

Ok, merci pour ces réponses. Le heap, je vais éviter aussi
Je avis aller voir le partitionnement.

Chambres d'hote tavel
Séjours en provence
Forum mariage

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 31/01/2006 à 00:21

ca depends des donnees, mais si c'est une liste de mots cles, ca pose pas de souci.

Par exemple, j'ai une table de 250 000 mails qui prend 25 Mo, si ton serveur SQL a pas ca de libre, c'est la deche

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 31/01/2006 à 09:17

bah perso meme avec 2Go de mémoire sur le serveur, cette mémoire est utilisée : sinon c'est que ton serveur est mal configuré.
Les 25Mo en "rabe", je préfère les utiliser pour les caches internes de MySQL. Si lui juge pertinant de charger intégralement cette table en mémoire, il le fera. Et d'un autre coté s'il a besoin de mémoire ailleurs, il déchargera cette table.
Au moins le code coté client n'est pas plus complexe, et tu ne risques pas de saturer inutilement la machine.

daevel : infogérance et conseil || moi

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.