Suggestions sur la façon de gérer les notes

Question

J'ai une question d'architecture avec laquelle je suis aux prises.

La conception du site aurait un système de karma/évaluation/points utilisateur assez similaire à la façon dont cela se fait ici sur stackoverflow. Des choses comme des commentaires, de nouveaux messages, etc. donneraient un coup de pouce aux évaluations d'un utilisateur. De même, des choses comme des votes sur certains contenus pourraient également donner un coup de pouce.

Ma question est de savoir comment cela pourrait être implémenté dans l'architecture. Ma première pensée est que je vais être intéressé à un moment donné de savoir exactement d'où viennent les points d'un utilisateur, donc avoir simplement un champ sous chaque utilisateur qui a été incrémenté ne fournirait pas les données dont j'ai besoin. Donc, mon modèle que j'ai dans ma tête qui donne un accès complet à ces données serait que chacun de ces événements (post, commentaire, upvote) soit enregistré et la note de l'utilisateur dérivée de ces logs. Le problème ici est que je sais que ce modèle ne s'adapte pas bien à long terme puisque le calcul de la note d'un utilisateur se transformerait en un cauchemar de requête SQL.

Donc, il y a une sorte de terrain d'entente ici. Quelqu'un a eu une suggestion sur la direction que je devrais prendre, ou sur une bonne lecture. Je ne suis même pas sûr de ce qu'il faut chercher.

Answer 1

Qui a dit que vous deviez stocker les données une seule fois?

Je suppose que le modèle que vous avez dans votre tête est le «bon», donc je m'en tiens à cela; calculer les valeurs sur un grand nombre de données - cela peut être traité.

Baes sur ce que vous dites, en plus de stocker des points spécifiques contre des entités spécifiques (comme des questions, des réponses, etc), vous pouvez également stocker un "total cumulé" (score) qui a été incrémenté suppose que ce serait une colonne Int dans la table "User" de votre base de données). En outre, vous pourriez avoir des processus asynchrones qui vérifient périodiquement la valeur incrémentée par rapport aux entités dont les points ont contribué au «score». Cette vérification peut s'exécuter sur toutes les données appropriées, ou simplement sur les données dans une certaine plage de temps (c'est-à-dire depuis la dernière vérification).

Une autre approche va dans le même sens mais à l'échelle industrielle; avez-vous entendu parler de OLTP et OLAP?(Traitement transactionnel en ligne) fait référence à une classe de systèmes qui facilitent et gèrent les applications transactionnelles. (Online Analytical Processing) est une approche permettant de répondre rapidement aux requêtes analytiques multidimensionnelles. Il semble que le modèle dans votre tête soit construit autour de la nature «transactionnelle» attendue de votre système, mais vous avez également identifié certaines exigences qui seraient mieux adaptées à une approche plus analytique.

Il n'y a aucune raison pour laquelle vous ne pouvez pas faire les deux, la grande question serait comment. La solution 'running total' fait cela mais seulement pour un cas très spécifique. Il pourrait être utile de regarder le système plus large (et où vous voulez le prendre) et peut-être «investir» dans un système partitionné plus complet maintenant.

Answer 2

Si vous voulez avoir un historique de tous les changements d'évaluation, vous devez le connecter en quelque sorte. Vous pouvez créer un fichier qui les consignera tous et les analysera, de cette façon vous pourrez conserver un historique long. Si vous voulez passer par SQL, gardez les n derniers changements en détail et codez le classement avant les changements.

Answer 3

Si vous pouvez utiliser quelque chose comme 'Redis', cela aidera beaucoup. L'idée est - écrire dans redis et mysql tous les deux mais en lisant lire seulement de redis. Mais, vous devez pré-décider toutes les clés dont vous aurez besoin en redis. Par exemple: Pour le comptage des commentaires, vous pouvez avoir des clés comme Comments:<userId>:count, que vous pouvez augmenter à chaque commentaire posté par. De même, vous pouvez avoir des clés comme Posts:<userId>:count etc. Fondamentalement, vous mettez (en quelque sorte) en cache tous les types de requêtes count (*) dans le serveur redis.

Si à un moment donné, vous devez changer les méthodes de karma/évaluation, vous pouvez utiliser les données mysql pour générer de nouveau les clés redis en fonction des besoins.