Implémenter un compteur de vue de page unique?

Question

Je souhaite implémenter un compteur de vues orienté utilisateur (similaire à ce que SO a pour les vues de questions) qui suit le nombre de vues uniques vers une page. Il y a quelques questions similar ici mais aucune ne semble répondre complètement à ma question.

Quelle serait la meilleure configuration pour cela (en termes de tables de base de données, etc.)? Serait-il bon d'ajouter une colonne 'views' à la table 'questions' et de l'incrémenter simplement sur chaque page? Et si je veux que les vues soient uniques, je suppose que je pourrais avoir une autre table avec des identifiants de questions et adresses IP et n'augmenter la colonne 'view' que s'il n'y a pas déjà une entrée avec l'adresse IP actuelle. Cependant, cette table 'ip-view' deviendra très vite très populaire ... Je m'inquiète surtout de devoir stocker chaque page vue et chaque adresse IP dans une table. Comment cela pourrait-il être optimisé afin qu'il ne devienne pas un goulot d'étranglement au niveau des performances? Y a-t-il une meilleure approche que celle que j'ai décrite? Veuillez noter qu'il est très important pour moi que seules les vues uniques soient comptabilisées. En plus de suggérer des méthodes de mise en œuvre, je voudrais également mieux comprendre où les problèmes de performance entrent en jeu en supposant l'approche naïve de simplement vérifier si la propriété intellectuelle existe et mettre à jour la colonne «vue» sur chaque page vue. Est-ce que le problème principal est une grande quantité d'insertions (en supposant un trafic important) ou plus la taille de la table de mapping objet-ip (qui pourrait être énorme puisqu'une nouvelle ligne sera insérée par question pour chaque nouveau visiteur). Est-ce que les conditions de course devraient être considérées (j'ai juste supposé qu'une instruction update/increment sql était atomique)? Désolé pour toutes les questions mais je suis juste perdu quant à la façon dont je devrais aborder cela.

Answer 1

Il semble y avoir une approche révolutionnaire (au-dessus de ma tête), dont je ne suis pas encore sûr d'être évolutif ou plutôt faisable.

Si vous souhaitez vraiment stocker l'adresse IP en DB et que vous souhaitez éviter l'obstruction de votre DB, pensez à les stocker dans un ordre hiérarchique.

<ID, IP_PART, LEVEL, PARENT_PART, VIEWS> 

donc, lorsqu'un utilisateur visite ur site de IP 212.121.139.54, les lignes ur table serait:

< 1, 212, 1, 0, 0> < 2, 121, 2, 1, 0> < 3, 139, 3, 2, 0> < 4, 54, 4, 3, 1>

Points à noter:

1. Seules les lignes avec LEVEL val = 4 auront le nombre de vues.
2. Pour éviter la redondance de stockage VIEWS val = 0, pour LEVEL val = 1,2,3; vous pouvez penser à les stocker dans une table différente.
3. L'idée, telle qu'elle a été conçue, ne semble pas adaptée à un petit ensemble d'adresses IP.
4. Bien que cela puisse avoir négligé le fait qu'une IP publique proxy assis devant un réseau privé accédant à votre site Web à partir de plus d'une boîte. Mais cela ne semble pas être votre question. j'imagine.

alors, chao, laissez-moi savoir ce que vous avez mis en œuvre?

Answer 2

Si vous avez besoin de suivre spécifiquement des vues uniques, il y a probablement deux façons de le faire ... sauf si vous travaillez avec des utilisateurs internes que vous pouvez identifier. Maintenant, pour ce faire, vous devez garder une trace de chaque utilisateur qui a visité la page.

Le suivi peut être effectué côté serveur ou côté client.

Le côté serveur devra être une adresse IP, sauf s'il s'agit d'utilisateurs internes que vous pouvez identifier. Et chaque fois que vous traitez avec des adresses IP, toutes les mises en garde habituelles concernant leur utilisation pour identifier les utilisateurs s'appliquent (il peut y avoir plusieurs utilisateurs par IP ou plusieurs adresses IP par utilisateur) et vous ne pouvez rien y faire.

Vous devez également tenir compte du fait que «l'immense table IP de la mort» n'est pas si mauvaise qu'une solution. Les performances ne deviendront un problème que si vous avez des centaines de milliers d'utilisateurs ... en supposant qu'ils soient correctement indexés, bien sûr.

Le côté client implique probablement que vous laissez un "J'ai visité!" biscuit. Si le cookie n'est pas présent, augmentez le nombre d'utilisateurs. Si le cookie ne peut pas être créé, vous devrez vivre avec une vue utilisateur gonflée. Et toutes les mises en garde concernant les cookies s'appliquent ... c'est-à-dire qu'elles vont mal finir par disparaître.