Progettazione dello schema del database MongoDB

Andrei con la seguente struttura:

1. Usa una raccolta per tutte le azioni che sono avvenute, Actions

2. Usa un'altra raccolta per chi segue chi, Subscribers

3. Utilizza una terza raccolta, Newsfeed per il feed di notizie di un determinato utente, gli elementi vengono aperti a ventaglio da Actions raccolta.

Il Newsfeed la raccolta verrà popolata da un processo di lavoro che elabora in modo asincrono le nuove Actions . Pertanto, i feed di notizie non verranno popolati in tempo reale. Non sono d'accordo con Geert-Jan sul fatto che il tempo reale è importante; Credo che alla maggior parte degli utenti non importi nemmeno un minuto di ritardo nella maggior parte (non tutte) le applicazioni (per il tempo reale, sceglierei un'architettura completamente diversa).

Se hai un numero molto elevato di consumers , il fan-out può richiedere del tempo, vero. D'altra parte, inserire i consumatori direttamente nell'oggetto non funzionerà nemmeno con conteggi di follower molto grandi e creerà oggetti eccessivamente grandi che occupano molto spazio nell'indice.

Ancora più importante, tuttavia, il design a ventaglio è molto più flessibile e consente il punteggio di pertinenza, il filtraggio, ecc. Di recente ho scritto un post sul blog sulla progettazione di schemi di feed di notizie con MongoDB in cui spiego parte di questa flessibilità in modo più dettagliato.

Parlando di flessibilità, starei attento a quelle specifiche di activitystream.ms. Sembra avere senso come specifica per l'interoperabilità tra diversi provider, ma non memorizzerei tutte quelle informazioni dettagliate nel mio database fintanto che non intendi aggregare attività da varie applicazioni.