2012-06-27 15 views
12

Rozmyślam o dobrej strukturze dokumentu do obsługi aplikacji wiadomości.Struktura MongoDB dla aplikacji wiadomości

I w zasadzie potrzebne są trzy (lub cztery) rodzaje obiektów:

  1. użytkownika (nazwa użytkownika, adres e-mail, hasło, itd.)
  2. listy kontaktów (zawierających różne kontakty lub grupy kontaktów)
  3. rozmowa (rozmowa jest zbiorem komunikatów między niektórych osób)
  4. komunikatu (zawiera treść wiadomości, niektóre datownik i twórca.)

Mój pomysł był aby osadzić kontakty do dokumentu użytkownika i osadzić wiadomości w dokumencie konwersacji:

1. użytkownik

{ 
    username: 'dev.puS', 
    usernameCanonical: 'dev.pus', // used for unique constraints 
    email: '[email protected], 
    emailCanonical: '[email protected], 
    salt: 'some hash', 
    password: 'hash with salt', 
    logs: { last_login: 12.06.2008, last_password_reset: 04.03.2007 }, 
    state: { online: true, available: false }, 
    contacts: [ user_id1, user_id2, user_id3 ] 
} 

2. Rozmowa

{ 
    members: [ user_id1, user_id2 ], 
    messages: [ 
     { author: user_2, body: 'Hi what's up' }, 
     { author: user_1, body: 'Nothing out here :(' }, 
     { author: user_2, body: 'Whanna ask some question on stackoverflow' }, 
     { author: user_1, body: 'Okay, lets go' } 
    ] 
} 

Co sądzisz o tym schemacie?

Myślę, że lepiej byłoby je oddzielić (więc każdy dokument jest taki sam), ponieważ każdy dokument ma inną częstotliwość aktualizacji. Ale ja naprawdę nie mam żadnego doświadczenia na ten temat, więc dobrze byłoby usłyszeć kilka rad :)

Pozdrowienia

+2

schematu MongoDB nigdy nie jest „dobre” lub „złe” sam. Musisz szczegółowo określić zapytania i aktualizacje, które zamierzasz wprowadzić. Tylko wtedy możesz ocenić, czy dany schemat pasuje do tych schematów operacji. –

+1

Należy również oszacować rozkład rozmiarów danych, np .: ile wiadomości konwersacja będzie zawierała średnio? Może to być ważne, jeśli chcesz osadzić. –

+0

OK, będę o tym pamiętać. Czy jest to typowe podejście do pamięci podręcznej, na przykład wiadomości z redis, a następnie zapisać je wszystkie do mongo po zakończeniu sesji? Nie jestem pewien co do wykonywania wielu akcji zapisu do obiektu "nieustrukturyzowanego". –

Odpowiedz

4

Twoje pytanie jest naprawdę jednym z projektowania schematu. Sugeruję przyjrzenie się tej stronie na schemacie schematu MongoDB, aby uzyskać sens wyborów i kompromisów: http://www.mongodb.org/display/DOCS/Schema+Design

Ponadto prawdopodobnie powinieneś przejrzeć linki w sekcji "Zobacz także" tego dokumentu. Szczególnie polecam prezentacje wideo.

Wreszcie, powinieneś zapoznać się z tym dokumentem do dyskusji z trzech możliwych schematów dla wiadomości/komentowania bazę danych, w tym kompromisy dla każdego projektu: http://docs.mongodb.org/manual/use-cases/storing-comments/

7

widzę, że to pytanie jest stary, ale dla wszystkich zainteresowanych, podobne pytanie zostało zadane i jedna odpowiedź wygląda realną https://stackoverflow.com/a/30830429/132610

Conversation : { 
id: 123, 
members: [ user_id1, user_id2 ] 
} 
Message { conversationId: 123, author: user_2, body: 'Hi what's up' } 
Message { conversationId: 123, author: user_1, body: 'Whanna ask some question on stackoverflow' } 
+0

Mam zamieszanie w mojej głowie, ty (i wszyscy inni) powiedzieliście jedną kolekcję dla "Rozmowy" i inną kolekcję dla "Wiadomości".powiedzmy, że mamy 1 milion użytkowników wiadomości i rozmawiają ze sobą, tablica "Wiadomości" może sięgać miliardów miliardów dokumentów, czy mongoidy mają możliwość zarządzania tak dużą kolekcją dokumentów, a co z czasem reakcji na wyszukiwanie? powiedzmy, że szukamy 100 ostatnich wiadomości jednego użytkownika w miliardach miliardów wiadomości ile czasu zajmie nam przywrócenie? –

Powiązane problemy