Memesan berdasarkan subjectID
Jika subjectID . Anda adalah (atau dapat diubah menjadi) nilai yang meningkat secara monoton (misalnya, ObjectID default MongoDB), Anda memiliki opsi langsung menggunakan find() normal dengan sortir, skip, dan limit yang sesuai. Dalam hal ini Anda dapat mencari dokumen dengan subjectIDs $gte (lebih besar dari atau sama dengan)
subjectID . Anda :
var page = 1;
var subjectID = ObjectId("515535a0760fe8735f5f6897");
db.users.find(
{ _id: { $gte : subjectID } }
).sort({'_id':1}).skip(page*20).limit(20)
Kerangka Agregasi
Seperti pada MongoDb 2.4, tidak ada fitur seperti itu di Kerangka Agregasi yang cocok berdasarkan posisi dokumen di saluran hasil. Anda dapat mengajukan saran fitur baru untuk SERVER proyek MongoDB Jira antrian.
Sepertinya Anda menginginkan operator saluran pipa baru seperti $matchfrom yang akan mengabaikan dokumen apa pun hingga kemunculan pertama $matchfrom kriteria. Anda kemudian dapat menambahkan $limit untuk mengambil n item berikutnya. Anda juga ingin mengurutkan keluaran sebelum $matchfrom jadi ada hasil yang dapat diprediksi.
Ini tampaknya terlalu rumit dibandingkan dengan memiliki subjectID yang meningkat, tetapi mungkin ada kasus penggunaan untuk melakukan paging berdasarkan kriteria pencarian lanjutan atau hasil yang dihitung dalam alur agregasi.
Pendekatan alternatif
Selain dukungan di masa mendatang untuk fitur semacam itu di Kerangka Agregasi, Anda memiliki beberapa opsi untuk menerapkan pendekatan pencocokan yang sama dalam kode:
-
gunakan
group()yang lebih lama perintah agregasi denganfinalize()fungsi. CATATAN:group()apakah tidak bekerja dengan sharded cluster. -
gunakan MapReduce dan
finalize()fungsi -
ambil seluruh kumpulan hasil dari Kerangka Agregasi, dan terapkan pencocokan/pengurangan hasil dalam kode aplikasi Anda (meskipun ini agak mengalahkan gagasan "paging" jika Anda mengambil semua halaman untuk setiap permintaan).
Pertimbangan kinerja
Kueri dengan skip masih harus membaca entri indeks yang mengganggu, jadi melewatkan sejumlah besar dokumen tidak akan terlalu efisien.
Alih-alih membuat halaman dengan offset lewati, Anda dapat mempertimbangkan untuk melakukan kueri halaman berturut-turut dengan memulai dari entri terakhir halaman sebelumnya (yaitu halaman pertama adalah $gte subjectID awal dan halaman berikutnya adalah $gt subjectID terakhir yang disertakan pada halaman sebelumnya). Ini akan tergantung pada bagaimana Anda menampilkan paging di antarmuka pengguna Anda - akan lebih mudah menggunakan pendekatan ini jika UI Anda hanya memiliki opsi untuk menampilkan halaman pesan "berikutnya" daripada melompat ke halaman tertentu.
