Conception de schéma de base de données MongoDB

J'irais avec la structure suivante :

1. Utilisez une collection pour toutes les actions qui se sont produites, Actions

2. Utiliser une autre collection pour qui suit qui, Subscribers

3. Utilisez une troisième collection, Newsfeed pour le fil d'actualité d'un certain utilisateur, les éléments sont déployés à partir des Actions collecte.

Le Newsfeed la collection sera remplie par un processus de travail qui traite de manière asynchrone les nouvelles Actions . Par conséquent, les flux d'actualités ne se rempliront pas en temps réel. Je ne suis pas d'accord avec Geert-Jan sur le fait que le temps réel est important ; Je crois que la plupart des utilisateurs ne se soucient même pas d'une minute de retard dans la plupart (pas toutes) les applications (pour le temps réel, je choisirais une architecture complètement différente).

Si vous avez un très grand nombre de consumers , la diffusion peut prendre un certain temps, c'est vrai. D'un autre côté, placer les consommateurs directement dans l'objet ne fonctionnera pas non plus avec un très grand nombre d'abonnés, et cela créera des objets trop volumineux qui occupent beaucoup d'espace d'index.

Plus important encore, cependant, la conception du déploiement est beaucoup plus flexible et permet la notation de la pertinence, le filtrage, etc.

En parlant de flexibilité, je ferais attention à cette spécification activitystream.ms. Cela semble logique en tant que spécification d'interopérabilité entre différents fournisseurs, mais je ne stockerais pas toutes ces informations détaillées dans ma base de données tant que vous n'avez pas l'intention d'agréger les activités de diverses applications.