Пагинация коллекции из БД при получении обновлений
Мне нужно предоставить клиенту элементы, отсортированные по определенному полю (score), с разбивкой на страницы.
Элементы хранятся в MongoDB как часть коллекции. Один документ выглядит так:
{
"id": ObjectId("<>"),
"score": 10
}
Для обслуживания элементов я выполняю обратную сортировку документов в поле score и обслуживаю 10 элементов для клиента.
Кроме того, значение в поле score постоянно получает обновления от другого потребителя в асинхронном режиме.
Как я могу выполнить нумерацию таких документов? Я думал о следующих подходах, которые я обычно использую, но не могу найти способ вписать их в приведенный выше дизайн:
- Вернуть последнюю обслуженную оценку как смещение, и в следующем запросе на выборку элементов использовать смещение. Проблема: это вернет несколько дубликатов с одинаковой оценкой (поскольку многие элементы могут иметь одинаковые оценки).
Нет фиксированной частоты обновления, но мы можем предположить, что они происходят каждые 2-3 минуты. Оценка на самом деле является производительностью определенного элемента, и клиенту необходимо отображать наиболее эффективные элементы для пользователя (вроде видео / изображения с самым высоким рейтингом / наибольшим просмотром). Показ первой десятки - хорошее решение для прототипа, но в конечном итоге все элементы придется обслуживать. Количество элементов может быть большим, поэтому я не смогу загрузить все в память.
Тогда все это связано с вашими бизнес-требованиями. Сначала набросайте их, как это должно быть видно пользователю, пользователю и т. д. Обдумайте возможные варианты. Например, предположим, что список элементов с размером страницы 10, если пользователю требуется 3-5 минут для чтения перед переходом к следующей странице, то может ли случиться так, что пока пользователь читает эти 10 элементов, они становятся следующими 10 элементами? Затем в соответствии с потребностями бизнеса разработайте технические требования. Возможно, в таком часто обновляемом списке нет необходимости, поэтому откладывайте обновления до 15/30-минутных интервалов, если требуется разбивка на страницы. Или, может быть, нумерация страниц вообще не нужна.
Ваши бизнес-требования могут смещать ваши технические требования от очень простых, например, показывать только топ-10, до таких сложных, как постоянные курсоры, где во время первоначального запроса вы делаете снимок пользовательского курсора на некоторый период действия и обновляете курсор. по истечении срока его действия. Все зависит от бизнеса. В пагинации нет хороших или плохих решений, обычно все решения плохие :) Зависит от того, насколько это удобно для пользователя :)
Верно, имеет смысл. Но технически использование постоянных курсоров для создания такого механизма кажется хорошей идеей.
Если ваши записи обновляются часто (как часто? В секунду / минуту / час?), То какой смысл в разбивке на страницы с сортировкой по количеству очков? ИМО, вы можете показать первую десятку просто для своего рода мониторинга. В противном случае, если частота очень высока, вы не сможете осмысленно перемещаться по такой коллекции. Также нужно учитывать, сколько таких записей у вас будет. Если это 10 или 100 секунд, а объекты не очень большие, может быть разумным периодически выполнять
findAll()и возвращать клиенту все данные и / или разбивать на страницы этот замороженный / кэшированный периодический моментальный снимок.