Lý lịch
Tôi đang làm việc trên một ứng dụng cho một khách hàng bao gồm một số tính năng mạng xã hội. Ban đầu tôi đã phát triển front-end di động, nhưng hoàn cảnh cũng khiến tôi phụ trách phát triển back end.
Là một nền tảng chung, hệ thống của chúng tôi cho phép người dùng theo dõi những người dùng khác và nhận thông báo về những người họ đang theo dõi, như bạn mong đợi từ một mạng xã hội. Một cảnh báo là chỉ có một tập hợp con nhỏ (nhiều nhất là vài trăm) người dùng sẽ được theo dõi, với mong muốn rằng hầu hết các cơ sở người dùng sẽ theo dõi ít nhất một trong số những cá nhân này.
Về phía UI, chúng tôi sẽ có một nút thông báo với một số trên đó và nhấp vào nút sẽ đưa bạn đến màn hình thông báo.
Vấn đề
Tôi đã nghiên cứu các chiến lược để thực hiện thông báo và hầu hết các tài nguyên mà tôi đã tìm thấy để tạo một hoặc nhiều bảng thông báo trong cơ sở dữ liệu. (Một ví dụ tôi thích là câu trả lời được chấp nhận ở đây: /programming/9735578/building-a-notification-system ).
Điều khiến tôi thất vọng là hầu hết các chiến lược dựa trên cơ sở dữ liệu cho các thông báo đều yêu cầu chèn một hàng cho mỗi thông báo cho mỗi người theo dõi. Vì vậy, nếu một nghìn người đang theo dõi Sally, chúng tôi sẽ chèn một nghìn hàng vào bảng tương ứng. Là khả năng mở rộng? Điều gì xảy ra nếu chúng ta đến điểm mà hàng chục hoặc hàng trăm ngàn người dùng đang theo dõi Sally và cô ấy đang tạo ra vài chục bài đăng mỗi ngày?
Ý tưởng ban đầu của tôi là xử lý mọi thứ bằng các truy vấn: số trên nút thông báo sẽ có được bằng cách yêu cầu số hàng trên nội dung được đăng gần đây hơn lần trước bạn truy cập màn hình thông báo, trong khi thông báo riêng lẻ sẽ được tạo từ các truy vấn chi tiết hơn khi bạn truy cập màn hình thông báo. Cách tiếp cận này sẽ không yêu cầu ghi hoặc lưu trữ thêm, nhưng không linh hoạt và có thể sẽ làm hỏng máy chủ khá khó khăn.
THIẾT LẬP
Phần cuối (được thiết lập bởi nhà phát triển trước) sử dụng CodeIgniter và cơ sở dữ liệu MySQL . Nó hiện đang chạy trên một tài khoản lưu trữ chia sẻ GoDaddy xảo quyệt, nhưng tôi cho rằng (hy vọng?) Điều này sẽ được nâng cấp trước khi chúng tôi đi vào sản xuất và gói lưu trữ sẽ được tăng quy mô với sự tăng trưởng của người dùng.
Hiện tại mặt trước duy nhất của chúng tôi là một ứng dụng di động, nhưng chúng tôi cũng có kế hoạch xây dựng một trang web sau này. Tôi không quan tâm tại thời điểm này với việc nhận được các bản cập nhật đẩy thời gian thực từ máy chủ về các thông báo.
ĐỊA CHỈ
Tôi không chuyên về phụ trợ và tôi ở trên đầu trong bộ phận đó. Khách hàng biết điều đó và tôi đã cố gắng hết sức để giải thích phạm vi của một dự án có tính chất này, nhưng họ đã nói rõ rằng tại thời điểm này, họ sẽ không tin tưởng bất kỳ ai khác làm việc trong dự án. Chúng tôi có thể có một tháng làm việc nữa trước khi chúng tôi có thể bắt đầu thêm người kiểm tra và tôi có thể nhận được bất kỳ loại số liệu hiệu suất nào. Tôi thực sự không thể ước tính có bao nhiêu người dùng chúng tôi có thể có hoặc phần cứng nào chúng tôi có thể có trong 5 năm tới, nhưng tôi nghĩ rằng khách hàng đang hy vọng cho hàng trăm ngàn người dùng trở lên.
Tôi hy vọng điều này đủ cụ thể về một vấn đề sẽ được đăng ở đây; Tôi có thể tinh chỉnh nó nếu cần. Vui lòng hỏi nếu bạn có bất kỳ câu hỏi hoặc tôi đã bỏ qua các chi tiết quan trọng.
tl; dr
- Hệ thống thông báo dựa trên cơ sở dữ liệu có tác động tiêu cực đến khả năng mở rộng dài hạn khi tất cả người dùng chỉ theo dõi một vài trong số vài trăm người không?
- Có cách nào để làm cho cơ sở dữ liệu thông báo được điều khiển mà không cần một hàng thông báo riêng cho mỗi thông báo cho mỗi người theo dõi không?
- Một hệ thống thông báo hoàn toàn dựa trên truy vấn sẽ có thể mở rộng hoặc có bất kỳ lợi thế nào ngoài việc không ghi bất kỳ dữ liệu nào vào DB?
- Tôi có lật đổ điều này quá sớm không? Tôi có nên xây dựng một cái gì đó hoạt động được không và chúng tôi có thể lo lắng về việc tối ưu hóa nó nếu nó trở thành một vấn đề, do khách hàng có ngân sách hạn chế và chúng tôi chưa biết liệu sản phẩm cuối cùng có phổ biến không?