Нужны Мнения / Перспективы - подход разбиения на страницы для большого набора данных

Question

У нас есть требование, когда нам нужно отображать много данных в нескольких сетках, а также предоставлять возможность сортировки на стороне пользовательского интерфейса.Существует 2 подхода:

1. Загрузка всего в пользовательском интерфейсе и разбиение на страницы и сортировка на стороне пользовательского интерфейса.
2. Загрузка данных на стороне сервера в пользовательском интерфейсе и если пользователь нажимает сортировку на основе любого другого столбца,вызвать API для повторной индексации данных в отсортированном столбце и снова отправить результаты в разбивке по страницам.

Общее ощущение состоит в том, что при подходе 1 пользовательский интерфейс будет излишне загружен экстремальными объемами данных(например, 10 тыс. записей в сетках - от 1-2 МБ), что может вызвать проблемы с производительностью пользовательского интерфейса, не говоря уже о серверах, обслуживающих эти запросы для большой группы пользователей, близкой к миллиону.При использовании подхода 2 каждый раз, когда пользователь щелкает по сортировке, происходит вызов API, и ресурсы сервера тратятся впустую на повторную сортировку огромных данных (где пользователь хотел бы увидеть только несколько десятков записей)

• Каков наилучший способ справиться с подобным сценарием?
• Существуют ли какие-либо отраслевые стандартные практики, на которые мы можем ссылаться?
• Как мы можем количественно оценить производительность пользовательского интерфейса?

Answer 1

Существует третий подход:

Сервер имеет разные индексы для каждого возможного порядка сортировки.Когда новые данные добавляются, они вставляются в нужное место в каждом индексе.Пользовательский интерфейс для каждого пользователя запрашивает у сервера «записи от N * K до (N = 1) * K» индекса, который соответствует тому порядку сортировки, который выбрал пользователь.Там нет сортировки.Нет необходимости загружать все в каждый пользовательский интерфейс.

Примечание 1. Вероятно, вы можете немного обмануть - например, если у вас есть индекс для «отсортировано по алфавиту в порядке возрастания», то вы можете использовать тот жеиндекс для "отсортировано по алфавиту в порядке убывания".Таким образом, вам может понадобиться только 4 индекса для 8 возможных порядков сортировки.

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

Существуют ли какие-либо отраслевые стандартные практики, на которые мы можем ссылаться?

Отраслевая стандартная практика зависит от того, в какой отрасли.Слишком много вещей смещается в сторону «веб-приложений», где общепринятая практика заключается в том, чтобы заставить некомпетентных разработчиков работать за минимальную заработную плату, чтобы собрать кусочек мусора с помощью крайне неэффективных структур.

Какмы количественно оцениваем производительность пользовательского интерфейса?

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