mongo db design di seguito e feed, dove dovrei incorporare?

Question

Ho una domanda di base su dove dovrei incorporare una raccolta di follower/following in un db mongo. Ha senso avere una raccolta incorporata di seguito in un oggetto utente, ma ha anche senso incorporare anche la raccolta di follower converse? Ciò significherebbe che avrei dovuto aggiornare e incorporare nel record profilo sia del:

1. seguente elenco incorporato nel seguace
2. E i seguaci lista incorporata del followee

posso' Garantire l'atomicità su questo, a meno che non mantenga in qualche modo lo stato di una transazione o di aggiornamento da qualche parte. Vale la pena di incorporarlo in entrambe le entità oppure devo semplicemente aggiornare il n. 1, incorporare il profilo del follower e inserirvi un indice in modo da poter interrogare i converser-followers su tutti i profili? La performance colpisce troppo?

È un candidato per una raccolta che non dovrebbe essere incorporata? Dovrei avere solo una collezione di spigoli dove conservo seguendo nella sua collezione con followerid e followingbyId?

Ora, se devo aggiornare un feed a entrambi gli utenti quando vengono seguiti o seguono, come dovrei organizzarlo?

Per quanto riguarda il caso d'uso, l'utente vedrà le persone che sta seguendo durante la visualizzazione dei feed, cosa che accade abbastanza spesso, e vedrà anche i follower di un profilo quando visualizzano i dettagli del profilo di chiunque, cosa che capita spesso ma non abbastanza quanto il 1 ° caso. In entrambi i casi, il numero totale di follower e follower appare su ogni pagina del profilo.

Answer 1

In generale, è una cattiva idea di incorporare seguente/seguiti da relazioni in documenti degli utenti, per diversi motivi:

(1) v'è un limite di dimensione massima del documento di 16 MB, ed è plausibile che un popolare l'utente di un sito ben sottoscritto potrebbe finire con centinaia di migliaia di follower, che si avvicinano alla dimensione massima del documento,

(2) le relazioni di followership cambiano frequentemente, e quindi il caso in cui un utente guadagna un sacco di follower traduce nella crescita di documenti ripetuti se si incorporano follower. La frequente crescita dei documenti ostacolerà significativamente le prestazioni di MongoDB, e quindi dovrebbe essere evitata (una crescita occasionale dei documenti, in particolare i documenti tendono a raggiungere una dimensione finale stabile, è meno penalizzante).

Quindi, sì, è meglio suddividere la seguente relazione seguito/seguito in una raccolta separata di record ognuno con due campi, ad esempio {_id:, oid:}, con indici su _id (per "chi" sto seguendo? "query) e oid (per la query" chi mi sta seguendo? "). Qualsiasi modifica di stato individuale è modellata da un'aggiunta o rimozione di un singolo documento, sebbene se si visualizzino anche cose come i conteggi dei follower, probabilmente si dovrebbero tenere contatori separati che si aggiornano dopo l'inserimento/eliminazione di un margine.

(Naturalmente, questo presuppone i requisiti aziendali consentono una certa flessibilità sui dettagli coerenza: in generale, se il codice di visualizzazione dice un utente lui ha 304 seguaci e poi procede per enumerare loro, solo l'utente più esigenti controllerà che i follower hanno elencato fino a 304. Se i requisiti aziendali richiedono una coerenza assoluta, avrete bisogno di un database che isola le transazioni per voi, altrimenti dovrete fare il conteggio voi stessi come parte della visualizzazione di tutte le identità degli utenti.)