MongoDB: come progettare follower in stile twitter/seguendo il modello di relazione in MongoDB?

Question

Sto sviluppando un'applicazione mobile Android che potenzialmente ha un sacco di utenti (diciamo circa 1 milione). Questi utenti possono seguire altri utenti (come Twitter). L'app sincronizza i dati dell'utente tramite un backend remoto REST. I dati dell'utente stesso sono mantenuti in un database orientato ai documenti (nel mio caso è un MongoDB).

Attualmente mi chiedo del modo migliore di progettare il modello utente, inclusi i suoi follower e le seguenti relazioni. Il primo pensiero è stato quello di incorporare le relazioni all'interno del documento dell'utente.

Esempio documento utente:

{ 
"_id":"50fd6bb530043e3c569af288", 
"name":"Marsha Garcia", 
"follower"["50fd6bb530043e3c569af287","50fd6bb530043e3c569af289","50fd6bb530043e3c569af28c"], 
"following":["70fd6bb530043e3c569af289","10fd6bb530043e3c569af222","89fd6bb530043e3c569af45o"] 
} 

La cosa positiva è che il seguito/seguenti rapporti sono già uniti con l'utente. Tuttavia diciamo che un utente segue circa 100.000 o più altri utenti. Quindi la dimensione del documento diventerà molto grande. Se carico questo oggetto utente tramite il servizio REST nella mia app mobile, potrebbe volerci un po 'di tempo. Inoltre, nel peggiore dei casi il documento dell'utente potrebbe superare il limite del documento di MongoDb 16MB.

Quindi il mio secondo pensiero era di modellare il seguace e seguire le relazioni in un modo più classico: un documento in più contenente le seguenti relazioni di ciascun utente.

'relazione utente' documento

Esempio:

La cosa positiva è che la dimensione di ciascun documento utente rimarrà costante. Il rovescio della medaglia è che con molti utenti e con le seguenti relazioni posso facilmente ottenere milioni di voci nella mia raccolta 'user relationship' di MongoDB. Ovviamente imposterò un indice sui campi ma non sono abbastanza sicuro che questa soluzione si riduca molto bene per quanto riguarda il caso d'uso di un utente di app che chiede i suoi/suoi attuali follower.

Apprezzerei qualsiasi pensiero, esperienza sul mio problema di modellazione. Forse qualcuno ha anche un approccio di soluzione migliore.

Thx molto in anticipo.

Answer 1

1. collection users: 
- userid 
- username 
- userpass 
- other user specific info user 


2. collection following: 
- userid 
- [array of followingid] 


3. collection followed: 
- userid 
- [array of followedid] 
4. messages_relation collection: 

- userid 
- messageid 
- time 

5. messages_text: 
- messageid 
- text 

Answer 2

mi piacerebbe iniziare con la lettura this documentazione sulla conservazione commenti in un CMS, se non l'hai già. Mentre è per i commenti, esiste lo stesso problema generale, in cui non è possibile memorizzare tutti i commenti in un singolo documento (nel tuo caso, follower/following).

O l'approccio Ibrido (che utilizza meno documenti e memorizza un numero di relazioni all'interno di un singolo documento) o l'approccio che stai descrivendo dovrebbe funzionare bene.

Suggerirei anche di creare un POC semplice per testare le prestazioni dei retrieval e così via. Potrebbe avere senso memorizzare nella cache alcuni risultati o precompilarli. Di solito, va bene in sistemi come questo se tutto non è immediatamente coerente per tutti gli utenti (come avere il conteggio follower corretto subito).

Probabilmente non è una soluzione perfetta e potrebbe richiedere alcune soluzioni per prestazioni ottimali (ad esempio, come un utente e i follower vengono gestiti possono cambiare in base all'aumento del numero di follower, ad esempio).

Answer 3

si consiglia di controllare flockDB un database che memorizza gli elenchi di regolarizzazione. https://github.com/twitter/flockdb