Bonjour, une question portant sur la meilleure stratégie du point de vue des performances :  
 
J'ai actuellement une table de plusieurs millions de lignes. Un champ de cette table permet de séparer ces données en plusieurs dizaines de catégories. On ne travaille sur les données principalement que par une catégorie à la fois (ou 2 par 2), mais rarement sur l'ensemble des catégories au cours d'une requête.
 
Il y aurait-il un gain de performance à mettre ces données dans des tables distinctes correspondant à chacune des catégories ?
Ca ferait donc quelques dizaines de tables contenant quelques centaines de milliers de lignes, VS une table de plusieurs millions de ligne.
 
Le gain de perf quand je travaillerai sur une seule catégorie vaudra-t-il la perte de perf quand je travaillerai sur l'ensemble des tables (pour travailler sur l'ensemble des catégories) ?
 
Bref, à votre avis, quel est la  meilleure stratégie ?

oui sauf si tu as des requêtes qui auraient besoin de taper dans plusieurs de ces tables en même temps.  
 
Sinon, le partitionnement est une bonne solution aussi

Moi je ne suis pas vraiment de cet avis. Pour moi ça reste à prouver. Si tu as des index correctement placés (notamment portant en premier lieux sur la catégorie, ordonné en cluster), et que tes paramètre de remplissage de la table sont corrects, tu n'auras aucune différence de performances entre une table de plusieurs millions de lignes ou une table de plusieurs centaine de milliers de lignes. Par contre, éviter un UNION ALL sur une centaine de tables, c'est quand même intéressant...

je suis d'accord avec toi MagicBuzz, mais mon collègue qui veut partitionner en plusieurs tables me dit qu'ainsi, l'index n'aura même pas à être intégralement parcouru, ce qui n'est pas faux.
 
D'autres avis ?

je pense que orafrance ne parlait pas de "partitionner en plusieurs tables" mais bien de partionner ta table. Et dans ton cas, un partionnement par liste me semble être une très bonne idée.
Tu travailles sur quel sgbd?

dans ce cas, tu as deux index.
 
mettons que tu as :
 
id (pk)
categorie
nom
etc...
 
 
tu as un premier index UNIQUE organisé en CLUSTER (car plus souvent utilisé, et permet de partitionner correctement les données) :
ix1 (categorie asc, id asc)
 
et un second index UNIQUE aussi (à compter que l'ID est bel et bien unique quelle que soit la catégorie)
ix2 (id asc)

 
la taille de l'index peut aussi être problèmatique... donc un index c'est bien mais ça a aussi ses limites

 
exactement, mais si le partitionnement n'est pas possible, la création de plusieurs tables peut aussi être une solution quand même

mouais.
 
m'enfin si le serveur n'arrive pas à se dépatouiller avec deux index uniques qui portent sur 1 et 2 champs, y'a un sérieux problème de perfs quelque-part, et on n'en est plus à se poser la question de tronçonner la table en rondelle (c'est du moins mon avis)
 
sinon, tu parles de "partitionnement". késako ?

tiens http://www.phpindex.com/index.php/ [...] ions-mysql c'est pas trop mal expliqué là ( pour mysql mais en gros c'est la même chose sur les autres sgbd)

ah ouais, ok.
c'est répartir les données sur plusieurs tablespace.
 
intéressant si on a une floppée de disques et qu'on n'est pas en raid.
pour un disque en RAID (comme très souvent), aucun intérêt donc, mise à part tout ralentir.
 
je pense surtout qu'il faut faire gaffe au "fill factor" dans ce cas, qui évite d'avoir un sérieux problème lorsqu'on insère une ligne dans une table organisée en cluster et qu'il n'y a plus de place
 
=> ce que le partitionning permet d'éviter sans se soucier du fill factor

pas seulement, c'est surtout répartir les données dans des entités physiques différentes.
 
Typiquement, tu partitionnes une table de 100 millions de lignes par partition de 100000 lignes te permettra de limiter les I/O. En effet, si le partitionnement est correct (s'entend, pas de sélection de plusieurs partitions) alors le SGBD traitera la table comme si elle n'avait que 100000 lignes et non 100 millions soit un gain de perf spectaculaire

merci pour vos réponses (j'utilise mysl).
 
Mais le partitionnement est efficace seulement si on ne tape jamais dans plusieurs tablespace en même temps non ?
Et il est inutile si tu n'as qu'une seule partition non ? Dans ce cas, diviser en plusieurs tables reste-t-il une bonne solution ?
 
Et finalement, si tu fais une utilisation "normale" de la table (c'est-à-dire taper n'importe où dans la table lors d'une requête), ça sert pas à grand chose de partitionner ou de faire plusieurs tables non ?

certes, il est évident qu'il faut faire un partitionnement (= plusieurs tables) logique c'est à dire en fonction d'un critère de sélection (pays, site, période comptable, etc...) et qui contiennent des ensembles disjoints