2011-06-29 13 views
7

Wiem, że podobne pytania zostały zadane, ale szukają bardzo podstawowej odpowiedzi na podstawowe pytanie. Jestem nowy w MongoDB i robię aplikację w stylu Twittera (blogi, obserwatorzy itd.) I zastanawiam się, jaki najlepszy schemat użyć.Najlepszy schemat MongoDB dla klonu twitter?

Teraz mam (na wysokim poziomie):

Member { 
    login: string, 
    pass: string, 
    posts: [ 
    { 
     title: string, 
     blog: string, 
     comments: [ { comment: string } ] 
    } 
    ] 
} 

Jest więcej do niego, ale to daje pomysł. Problem polega na tym, że chcę dodać funkcję "obserwuj" i nie jestem pewien, jaką trasę wybrać najlepiej.

Mogę dodać "dołączony" dokument do elementu członkowskiego, ale nie jestem pewien, używając mongoDB, jaka byłaby najmądrzejsza metoda. Moim głównym pomysłem będzie oczywiście główna strona "feed", na której zobaczysz wszystkie osoby, które obserwujesz.

Odpowiedz

0

To pytanie jest tym samym, jak szeroko stosowane w postach na blogu i jak modelować posty i komentarze na blogu. Trzeba po prostu zastosować te same pojęcia tutaj. Dostępne są następujące opcje:

  • osadzone dokumenty
  • dedykowane kolekcji i wykonywanie wielu zapytań

Plusy i minusy były szeroko omawiane. Osadzone dokumenty mogą mieć tylko 16 MB i nie można zwrócić pojedynczych części dopasowanej macierzy w MongoDB ... dokonać wyboru.

Nie idzie dalej, bo jak już powiedziano: to samo pytanie zostało omówione w licznych pytaniach na temat "projektu schematu". Wystarczy google "Schema Design MongoDB" lub poszukać tego samego na SO.

+0

Proste blogi lub tweety, które otrzymuję, ale nie są w żaden sposób takie same, jak o to pytam. Moje jedyne pytanie dotyczy dodania funkcji "follow". To, czego szukam, to ktoś, kto ma więcej opinii na temat najlepszego sposobu, by go skonfigurować. Dla funkcji "obserwuj" muszę albo wymienić w dokumentach członków wszystkich ludzi, których obserwują, albo mogę zamiast tego umieścić wszystkie osoby, które ich śledzą itp. Klony Twittera, które widziałem, tylko zajmują się dodawaniem "tweet" lub blog. Żadna z nich nie dotyka trudniejszego problemu z ustanowieniem "podążania". – MrBojangles

+0

Nie można wyodrębnić podanych rozwiązań problemu z punktu widzenia modelu danych. Obsługa relacji z każdej natury w MongoDB poprzez dedykowane kolekcje lub osadzone dokumenty. Każda dokumentacja wyjaśnia to. Proszę, zastosuj to do swojego problemu. –

+0

Chociaż nie zgadzam się, że schemat twittera będzie przypominał schemat bloga, że ​​blisko ogólny temat był szeroko dyskutowany, więc kilka google tu i tam powinno cię zabrać. –

0

Dodanie tablicy "podążającej" do dokumentu członkowskiego powinno działać dobrze. Powinien zawierać identyfikatory użytkowników osób obserwowanych przez użytkownika. Twój kod będzie musiał pobrać listę i skonstruować zapytanie, które będzie pobierać tweety tych użytkowników. Ponieważ Mongo nie jest relacyjne, nie ma możliwości skonstruowania zapytania, które dołącza do kolekcji Member i Tweet i robi to w jednym zapytaniu, ale powinieneś być w stanie zmniejszyć obciążenie sieci, wykonując to na serwerze bazy danych, używając wykonywania kodu po stronie serwera : http://www.mongodb.org/display/DOCS/Server-side+Code+Execution.

+1

Zarówno wykonanie kodu po stronie serwera, jak i potencjalnie duże, stale rosnące macierze osadzone powinny być używane oszczędnie w środowiskach produkcyjnych, w których obciążenie może być znaczne. –

+0

Wydaje się, że dałeś temu więcej uwagi niż ja, @Remon. Trochę o ciągle rosnących tablicach ma sens, ale nie widzę, jak wykonanie kodu po stronie serwera byłoby gorsze od dwóch podróży w obie strony na serwer. –

+1

Jest to mniej niż oczywiste, ale wynika to z faktu, że silnik JS w Mongo jest jednokrotnym gwintem i dlatego nie może wykorzystać wszystkich dostępnych zasobów procesora. Nawet mapa/zmniejszenie obecnie cierpi z tego powodu (co jest dziwne, ponieważ zostało w zasadzie wynalezione z myślą o równoległości). Jeśli ten skrypt po stronie serwera jest używany częściej niż pojedynczy rdzeń, który może go przetworzyć, zacznie spowalniać cały serwer. Więc tak, w niektórych przypadkach dwie wycieczki w obie strony są w rzeczywistości szybsze, a przynajmniej łatwiejsze do skalowania;) Tak jak w przypadku wszystkich testów, sprawdź i sprawdź, co działa najlepiej. –

10

To nie jest idealny schemat dla klona Twittera. Głównym problemem jest to, że "posty" to stale rosnąca sieć, co oznacza, że ​​mongo będzie musiał przenosić twój masywny dokument co kilka postów, ponieważ zabrakło dopełnienia dokumentu. Ponadto istnieje twardy (16 MB) limit rozmiaru dokumentów, co czyni ten schemat w najlepszym wypadku restrykcyjnym.

Idealny schemat zależy od tego, czy oczekujesz obciążenia Twittera. "Doskonały" schemat mongodów pod względem łatwości obsługi i łatwości użycia nie jest tym samym, co ten, którego użyłbym do czegoś z przepustowością Twittera. Na przykład w pierwszym przypadku użyłbym kolekcji postów z dokumentem na post. W scenariuszu o wysokiej przepustowości zacznę tworzyć dokumenty zbiorcze dla małych grup postów (np. Jedna na stronę "uzyskaj więcej"). Dodatkowo w scenariuszu o wysokiej przepustowości trzeba było aktualizować linię czasu osoby obserwującej w osobnych dokumentach osi czasu użytkownika, podczas gdy w scenariuszach o niskiej przepustowości można po prostu zapytać o nie.

+0

Dobra rada, @Remon, ale pytanie OP nie dotyczyło tablicy "wpisów". On/ona wspomniał, że jest to uproszczona wersja schematu, a pytanie brzmi, jak wdrożyć następujące. –

+0

Dzięki @Remon to świetna informacja. Strona nigdy nie będzie musiała skalować do poziomu, jaki robi Twitter, ale nie jest też przeznaczona dla małej witryny. Musi być w stanie skalować, ale nic szalonego. I jak wspomniałem @Martin Vilcans, wszelkie dane wejściowe dotyczące "następującego" aspektu byłyby świetne. Ale informacje, które podałeś, już pomagają. Myślę, że obawiam się, że uda mi się nawiązać relacje, więc może mi to zaszkodzić. – MrBojangles

+0

Niestety, błędnie przeczytałem pierwotne pytanie. Następująca powinna być zaimplementowana przez osadzoną tablicę zgodnie z sugestią, ponieważ stosunkowo trudno jest osiągnąć 16-gigabajtowy limit za pomocą tylko tablicy UUID. Jeśli planujesz przykleić wiele innych danych do kolekcji użytkowników, możesz umieścić tablicę followes w dedykowanych dokumentach dla każdego użytkownika. Następnie, gdy użytkownik wpisze nowy post asynchronicznie (użyj kolejki komunikatów w kolejce obciążenia/modelu konsumenta), aby iterować po tej tablicy i zaktualizować osie czasu wszystkich obserwatorów. Pozwala to na niemal nieograniczone skalowanie i jest zbliżone do obecnej architektury Twittera. –