6
votes

À propos de YouTube Vues compter

Je suis implémentant une application qui garde une trace du nombre de fois qu'un poste est vu. Mais j'aimerais garder une méthode «intelligente» de garder une piste. Cela signifie que je ne veux pas augmenter le compteur de vue simplement parce qu'un utilisateur rafraîchit son navigateur.

J'ai donc décidé de n'augmenter que le compteur de vue si IP et utilisateur utilisateur (navigateur) sont uniques. Qui fonctionne jusqu'à présent.

Mais alors je pensais. Si YouTube, le fait de cette façon et ils ont plusieurs vidéos avec des milliers ou même des millions de vues. Cela signifierait que leur table de visions dans la base de données serait trop peuplée avec des agents IP et des agents d'utilisateur ....

Ce qui m'apporte à l'hypothèse que leur table vidéo a un compteur de cache pour vues (I.e. vues_count ). Cela signifie que lorsqu'un utilisateur clique sur une vidéo, l'IP et l'agent utilisateur sont stockés. De plus, la colonne de cache de compteur dans la table vidéo est augmentée.

Chaque fois qu'une vidéo est cliquée. YouTube aurait besoin d'interroger la table de vues et de compter le nombre d'entrées. Cela n'a pas d'incidence sur la performance drastiquement?

Est-ce comment ils le font? Ou y a-t-il une meilleure façon?


0 commentaires

3 Réponses :


1
votes

Si vous souhaitez stocker toutes les IP et les navigateurs, assurez-vous d'avoir suffisamment d'espace de stockage de DB, ajoutez un index et c'est tout. Sinon, vous pouvez utiliser la session Rails pour stocker la liste des vidéos visitées et incrémente l'attribut View_Count d'une vidéo lorsqu'il visite une nouvelle vidéo.


3 commentaires

Avec ce dernier. Cela n'aurait-il pas atteint la limite de mémoire de la quantité de session peut stocker par utilisateur? Imaginez un utilisateur qui visionne plusieurs milliers de vidéos ou plus


Je ne m'inquiéterais pas pour ça. Vous stockeriez un hachage d'INTS (ID vidéo), qui sont 8 octets les plus graves. 1000 * 8 = ~ 8kb, qui n'est rien à mon avis :)


En outre, il n'est pas trop courant qu'un utilisateur regarde plus de 1000 vidéos dans la même session.



1
votes

Tout d'abord, Afaik, YouTube utilise Bigtable, alors ne vous inquiétez pas pour interroger le compte, nous ne connaissons pas toute façon la structure exacte de la base de données.

En supposant que vous êtes sur un modèle relationnel, créez une vue sur colonne, mais ne le mettez pas à jour sur chaque actualisation. Enregistrez les visistes et mettez à jour périodiquement le cache.

En outre, vous pouvez générer HASH à partir de la propriété intellectuelle, du navigateur, de la date et de toute autre information que vous utilisez pour détecter s'il s'agit d'une vue unique et ne stockez pas toutes les données.

En outre, vous pouvez utiliser la session / cookie pour enregistrer la vue visualisée. Puisqu'il expirera, ce ne sera pas un problème de mémoire, je ne crois pas que quiconque visionne des milliers de vidéos dans une session


5 commentaires

Vous suggérez donc si je tiens un enregistrement de toutes les visites dans une table dans la DB, cela ne devrait pas être un problème? Même si j'ai des millions de rangées?


Je suggère de ne pas conserver tous les enregistrements, mais de les agréger périodiquement et de les supprimer.


Donc, fondamentalement une sorte de travail cron en arrière-plan pour supprimer des enregistrements d'affichage plus tard que 24 heures?


Exactement. Vous pouvez également utiliser MEMCCACHÉ SUPPORTEMENT MYSQL, car l'augmentation de l'opération dans MemCached est atomique et perdre une visite ou deux habituellement n'est pas critique.


Les sessions sonnent comme une bonne idée. Mais comment puis-je empêcher les robots, les robots de crazer, etc. d'augmenter au hasard le comte?



2
votes

Je tirerais parti de l'empreinte digitale du navigateur côté client pour identifier de manière unique les comptes d'affichage. Cette bibliothèque semble avoir une traction importante:

https://github.com/valve/fingerprintjs

Je recommanderais également d'utiliser Redis pour quelque chose à voir avec les comptes. Ses commandes Atomic Incrément sont faciles à utiliser et garantissent que vos comptes ne sont jamais foirés via des conditions de course.

Ce serait la commande que vous voudriez utiliser pour incrémenter vos comptoirs:

http://redis.io/commands/incr

La touche dans ce cas serait l'empreinte digitale du navigateur qui vous a été envoyée à partir du client. Vous pourriez alors avoir un "SET" REDIS qui contiendrait une liste de toutes les empreintes digitales du navigateur connues pour être associées à un utilisateur donné (la clé de l'ensemble serait User_id).

Enfin, si vous avez vraiment besoin de, vous exécutez un travail de cron ou un autre processus ASYNC qui décharge que la vue compte pour chaque utilisateur dans votre champ de cache de votre compteur pour votre base de données relationnelle.

Vous pouvez également prendre l'approche où vous stockez user_id, empreinte digitale de navigateur et horodatage dans une base de données relationnelle (MySQL?) et contre-cache dans votre table utilisateur périodiquement (probablement via Cron).


0 commentaires