Suivre les vues d'une ligne donnée

Question

J'ai un site où les utilisateurs peuvent consulter un assez grand nombre de messages. Chaque fois que cela est fait, j'exécute une requête similaire à la table UPDATE SET views = views + 1 WHERE id =? . Cependant, cette approche présente plusieurs inconvénients:

• Il n’existe aucun moyen de suivre le moment où les pages vues se produisent: elles sont simplement incrémentées.
• La mise à jour de la table effacera souvent le cache MySQL de la ligne, ce qui ralentira le prochain SELECT de cette ligne.

Par conséquent, j’envisage d’utiliser une approche consistant à créer un tableau, par exemple:
object_views {object_id, année, mois, jour, vues} , afin que chaque objet ait une ligne pr. jour dans cette table. Je mettrais ensuite à jour périodiquement la colonne des vues dans la table objets afin de ne pas avoir à faire des jointures coûteuses tout le temps.

C’est la solution la plus simple à laquelle je puisse penser, et il semble que c’est aussi celle qui a le moins d’impact sur les performances. Êtes-vous d'accord?

(Le site est basé sur PHP 5.2, Symfony 1.4 et Doctrine 1.2, au cas où vous vous le demanderiez)

Modifier:
Le but n’est pas d’analytique Web - je sais comment le faire et c’est déjà fait. Il y a deux objectifs:

• Permet à l'utilisateur de voir combien de fois un objet donné a été affiché, par exemple aujourd'hui ou hier.
• Permettez aux modérateurs du site de voir les simples statistiques sans passer par Google Analytics, Omniture ou une solution quelconque. De plus, les résultats dans le backend doivent être en temps réel, une fonctionnalité que l’AG ne peut offrir pour le moment. Je ne souhaite pas utiliser l'API Analytics pour récupérer les données d'utilisation (pas en temps réel, GA nécessite JavaScript).

Answer 1

Citation: La mise à jour de la table effacera souvent le cache MySQL de la ligne, ce qui ralentira le prochain SELECT de cette ligne.

Il y a beaucoup plus que cela. Ceci est tueur de base de données. Je vous suggère de faire table comme ça: object_views {object_id, timestamp} De cette façon, vous pouvez agréger sur object_id (fonction count ()). Ainsi, chaque fois que quelqu'un visualise la page, vous INSEREZ l'enregistrement dans la table. De temps en temps, vous devez nettoyer les anciens enregistrements de la table. L'instruction UPDATE est EVIL :) Sur la plupart des plates-formes, il marque essentiellement la ligne comme étant supprimée et en insère une nouvelle, ce qui rend le tableau fragmenté. Sans parler des problèmes de verrouillage.

L’espoir que cela aide

Answer 2

Dans la même veine que Rage, vous n'obtiendrez tout simplement pas les mêmes résultats si vous utilisiez un million d'outils de journalisation tiers. Si vous effectuez un suivi quotidien, un programme de base tel que Webtrends est tout à fait capable de suivre les hits, en particulier si votre URL contient l'identifiant des éléments que vous souhaitez suivre ... Je ne saurais trop insister sur ce point, c'est tout. à propos de l'URL en ce qui concerne ces outils (Wordpress permet par exemple de nombreuses constructions d'URL différentes)

Maintenant, si vous recherchez des informations sur "impression". le suivi est alors un autre jeu de balle car vous suivez probablement chaque objet, la page, l'utilisateur et éventuellement une valeur pondérée en fonction de l'emplacement sur la page. Si tel est le cas, vous pouvez maintenir vos performances en hébergeant le suivi sur un autre serveur, sur lequel vous pouvez déclencher et oublier. Auparavant, je travaillais à l'aide de la mise à jour SQL par rapport à l'ID et d'une version chaîne de la date. Ainsi, lorsque la date change de 20091125 à 20091126, il s'agit d'une requête simple sans la surcharge d'une fonction datiff.

Answer 3

Tout d'abord, une petite remarque, pourquoi ne pas additionner l'année, le mois et le jour dans DATETIME , cela aurait plus de sens dans mon esprit.

De plus, je ne suis pas vraiment sûr de la raison exacte pour laquelle vous le faites. Si vous avez des objectifs de marketing / statistiques Web, vous avez intérêt à utiliser des outils conçus à cet effet.

Maintenant, il existe deux grandes familles d’outils capables de vous donner une idée des statistiques d’accès à votre site Web, basées sur des journaux ( awstats est probablement le plus populaire), basé sur les images ajax / 1pixel ( google analytics ). serait le plus populaire).

Si vous préférez créer votre propre base de données de statistiques, vous pouvez probablement créer facilement un analyseur de journaux à l’aide de PHP. Si l'analyse des journaux Apache (ou des journaux IIS) est trop lourde, votre application produira probablement des journaux personnalisés, formatés de manière plus simple.

Une autre solution possible consiste à utiliser memcached , le démon fournit une sorte de compteur que vous pouvez incrémentation . Vous pouvez vous connecter à cette vue et demander à un script de collecter le résultat tous les jours.

Answer 4

Si vous voulez faire cela, pourquoi ne pas vous connecter chaque accès? MySQL peut très bien mettre en cache des insertions dans des tables continues, il ne devrait donc pas y avoir de ralentissement notable en raison de l'insertion. Vous pouvez toujours exécuter Afficher les profils pour voir ce que la pénalité de performance est réellement.

Sur le problème de date / heure, vous pouvez toujours utiliser GROUP BY MONTH (accès_at), YEAR (accès_at) ou WHERE MONTH (accès_at) = 11 ET AN (accès_at) = 2009 .