Necesita consejo sobre MongoDB Schema for Chat App. Embedded vs Related Documents

Question

Estoy comenzando un proyecto MongoDB solo por patadas y como una oportunidad para aprender esquemas MongoDB/NoSQL. Será una aplicación de chat en vivo y la pila incluye: Rails 3, Ruby 1.9.2, Devise, Mongoid/MongoDB, CarrierWave, Redis, JQuery.

Voy a manejar el chat en vivo/colas de mensajes por separado. Aún no estoy seguro de cómo, ya sea Node.js, APE o la aplicación EventMachine personalizada. Pero en lo que respecta a Mongo, estoy pensando en usarlo para todo lo demás en la aplicación, específicamente registros de chat y transcripciones históricas.

Mi pregunta es cuál es la mejor manera de diseñar el esquema, ya que toda mi experiencia previa ha sido con MySQL y con los esquemas DB relacionales. Y como una subpregunta, ¿cuándo es mejor para nosotros los documentos integrados y los documentos relacionados?

La aplicación va a tener:

cuentas

• múltiples que tienen múltiples habitaciones
• habitaciones múltiples
• varios usuarios por habitación
• lista de las salas se permite a un usuario estar en
• múltiple chats de usuario por habitación
• Registros de chat buscables por habitación y por usuario
• archivo adjunto opcional para una charla dada

Dada Mongo (al menos la última vez que lo comprobé) tiene un límite de documentos de 4MB, no creo que tenga una colección de habitaciones y almacenar todos los chats de las habitaciones como la inclusión de documentos funcionaría tan bien.

Por lo que he pensado hasta ahora, estoy pensando en hacer algo como:

• Una colección de cuentas
• Una colección de habitaciones
  • Cada habitación se relaciona de nuevo a una cuenta
  • Documentos relacionados en colecciones de chat para todos los mensajes de chat en la habitación
  • Documento incrustado que enumera todos los usuarios actualmente en t él habitación
• Una colección para los usuarios
  • documento incrustado lista de todas las habitaciones que el usuario se encuentra actualmente en
  • documento incrustado lista de todas las habitaciones se permite al usuario estar en
• Una colección para chats
  • Cada chat se relaciona con una habitación de la colección de habitaciones
  • Cada chat se relaciona con un usuario en la colección de usuarios
  • Documento incrustado con información sobre archivos adjuntos cargados opcionalmente.

Mi principal preocupación es qué tan lejos puedo ir hasta que esta termina pareciéndose a un esquema relacional y que suprima la función? Definitivamente hay más relacionamientos que incrustaciones.

Otra preocupación es que hacer referencia a los documentos relacionados es mucho más lento que acceder a los documentos incrustados que he escuchado.

Quiero hacer consultas genéricas tales como:

• Dame todas las habitaciones de una cuenta
• Dame todos los chats en una habitación (o filtrada a través de rango de fechas)
• Dame todos los chats desde un usuario específico
• Dame todos los archivos cargados en una habitación determinada, para una org dado
• etc

¿Alguna sugerencia sobre cómo estructurar el esquema de manera eficiente en una escala? Gracias a todos.

Answer 1

Creo que estás más o menos en el camino correcto. Utilizaría un capped collection para las líneas de chat, con cada línea que contiene la identificación del usuario, la identificación de la habitación, la marca de tiempo y lo que se dijo. Estos datos caducarán una vez que se alcance el "final" de la colección limitada, por lo que si necesita un registro histórico, querrá copiar datos de la colección limitada en una colección de "registro" periódicamente, pero las colecciones limitadas están diseñadas específicamente para el registro. aplicaciones de estilo donde no va a eliminar documentos, y el orden de inserción importa. En el caso del chat, es una combinación perfecta.

El único otro cambio que sugeriría sería mantener las cargas en una colección separada, también.

Answer 2

Soy un gran admirador de mongodb como una base de datos de documentos también. Pero, ¿estás seguro de que estás usando mongodb por la razón correcta? ¿Qué es poderoso en mongodb?

Es una pregunta subjetiva, pero para mí las actualizaciones en el lugar (atómicas) de los documentos es lo que hace que mongodb sea poderoso. Y realmente no puedo verte usando tanto. Y además de eso, también estás atacando el problema del límite de tamaño del documento (con la experiencia, puedo decirte que incrustar archivos en mongodb no es una buena idea). También desea tener una aplicación de chat en vivo encima de la base de datos.

El esquema de su documento parece lógico. Pero no me gustaría ir con mongodb para este tipo de proyectos donde su aplicación depende en gran medida de insertos. Yo iría por CouchDB.

Con CouchDB no tendría que preocuparse por los problemas de los adjuntos, puede incrustarlos fácilmente. "_cambios" le facilitarían mucho más la vida a la hora de crear una aplicación de chat en vivo/motor de búsqueda de agrupamiento/alimentación larga (si desea implementar uno).

Y vi un open source showcase project en el sofá. Tiene algunas similitudes con tus objetivos: Anologue. Usted deberia comprobar esto.

PD: Lo siento, fue un poco fuera de tema pero no pude contenerme.