Thiết kế lược đồ cơ sở dữ liệu MongoDB

Tôi đi với cấu trúc sau:

1. Sử dụng một bộ sưu tập cho tất cả các hành động đã xảy ra, Actions

2. Sử dụng một bộ sưu tập khác để biết ai theo dõi ai, Subscribers

3. Sử dụng bộ sưu tập thứ ba, Newsfeed đối với nguồn cấp tin tức của một người dùng nhất định, các mục được tạo ra từ Actions bộ sưu tập.

Newsfeed bộ sưu tập sẽ được điền bởi một quy trình công nhân xử lý không đồng bộ Actions mới . Do đó, các nguồn cấp tin tức sẽ không xuất hiện trong thời gian thực. Tôi không đồng ý với Geert-Jan rằng thời gian thực là quan trọng; Tôi tin rằng hầu hết người dùng không quan tâm đến dù chỉ một phút chậm trễ trong hầu hết (không phải tất cả) ứng dụng (trong thời gian thực, tôi chọn một kiến ​​trúc hoàn toàn khác).

Nếu bạn có một số lượng rất lớn consumers , việc fan-out có thể mất một lúc, đúng như vậy. Mặt khác, việc đưa người tiêu dùng vào ngay đối tượng cũng sẽ không hoạt động với số lượng người theo dõi quá lớn và nó sẽ tạo ra các đối tượng quá lớn, chiếm nhiều không gian chỉ mục.

Tuy nhiên, quan trọng nhất, thiết kế quạt ra linh hoạt hơn nhiều và cho phép chấm điểm mức độ liên quan, lọc, v.v. Gần đây, tôi vừa viết một bài đăng trên blog về thiết kế lược đồ nguồn cấp tin tức với MongoDB, nơi tôi giải thích một số tính linh hoạt đó một cách chi tiết hơn.

Nói về tính linh hoạt, tôi sẽ cẩn thận về thông số activitystrea.ms đó. Nó có vẻ hợp lý khi là một đặc tả để tương tác giữa các nhà cung cấp khác nhau, nhưng tôi sẽ không lưu trữ tất cả thông tin dài dòng đó trong cơ sở dữ liệu của mình miễn là bạn không có ý định tổng hợp các hoạt động từ các ứng dụng khác nhau.