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

Question

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

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

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

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

Answer 1

Есть третий подход:

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

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

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

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

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

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

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