Quelle est la meilleure façon de mettre en œuvre un flux d'activités sociales ?

Question

J'aimerais connaître votre avis sur la meilleure façon de mettre en œuvre un flux d'activités sociales (Facebook est l'exemple le plus connu). Les problèmes/défis à relever sont les suivants :

• Différents types d'activités (postage, commentaires )
• Différents types d'objets (message, commentaire, photo )
• 1-n utilisateurs impliqués dans des rôles différents ("L'utilisateur x a répondu au commentaire de l'utilisateur y sur le post Z de l'utilisateur")
• Différentes vues du même élément d'activité ("vous avez commenté .." vs. "votre ami x a commenté" vs. "l'utilisateur x a commenté .." => 3 représentations d'une activité "commentaire")

et bien plus encore, surtout si l'on atteint un haut niveau de sophistication, comme le fait Facebook, par exemple, en combinant plusieurs éléments d'activité en un seul ("les utilisateurs x, y et z ont commenté cette photo").

Toute réflexion ou indication sur des modèles, des articles, etc. sur les approches les plus flexibles, efficaces et puissantes pour mettre en œuvre un tel système, modèle de données, etc. serait appréciée.

Bien que la plupart des problèmes soient indépendants de la plate-forme, il est probable que je finisse par mettre en œuvre un tel système sur Ruby on Rails.

Answer 1

J'ai créé un tel système et j'ai adopté cette approche :

Table de base de données avec les colonnes suivantes : id, userId, type, data, time.

• userId est l'utilisateur qui a généré l'activité
• type est le type d'activité (c.-à-d. Écriture d'un article de blog, ajout d'une photo, commentaire sur la photo d'un utilisateur)
• données est un objet sérialisé avec des méta-données pour l'activité où vous pouvez mettre ce que vous voulez.

Cela limite les recherches que vous pouvez effectuer dans les flux aux utilisateurs, au temps et aux types d'activité, mais dans un flux d'activité de type facebook, ce n'est pas vraiment limitatif. Et avec des indices corrects sur la table, les recherches sont les suivantes rapide .

Avec cette conception, vous devrez décider des métadonnées à fournir pour chaque type d'événement. Par exemple, une activité de flux pour une nouvelle photo pourrait ressembler à ceci :

{id:1, userId:1, type:PHOTO, time:2008-10-15 12:00:00, data:{photoId:2089, photoName:A trip to the beach}}

Vous pouvez voir que, bien que le nom de la photo soit très certainement stocké dans une autre table contenant les photos, et que je pourrais y récupérer le nom, je vais dupliquer le nom dans le champ de métadonnées, car vous ne voulez pas faire de jointures sur d'autres tables de base de données si vous voulez de la rapidité. Et pour afficher, disons 200 événements différents provenant de 50 utilisateurs différents, vous avez besoin de rapidité.

Ensuite, j'ai des classes qui étendent une classe FeedActivity de base pour rendre les différents types d'entrées d'activité. Le regroupement des événements serait également intégré dans le code de rendu, afin d'éviter toute complexité au niveau de la base de données.

Answer 2

Il s'agit d'une très bonne présentation décrivant comment Etsy.com a architecturé ses flux d'activité. C'est le meilleur exemple que j'ai trouvé sur le sujet, bien qu'il ne soit pas spécifique aux rails.

http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture

Answer 3

Les plus gros problèmes avec les flux d'événements sont la visibilité et les performances ; vous devez restreindre les événements affichés pour qu'ils ne soient que ceux qui sont intéressants pour cet utilisateur particulier, et vous devez faire en sorte que le temps nécessaire pour trier et identifier ces événements reste gérable. J'ai construit un réseau social de taille modeste ; j'ai constaté qu'à petite échelle, le maintien d'une table "événements" dans une base de données fonctionne, mais que cela devient un problème de performance en cas de charge modérée.

Avec un flux plus important de messages et d'utilisateurs, il est probablement préférable d'opter pour un système de messagerie, où les événements sont envoyés sous forme de messages à des profils individuels. Cela signifie que vous ne pouvez pas vous abonner facilement aux flux d'événements des autres et voir les événements précédents très facilement, mais que vous rendez simplement un petit groupe de messages lorsque vous devez rendre le flux pour un utilisateur particulier.

Je crois que c'est le défaut de conception initial de Twitter. Je me souviens avoir lu qu'ils utilisaient la base de données pour extraire et filtrer leurs événements. Cela avait tout à voir avec l'architecture et rien à voir avec Rails, qui a (malheureusement) donné naissance au mème "ruby doesn't scale". Récemment, j'ai assisté à une présentation dans laquelle le développeur utilisait le logiciel Amazon's Service de file d'attente simple comme backend de messagerie pour une application de type twitter qui aurait des capacités de mise à l'échelle bien plus élevées - il peut être intéressant d'envisager SQS dans le cadre de votre système, si vos charges sont suffisamment élevées.

Answer 4

Chez Fashiolista, nous avons ouvert notre approche de la construction de systèmes d'alimentation. https://github.com/tschellenbach/Feedly Il s'agit actuellement de la plus grande bibliothèque open source visant à résoudre ce problème.

La même équipe qui a créé Feedly propose également une API hébergée, qui gère la complexité pour vous. Jetez un coup d'œil à getstream.io

Vous pouvez également consulter cet article sur la haute évolutivité, où nous expliquons certaines des décisions de conception impliquées : http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html

Ce tutoriel vous aidera à mettre en place un système comme le flux de Pinterest en utilisant Redis. C'est assez facile à mettre en place.

Pour en savoir plus sur la conception des flux, je vous recommande vivement de lire certains des articles sur lesquels nous avons fondé Feedly :

• Document de recherche sur Yahoo
• Twitter 2013 basé sur Redis avec repli
• Cassandra sur Instagram
• Mise à l'échelle des flux Etsy
• Historique de Facebook
• Projet Django avec de bonnes conventions de dénomination. (Mais base de données seulement)
• http://activitystrea.ms/specs/atom/1.0/ (acteur, verbe, objet, cible)
• Post Quora sur les meilleures pratiques
• Quora met à l'échelle un flux de réseau social
• Exemple Redis ruby
• L'approche FriendFeed
• Configuration de Thoonk
• L'approche de Twitter

Bien que Feedly soit basé sur Python, il ne serait pas trop difficile de l'utiliser à partir d'une application Ruby. Il suffirait de l'exécuter comme un service et de lui adjoindre une petite API http. Nous envisageons d'ajouter une API pour accéder à Feedly depuis d'autres langues. Pour l'instant, vous devrez vous débrouiller tout seul.

Answer 5

// one entry per actual event
events {
  id, timestamp, type, data
}

// one entry per event, per feed containing that event
events\_feeds {
  event\_id, feed\_id
}

Lorsque l'événement est créé, décidez des flux dans lesquels il apparaît et ajoutez-les à events_feeds. Pour obtenir un flux, sélectionnez dans events_feeds, joignez les événements, ordonnez par horodatage. Le filtrage et l'agrégation peuvent ensuite être effectués sur les résultats de cette requête. Avec ce modèle, vous pouvez modifier les propriétés des événements après leur création, sans travail supplémentaire.