2012-06-27 29 views
12

Tôi đang suy nghĩ về một cấu trúc tài liệu tốt để xử lý ứng dụng tin nhắn.Cấu trúc MongoDB cho ứng dụng nhắn tin

tôi về cơ bản cần ba (hoặc bốn) loại đối tượng:

  1. Người dùng (username, email, mật khẩu, vv)
  2. Danh sách liên lạc (có chứa địa chỉ liên lạc khác nhau hoặc địa chỉ liên lạc nhóm)
  3. Cuộc trò chuyện (cuộc trò chuyện là tập hợp các tin nhắn giữa một số người)
  4. Tin nhắn (chứa nội dung tin nhắn, một số dấu thời gian và người tạo.)

Ý tưởng của tôi là để nhúng các điểm tiếp xúc vào tài liệu sử dụng và nhúng các thông điệp trong một tài liệu hội thoại:

1. Người sử dụng

{ 
    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. Đối thoại

{ 
    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' } 
    ] 
} 

Bạn nghĩ gì về lược đồ này?

Tôi nghĩ sẽ tốt hơn nếu giữ chúng tách biệt (vì vậy mỗi tài liệu cho riêng nó) vì mỗi tài liệu có tần suất cập nhật khác nhau. Nhưng tôi thực sự không có bất kỳ kinh nghiệm về nó để nó sẽ là tốt để nghe một số lời khuyên :)

Trân

+2

Lược đồ MongoDB không bao giờ "tốt" hoặc "xấu". Bạn cần nêu chi tiết các truy vấn và cập nhật bạn sẽ thực hiện. Chỉ khi đó bạn mới có thể đánh giá nếu một lược đồ đã cho phù hợp với các mẫu hoạt động này. –

+1

Bạn cũng cần phải ước tính phân phối kích thước dữ liệu, ví dụ: số lượng cuộc hội thoại sẽ có tối đa bao nhiêu tin nhắn? Điều này có thể quan trọng nếu bạn muốn nhúng. –

+0

OK, tôi sẽ ghi nhớ điều này. Đây có phải là một cách tiếp cận phổ biến cho bộ nhớ cache ví dụ như các thông báo có redis và lưu tất cả chúng vào mongo khi phiên kết thúc? Tôi có một chút không chắc chắn về việc thực hiện rất nhiều hành động viết cho một đối tượng "không có cấu trúc" –

Trả lời

4

Câu hỏi của bạn thực sự là một trong những thiết kế giản đồ. Tôi khuyên bạn nên xem trang này trên thiết kế lược đồ MongoDB để có được ý nghĩa về các lựa chọn và sự cân bằng: http://www.mongodb.org/display/DOCS/Schema+Design

Ngoài ra, bạn nên xem lại các liên kết trong phần 'Xem thêm' của tài liệu đó. Tôi đặc biệt giới thiệu các bản trình bày video.

Cuối cùng, có lẽ bạn nên xem xét tài liệu này để thảo luận về ba schemas có thể cho một tin nhắn/cho ý kiến ​​cơ sở dữ liệu, bao gồm cả thương mại-offs cho mỗi thiết kế: http://docs.mongodb.org/manual/use-cases/storing-comments/

7

Tôi thấy rằng câu hỏi này là cũ, nhưng đối với bất kỳ ai quan tâm, một câu hỏi tương tự đã được hỏi và một câu trả lời có vẻ khả thi 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

Tôi có một sự nhầm lẫn trong tâm trí của tôi, bạn (và tất cả mọi người khác) đã nói một bộ sưu tập cho 'Conversations' và một Collection khác cho' Messages'.giả sử chúng ta có 1 triệu người dùng trong tin nhắn và họ đang nói chuyện với nhau, bảng 'Messages' có thể đạt tới hàng tỷ tỷ tài liệu, mongodb có khả năng quản lý bộ sưu tập tài liệu lớn và thời gian phản hồi tìm kiếm không? giả sử chúng ta tìm kiếm 100 tin nhắn cuối cùng một người dùng duy nhất trong hàng tỷ tỷ tin nhắn sẽ mất bao nhiêu thời gian để quay trở lại? –

Các vấn đề liên quan