MongoDB/Mongoose Schema per messaggi filettati (Efficientemente)

Question

Sono un po 'nuovo ai database noSQL (sono abbastanza buono con i database relazionali), e mi chiedo quale sia il modo più efficiente per gestire un sistema di posta in arrivo con thread i messaggi sarebbero

Ogni 'messaggio' avrà un singolo mittente e destinatario. Il numero di messaggi ricevuti/inviati varierà ampiamente tra gli utenti. Questo sistema dovrebbe adattarsi bene a più di 1k + utenti.

Ho letto i fan su write/read ma non sono sicuro di come funzionerebbe questo per i messaggi con thread.

Dato che sono nuovo in MongoDB/NoSQL in generale, non sono molto abituato a strutturare i dati in modo efficiente in questo modo.

Immagino che ci saranno oggetti annidati in qualsiasi tipo di modo efficiente di gestire questo ... ma non posso accontentarmi di un design che sembra sia efficiente e conveniente per conversazioni a threading tra 2 utenti.

Ho pensato di memorizzare i dati con un array di 2 utenti, combinato con una serie di oggetti 'messaggio'. Ma poi c'è il problema dell'ordine dei nomi utente di 2 utenti. (Es. [UtenteA, UtenteB] e [UtenteB, UtenteA] sono entrambi possibili e sarebbero problematici, quindi sembrava una cattiva idea).

Ho pensato di fare tutto il fan su cosa leggere/scrivere, ma non sembra efficiente per i messaggi con thread (dal momento che se afferrare i messaggi dal destinatario è conveniente, i messaggi afferrati dal mittente non saranno e viceversa) .

Sono propenso a favorire l'acquisizione di messaggi da parte del destinatario (poiché la posta in arrivo carica più messaggi e l'invio comporta solo uno [anche se con un tempo di ricerca più lungo]). Ma mi piacerebbe davvero prendere una conversazione con thread in una volta sola, così come l'elenco di utenti con cui un utente ha conversato con thread (per l'elenco di thread).

Se qualcuno potesse darmi uno schema efficiente per conversazioni con thread sarei molto grato. Ho fatto ricerche su questo e ho cercato di accontentarmi di un progetto per ore, e sono esausto. Continuo a trovare difetti nei miei progetti e li demolisco e mi piacerebbe davvero un input da qualcuno più esperto con database NoSQL/MongoDB, così posso evitare di creare un enorme difetto di progettazione e/o logica di scrittura che potrebbe essere stata gestita con un migliore progettazione del database.

Grazie in anticipo per qualsiasi aiuto.

Answer 1

Su questo argomento particolare siete fortunati, v'è un grande post discutere i vari approcci allo schema qui (è una leggera torsione su ciò che si sta guardando, ma non molto diverso):

http://blog.mongodb.org/post/65612078649/schema-design-for-social-inboxes-in-mongodb

Poi, questo argomento è stato anche trattato in dettaglio in MongoDB mondo 2014 in tre parti da Darren legno e Asya Kamsky:

Part 1 Outline e Video

Part 2 Outline e Video

Part 3 Outline e Video

Anche a MongoDB mondiale i ragazzi di Dropbox ha parlato delle lezioni che hanno imparato quando si costruisce la loro cassetta postale:

http://www.mongodb.com/presentations/mongodb-mailbox

E poi, per arrotondare fuori , c'è un'architettura di riferimento completa con il codice chiamato Socialite su Github scritto dal già citato Darren Wood:

https://github.com/10gen-labs/socialite