Discussion :

[AntoineGael]

Bonjour à tous,

Je suis en train de réfléchir à un modèle pour une DB (MySQL) et j'ignore s'il est viable.
Il s'agit de statistiques sur des joueurs de poker à des tables de jeux.
J'ai :
GAMES(game_id,variante, limite)
JOUEURS(joueur_id,pseudo)
STATS(joueur_id, game_id, stat1, stat2, ...)
Jusqu'ici aucun problème, je peux faire les calculs que je veux comme je veux.

Mais comme je vais avoir une quantité conséquente de stats (de l'ordre de centaines de millions de lignes), je pense à ce modèle :
- je stocke les GAMES et les JOUEURS dans une DB (DB1)
- je stocke les STATS dans une autre DB (DB2). Chaque table de cette DB a pour nom le game_id de chaque GAMES
Si j'ai GAMES(123,TEXAS,10) et GAMES(456,TEXAS,100), j'aurai les tables
123(joueur_id, stat1, stat2...)
et 456(joueur_id, stat1, stat2,...)
dans DB2

Avantage : je "disperse" mes données, je n'ai pas une table STATS unique et gigantesque.
Inconvénient : je veux faire la moyenne de la stat2 à travers les games 123 et 456 pour le joueur 1000. Donc quelque chose qui serait :
SELECT AVG(123.stat2,456.stat2) FROM 123,456 WHERE 123.joueur_id=1000 AND 456.joueur_id=1000
Sachant que l'idéal serait une requête qui arriverait à utiliser une jointure avec la table DB1.GAMES afin de trouver les bonnes tables dans DB2.

J'ai le sentiment que c'est impossible. Je me trompe ? Mon modèle est il inconséquent ? Y a t'il un modèle plus adapté ?


Merci pour votre aide
Antoine

[vmolines]

Modélisez de manière normalisée. Générez des lignes de test afin d'arriver à une volumétrie future et tester les performances.

Si ça passe tant mieux.

Sinon, vous pouvez palier aux problèmes de performance de plusieurs manières :

- Upgrade du serveur (cpu, mémoire, disque selon le facteur limitant)
- Partitionnement des tables logiques en plusieurs espaces physiques
- Changement de SGBD pour un qui permette plus de tuning
- Utilisation de vues matérialisées
- ...


Mais surtout, ne dénormalisez pas, ne créez pas plusieurs table logiques pour une même entité.

[AntoineGael]

Bonjour,

Merci de votre réponse. J'ai une question par rapport à celle-ci : en quoi est ce un problème de dénormalisé ? C'est pour une raison d'organisation ? (par exemple, si la structure change, je dois changer la structure de toutes les tables). Ou bien pour des raisons de performances ? (l'accès à de multiples tables est pénalisant ?).
Je suis tout de même inquiet à l'idée d'avoir toutes mes données dans une seule table. Combien même je peux tenter des upgrades, du tuning... Je préfère envisager un modèle moins "brutal" que le "tout dans une table". Maintenant, est ce possible... ?
Je n'ai aucune expérience en matière de quantités de données à l'échelle de centaines de millions.

Antoine

[vmolines]

L'utilisation d'un modèle non normalisé est une plaie à l'utilisation. Toutes les requêtes se complexifient et perdent de leur sens.

On pourrait comprendre le besoin de dénormaliser dans le cas où vous stockeriez de la redondance pour accélérer l'interrogation de données aggrégées. Mais ici vous voulez simplement faire un découpage logique qui n'apportera aucun gain de performance. Votre disque devra aller chercher autant de données que si elles étaient présente sur une même table.

[Antoun]

Quel est ton SGBD ? Prend-il en charge le partitionnement horizontal ?

[AntoineGael]

Bonjour Antoun,

Je crois que ta question ma fourni un bel élément de réponse ! :-)
C'est du MySQL 5.0.27, mais avec le partitionnement je pense upgrader vers la 5.1.23
Je viens de parcourir rapidement cet article :
http://krierjon.developpez.com/mysql/partitionnement/
Mais j'ai du mal à déterminer le meilleur partitionnement.
Je ré-expose mon problème avec cette nouvelle perspective...

J'ai une table de joueurs (quelques millions de lignes) :
joueurs(joueur_id PRIMARY KEY AUTOINCREMENT, pseudo VARCHAR(64))
et une tables de jeux (entre 500 000 et 1 million de lignes) :
jeux(jeu_id PRIMARY KEY AUTOINCREMENT, variante INT, prix INT).

Dans une table de stats, je stocke pour chaque joueur ses statistiques sur les différents jeux auquel il a joué :
stats(joueur_id, jeu_id, stat1 INT, stat2 INT)
J'ai donc indexé les champs "joueur_id" et "jeu_id" de ma table "stats".

Voici typiquement le genre de requêtes que je serai amené à produire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
SELECT 
  SUM(stats.stat1),
  SUM(stats.stat2) 
FROM 
  stats 
  INNER JOIN jeux ON (jeux.jeu_id=stats.jeu_id) 
WHERE 
  stats.joueur_id=1000 
 AND 
  ( jeux.variante=xxx AND (jeux.prix=0.10 OR jeux.prix=25) )

Vue la quantité de données (plus millions que multiplie entre 500 000 et 1 million), je crains pour les performances voire la robustesse de ma base de données. C'est pour cela que je voulais "découper" ma table en une multitude de tables. Solution plutôt agressive, je le reconnais.

Apparemment, le partitionnement horizontal résout totalement mon problème, de façon transparente. Au premier abord, il semblerait que le partitionnement par clef sur stats.jeu_id soit le plus adapté : je ne peux pas déterminer les critères les plus pertinents. Dans mon exemple il y a variante et prix, mais en réalité j'ai jusqu'à 7 critères (d'où la génération de plus de 500 000 lignes pour la table jeux). Donc, en partitionnant par clef, je laisse MySQL faire au mieux.

Mon raisonnement est il correct ?

Merci encore pour votre aide

Antoine