Discussion :

[John_attend]

Bonjour à toutes et à tous,

Je viens tout juste de m'inscrire sur les forums de Developpez.com, site sur lequel je consulte régulièrement les nombreux articles

Mon premier message concernera donc l'optimisation d'une table MySQL (autrement que par les INDEX ou autres méthodes traditionnelles).


Contexte : Pour les sites ayant de très grosses bases de données de membres (par exemple 1,000,000 de membres actifs), il parait évident de diviser ces membres en plusieurs tables (ou bases).

Et c'est là que ma question intervient, pour moi, il y a deux solutions possibles :

• Créer, de manière automatique ou manuelle, plusieurs tables membres_1, membres_2, membres_3 dans lesquelles seraient répartis de manière équilibrée tous les membres.
  
• Créer plusieurs bases de données (base_1, base_2, base_3, ...) où chaque base contiendrait une table membres. Chaque base accueillant un nombre équilibré de membres.

Ces solutions se valent elles ou y en a t-il une mieux que l'autre ?

Pour faire simple, vaut il mieux une simple division des membres en plusieurs tables ou alors carrément une division en plusieurs bases ?

Je précise que j'utilise MySQL 5 sur un serveur dédié (je n'ai donc pas de limitation de taille par base).

Pouvez vous me donnez votre propre avis sur la question ?

Merci d'avance

[alain.couthures]

Plusieurs bases de données ou plusieurs tables, je ne vois pas la différence en terme de charge système (pas comme avec Oracle) mais il parait évident qu'il faut être dans la même base pour pouvoir faire des requêtes UNION sur les différentes tables.

Je suis curieux de voir si les performances seront meilleures car je miserais sans hésiter pour l'efficacité maximale avec une seule table puisque le parcours de l'index ne devrait pas être aussi sensible que cela. Avec plusieurs tables il faudra bien orienter entre les différentes tables...

Par contre, la taille du cache de MySQL est déterminante pour la rapidité : ça doit être réglable...

[Antoun]

Il ne s'agit pas de "division" mais de partitionnement. Je te conseille la lecture de l'article de Jonathan Krier à ce sujet http://krierjon.developpez.com/mysql/partitionnement.

Quant à la séparation en plusieurs bases, ça me semble complètement absurde.

[John_attend]

Merci de vos réponses. Ca suit dans un sens ce que je pensais

La partionnement par bases (pour reprendre alors la bonne expression) ne serait alors nécessaire que dans le cas où l'on aurait besoin de plusieurs serveurs pour héberger le contenu MySQL (et si l'on ne souhaite pas utiliser un cluster).

Je vais de ce pas lire l'article que tu m'as donné.

Merci

[alain.couthures]

Le partitionnement de table est fait pour que le SGBD n'ait pas à parcourir toute la table alors que la requête ne porte que sur un sous-ensemble.J'aime bien l'exemple où l'on partitionne selon le pays : rien ne sert de parcourir les enregistrements liés au Japon quand on veut faire des statistiques sur le France.