Návrh schématu databáze MongoDB

Použil bych následující strukturu:

1. Použijte jednu sbírku pro všechny akce, které se staly, Actions

2. Použijte jinou sbírku pro toho, kdo koho sleduje, Subscribers

3. Použijte třetí sbírku, Newsfeed pro zdroj zpráv určitého uživatele jsou položky rozbaleny z Actions kolekce.

Newsfeed kolekce bude naplněna pracovním procesem, který asynchronně zpracovává nové Actions . Zpravodajské kanály se proto nebudou plnit v reálném čase. Nesouhlasím s Geert-Janem v tom, že reálný čas je důležitý; Domnívám se, že většina uživatelů většinu nezajímá ani minutu zpoždění (ne všechny) aplikace (pro reálný čas bych zvolil úplně jinou architekturu).

Pokud máte velmi velký počet consumers , fan-out může chvíli trvat, pravda. Na druhou stranu, umístění spotřebitelů přímo do objektu nebude fungovat ani s velmi velkým počtem sledujících a vytvoří příliš velké objekty, které zaberou hodně místa v indexu.

Nejdůležitější však je, že vějířovitý design je mnohem flexibilnější a umožňuje hodnocení relevance, filtrování atd. Nedávno jsem napsal blogový příspěvek o návrhu schématu zpravodajského kanálu s MongoDB, kde podrobněji vysvětluji některé z této flexibility.

Když už mluvíme o flexibilitě, byl bych opatrný ohledně té specifikace activitystrea.ms. Zdá se, že to dává smysl jako specifikace interoperability mezi různými poskytovateli, ale neukládal bych všechny ty podrobné informace do své databáze, pokud nehodláte shromažďovat aktivity z různých aplikací.