Design des MongoDB-Datenbankschemas

Ich würde mit der folgenden Struktur gehen:

1. Verwenden Sie eine Sammlung für alle Aktionen, die passiert sind, Actions

2. Verwenden Sie eine andere Sammlung dafür, wer wem folgt, Subscribers

3. Verwenden Sie eine dritte Sammlung, Newsfeed für den Newsfeed eines bestimmten Benutzers werden Elemente aus den Actions aufgefächert Sammlung.

Der Newsfeed -Sammlung wird von einem Arbeitsprozess gefüllt, der neue Actions asynchron verarbeitet . Daher werden Newsfeeds nicht in Echtzeit gefüllt. Ich stimme Geert-Jan darin nicht zu, dass Echtzeit wichtig ist; Ich glaube, die meisten Benutzer interessieren sich nicht einmal für eine Minute Verzögerung in den meisten (nicht alle) Anwendungen (für Echtzeit würde ich eine ganz andere Architektur wählen).

Wenn Sie eine sehr große Anzahl von consumers haben , das Auffächern kann eine Weile dauern, stimmt. Auf der anderen Seite funktioniert das Einfügen der Verbraucher direkt in das Objekt auch nicht mit sehr großen Followerzahlen und es werden übermäßig große Objekte erstellt, die viel Platz im Index einnehmen.

Am wichtigsten ist jedoch, dass das Fan-out-Design viel flexibler ist und ermöglicht Relevanzbewertung, Filterung usw. Ich habe erst kürzlich einen Blogbeitrag über das Design von Newsfeed-Schemas mit MongoDB geschrieben, in dem ich einige dieser Flexibilitäten ausführlicher erkläre.

Apropos Flexibilität, ich würde bei dieser Activitystream.ms-Spezifikation vorsichtig sein. Es scheint als Spezifikation für Interop zwischen verschiedenen Anbietern sinnvoll zu sein, aber ich würde nicht all diese ausführlichen Informationen in meiner Datenbank speichern, solange Sie nicht beabsichtigen, Aktivitäten von verschiedenen Anwendungen zusammenzufassen.