Système de notification des réseaux sociaux

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?

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.