Как сделать пагинацию с MongoDB?

Question

[Stopy]

Нужно сделать пагинацию, почитал про ужасную скорость skip(), limit(), на забугорных сайтах рекомендуют делать так, с каждой выборки брать id последнего документа и делать find() по начиная с него, а потом опять limit(), но дело в том, что мне надо для любого числа, найти свои 10 записей. Т.е. может просто прийти число 5000, и мне нужно сформировать 10 записей с 5000 страницы. skip(), limit() не вариант, а как тогда сделать?

Comments

[Станислав]

Странно, имеется база в 100к документов, получаю выборку с лимитом и отступом буквально за 0.0... секунды. Может сам запрос косячный? Или структура косячная. Я просто в силу структуры базы использую в основном агрегирование, есть такой жесткий запрос, если разложить его то строк на 100 получится )) работает молниеносно, доли секунды. Тестировал с 7 обычными запросами и с агрегированием, второе в итоге по времени в разы быстрее дергает данные, если учесть что перебор контента в 7-10 подходов, а так потребовалось бы 7-10 запросов делать. На сколько я помню при профилировании эти 7-10 запросов выполнялись порядка 2-3 секунд, с агрегированием за 0.1-0.2сек данные уже готовые выплевывает. Какая версия mongodb, покажите структуру документа и как дергаете записи.

[Stopy]

последняя mongodb 2.0.27, обычной асинхронной db.col.find().skip(5000).limit(10)

[Stopy]

Станислав: stackoverflow.com/questions/10072518/what-is-the-b... вот например рекомендации к эффективности

[Станислав]

Stopy: последняя вобще 3.0.Х docs.mongodb.org/manual/. Я не использовал mongodb ниже 2.6, может там действительно на более ранних версиях фигово работает skip да limit

[Stopy]

Станислав: при 50000 записях обращение к последней странице с зажатым F5 ожидание проседает за 1.5 секунды, щас обновлю и перепроверю)

[Stopy]

Станислав: мда, после обновления при зажатии задержка стала увеличиваться экспоненциально, а при простом обращении задержка около секунды

[Stopy]

Станислав: и кстати на npm последняя версия mongodb@2.0.40

[Александр Мелеховец]

по замерам в продакшене каково распределение запросов между страницами 1-10 и 5000-5010 ?

[Stopy]

Александр Мелеховец: я не в продакшене ведь меряю, при 50 тысячах записей к первой странице обращается за ~0.3сек, к последней секунду. но разве на эту секунду он не зажрет все ресурсы сервера?

[Stopy]

Кстати если не делать перед skip, limit сортировки, то запрос к любой странице выполняется не дольше 0.015 секунд. Эксперты, есть идеи?

[Александр Мелеховец]

Stopy: для запроса с сортировкой есть соответствующий индекс?

[Станислав]

Stopy: У себя смотрю, в результате формирование страницы целиком 250-300ms, что на первой странице, что в середине, что на последней, время одно и тоже, даже при нажатии на F5. Это при том что шаблон сформировать надо, скрипты загрузить со стилями, картинки. Кстати в продакшене включается какие то плюшки кеширования, я на не продакшене проверить не могу в данный момент, но когда разрабатывал систему не замечал что где то тормозит что то.

На сервере стоит:
Node.js 0.12.6
MongoDB 2.6.10

По серверу:
Ubuntu 10.04 (при том что x32). Сейчас собираюсь ставить 14.04 х64 и ставить MongoDB 3.0.Х
Xeon 2x2000
Оперативки 4GB
Диск 100GB RAID-10 HDD с SSD-кешированием

Вобще проблем с обработкой данных не вижу, хотя железка мягко говоря не очень.

[Stopy]

Александр Мелеховец: в смысле по какому критерию собираюсь сортировать? или вы о чем то другом?

[Stopy]

Станислав: могу увидеть ваш ресурс? и как вы сформировали ваш запрос к базе

[Александр Мелеховец]

Stopy: да, фильтровать и сортировать. Судя по тому, что вы задаёте такие вопросы, могу предположить, что индексов там нет. И оптимизация сводится к их созданию после изучения, что такое индексы и как их использовать.

[Stopy]

Александр Мелеховец: Похоже уже научился, напишу в ответы

[Александр Мелеховец]

lh3.ggpht.com/-YgkFG7oPp7Q/U5_tqSUq1eI/AAAAAAAADGQ...
успехов)

[Stopy]

Александр Мелеховец: хах) спасибо, и вам

Answer 1

[lega]

skip(), limit() работают быстро, вам нужно просто сделать правильный индекс.

брать id последнего документа и делать find()

Это может работать медленнее, зависит от запроса и индексов.
А вообще для пагинации этот способ хорош тем что выдаст как раз следующие N элементов, когда skip+limit вам выдадут "дубли" с предыдущей страницы если в базе появятся новые элементы (например на хабре если перелистывать страницу раз в час, то можно на 2-й странице увидеть посты которые вы просмотрели на 1-й странице)

Comments

[Stopy]

мне нужно чтобы скрипт не ориентировался на прошлый запрос, а чтобы даже первый запрос мог быть на 5000ную страницу

[lega]

Попробуйте указать сортировку:
db.obj.find({}).sort({_id: 1}).skip(500000).limit(1)
без сортировки запрос работал без индекса (просто перебор), с сортировкой гораздо быстрее.

Так же можно разбить коллекцию на несколько, например по 10к в каждой, тогда получать будет посложнее, но быстрее.

Так же можно "вешать метки" на документы или делать на них ссылки в отдельной коллекции, например "помечать" каждый 1000-ый документ, и для запроса быстро находить нужную тысячу и для неё делать запрос.

[Stopy]

lega: а что если я только что был на странице с документами 9990-10000, делаю метку на 10000, а за это время он уже не 10000, а 9989 или 1100

[Stopy]

lega: а еще не обязательно я с первых 10 документов дощелкаю до последних 10, запрос может прийти сразу на последние 10, что метками даже воспользоваться некогда будет. насколько быстрей идет выборка по сортированным документам? при выборке из 5 тысяч велика ли будет задержка?

[lega]

Не, метки строятся заранее и на "всю жизнь", нюансы нужно учитывать поэтому лугче чем skip+limit не будет.

У меня skip 500k отработал за 0.3 сек,
skip 100k за 30мс, вашы 5к будут не заметны.

[Stopy]

lega: в тех же условиях что и у меня? в смысле что без меток и других оптимизаций, только сортировка и скип, лимит?

[Stopy]

lega: и что если у меня этот skip не один пользователь запросит а 100? 30 секунд крайний из них будет ждать?

[lega]

> и что если
Не переживайте, сначала сделайте skip-limit (для 99% случаев хватает), а если будет тормозить тогда уже "химичить".

[Stopy]

lega: дак дело то в том, что я не уверен, что будет какое-либо решение, к тому моменту когда будет тормозить. тогда придется еще больше переделывать, чем пришлось бы сейчас. например выбрать другую базу

[Станислав]

Stopy: делай, у меня 3 проекта работают на монго уже пол года, никогда проблем не было с базой, структуру документа только нормальную сделай и будет у тебя все шустро работать. Могу тебе сказать одно, я конечно кроме MySQL и MongoDB ничего не использовал, но возвращаться к MySQL после монго точно не стану =). Пересаживал проекты с PHP+MySQL на Node.js+MongoDB, скорость загрузки увеличилась более чем в 12-15 раз.

[Stopy]

Станислав: возможно ты с такой проблемой не сталкивался? вот как мне свой запрос оптимизировать

[Stopy]

Stopy: Нашел решение, напишу его в ответ к вопросу, кому интересно гляньте

Answer 2

[Stopy]

Нашел решение: docs.mongodb.org/manual/tutorial/optimize-query-pe...
Примерный код:

posts.createIndex({ time: 1},{}, function(err, indexName){
   if (err) next(err);
      posts.find({}).sort({time: -1}).skip((page-1)*10).limit(10).toArray(function(err, data) {
         if (err) next(err);
         callback(data);
      });
});