que - Estructura de MongoDB para aplicación de mensajes

mongodb español

Question

Estoy pensando en una buena estructura de documentos para manejar una aplicación de mensajes.

Básicamente necesito tres (o cuatro) tipos de objetos:

1. El usuario (nombre de usuario, correo electrónico, contraseña, etc.)
2. La lista de contactos (que contiene diferentes contactos o grupos de contactos)
3. La conversación (una conversación es una colección de mensajes entre algunas personas)
4. El mensaje (contiene el cuerpo del mensaje, alguna marca de tiempo y el creador).

Mi idea fue incrustar los contactos en el documento del usuario e incrustar los mensajes en un documento de conversación:

1. Usuario

{
username: ''dev.puS'',
usernameCanonical: ''dev.pus'', // used for unique constraints
email: ''[email protected],
emailCanonical: ''[email protected],
salt: ''some hash'',
password: ''hash with salt'',
logs: { last_login: 12.06.2008, last_password_reset: 04.03.2007 },
state: { online: true, available: false },
contacts: [ user_id1, user_id2, user_id3 ]
}

2. Conversación

{
members: [ user_id1, user_id2 ],
messages: [
{ author: user_2, body: ''Hi what''s up'' },
{ author: user_1, body: ''Nothing out here :('' },
{ author: user_2, body: ''Whanna ask some question on stackoverflow'' },
{ author: user_1, body: ''Okay, lets go'' }
]
}

¿Qué te parece este esquema?

Creo que sería mejor mantenerlos separados (para que cada documento sea propio) porque cada documento tiene una frecuencia de actualización diferente. Pero realmente no tengo ninguna experiencia al respecto, por lo que sería bueno escuchar algunos consejos :)

Saludos

Answer 1

Su pregunta es realmente uno de diseño de esquema. Sugiero echar un vistazo a esta página sobre el diseño del esquema de MongoDB para tener una idea de las opciones y las compensaciones: http://www.mongodb.org/display/DOCS/Schema+Design

Además, probablemente debería revisar los enlaces en la sección "Ver también" de ese documento. Recomiendo especialmente las presentaciones en video.

Finalmente, probablemente debería echar un vistazo a este documento para una discusión de los tres esquemas posibles para una base de datos de mensajería / comentarios, incluyendo las compensaciones para cada diseño: http://docs.mongodb.org/manual/use-cases/storing-comments/

Answer 2

Veo que esta pregunta es antigua, pero para cualquier persona interesada, se hizo una pregunta similar y una respuesta parece viable https://.com/a/30830429/132610

Conversation : {
id: 123,
members: [ user_id1, user_id2 ]
}
Message { conversationId: 123, author: user_2, body: ''Hi what''s up'' }
Message { conversationId: 123, author: user_1, body: ''Whanna ask some question on '' }

Actualización # 1

1) Escalabilidad: MongoDB se adapta bien con una colección muy grande. Miles de millones de mensajes por colección. Existe una técnica llamada fragmentación que puede permitirle dividir una colección más grande en varios nodos.

2) Lectura. Como MongoDB tiene mecanismos de indexación, las lecturas son comparables a cualquier motor de base de datos ajustado. Así que la lectura no será un problema. Especialmente, cuando una conversación (grupo | sala) tiene menos participantes, por ejemplo, dos personas se envían mensajes.

Answer 3

esta es mi sugerencia

{
"_id" : ObjectId("5a9e9581a2147c0c0f00002e"),
"id_members1" : "5a9e9581a2147c0c0f02345t",
"id_members2" : "5a9e9581a2147c0c0f02134g",
"name" : [
"Omar",
"Mohamed"
],
"messages" : [
{
"author" : "Omar",
"body" : "salam 3likom",
"create_at" : ISODate("2018-03-07T09:04:04.000Z")
},
{
"author" : "Mohamed",
"body" : "Wa3likom salam",
"create_at" : ISODate("2018-03-07T09:04:04.000Z")
},
{
"author" : "Mohamed",
"body" : "wach teshak",
"create_at" : ISODate("2018-03-07T09:04:04.000Z")
},
{
"author" : [
"Omar",
"Mohamed"
],
"body" : "test msg",
"create_at" : ISODate("2018-03-25T15:30:05.000Z")
}
],
"comments" : [
null,
{
"author" : [
"Omar",
"Mohamed"
],
"body" : "test msg",
"create_at" : ISODate("2018-03-25T15:28:11.000Z")
},
{
"author" : [
"Omar",
"Mohamed"
],
"body" : "test msg",
"create_at" : ISODate("2018-03-25T15:28:31.000Z")
}
]

}