Projekt schematu bazy danych MongoDB

Poszedłbym z następującą strukturą:

1. Użyj jednej kolekcji dla wszystkich akcji, które miały miejsce, Actions

2. Użyj innej kolekcji dla tego, kto kogo obserwuje, Subscribers

3. Użyj trzeciej kolekcji, Newsfeed dla kanału wiadomości określonego użytkownika, elementy są rozdzielane z Actions kolekcja.

Newsfeed kolekcja zostanie wypełniona przez proces roboczy, który asynchronicznie przetwarza nowe Actions . Dlatego kanały informacyjne nie będą wypełniane w czasie rzeczywistym. Nie zgadzam się z Geert-Janem, że czas rzeczywisty jest ważny; Uważam, że większości użytkowników nie obchodzi nawet minutowe opóźnienie w większości (nie wszystkie) aplikacje (dla czasu rzeczywistego wybrałbym zupełnie inną architekturę).

Jeśli masz bardzo dużą liczbę consumers , rozłożenie może chwilę potrwać, prawda. Z drugiej strony umieszczenie konsumentów bezpośrednio w obiekcie nie zadziała również przy bardzo dużej liczbie obserwujących i stworzy zbyt duże obiekty, które zajmą dużo miejsca na indeksy.

Co jednak najważniejsze, projekt fan-out jest znacznie bardziej elastyczny i umożliwia ocenianie trafności, filtrowanie itp. Niedawno napisałem wpis na blogu o projektowaniu schematu kanału informacyjnego za pomocą MongoDB, w którym szczegółowo wyjaśniam niektóre z tych elastyczności.

Mówiąc o elastyczności, byłbym ostrożny ze specyfikacją activitystream.ms. Wydaje się, że ma to sens jako specyfikacja współdziałania różnych dostawców, ale nie przechowywałbym tych pełnych informacji w mojej bazie danych, o ile nie zamierzasz agregować działań z różnych aplikacji.