scinder grosse BDD ?

9 réponses

Auteur	Message
Geo 113 \| Modérateur Inscrit le : 04/05/2005	# Le 21/11/2009 à 11:53 Bonjour, je fais appel à ceux qui ont eu l'occasion de bosser sur des grosses tables mysql, de mon expérience, même indexée, une table avec quelques dizaines de millions d'enregistrement est beaucoup plus longue à réagir qu'une bdd avec quelques centaines de milliers de lignes. Comment procédez vous ? Est ce qu'il existe des astuces pour qu'une bdd ne deviennent pas trop lourde, sachant que plus les enregistrements sont anciens, moins ils seront accédés souvent. J'ai pensé à scinder les bdd (par exemple en expédiant les enregistrement de plus de xx jours dans une table archive) ou alors à répartir dans x tables les données, mais quid de l'accès. Que feriez vous, en comment pensez vous que font les facebook et les twitter, dont je serais étonné qu'ils stockent leur messages dans une unique table. Merci à vous de vos conseils, bon week end Cosmix Rendez imprévisible l'Economie; Mentez aux sondages
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 21/11/2009 à 12:10 Personnelement je m'arrangeai pour placer tout ce qui est utile en permanence (lors du listage) dans une table unique avec les index comme il faut. Et tout ce qui est contenu long (text/varchar élevé etc.) dans une seconde table. J'ai fonctionné comme ça pour un forum de 9 millions de messages, j'avais aucun lag. A mon avis, si tu veux une réponse adapté, il faudrait indiqué ce que contient ta table et comment tu t'en sers. C'est du cas par cas.
Akarys \| Thierry Membre Inscrit le : 19/01/2008	# Le 21/11/2009 à 12:19 Bonjour Geo, Sur mon ancien forum chaque sous-forum SF avait un SFA (Archives) associés. Je basculais automatiquement les discussions de SF vers SFA - si la discussion n'avait pas été modifiée depuis 1 mois, - et s'il restait au moins 50 discussions (2 pages) dans SF. Les discussions n'étaient pas lockées dans SFA et pouvaient revenir dans SF si quelqu'un y répondait à nouveau. C'était fait sur un forum Phorum et le basculement d'un (sous-)forum à un autre se faisait par un simple champs associée au 1er message de la discussion. Donc facile à gérer.
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 21/11/2009 à 12:20 avec mysql 5.1 : partitionnement sur la clef primaire ou partionnement manuelle : table_0 table_1 jusqu' a table_9 Suffit de séparer tes données avec ton id => prendre le dernier chiffre. Mais ce genre de partitionnement est très efficace pour les écritures et accès, mais si tu as besoin de faire un tri sur toute ta table > oubli ! Facebook ils ont grossomodo 900 maitres et 900 esclaves, et ils partitionnement leurs données en fonction des users, dans leur cas c'est vraiment simple & efficace ! (Par la dessus ils ont près de 2000 serveurs memcache pour leur tchat + mises en cache) @+ Jean-Philippe
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 21/11/2009 à 17:21 Ça dépend du type d'infos que tu récupères de ta base. Si par exemple tu fais beaucoup de GROUP BY tu peux peut être mettre en place des solutions type data warehouse. Ou plus simplement, si tes requêtes font souvent intervenir plusieurs tables, tu dénormalises de manière à supprimer toutes les jointures. Tu gagneras déjà beaucoup. Feu d'artifice Paris
Geo 113 \| Geoffrey Modérateur Inscrit le : 04/05/2005	# Le 21/11/2009 à 19:00 Ok merci beaucoup pour vos idées à tous, je vais étudier ce qui se prête le mieux. Les données sont assez hétérogènes, et de pas mal de tables, mais on va y arriver. Cosmix Rendez imprévisible l'Economie; Mentez aux sondages
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 21/11/2009 à 19:01 Geo > si tu est vraiment en difficulté je te conseille d'appeler mysql France et de prendre rendez vous avec un consultant, il vient directement chez toi, c'est assez rapide, un peu chère mais ils sont très très très fort ! @+ Jean-Philippe
Geo 113 \| Geoffrey Modérateur Inscrit le : 04/05/2005	# Le 22/11/2009 à 00:16 ok flush, j'avais déjà vu que tu avais fait appel à eux, je ne pensais pas qu'ils faisaient des missions ponctuelles. Cosmix Rendez imprévisible l'Economie; Mentez aux sondages
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 22/11/2009 à 13:17 Geo > c'est à la journée, entre 1 et 4 jours généralement. @+ Jean-Philippe
superfc \| Florent Membre Inscrit le : 01/07/2006	# Le 30/12/2009 à 00:38 Bonjour, Je voudrais juste réagir sur le départ de la discussion. Les index de base de données sont en B-Tree par défaut, donc la théorie c'est que la base de données fait une instruction de recherche en plus à chaque fois que taille de la base de données double. En réalité, c'est souvent moins efficace, mais pas tant que ça ( http://en.wikipedia.org/wiki/B-tree#Best_case_and_... ). Donc bien sur ça ralentit, mais le fait de scinder en différentes table fait perdre pas mal de confort pour l'accès aux données et le découpage par clé-primaire tue totalement les performances pour la plupart de requêtes de sélection. Tout ça pour dire : Moi je ne toucherai à rien si ce n'est les index. J'ai une table avec 31 millions d'enregistrements pour 3 ans de données sur du InnoDB. Et je n'ai aucun soucis de performance. Exemple sur une requête non mise en cache : SELECT * FROM `logs` WHERE `date` > '2008-06-01' AND `date` < '2008-09-01' AND `equipment_id`=20 LIMIT 100 : 100 total, Query took 0.0038 sec Souvent les soucis de performances sont dus à un défaut d'index (oui, ça semble bateau mais bon personne n'est à l'abri d'un oubli). Par exemple quand on recherche sur deux colonnes, souvent les gens s'imaginent qu'ils suffit de mettre un index sur chaque colonne. Mais il faut mettre un index sur les 2 colonnes (et souvent dans un ordre précis). On peut utiliser des coup de "EXPLAIN <requête>" pour voir si tout se passe bien comme on veut, et notamment si MySQL utilise le bon index : http://dev.mysql.com/doc/refman/5.0/en/using-expla... Par contre, bien sur d'optimiser ces index pour correspondre à tous les cas d'usages coûte un MAX d'espace. On doit prévoir tous les cas, et ne pas mettre des index "au cas où". Cette table pèse 2.1 Go et 2.4 Go d'index. Après bien sur ça ne reste rapide que si on exploite couramment qu'une petite partie de ces indexs (histoire qu'ils puissent tenir en RAM). Florent Clairambault - http://florent.clairambault.fr Gtalk : superfc@gmail.com

Auteur

Message

Inscrit le : 04/05/2005

# Le 21/11/2009 à 11:53

Bonjour,

je fais appel à ceux qui ont eu l'occasion de bosser sur des grosses tables mysql,
de mon expérience, même indexée, une table avec quelques dizaines de millions d'enregistrement est beaucoup plus longue à réagir qu'une bdd avec quelques centaines de milliers de lignes.

Comment procédez vous ? Est ce qu'il existe des astuces pour qu'une bdd ne deviennent pas trop lourde, sachant que plus les enregistrements sont anciens, moins ils seront accédés souvent.

J'ai pensé à scinder les bdd (par exemple en expédiant les enregistrement de plus de xx jours dans une table archive) ou alors à répartir dans x tables les données, mais quid de l'accès.

Que feriez vous, en comment pensez vous que font les facebook et les twitter, dont je serais étonné qu'ils stockent leur messages dans une unique table.

Merci à vous de vos conseils,

bon week end

Cosmix
Rendez imprévisible l'Economie; Mentez aux sondages

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 21/11/2009 à 12:10

Personnelement je m'arrangeai pour placer tout ce qui est utile en permanence (lors du listage) dans une table unique avec les index comme il faut. Et tout ce qui est contenu long (text/varchar élevé etc.) dans une seconde table. J'ai fonctionné comme ça pour un forum de 9 millions de messages, j'avais aucun lag.

A mon avis, si tu veux une réponse adapté, il faudrait indiqué ce que contient ta table et comment tu t'en sers. C'est du cas par cas.

Akarys | Thierry
Membre

Inscrit le : 19/01/2008

# Le 21/11/2009 à 12:19

Bonjour Geo,
Sur mon ancien forum chaque sous-forum SF avait un SFA (Archives) associés.
Je basculais automatiquement les discussions de SF vers SFA
- si la discussion n'avait pas été modifiée depuis 1 mois,
- et s'il restait au moins 50 discussions (2 pages) dans SF.
Les discussions n'étaient pas lockées dans SFA et pouvaient revenir dans SF si quelqu'un y répondait à nouveau.
C'était fait sur un forum Phorum et le basculement d'un (sous-)forum à un autre se faisait par un simple champs associée au 1er message de la discussion. Donc facile à gérer.

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 21/11/2009 à 12:20

avec mysql 5.1 : partitionnement sur la clef primaire ou partionnement manuelle :
table_0
table_1 jusqu' a table_9

Suffit de séparer tes données avec ton id => prendre le dernier chiffre.

Mais ce genre de partitionnement est très efficace pour les écritures et accès, mais si tu as besoin de faire un tri sur toute ta table > oubli !

Facebook ils ont grossomodo 900 maitres et 900 esclaves, et ils partitionnement leurs données en fonction des users, dans leur cas c'est vraiment simple & efficace !

(Par la dessus ils ont près de 2000 serveurs memcache pour leur tchat + mises en cache)

@+ Jean-Philippe

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 21/11/2009 à 17:21

Ça dépend du type d'infos que tu récupères de ta base. Si par exemple tu fais beaucoup de GROUP BY tu peux peut être mettre en place des solutions type data warehouse. Ou plus simplement, si tes requêtes font souvent intervenir plusieurs tables, tu dénormalises de manière à supprimer toutes les jointures. Tu gagneras déjà beaucoup.

Feu d'artifice Paris

Geo 113 | Geoffrey
Modérateur

Inscrit le : 04/05/2005

# Le 21/11/2009 à 19:00

Ok merci beaucoup pour vos idées à tous, je vais étudier ce qui se prête le mieux. Les données sont assez hétérogènes, et de pas mal de tables, mais on va y arriver.

Cosmix
Rendez imprévisible l'Economie; Mentez aux sondages

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 21/11/2009 à 19:01

Geo > si tu est vraiment en difficulté je te conseille d'appeler mysql France et de prendre rendez vous avec un consultant, il vient directement chez toi, c'est assez rapide, un peu chère mais ils sont très très très fort !

@+ Jean-Philippe

Geo 113 | Geoffrey
Modérateur

Inscrit le : 04/05/2005

# Le 22/11/2009 à 00:16

ok flush, j'avais déjà vu que tu avais fait appel à eux, je ne pensais pas qu'ils faisaient des missions ponctuelles.

Cosmix
Rendez imprévisible l'Economie; Mentez aux sondages

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 22/11/2009 à 13:17

Geo > c'est à la journée, entre 1 et 4 jours généralement.

@+ Jean-Philippe

superfc | Florent
Membre

Inscrit le : 01/07/2006

# Le 30/12/2009 à 00:38

Bonjour,

Je voudrais juste réagir sur le départ de la discussion. Les index de base de données sont en B-Tree par défaut, donc la théorie c'est que la base de données fait une instruction de recherche en plus à chaque fois que taille de la base de données double. En réalité, c'est souvent moins efficace, mais pas tant que ça ( http://en.wikipedia.org/wiki/B-tree#Best_case_and_... ).
Donc bien sur ça ralentit, mais le fait de scinder en différentes table fait perdre pas mal de confort pour l'accès aux données et le découpage par clé-primaire tue totalement les performances pour la plupart de requêtes de sélection.

Tout ça pour dire : Moi je ne toucherai à rien si ce n'est les index.

J'ai une table avec 31 millions d'enregistrements pour 3 ans de données sur du InnoDB. Et je n'ai aucun soucis de performance.
Exemple sur une requête non mise en cache :
SELECT * FROM `logs` WHERE `date` > '2008-06-01' AND `date` < '2008-09-01' AND `equipment_id`=20 LIMIT 100 : 100 total, Query took 0.0038 sec

Souvent les soucis de performances sont dus à un défaut d'index (oui, ça semble bateau mais bon personne n'est à l'abri d'un oubli). Par exemple quand on recherche sur deux colonnes, souvent les gens s'imaginent qu'ils suffit de mettre un index sur chaque colonne. Mais il faut mettre un index sur les 2 colonnes (et souvent dans un ordre précis).
On peut utiliser des coup de "EXPLAIN <requête>" pour voir si tout se passe bien comme on veut, et notamment si MySQL utilise le bon index : http://dev.mysql.com/doc/refman/5.0/en/using-expla...

Par contre, bien sur d'optimiser ces index pour correspondre à tous les cas d'usages coûte un MAX d'espace. On doit prévoir tous les cas, et ne pas mettre des index "au cas où". Cette table pèse 2.1 Go et 2.4 Go d'index. Après bien sur ça ne reste rapide que si on exploite couramment qu'une petite partie de ces indexs (histoire qu'ils puissent tenir en RAM).

Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com

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.