Diseño de esquema de base de datos MongoDB

Question

Tengo un sitio web con 500k usuarios (se ejecuta en el servidor sql 2008). Deseo ahora incluir corrientes de actividad de usuarios y sus amigos. Después de probar algunas cosas en SQL Server, resulta evidente que RDMS no es una buena opción para este tipo de características. es lento (incluso cuando desnormalicé mucho mis datos). Entonces, después de mirar otras soluciones NoSQL, he pensado que puedo usar MongoDB para esto. Estaré siguiendo la estructura de datos basada en activitystrea.ms json specifications for activity stream Así que mi pregunta es: ¿cuál sería el mejor diseño de esquema para el flujo de actividad en MongoDB (con este muchos usuarios se puede predecir que será muy pesado en las escrituras, de ahí mi elección de MongoDB: tiene un gran rendimiento de "escrituras". He pensado en 3 tipos de estructuras, por favor dígame si esto tiene sentido o debería usar otros patrones de esquema.

1 - Almacenar cada actividad con todos los amigos/seguidores en este patrón:

 

    { 
    _id:'activ123', 
    actor:{ 
      id:person1 
      }, 
    verb:'follow', 
    object:{ 
      objecttype:'person', 
      id:'person2' 
      }, 
    updatedon:Date(), 
    consumers:[ 
      person3, person4, person5, person6, ... so on 
      ] 

    } 

2 - Segundo diseño: Collectio n Nombre activity_stream_fanout

 

    { 
    _id:'activ_fanout_123', 
    personId:person3, 
    activities:[ 
    { 
    _id:'activ123', 
    actor:{ 
      id:person1 
      }, 
    verb:'follow', 
    object:{ 
      objecttype:'person', 
      id:'person2' 
      }, 
    updatedon:Date(), 
    } 

    ],[ 
    //activity feed 2 
    ] 

    } 

3 - Este enfoque sería la de almacenar los elementos de actividad en una colección, y los consumidores de otro. En las actividades, es posible que tenga un documento como:

 

    { _id: "123", 
     actor: { person: "UserABC" }, 
     verb: "follow", 
     object: { person: "someone_else" }, 
     updatedOn: Date(...) 

    } 

Y luego, para los seguidores, que tendría las siguientes "Notificaciones" documentos:

 

    { activityId: "123", consumer: "someguy", updatedOn: Date(...) } 
    { activityId: "123", consumer: "otherguy", updatedOn: Date(...) } 
    { activityId: "123", consumer: "thirdguy", updatedOn: Date(...) } 

Sus respuestas son muy apreciadas.

Answer 1

me gustaría ir con la siguiente estructura:

1. Utilice una colección de todas las acciones que resultamos, Actions

2. utilizar otra colección para que siga los cuales, Subscribers

3. Use una tercera colección, Newsfeed para un determinado usuario n alimentación de ews, los artículos se extienden de la colección Actions.

La colección Newsfeed se rellenarán por un proceso de trabajo que procesa de forma asíncrona nuevo Actions. Por lo tanto, las noticias no se llenará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 siquiera un minuto de demora en la mayoría de las aplicaciones (no todas) (en tiempo real, elegiría una arquitectura completamente diferente).

Si tiene un número muy grande de consumers, la distribución puede tardar un tiempo, es cierto. Por otro lado, poner a los consumidores en el objeto no funcionará con cuentas de seguidores muy grandes tampoco, y creará objetos demasiado grandes que ocuparán mucho espacio de índice.

Lo más importante, sin embargo, el diseño de ventilador de salida es mucho más flexible y permite anotar relevancia, filtrado, etc. recientemente he escrito un post sobre news feed schema design with MongoDB donde explico algunos de que la flexibilidad en mayor detalle.

Hablando de flexibilidad, tendría cuidado con esa especificación activitystrea.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 desde varias aplicaciones.

Answer 2

creo que usted debe buscar en sus patrones de acceso: qué consultas es probable que se realice la mayor parte de estos datos, etc.

Para mí El caso de uso que debe ser el más rápido es ser capaz de empujar una cierta actividad al 'muro' (en términos fb) de cada uno de los 'consumidores de la actividad' y hacerlo inmediatamente cuando entra la actividad.

Desde este punto de vista (no lo he pensado mucho) hubiera ir con 1, ya que 2. parece que las actividades por lotes para un determinado usuario antes de procesarlas? Por lo tanto, si falla la necesidad "inmediata" de actualizaciones. Además, no veo la ventaja de 3. más de 1 para este caso de uso.

Algunas mejoras en 1? Pregúntese si realmente necesita la flexibilidad de definir una gama de consumidores para cada actividad. ¿Realmente hay una necesidad de especificar esto en esta escala fina? en cambio, ¿no sería suficiente una referencia a los "amigos" del "actor"? (Esto supondría mucho espacio a largo plazo, ya que veo que la matriz de consumidores es la mayor parte del mensaje para cada actividad cuando los consumidores suelen oscilar entre los cientos (?).

en una nota algo relacionada: dependiendo de cómo desee implementar notificaciones en tiempo real para estas secuencias de actividad, podría valer la pena consultar Pusher - http://pusher.com/ y soluciones similares.

hth