MongoDB databaseschema-ontwerp

Ik zou voor de volgende structuur gaan:

1. Gebruik één verzameling voor alle acties die hebben plaatsgevonden, Actions

2. Gebruik een andere verzameling voor wie wie volgt, Subscribers

3. Gebruik een derde verzameling, Newsfeed voor de nieuwsfeed van een bepaalde gebruiker worden items uitgespreid uit de Actions collectie.

De Newsfeed collectie wordt gevuld door een werkproces dat asynchroon nieuwe Actions verwerkt . Daarom worden nieuwsfeeds niet in realtime gevuld. Ik ben het niet met Geert-Jan eens dat realtime belangrijk is; Ik geloof dat de meeste gebruikers geen minuut vertraging geven in de meeste (niet alle) applicaties (voor realtime zou ik een heel andere architectuur kiezen).

Als u een zeer groot aantal consumers heeft , het uitwaaieren kan even duren, dat is waar. Aan de andere kant zal het ook niet werken om de consumenten rechtstreeks in het object te plaatsen met zeer grote aantallen volgers, en het zal te grote objecten creëren die veel indexruimte in beslag nemen.

Het belangrijkste is echter dat het uitwaaierende ontwerp veel flexibeler is en maakt relevantiescores, filtering, enz. mogelijk. Ik heb onlangs een blogpost geschreven over het ontwerpen van nieuwsfeedschema's met MongoDB, waarin ik een deel van die flexibiliteit in meer detail toelicht.

Over flexibiliteit gesproken, ik zou voorzichtig zijn met die activitystream.ms-specificatie. Het lijkt logisch als een specificatie voor interoperabiliteit tussen verschillende providers, maar ik zou al die uitgebreide informatie niet in mijn database opslaan zolang je niet van plan bent activiteiten van verschillende applicaties samen te voegen.