Discussion :

[hatembr]

Bonjour,

Je suis en train de réfléchir à la meilleure structure pour stocker le profil d'un membre sur un site de rencontres style meetic.

Le profil comportera une soixantaine de critères et donc là se pose le problème : j'hésite entre 3 possibilités :

1. stocker tous les champs ds la meme table "membre"
=> probleme car les recherches se feront sur une soixantaine de champs avec toutes les combinaisons possibles et imaginables, alors que les index ne peuvent contenir qu'un max de 16 champs.


2. eclater la table en plusieurs tables, chacune comportera un certain nombre de champs selon la catégorie de l'info (generalités, look, préférences ...)
=> probleme 1: les index comme pour le point 1 car certaines infos telles que les preferences depassent les 16 criteres, à moins d'eclater les tables à un deuxieme niveau (preferences1 et peferences2)
=> probleme 2: lourdeur au niveau des requetes à cause des jointures qui seront plusieures avec en plus d'autres tables annexes qui seront forcéement incluses ds les requetes


3. utiliser une structure générique du type (id_categorie, id_champ, valeur_champ, id_user) qui permettra de stocker les infos en vrac ds la meme table et qui sera indexé sur les 4 champs mais qui à terme risque de saturer la BD et le HD du serveur.


Voilà, je n'ai aucune idée sur les possibles performances de chaque méthode sur un grand nombre de membres stockés ds la BD, mais le choix doit être définitif, tout ce que je sais c'est que j'ai lu qqe part une interview du fondateur de meetic qui a expliqué qu'à un moment donné, ils ont du dénormaliser leurs BD et stocker des données redondantes afin d'optimiser les temps d'accès .

Est-ce que qqun peut me donner son avis là dessus ? quel est le meilleur choix à votre avis ?

Merci d'avance



PS: j'utilise MySQL4 sur mon serveur

[hatembr]

pas d'idées ??

[Antoun]

- tu peux toujours créer plusieurs index, chacun indexant de 1 à 16 colonnes hiérarchisées...

- l'intérêt d'un index est fonction de sa sélectivité ; par exemple, un index sur le sexe donnerait une sélectivité de 50% (si tes membres sont bien répartis) ; l'optimiseur MySQL trouverait que cette sélectivité est si faible qu'il n'utiliserait même pas l'index (je crois que le seuil par défaut est 33% ou 25%). De même, si tu indexes 10000 communes, mais que 80% de tes membres habitent à Paris, seules les requêtes des 20% de provinciaux seront améliorées par l'index.

- la solution 3/ te facilitera la tâche quand il faudra faire des requêtes du type "8 critères remplis sur 10", ou calculer un % de pertinence.

[hatembr]

merci d'avoir répondu antoun.

sur le plan pratique, il est clair que la solution 3 est la meilleure et la plus rapide à mettre en place également.
mais ce dont je me soucie le plus, c'est les performances du site et le temps de réponse aux recherches.
Est ce que le fait de créer plusieurs index peut s'évérer plus rapide que l'éclatement en plusieurs table et l'utilisation de jointures pour reconstituer le profil ?

[Antoun]

A priori, oui, ça évite des jointures. Dans la réalité... à tester.

[hatembr]

pour tester y a t il des outils connus pour faire des stress tests sur les BD ?

[hatembr]

finalement j'ai opté pour cette structure :

id_set int(11)
id_field int(11)
id_member int(11)
val varchar(100)
val2 varchar(100)

où la clé est composé de (id_set, id_field, id_member) avec :
id_set = représente l'ensemble des champ (look, préférences, personnalité...)
id_field = le critère (couleur des yeux, longueur des cheveux ... )
id_member = l'id du membre

Je vais tester cette config là et voir les perf, mais là je suis bloquéà case d'un petit truc qui était trop facile à implémenter avec l'ancienne version de la table comportant 73 champs :
il s'agit en fait de pouvoir calculer le % de ressemblance entre 2 profils dans la même requete à l'aide de CASE WHEN (champ = XXX) THEN 1 ELSE 0 END + CASE WHEN (champ2 = XXX) THEN 1 ELSE 0 END ....

y a-t-il un moyen de le faire avec cette nouvelle structure ?

[Antoun]

si je suis un homme châtain qui préfère les femmes rousses, comment cela se traduit-il dans ta structure ?

[hatembr]

si c'est une recherche classique ce sera du genre :

SELECT id_member FROM ma_table WHERE id_member != MON_ID AND id_set=ID_ENSEMBLE_CRITERES_DU_LOOK AND id_field=ID_CRITERE_COULEUR_CHEVEUX AND val='roux'


mais par contre ça bloque s'il faut calculer le % de ressemblance, ou je sommais des 1 ou des 0 selon le résultat du CASE et je divisais par 100.

en fin de compte, je pense que l'ancienne structure est plus adaptée, mais ça résultera en une dizaine de tables avec des index de plus de 3 champs et une tonne de jointure pour comparer les profils car je suis obligé d'éclater la table look en deux tables look1 et look2 et preferences en pref1 et pref2 etc.

[Antoun]

Normalement, c'est plus facile à faire dans la nouvelle structure, mais je ne comprends pas trop certains trucs... notamment ce qu'est que val2 par rapport à val, ni comment ton calcul fonctionnait avant, ni non plus ce que tu veux vraiment...

Pour faire avancer le schmilblick, je te propose la requête suivante qui calcule le nombre de points communs entre les membres 1 et 2 sur l'ensemble des critères, sans prendre en compte la val2 :

Code :

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

1
2
3
4
5
6
7
SELECT M1.id_member, M2.id_member,
  SUM(CASE WHEN M1.val = M2.VAL THEN 1 ELSE 0 END)
FROM ta_table M1
  INNER JOIN ta_table M2 ON M1.id_set = M2.id_set AND M1.id_field = M2.id_field
WHERE M1.id_member = 1
  AND M2.id_member = 2
GROUP BY M1.id_member, M2.id_member