Cần tư vấn về Lược đồ MongoDB cho Ứng dụng trò chuyện. Nhúng vs Các tài liệu liên quan

Question

Tôi bắt đầu một dự án MongoDB chỉ dành cho các cú đá và là một cơ hội để tìm hiểu các lược đồ MongoDB/NoSQL. Nó sẽ là một ứng dụng trò chuyện trực tiếp và ngăn xếp bao gồm: Rails 3, Ruby 1.9.2, Devise, Mongoid/MongoDB, CarrierWave, Redis, JQuery.

Tôi sẽ xử lý riêng hàng đợi cuộc trò chuyện/tin nhắn trò chuyện trực tiếp. Bạn chưa chắc chắn cách thức, hoặc là Node.js, APE hoặc ứng dụng EventMachine tùy chỉnh. Nhưng đối với Mongo, tôi đang nghĩ để sử dụng nó cho mọi thứ khác trong ứng dụng, cụ thể là các bản ghi trò chuyện và bảng điểm lịch sử.

Câu hỏi của tôi là cách tốt nhất để thiết kế lược đồ như tất cả kinh nghiệm trước đây của tôi là với MySQL và lược đồ DB quan hệ. Và như một câu hỏi phụ, khi nào thì tốt nhất là chúng tôi nhúng tài liệu với các tài liệu liên quan.

Ứng dụng sẽ có:

• Nhiều tài khoản đó có nhiều phòng
• Nhiều phòng
• Nhiều người sử dụng mỗi phòng
• Danh sách phòng một người dùng được phép có trong
• Nhiều cuộc trò chuyện của người dùng trên mỗi phòng
• Nhật ký trò chuyện có thể tìm kiếm trên cơ sở mỗi phòng và cho mỗi người dùng
• tập tin đính kèm tập tin tùy chọn cho một cuộc trò chuyện trao

Với Mông Cổ (ít nhất là cuối cùng thời gian tôi đã kiểm tra) có một giới hạn tài liệu của 4MB, tôi không nghĩ rằng có một bộ sưu tập cho các phòng và lưu trữ tất cả chat room như các văn bản nhúng sẽ hoạt động rất tốt.

Từ những gì tôi đã suy nghĩ về cho đến nay, tôi đang nghĩ đến việc làm một cái gì đó như:

• Một bộ sưu tập cho các tài khoản
• Một bộ sưu tập cho phòng
  • Mỗi phòng đều liên quan trở lại một tài khoản
  • Tài liệu liên quan trong bộ sưu tập trò chuyện cho tất cả các tin nhắn trò chuyện trong phòng
  • Tài liệu nhúng liệt kê tất cả người dùng hiện tại ông phòng
• Một bộ sưu tập cho người dùng
  • Document Embedded liệt kê tất cả các phòng người dùng hiện tại
  • Document Embedded liệt kê tất cả các phòng người dùng được phép có trong
• Bộ sưu tập cho các cuộc trò chuyện
  • Mỗi cuộc trò chuyện liên quan trở lại phòng trong bộ sưu tập phòng
  • Mỗi cuộc trò chuyện liên quan đến người dùng trong bộ sưu tập người dùng
  • Tài liệu được nhúng với thông tin về tệp đính kèm được tải lên tùy chọn.

mối quan tâm chính của tôi là bao xa để tôi đi cho đến khi kết thúc này lên trông như một lược đồ quan hệ và tôi đánh bại mục đích? Có chắc chắn là có liên quan nhiều hơn nhúng đang xảy ra.

Một mối quan ngại khác là việc tham chiếu tài liệu liên quan chậm hơn nhiều so với việc truy cập tài liệu được nhúng mà tôi đã nghe.

Tôi muốn làm cho các truy vấn chung chung như:

• Hãy cho tôi tất cả các phòng cho một tài khoản
• Hãy cho tôi tất cả các cuộc trò chuyện trong phòng (hoặc lọc qua phạm vi ngày)
• Hãy cho tôi tất cả chat từ một người dùng cụ
• Hãy cho tôi tất cả các file được tải lên trong một căn phòng nhất định hoặc cho một org cho
• vv

Bất kỳ đề xuất nào về cách cấu trúc giản đồ hiệu quả theo cách có quy mô? Cảm ơn mọi người.

Answer 1

Tôi nghĩ bạn đang đi đúng hướng. Tôi muốn sử dụng capped collection cho các dòng trò chuyện, với mỗi dòng chứa ID người dùng, ID phòng, dấu thời gian và nội dung được nói. Dữ liệu này sẽ hết hạn sau khi đạt đến "kết thúc" của bộ sưu tập, vì vậy nếu bạn cần một bản ghi lịch sử, bạn muốn sao chép dữ liệu ra khỏi bộ sưu tập được giới hạn vào bộ sưu tập "nhật ký" định kỳ, nhưng bộ sưu tập được giới hạn được thiết kế đặc biệt để ghi nhật ký- các ứng dụng kiểu mà bạn sẽ không xóa tài liệu và các vấn đề về thứ tự chèn. Trong trường hợp trò chuyện, đó là một trận đấu hoàn hảo.

Sự thay đổi duy nhất khác mà tôi đề xuất cũng sẽ là duy trì tải lên trong bộ sưu tập riêng biệt.

Answer 2

Tôi là người hâm mộ lớn của mongodb như một cơ sở dữ liệu tài liệu. Nhưng bạn có chắc bạn đang sử dụng mongodb vì lý do chính đáng? Mongodb mạnh là gì?

Đó là một câu hỏi chủ quan nhưng đối với tôi tại chỗ (nguyên tử) cập nhật trên tài liệu là những gì làm cho mongodb mạnh mẽ. Và tôi thực sự không thể thấy bạn sử dụng nó nhiều như vậy. Và trên hết, bạn đang gặp phải vấn đề về giới hạn kích thước tài liệu (Với kinh nghiệm tôi có thể cho bạn biết rằng việc nhúng các tệp vào mongodb không phải là một ý hay). Bạn muốn có một ứng dụng trò chuyện trực tiếp trên cơ sở dữ liệu.

Giản đồ tài liệu của bạn có vẻ hợp lý. Nhưng tôi sẽ không đi với mongodb cho loại dự án mà ứng dụng của bạn phụ thuộc rất nhiều vào chèn. Tôi sẽ đi cho CouchDB.

Với CouchDB bạn sẽ không phải lo lắng về sự cố tệp đính kèm, bạn có thể nhúng chúng dễ dàng. "_changes" sẽ làm cho cuộc sống của bạn dễ dàng hơn nhiều so với eighter xây dựng một ứng dụng chat trực tiếp/công cụ tìm kiếm/gộp hồ sơ dài (nếu bạn muốn thực hiện).

Và tôi thấy một số open source showcase project trên ghế dài. Nó có một số điểm tương đồng với mục tiêu của bạn: Anologue. Bạn nên kiểm tra xem nó ra.

PS: Xin lỗi, đó là một chủ đề nhỏ nhưng tôi không thể giữ bản thân mình.