Sắp xếp phạm vi hoạt động tốt cho bạn. yêu cầu đầu tiên sẽ mất 10 hạng mục đầu tiên được sắp xếp theo ngày:
db.articles.find({}).sort({ date : -1 }).limit(10);
Sau này, bạn sẽ cần phải lưu trữ ở đâu đó ngày mục cuối cùng và sử dụng id trong yêu cầu phân trang tiếp theo:
db.articles.find({"date": {$lt: storedDateOfLastItem}}).sort({ date : -1 }).limit(10);
Vì vậy, tôi đoán nó nên làm việc tốt cho bạn. Để ước tính tổng số trang bạn cần sử dụng count.
Nhưng dường như không thành công nếu có bất kỳ mục được sắp xếp nào bị xóa.
Nếu bạn sẽ xóa bài viết ví dụ từ trang # 1, hãy chắc chắn rằng trang ngắt # 2 vì ngày cuối cùng được lưu trữ sẽ bị thay đổi. Để tránh điều này, bạn có thể ước tính số lượng mặt hàng trước ngày đã lưu hiện tại
db.articles.find({"date": {$gt: storedDateOfLastItem}}).sort({ date : -1 }).count()
Nếu số này bị thay đổi (giả sử 2 đã bị loại bỏ). Bạn cần cập nhật storedDateOfLastItem
db.articles.find({"date": {$gt: storedDateOfLastItem}}).sort({ date : -1 }).take(2)
Một lần nữa lưu trữDateOfLastItem từ mục cuối cùng trên yêu cầu và tiếp tục phân trang.
Nhưng ý kiến của tôi chỉ giữ phân trang này vì nó không có logic bổ sung, bởi vì tôi cho rằng việc xóa bài viết là hoạt động hiếm.
Từ tài liệu MongoDB:
Chi phí Paging Thật không may bỏ qua có thể được (rất) tốn kém và đòi hỏi máy chủ để đi bộ từ đầu của bộ sưu tập, hoặc chỉ số, để có được để bù đắp vị trí/skip trước khi nó có thể bắt đầu trả lại trang của dữ liệu (giới hạn). Khi số trang tăng, bỏ qua sẽ trở nên chậm hơn và nhiều CPU hơn, và có thể IO bị ràng buộc, với các bộ sưu tập lớn hơn.
Phân trang dựa trên phạm vi cung cấp việc sử dụng chỉ mục tốt hơn nhưng không cho phép bạn dễ dàng chuyển đến một trang cụ thể.
chấp nhận câu trả lời và đóng câu hỏi này – beNerd