Bonjour,
 
Si je viens vous demander conseil avant de me lancer c'est que je dois travailler sur des tables assez grandes et qu'il va falloir faire quelque chose de propre sous peine d'avoir une page qui soit longue a générer.
 
Je vous explique la situation:
J'ai une liste d'utilisateur (environ 15000) qui chacun peuvent participer a une ou plusieurs activités parmi 50 proposées. La participation a ces activités permet a chacun de gagner des points et les résultats sont affichées sur les sites respectifs de chaque activités. Mon role la dedans c'est de faire un site de classement des utilisateurs en fonction de leurs points. Les mises a jour sont faites tous les jours a minuit. Voila pourquoi la base de données grossie rapidemment (environ 400.000 nouvelles lignes par jour).
 
Ce que je souhaite faire:
Je voudrais faire une page pour chaque utilisateur avec l'historique des points récoltés chaque mois avec le total et le detail pour chaque activités.
 
Mon problème:
Il arrive que certaines mises a jour ne se fasses pas pour diverses raisons (panne internet, coupure d'electricite, panne ou saturation des serveurs hebergeant les sites des activités...) et si ca tombe sur la mise a jour du 1er jour du mois (et c'est courant, presque tous les jours il manque au moins un serveur a l'appel) ca me fausse tout mes statistiques.
 
Comment le résoudre?
1- lors de la mise a jour détecter les activités qui ne se sont pas mises a jour et rajouter les résultats des stats a partir du jour précedent. Cette solution correspond a "prévenir" donc être sur que je n'ai pas de "trous" dans la BDD. l'avantage c'est que par la suite je peux faire des requetes SQL simples (sans JOIN) car je suis sur a 99% que j'ai toutes les valeur dans ma BDD. Le 1% c'est le cas si c'est mon serveur qui est en panne lors de la mise a jour et la j'aurais des bugs.
2- lors de la création de la page avec la recap mois par mois détecter les mises a jour manquantes et trouver les dernieres valeurs disponibles (le jour precedent par exemple). Cette solution c'est plutôt "guerir" vu qu'elle consiste a detecter les "trous" et a les boucher. A priori le résultat est garanti a 100% mais j'ai peur que dans ce cas la page soit vraiment lourde du fait de sa complexité.
3-...    
 
 
Est ce que vous voyez d'autres solutions? Laquelle vous parrait la meilleure?
 
Merci pour vos conceils

et pourquoi ne pas utiliser, sur un 2nd serveur, des possibilités de réplication/clustering ? MySQL propose ça justement. en gros dès qu'il y a une activité sur le serveur 1, elle est répliquée sur le 2.

Pour regler le probleme des 1% dont j'ai parlé, c'est a dire si mon serveur tombe en panne?

Salut,
 
1) Il y a un truc que je ne comprends pas : tu n'as vraiment aucun log qui permet de savoir ce qui a été fait et ce qui manque?
C'est quand même la base quand on veut mettre en place un système de reprise après incident.
En fait, ce que je dis, ça correspond en gros à ton 1).
 
2) Pour ton 1% Ca n'est pas après coup qu'il faut jouer au devin pour savoir si oui ou non le serveur n'était pas en panne, mais aux différents programmes de détecter les pertes de connections et y remédier soit en loggant les problèmes (et en prévenant l'utilisateur) soit en passant sur un autre serveur sql.
 
3) Quand vous faites la mise à jour mensuelle, vous n'avez pas pensé à utiliser les transactions? C'est quand même très utile pour éviter les conneries du genre "ça a planté alors on a que 11 catégories sur 12 qui se sont mises à jours" ou bien "la table X est OK mais la table Y a encore les données du mois dernier".
 
4) comme dit NewsletTux, une réplication circulaire avec mysql (chaque serveur applique les mises à jours que les autres ont reçu) limite grandement le 1% de chance de "mais le serveur il a planté". A noter qu'il faut penser à bien définir le auto_increment_increment (et autres éléments liés) pour éviter les collisions d'autoincrémentation.
C'est le point le plus rapide à mettre en place mais ça nécessite d'arriver à détecter les problèmes de connexion et à choisir le bon serveur en conséquence. A noter qu'avec ce système on ne peut pas se baser directement sur l'ordre numérique des colonnes autoincrémenté pour savoir dans quelle ordre les données ont été inséré.
 
 
 
Voilà donc à mes yeux les trucs à faire pour avoir un bon système. Reste à voir si vous aurez le temps de faire bien les choses ou si vous allez choisir des bidouilles par ce que "dans 99% du temps tout va bien".

Salut Omega2,
 
1) Si j'ai des logs pour chaque mise a jour pour savoir ce qui a marché et ce qui ne l'a pas. Ce n'est pas un soucis en soi.
 
2) Le 1% ne me préoccupe pas plus que ca car c'est juste un site de stats entre potes, on assure pas la sécurité nationale non plus Enfin disons que c'est secondaire etant donné que j'ai a cote le gros 99% a regler
 
Ce qui me préoccupe c'est le gros 99% des pannes qui survient et qui sont les pannes des serveurs distant et qui font que les mises a jour ne sont pas completes. Et la un serveur redondant ne changera rien si le serveur distant que j'interroge est dans les choux.
 
Le soucis c'est quelle approche je dois avoir avec ma base de données. Dois-je traiter les valeurs manquantes dans la mise a jour ou bien opter pour un post-traitement lorsque la page est consultées par l'utilisateur?

Salut IvanleFou,
 
Visiblement il me manquait certaines informations et j'en ai mal comprises d'autres ce qui fait que j'ai fait des suppositions erronées.
 
Pour les 99% et 1% dont tu parlais je pensais que tu parlais de 99% de cas qui marchent et 1% d'erreurs, toutes dû à des pannes serveur. D'après ce que tu as posté hier, ça n'est pas le cas.
 
Vu que tu as des log qui te permettent de savoir ce qui n'a pas marché et que ton problème principal c'est les cas où les serveurs distants n'ont pas fonctionné, vu aussi que tu ne considères pas ton système comme critique et que tu peux tolérer une petite marge d'erreur, alors là solution la plus simple à mon avis serait de mettre en place un système de rappel pour les serveurs qui sont hors ligne.
Par système de rappel, j'entend de retenter toutes les x minutes (15 ou 30 par exemple) une connexion avec tous les serveurs qui n'ont pas répondus le coup précédant. Ce délais permet de ne pas saturer les réseaux et de ne pas faire fondre son quotas mensuel tout en gardant des statistiques les plus fiables possible.
 
Faire comme ça évite de perdre les 24h de statistiques si un serveur a redémarré au mauvais moment. Ca permet aussi d'éviter d'avoir une page trop lourde pour le visiteur vu que ce traitement n'est pas fait quand on demande une page du site.
Par contre il faut pouvoir indiquer "statistiques temporaires" pour les serveurs qui n'ont pas répondus et dupliquer les données de la veille en notant bien que ça ne sont pas les statistiques définitive. C'est un peu comme pour les tournois de foot quand un match a été décalé.
 
 
PS pour plus tard : Quand tu te pencheras sur la réplication mysql, que ça soit pour plus de fiabilité ou pour régler des problèmes de vitesse, tu pourras aussi regarder "mysql proxy". C'est un programme qui se place entre le site web (ou tout autre logiciel qui fait appel à la base de donnée) et le serveur de bas de donnée et que les programmes appellent exactement comme un serveur mysql classique. Grâce à lui on peut faire du "load balancing" (faire s'exécuter une requête sur l'un ou l'autre des serveurs en fonction de la charge) , faire les requêtes de sélection sur un serveur et les sélection sur un autre, etc tout en ayant qu'une seule connexion à la base de donnée à gérer. A noter que ce programme gère aussi les pannes de serveur dans le sens ou si un serveur tombe, il enverra les demandes sur les autres.
A noter que je ne l'ai jamais utilisé, il a été rendus public après que j'ai quitté le boulot où je gérais des serveurs mysql.

Re,
 
Ho ho, merci pour ces infos elle vont bien m'aider   Finalement l'adage est toujours vérifié, il vaut mieux prévenir que guérir!
Ce "mysql proxy" semble très interessant, je ne manquerai pas de m'y intéresser. Merci pour l'infos.
 
Bon ben il me reste plus qu'a me mettre au boulot  
 
Merci en tout cas.