Système de notification des réseaux sociaux


10

Contexte

Je travaille sur une application pour un client qui inclut des fonctionnalités de réseautage social. Je développais à l'origine le front-end mobile, mais les circonstances m'ont laissé en charge du développement du back-end également.

En tant que contexte général, notre système permet aux utilisateurs de suivre d'autres utilisateurs et de recevoir des notifications sur ceux qu'ils suivent, comme vous pouvez vous y attendre d'un réseau social. Une mise en garde est que seul un petit sous-ensemble (au plus quelques centaines) d'utilisateurs sera suivable, avec l'espoir que la plupart des utilisateurs suivront au moins une de ces personnes.

Du côté de l'interface utilisateur, nous aurons un bouton de notification avec un numéro, et cliquer sur le bouton vous amènera à l'écran de notification.

Le problème

J'ai recherché des stratégies pour implémenter les notifications et la plupart des ressources que j'ai trouvé utiles pour créer une ou plusieurs tables de notification dans la base de données. (Un exemple que j'aime est la réponse acceptée ici: /programming/9735578/building-a-notification-system ).

Ce qui me décourage, c'est que la plupart des stratégies basées sur la base de données pour les notifications nécessitent l'insertion d'une ligne pour chaque notification pour chaque abonné. Donc, si mille personnes suivent Sally, nous insérons mille lignes dans le tableau correspondant. Est-ce évolutif? Que se passe-t-il si nous arrivons au point où des dizaines ou des centaines de milliers d'utilisateurs suivent Sally et qu'elle publie quelques dizaines de messages par jour?

Mon idée originale était de tout gérer avec des requêtes: le nombre sur le bouton de notification serait obtenu en demandant le nombre de lignes sur le contenu publié plus récemment que la dernière fois que vous avez visité l'écran de notification, tandis que les notifications individuelles seraient générées à partir de requêtes plus détaillées lorsque vous avez visité l'écran de notification. Cette approche ne nécessiterait aucune écriture ou stockage supplémentaire, mais est inflexible et martelerait probablement le serveur assez fort.

INSTALLER

Le backend (tel qu'établi par le développeur précédent) utilise CodeIgniter et une base de données MySQL . Il fonctionne actuellement sur un compte d'hébergement partagé de GoDaddy, mais je suppose (espérons?) Que cela sera mis à niveau avant de passer en production et que le package d'hébergement sera adapté à la croissance des utilisateurs.

Actuellement, notre seul front-end est une application mobile, mais nous prévoyons également de créer un site Web ultérieurement. Je ne souhaite pas pour l'instant obtenir des mises à jour push en temps réel du serveur concernant les notifications.

ADDENDA

Je ne me spécialise pas dans les backends et je suis au dessus de ma tête dans ce département. Le client le sait, et j'ai fait de mon mieux pour essayer d'expliquer la portée d'un projet de cette nature, mais il a clairement indiqué qu'à ce stade, il ne fera confiance à personne d'autre pour travailler sur le projet. Nous avons probablement encore un mois de travail à faire avant de pouvoir commencer à ajouter des testeurs et je peux obtenir tout type de mesures de performances. Je ne peux vraiment pas estimer le nombre d'utilisateurs que nous pourrions avoir ou le matériel sur lequel nous pourrions être dans les 5 prochaines années, mais je pense que le client espère des centaines de milliers d'utilisateurs ou plus.

J'espère que c'est suffisamment spécifique d'un problème pour être signalé ici; Je peux l'affiner si besoin est. Veuillez demander si vous avez des questions ou si j'ai omis des détails importants.

tl; dr

  • Un système de notification basé sur une base de données a-t-il des implications négatives pour l'évolutivité à long terme lorsque tous les utilisateurs ne suivent que quelques-uns des quelques centaines de personnes?
  • Existe-t-il un moyen de rendre la base de données de notifications pilotée sans avoir besoin d'une ligne de notification distincte pour chaque notification pour chaque abonné?
  • Un système de notification entièrement axé sur les requêtes serait-il évolutif ou aurait-il des avantages à ne pas écrire de données dans la base de données?
  • Suis-je trop penser à cela trop tôt? Dois-je simplement construire quelque chose qui fonctionne pour l'instant et nous pouvons nous soucier de l'optimiser si cela devient un problème, étant donné que le client a un budget limité et que nous ne savons pas encore si le produit final sera populaire?

Pouvez-vous expirer les notifications? Par exemple, supprimez tout ce qui a plus de 2 semaines. Cela devrait plus ou moins équilibrer la taille de la table utilisée à mesure que le site mûrit.
GrandmasterB

Ce ne sera pas un problème, j'étais plus préoccupé par les implications en termes de performances du verrouillage de la base de données en écrivant 50 000 entrées dans le tableau des notifications chaque fois qu'un utilisateur populaire publie un message.
user45623

J'ai travaillé sur un projet avec un système de notification similaire (mais plus petit). J'ai eu un processus d'arrière-plan qui a examiné une file d'attente de nouveaux messages et a géré les notifications (qui dans ce cas insérait en fait un e-mail dans une deuxième file d'attente pour l'envoi). Ce n'était pas en temps réel, mais il gérait généralement tout en quelques minutes.
GrandmasterB

Réponses:


10

Donc, si mille personnes suivent Sally, nous insérons mille lignes dans le tableau correspondant. Est-ce évolutif?

Oui, à condition que les tables de base de données soient correctement indexées.

Que se passe-t-il si nous arrivons au point où des dizaines ou des centaines de milliers d'utilisateurs suivent Sally et qu'elle publie quelques dizaines de messages par jour?

Vous générerez quelques dizaines ou centaines de milliers d'enregistrements de notification par jour pour Sally, en supposant que vous souhaitez garder une trace de chaque notification à perpétuité. Le pourcentage d'utilisateurs comme Sally avec ce type de trafic est toujours très faible.

Mon idée originale était de tout gérer avec des requêtes: le nombre sur le bouton de notification serait obtenu en demandant le nombre de lignes sur le contenu publié plus récemment que la dernière fois que vous avez visité l'écran de notification, tandis que les notifications individuelles seraient générées à partir de requêtes plus détaillées lorsque vous avez visité l'écran de notification.

Cela semble inutilement compliqué. Si vous avez besoin de statistiques détaillées sur les notifications, stockez simplement les notifications.

Un système de notification basé sur une base de données a-t-il des implications négatives pour l'évolutivité à long terme lorsque tous les utilisateurs ne suivent que quelques-uns des quelques centaines de personnes?

C'est pourquoi cela fonctionne ... un petit nombre de personnes génèrent toujours la grande majorité du trafic.

Existe-t-il un moyen de rendre la base de données de notifications pilotée sans avoir besoin d'une ligne de notification distincte pour chaque notification pour chaque abonné?

Oui ... Ne stockez pas les notifications; il suffit d'envoyer les e-mails de notification, dans le style feu-et-oublier. Ou, stockez les notifications pendant une certaine période, puis supprimez-les. Vous pouvez également ignorer chaque notification après sa lecture.

Un système de notification entièrement axé sur les requêtes serait-il évolutif ou aurait-il des avantages à ne pas écrire de données dans la base de données?

Je ne sais pas ce que tu veux dire par là. Si vous souhaitez interroger les notifications, vous devez les stocker dans la base de données. Sinon, il n'y a rien à interroger.

Suis-je trop penser à cela trop tôt?

Parlez à quelqu'un qui peut vous aider à concevoir une base de données indexée correctement normalisée avec les bonnes tables. Je ne vois aucune raison pour laquelle une telle base de données ne pourrait pas gérer efficacement les scénarios que vous décrivez.

Un exemple concret

Pour autant que je sache, Stack Exchange stocke tout à perpétuité, y compris toutes les notifications. Ils utilisent une technologie de base de données similaire à MySql et certaines technologies de mise en cache. Bien que leur matériel et leur espace de stockage soient importants, la quantité de trafic qu'ils obtiennent est un bon problème.


Wow, vous avez tout abordé! Merci, Robert! La base de données est normalisée mais je n'ai pas encore examiné l'indexation. Malheureusement, je ne peux pas "parler à quelqu'un qui peut m'aider", car les conditions sont strictes, je ne peux pas discuter des détails spécifiques du projet avec qui que ce soit, et le client est arrivé au point de ne faire confiance à personne mais moi sur le projet ... Bon, je devrais pouvoir faire des recherches sur l'indexation. Merci!
user45623

1
Règles générales pour l'indexation: chaque clé étrangère doit être indexée avec des doublons possibles. Chaque clé primaire doit déjà être indexée. Les champs sur lesquels vous devrez rechercher ou appliquer une clause WHERE doivent être indexés; ceux-ci devraient être peu nombreux.
Robert Harvey

1
Ceci est une erreur. Ce n'est PAS évolutif. Pour chaque "Sally", vous générez N lignes où N est votre nombre d'utilisateurs. Cela va devenir un problème rapidement si vous avez un nombre raisonnable d'utilisateurs. 100 "Sallys" affichant 10 fois pour 10 000 utilisateurs, c'est 10 millions de lignes par jour - ça ne sonne pas trop bien hein? Ce que vous voulez réellement faire, c'est inverser cela et créer une ligne par publication "Sally" et demander à tous les utilisateurs qui suivent Sally de les récupérer au lieu de leur propre copie personnelle. Bien sûr, cela va causer des problèmes si vous avez besoin d'une logique spécifique à l'utilisateur (par exemple l'agrégation) ...
Ben

1
... l'explication "éviter une ligne par poste" est évidemment un homme de paille car la plupart des systèmes exigeront que ces messages restent. De plus, vous n'évitez pas les requêtes "parce qu'elles sont compliquées", vous les évitez car elles entraîneront des frais généraux non viables à mesure que le système évolue.
Ben
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.