Подреждане по subjectID
Ако вашият subjectID е (или може да бъде променено на) монотонно нарастваща стойност (например MongoDB ObjectID по подразбиране), имате ясна опция, като използвате нормален find() с подходящо сортиране, пропускане и ограничение. В този случай можете да търсите документи с идентификатори на обект $gte (по-голямо или равно на)
вашият subjectID :
var page = 1;
var subjectID = ObjectId("515535a0760fe8735f5f6897");
db.users.find(
{ _id: { $gte : subjectID } }
).sort({'_id':1}).skip(page*20).limit(20)
Рамка за агрегиране
Както при MongoDb 2.4, няма такава функция в Aggregation Framework, която да съответства въз основа на позицията на документа в конвейера на резултатите. Можете да подадете предложение за нова функция в SERVER на проекта MongoDB Jira опашка.
Изглежда, че бихте искали нов оператор на тръбопровод като $matchfrom което би игнорирало всички документи до първото срещане на $matchfrom критерии. След това можете да добавите $limit за да вземете следващите n елемента. Също така бихте искали да имате сортиран изход преди $matchfrom така че има предвидим резултат.
Това изглежда прекалено сложно в сравнение с наличието на нарастващ subjectID, но може да има случай на използване за извършване на страниране въз основа на по-усъвършенствани критерии за търсене или резултати, изчислени в конвейера за агрегиране.
Алтернативни подходи
Освен бъдещата поддръжка за такава функция в Aggregation Framework, имате няколко опции за прилагане на същия подход за съвпадение в кода:
-
използвайте по-стария
group()команда за агрегиране сfinalize()функция. ЗАБЕЛЕЖКА:group()правине работа с разделени клъстери. -
използвайте MapReduce и
finalize()функция -
извлечете целия набор от резултати от рамката за агрегиране и внедрите съпоставянето/намаляването на резултатите в кода на вашето приложение (въпреки че това донякъде обезсмисля идеята за "странициране", ако извличате всички страници за всяка заявка).
Съображения за производителност
Заявки с skip все още трябва да прочетете междинните записи на индекса, така че пропускането на голям брой документи няма да бъде много ефективно.
Вместо страниране с отместване за пропускане, можете да помислите за извършване на последователни заявки за страници, като започнете от последния запис на предишната страница (т.е. първата страница ще бъде $gte началният субектID и следващите страници ще бъдат $gt последният субектID, включен на предишната страница). Това ще зависи от начина, по който представяте странирането във вашия потребителски интерфейс - би било най-лесно да използвате този подход, ако потребителският ви интерфейс има само опцията да показва „следващата“ страница със съобщения, вместо да прескача към конкретна страница.
