Что такое хорошая практика для разбиения на страницы, используя номер страницы и лимит в Go?

Question

Я создал Pagination в Go, используя номер страницы и лимит.Где Limit & Page Number are INT

и я создал нумерацию страниц как:

MONGO_SESSION.Find(nil).Skip(pageNumber*limit).Limit(limit).Sort("_id").All(&RETURN_STRUCT)

Работает нормально.Но когда я отправляю номер страницы или ограничение НОЛЬ.По умолчанию Mongo DB возвращает все записи, потому что ничего не пропустить и ограничить.

Поэтому мой вопрос заключается в том, что является хорошей практикой в ​​случае нулевого ограничения и нулевого номера страницы.

Практика 1: Отправить все данные.Не отправлять ответ об ошибке.

Практика 2: Отправлять ответ об ошибке, говоря: «Номер страницы и лимит не могут быть равны нулю»

Примечание: я не могу жестко кодироватьограничение или номер страницы.

Любое предложение будет оценено.

Answer 1

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

Однако, если коллекция достаточно большая, отправка всех данных - плохая идея.

Есть еще одна проблема с оператором «пропустить» (хотя это не уникально для Монго): чтобы пропустить N записей, БД должен выполнить полное сканирование (полное сканирование коллекции в случае монго), поэтому для получения результатов для страницы N + 1 потребуется больше времени, чем для страницы N.

Теперь, чтобы разобраться с этим, есть «хитрость»: Не работайте с пропуском вообще, вместо этого «запомните» последний идентификатор документа (он все равно уже проиндексирован, и вы все равно сортируетесь по _id). Тогда запросы будут (псевдокод, так как я не говорю «Go»):

• Для первого запроса: Find().sort(_id).limit(limitSize)

• Для последующих запросов: Find ().where(_id > lastMemorizedId).sort(_id).limit(limitSize)

Answer 2

Этот вопрос в некоторой степени основан на мнении (и, следовательно, несколько не по теме для StackOverflow), но я думаю, что некоторые советы или общие рекомендации могут быть полезными и полезными для других. Поэтому следующий ответ - мое мнение.

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

Тем не менее, отправка всех документов, когда клиент не может указать предел (случайно или преднамеренно), является худшим способом справиться с ситуацией. Это как кричать: «Эй, клиенты и хакеры, вот конечная точка, и если вы хотите DoS-атака мой сервер, просто позвоните этой конечной точке пару раз».

Чтобы защитить ваш сервер, у вас должен быть предел безопасности даже для параметра «limit», потому что разрешение любого значения для него может быть столь же плохим: только потому, что вы заставляете клиентов указывать ограничение, не защищает ваш сервер, для «плохих» клиентов также может быть установлен предел 1e9, который, скорее всего, будет включать все ваши документы.

Мой совет: всегда иметь значимые значения по умолчанию и пределы безопасности . Значения по умолчанию всегда должны быть задокументированы, пределы безопасности не так важны (но также могут быть задокументированы).

Итак, как вы должны справиться с этим:

1. Если предел отсутствует, примените значения по умолчанию. Если у вас не может быть значений по умолчанию, просто пропустите этот шаг (хотя должна быть веская причина не иметь / не разрешать значение по умолчанию).

2. Предел должен быть сверен с пределом безопасности. Если оно превышает значение безопасности, используйте предел безопасности (максимально допустимый предел).

3. Если у сервера есть «право» изменить запрошенный лимит (например, использование значения по умолчанию при отсутствии лимита или ограничение лимита на основе предела безопасности), сервер должен сообщить клиенту лимит фактически использовался для обслуживания запроса.

А что касается эффективной подкачки страниц в MongoDB: я рекомендую использовать Query.Skip() и Query.Limit() только для "небольшого" количества документов. Для эффективной подкачки, которая «масштабируется» с количеством документов, проверьте этот вопрос + ответ: Эффективная подкачка в MongoDB с использованием mgo

Answer 3

Я тоже сталкивался с такой же проблемой. Я предпочел отправить ответ об ошибке, а не показывать все данные.

Потому что это тяжелая транзакция для БД, если БД должна отправлять все данные. В небольших коллекциях он работает нормально, но для больших коллекций он может повесить DB.

Итак, отправьте ответ об ошибке.