сортировка по диапазону должна работать хорошо для вас. Первый запрос займет первые 10 элементов, отсортированных по дате:
db.articles.find({}).sort( { date : -1 } ).limit(10);
После этого вам нужно будет где-то сохранить дату последнего элемента и использовать идентификатор в следующем запросе на пейджинг:
db.articles.find({"date": {$lt: storedDateOfLastItem}}).sort( { date : -1 } ).limit(10);
Итак, я думаю, это должно сработать для вас. Для оценки общего количества страниц вам нужно будет использовать count .
Но, похоже, произойдет сбой, если какой-либо из отсортированных элементов будет удален.
Если вы удалите, например, статью со страницы № 1, то она наверняка прервет страницу № 2 из-за сохраненной последней даты, которая будет изменена. Чтобы избежать этого, вы можете оценить количество предметов, которые были до текущей сохраненной даты
db.articles.find({"date": {$gt: storedDateOfLastItem}}).sort( { date : -1 } ).count()
Если это количество было изменено (скажем, было удалено 2 сочленения). Вам нужно обновить storedDateOfLastItem
db.articles.find({"date": {$gt: storedDateOfLastItem}}).sort( { date : -1 } ).take(2)
Снова извлекаем хранимую переменную из элемента StorageDateOfLastItem из последнего элемента вышеупомянутого запроса и продолжайте делать пейджинг.
Но, по моему мнению, просто сохраните эту страницу без лишней логики, потому что я полагаю, что удаление статьи - редкая операция.
Из документации mongodb:
Расходы на пейджинг К сожалению, пропуск может быть (очень) дорогостоящим и требует
сервер, чтобы идти от начала коллекции, или индекса, чтобы получить
в положение смещения / пропуска, прежде чем он сможет начать возвращать страницу
данные (предел). По мере увеличения номера страницы пропуск станет медленнее и
более интенсивный процессор и, возможно, связанный с IO, с большими коллекциями.
Пейджинг на основе диапазона обеспечивает лучшее использование индексов, но не позволяет
Вы легко можете перейти на определенную страницу.