Identifiez-vous Devenir membre

Rechercher

Partionnement Mysql

13 réponses

Auteur	Message
cerise Membre Inscrit le : 31/10/2008	# Le 21/04/2009 à 10:24 Bonjour, est-il possible, sous Mysql 5.1, de faire un partitionnement basé sur la colonne pseudo d'une table, par groupe d'intervalles de lettre. je m'explique : plutôt que d'avoir X tables pour répartir les données comme par exemple une table pour les pseudos de A à E, une pour les pseudo de F à K etc, l'idée serait d'avoir une seule table afin d'éviter les jointures et d'utiliser le partitionnement que propose mysql à la place. Seulement, je n'ai rien trouvé de probant sur la question : tous les exemples que j'ai vu se font sur des partitionnements par date ou valeurs numériques... Une idée ? CeriseClub
Bool Modérateur Inscrit le : 09/05/2005	# Le 21/04/2009 à 11:31 Hello, c'est pourtant un mode de fonctionnement classique du partitionnement, qu'est ce qui te pose problème ? Google is watching you.
cerise Membre Inscrit le : 31/10/2008	# Le 21/04/2009 à 11:48 ok Bool, En fait je découvre cette fonction de partitionnement qui est nouvelle sous mysql5.1 alors qu'on tournait avant sur la version 5.0 Du coup, j'envisage de partitionner une seule table qui contient tous les membres plutôt que d'utiliser plusieurs tables en jointure pour répartir les membres en fonction de leur pseudo. Mysql5.1 permet un partitionnement par range, list, hash ou key. Je me demande comment appliquer ce partitionnement à la table `membres` afin d'avoir des partitions par intervalles A-E / F-K etc sachant que tout ce que j'ai trouvé sur les intervalles s'appliquent soit à des dates, soit à des valeurs numériques comme des ID par exemple CeriseClub
erwinol Membre Inscrit le : 09/05/2005	# Le 21/04/2009 à 12:02 Je ne connaissais pas ce principe de partitionnement de tables, je vais regarder ça de plus près avant que mes tables explosent Le cul ça paie pas, le mobile ça paie pas, l'affiliation ça paie pas, le parrainage ça paie pas ... comment se fait-il que je gagne bien ma vie ?
cerise Membre Inscrit le : 31/10/2008	# Le 21/04/2009 à 12:12 http://dev.mysql.com/doc/refman/5.1/en/partitionin... CeriseClub
Bool Modérateur Inscrit le : 09/05/2005	# Le 21/04/2009 à 13:47 cerise : pour des chaines il me semble plus simple de mettre un partitionnement par hash, et d'indiquer uniquement le nombre de partitions que tu veux. Sinon tu peux utiliser une fonction "utilisateur" il me semble, et dans ce cas tu renverrais le caractère ascii de la première lettre, puis ferait un partitionnement par range classique. Google is watching you.
cerise Membre Inscrit le : 31/10/2008	# Le 21/04/2009 à 14:20 ouais... C'est un peu la réponse que j'espérais pas lire Par hash, en fait tu laisses mysql gérer à sa sauce l'optimisation du partitionnement. bon en tout cas, le mieux est de faire des tests et de comparer les temps d'exécution des requêtes, on verra bien si le hash ne découpe pas ma table ... à la hache CeriseClub
MathieuC Modérateur Inscrit le : 15/07/2005	# Le 21/04/2009 à 15:40 Perso je comprends pas trop vos inquietudes, MySQL ne rame pas sur les grosses tables a moins d'avoir plusieurs dizaines de millions d'enregistrements. Nous on utilise quotidiennement des tables avec 5 millions d'enregistrement qui font 500 Mo chacunes, et avec les index qui vont bien, tout est parfaitement fluide (utilisation quotidienne = + de 10 000 insert / jours et + de 20 000 select) Meme chose, notre table de 1 million de membres (100 Mo la table) ne pose aucun probleme de perf. Notre base de statistiques la plus grosse fait 54 millions d'enregistrement pour 3.5 Go, et les requetes avec les index qui vont bien sont encore tres rapides (en dessous de la seconde). Donc a priori, le partitionnement personne n'en a besoin pour un site web classique (apres, c'est sur qu'il faut avoir optimise sa BDD, mais c'est la moindre des choses quand meme).
tonguide Modérateur Inscrit le : 09/05/2005	# Le 21/04/2009 à 15:43 Idem, je ne comprends pas l'intérêt pour les mêmes raisons.
Bool Modérateur Inscrit le : 09/05/2005	# Le 21/04/2009 à 16:01 J'utilise ça sur deux tables de plus de 10Go pour ma part. La machine n'ayant "que" 8Go de mémoire, le partitionnement est quasi indispensable. Edit, pour être précis : table history : 198 Millions de lignes, 18Go. table history_unit : 280 Millions de lignes, 27Go. (merci Zabbix) Maintenant tu affiches un "écran" de Zabbix qui affiche 16 graphiques, chacun correspondant à 1 select dans une de ces deux tables. Et évidement, Zabbix rafraîchit la page toutes les 30 secondes. Je ne dis pas que c'est un besoin courant, mais le partitionnement rend bien des services. (Message édité le 21-04-2009 à 16h09 par Bool) Google is watching you.
cerise Membre Inscrit le : 31/10/2008	# Le 21/04/2009 à 16:15 Si je posais la question, c'est que vraiment il y a une bonne raison et que je m'amuserai pas à ça pour le plaisir ou sur des petites tables, même de quelques gigas... Avoir une table de 54 millions d'enregistrements avec 2 champs (Je dis 2 vu le poids de seulement 3,5 gigas...) c'est pas pareil que la même chose avec 20 champs dont des blob et des text... L'intêret n'est pas pour un site web mais pour un backoffice utilisé par des gens qui en ont marre que ça rame. En plus grosse connerie, il y a une appli en flash dessus pour avoir des stats qui mettent plusieurs secondes à générer les résultats. Bref, ce n'est pas super productif... Enfin, il ne s'agit malheureusement pas de 5 tables de quelques centaines de mega mais de grosses tables bien lourdes de plusieurs gigas... qui manque de pot, ont été mal construites à la base (au lieu de répartir les différentes données sur plusieurs tables, toutes les données sont dans une seule et unique table avec plus de 20 champs donc un tas de truc qui servent qu'une fois par an...) et une mauvaise définition de l'auto increment ce qui fait que chaque membre peut avoir à lui tout seul beaucoup de lignes dans la table. La solution qui a été trouvée dans un premier temps a été de séparer les tables en fonction des pseudos des membres qui sont actuellement répartis sur 5 tables différentes. Mais ça ne résout pas le problème lors des jointures Comme il n'est pas possible actuellement de restructurer la base pour une question de temps, je suis bien obligé de faire avec et de trouver la meilleure solution rapidement. Donc j'ai vu cette fonction de partitionnement proposée par mysql 5.1, et je me suis ouais, pourquoi pas essayer. Maintenant si vous me dites qu'il y a pas d'intérêt, j'exige que les tables soient correctement structurées avant de faire quoi que ce soit ! CeriseClub
Bool Modérateur Inscrit le : 09/05/2005	# Le 21/04/2009 à 16:22 cerise : sur mon Zabbix c'est vraiment le jour et la nuit, et pourtant le modèle de données est pas trop mal fait. Ces 2 tables sont scindées en 100 partitions chacune (avec 10 partitions je n'avais que peu de gain). Google is watching you.
MathieuC Modérateur Inscrit le : 15/07/2005	# Le 21/04/2009 à 17:19 cerise> la table contient une dizaine de champs, mais tous numeriques quasiement, tout a ete optimise a la base, donc ca marche tres bien. Dans ton cas effectivement, ton design a apparemment ete tres mal fait, ne serait-ce que stocker des blobs dans mysql... En cherchant une rustine, tu ne fais que repousser ton probleme, d'ici quelques temps, il deviendra forcement insoluble, meme avec le partitionnement. A terme il faudra bien que tu remette a plat le design de ton backoffice et que tu migres sur une base optimisee, meme si ca prend du temps, ca reste la meilleure solution a terme.
cerise Membre Inscrit le : 31/10/2008	# Le 21/04/2009 à 17:25 ben oui c'est ça le probleme, si seulement c'était des champs numériques... J'ai absolument pas le temps de me plonger dans un code et de tout refaire en ce moment, donc comme tu dis je cherche une rustine, même temporaire, mais si ça peut faire gagner du temps sur les requêtes, ça sera déjà ça, avant de reprendre un développement complet de la structure plus tard, et si mon client est d'accord bien sûr parce que bien sûr il y aura un coût CeriseClub

Auteur

Message

cerise
Membre

Inscrit le : 31/10/2008

# Le 21/04/2009 à 10:24

Bonjour,

est-il possible, sous Mysql 5.1, de faire un partitionnement basé sur la colonne pseudo d'une table, par groupe d'intervalles de lettre.

je m'explique : plutôt que d'avoir X tables pour répartir les données comme par exemple une table pour les pseudos de A à E, une pour les pseudo de F à K etc, l'idée serait d'avoir une seule table afin d'éviter les jointures et d'utiliser le partitionnement que propose mysql à la place.
Seulement, je n'ai rien trouvé de probant sur la question : tous les exemples que j'ai vu se font sur des partitionnements par date ou valeurs numériques...

Une idée ?

CeriseClub

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 21/04/2009 à 11:31

Hello,

c'est pourtant un mode de fonctionnement classique du partitionnement, qu'est ce qui te pose problème ?

Google is watching you.

cerise
Membre

Inscrit le : 31/10/2008

# Le 21/04/2009 à 11:48

ok Bool,
En fait je découvre cette fonction de partitionnement qui est nouvelle sous mysql5.1 alors qu'on tournait avant sur la version 5.0
Du coup, j'envisage de partitionner une seule table qui contient tous les membres plutôt que d'utiliser plusieurs tables en jointure pour répartir les membres en fonction de leur pseudo.

Mysql5.1 permet un partitionnement par range, list, hash ou key. Je me demande comment appliquer ce partitionnement à la table `membres` afin d'avoir des partitions par intervalles A-E / F-K etc sachant que tout ce que j'ai trouvé sur les intervalles s'appliquent soit à des dates, soit à des valeurs numériques comme des ID par exemple

CeriseClub

erwinol
Membre

Inscrit le : 09/05/2005

# Le 21/04/2009 à 12:02

Je ne connaissais pas ce principe de partitionnement de tables, je vais regarder ça de plus près avant que mes tables explosent

Le cul ça paie pas, le mobile ça paie pas, l'affiliation ça paie pas, le parrainage ça paie pas ... comment se fait-il que je gagne bien ma vie ?

cerise
Membre

Inscrit le : 31/10/2008

# Le 21/04/2009 à 12:12

http://dev.mysql.com/doc/refman/5.1/en/partitionin...

CeriseClub

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 21/04/2009 à 13:47

cerise : pour des chaines il me semble plus simple de mettre un partitionnement par hash, et d'indiquer uniquement le nombre de partitions que tu veux. Sinon tu peux utiliser une fonction "utilisateur" il me semble, et dans ce cas tu renverrais le caractère ascii de la première lettre, puis ferait un partitionnement par range classique.

Google is watching you.

cerise
Membre

Inscrit le : 31/10/2008

# Le 21/04/2009 à 14:20

ouais... C'est un peu la réponse que j'espérais pas lire
Par hash, en fait tu laisses mysql gérer à sa sauce l'optimisation du partitionnement. bon en tout cas, le mieux est de faire des tests et de comparer les temps d'exécution des requêtes, on verra bien si le hash ne découpe pas ma table ... à la hache

CeriseClub

MathieuC
Modérateur

Inscrit le : 15/07/2005

# Le 21/04/2009 à 15:40

Perso je comprends pas trop vos inquietudes, MySQL ne rame pas sur les grosses tables a moins d'avoir plusieurs dizaines de millions d'enregistrements.

Nous on utilise quotidiennement des tables avec 5 millions d'enregistrement qui font 500 Mo chacunes, et avec les index qui vont bien, tout est parfaitement fluide (utilisation quotidienne = + de 10 000 insert / jours et + de 20 000 select)

Meme chose, notre table de 1 million de membres (100 Mo la table) ne pose aucun probleme de perf.
Notre base de statistiques la plus grosse fait 54 millions d'enregistrement pour 3.5 Go, et les requetes avec les index qui vont bien sont encore tres rapides (en dessous de la seconde).

Donc a priori, le partitionnement personne n'en a besoin pour un site web classique (apres, c'est sur qu'il faut avoir optimise sa BDD, mais c'est la moindre des choses quand meme).

tonguide
Modérateur

Inscrit le : 09/05/2005

# Le 21/04/2009 à 15:43

Idem, je ne comprends pas l'intérêt pour les mêmes raisons.

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 21/04/2009 à 16:01

J'utilise ça sur deux tables de plus de 10Go pour ma part. La machine n'ayant "que" 8Go de mémoire, le partitionnement est quasi indispensable.

Edit, pour être précis :
table history : 198 Millions de lignes, 18Go.
table history_unit : 280 Millions de lignes, 27Go.
(merci Zabbix)

Maintenant tu affiches un "écran" de Zabbix qui affiche 16 graphiques, chacun correspondant à 1 select dans une de ces deux tables. Et évidement, Zabbix rafraîchit la page toutes les 30 secondes.

Je ne dis pas que c'est un besoin courant, mais le partitionnement rend bien des services.

(Message édité le 21-04-2009 à 16h09 par Bool)

Google is watching you.

cerise
Membre

Inscrit le : 31/10/2008

# Le 21/04/2009 à 16:15

Si je posais la question, c'est que vraiment il y a une bonne raison et que je m'amuserai pas à ça pour le plaisir ou sur des petites tables, même de quelques gigas...
Avoir une table de 54 millions d'enregistrements avec 2 champs (Je dis 2 vu le poids de seulement 3,5 gigas...) c'est pas pareil que la même chose avec 20 champs dont des blob et des text...

L'intêret n'est pas pour un site web mais pour un backoffice utilisé par des gens qui en ont marre que ça rame. En plus grosse connerie, il y a une appli en flash dessus pour avoir des stats qui mettent plusieurs secondes à générer les résultats. Bref, ce n'est pas super productif...
Enfin, il ne s'agit malheureusement pas de 5 tables de quelques centaines de mega mais de grosses tables bien lourdes de plusieurs gigas... qui manque de pot, ont été mal construites à la base (au lieu de répartir les différentes données sur plusieurs tables, toutes les données sont dans une seule et unique table avec plus de 20 champs donc un tas de truc qui servent qu'une fois par an...) et une mauvaise définition de l'auto increment ce qui fait que chaque membre peut avoir à lui tout seul beaucoup de lignes dans la table.

La solution qui a été trouvée dans un premier temps a été de séparer les tables en fonction des pseudos des membres qui sont actuellement répartis sur 5 tables différentes. Mais ça ne résout pas le problème lors des jointures

Comme il n'est pas possible actuellement de restructurer la base pour une question de temps, je suis bien obligé de faire avec et de trouver la meilleure solution rapidement. Donc j'ai vu cette fonction de partitionnement proposée par mysql 5.1, et je me suis ouais, pourquoi pas essayer.
Maintenant si vous me dites qu'il y a pas d'intérêt, j'exige que les tables soient correctement structurées avant de faire quoi que ce soit !

CeriseClub

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 21/04/2009 à 16:22

cerise : sur mon Zabbix c'est vraiment le jour et la nuit, et pourtant le modèle de données est pas trop mal fait. Ces 2 tables sont scindées en 100 partitions chacune (avec 10 partitions je n'avais que peu de gain).

Google is watching you.

MathieuC
Modérateur

Inscrit le : 15/07/2005

# Le 21/04/2009 à 17:19

cerise> la table contient une dizaine de champs, mais tous numeriques quasiement, tout a ete optimise a la base, donc ca marche tres bien.

Dans ton cas effectivement, ton design a apparemment ete tres mal fait, ne serait-ce que stocker des blobs dans mysql...

En cherchant une rustine, tu ne fais que repousser ton probleme, d'ici quelques temps, il deviendra forcement insoluble, meme avec le partitionnement. A terme il faudra bien que tu remette a plat le design de ton backoffice et que tu migres sur une base optimisee, meme si ca prend du temps, ca reste la meilleure solution a terme.

cerise
Membre

Inscrit le : 31/10/2008

# Le 21/04/2009 à 17:25

ben oui c'est ça le probleme, si seulement c'était des champs numériques... J'ai absolument pas le temps de me plonger dans un code et de tout refaire en ce moment, donc comme tu dis je cherche une rustine, même temporaire, mais si ça peut faire gagner du temps sur les requêtes, ça sera déjà ça, avant de reprendre un développement complet de la structure plus tard, et si mon client est d'accord bien sûr parce que bien sûr il y aura un coût

CeriseClub

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.