Ordenando por subjectID
Se o seu
subjectID é (ou pode ser alterado para) um valor monotonicamente crescente (por exemplo, um ObjectID padrão do MongoDB), você tem uma opção direta usando um find() normal com classificação, salto e limite apropriados. Nesse caso, você pode procurar documentos com subjectIDs $gte (maior ou igual a)
seu subjectID :var page = 1;
var subjectID = ObjectId("515535a0760fe8735f5f6897");
db.users.find(
{ _id: { $gte : subjectID } }
).sort({'_id':1}).skip(page*20).limit(20)
Estrutura de agregação
Como no MongoDb 2.4, não existe tal recurso no Aggregation Framework para corresponder com base na posição do documento no pipeline de resultados. Você pode enviar uma nova sugestão de recurso para o SERVER do projeto MongoDB Jira fila.
Parece que você gostaria de um novo operador de pipeline, como um
$matchfrom que ignoraria quaisquer documentos até a primeira ocorrência do $matchfrom critério. Você pode adicionar um $limit para pegar os próximos n itens. Você também gostaria de ter a saída classificada antes do $matchfrom então há um resultado previsível. Isso parece muito complicado em comparação a ter um subjectID crescente, mas pode haver um caso de uso para fazer a paginação com base em critérios de pesquisa mais avançados ou resultados calculados no pipeline de agregação.
Abordagens alternativas
Além do suporte futuro para esse recurso no Aggregation Framework, você tem algumas opções para implementar a mesma abordagem de correspondência no código:
-
use ogroup()mais antigo comando de agregação com umfinalize()função. NOTA:group()não trabalhar com clusters fragmentados.
-
use MapReduce e umfinalize()função
-
busque todo o conjunto de resultados do Aggregation Framework e implemente a correspondência/redução de resultados em seu código de aplicativo (embora isso anule um pouco a noção de "paginação" se você estiver buscando todas as páginas para cada solicitação).
Considerações de desempenho
Consultas com
skip ainda precisa ler as entradas de índice intermediárias, portanto, pular um grande número de documentos não será muito eficiente. Em vez de paginar com um deslocamento de salto, você pode considerar fazer consultas de página sucessivas começando pela última entrada da página anterior (ou seja, a primeira página seria
$gte o subjectID inicial e as páginas subsequentes seriam $gt o último subjectID incluído na página anterior). Isso dependerá de como você apresenta a paginação em sua interface de usuário - seria mais fácil usar essa abordagem se sua interface do usuário só tivesse a opção de mostrar a "próxima" página de mensagens em vez de pular para uma página específica. 
