Diseño de esquema de base de datos MongoDB

Me quedaría con la siguiente estructura:

1. Utilice una colección para todas las acciones que sucedan, Actions

2. Use otra colección para quién sigue a quién, Subscribers

3. Use una tercera colección, Newsfeed para el suministro de noticias de un determinado usuario, los elementos se distribuyen desde las Actions colección.

El Newsfeed la colección se completará con un proceso de trabajo que procesa de forma asíncrona nuevas Actions . Por lo tanto, las fuentes de noticias no se completarán en tiempo real. No estoy de acuerdo con Geert-Jan en que el tiempo real es importante; Creo que a la mayoría de los usuarios no les importa ni un minuto de retraso en la mayoría (no todas) las aplicaciones (en tiempo real, elegiría una arquitectura completamente diferente).

Si tiene una gran cantidad de consumers , el fan-out puede llevar un tiempo, cierto. Por otro lado, colocar a los consumidores directamente en el objeto tampoco funcionará con un gran número de seguidores y creará objetos demasiado grandes que ocuparán mucho espacio de índice.

Sin embargo, lo más importante es que el diseño de abanico es mucho más flexible. y permite la puntuación de relevancia, el filtrado, etc. Hace poco escribí una publicación de blog sobre el diseño de esquemas de fuentes de noticias con MongoDB, donde explico algo de esa flexibilidad con mayor detalle.

Hablando de flexibilidad, tendría cuidado con esa especificación de activitystream.ms. Parece tener sentido como una especificación para la interoperabilidad entre diferentes proveedores, pero no almacenaría toda esa información detallada en mi base de datos siempre que no tenga la intención de agregar actividades de varias aplicaciones.