Я ищу лучший aproach с точки зрения производительности, чтобы показать на веб-странице частично на странице, на 10 страницах, и если пользователь хочет увидеть больше результатов, он нажимает "next" btn. Я думаю (вероятно, неправильно), это должен быть новый запрос на сервер при нажатии кнопки «Далее»?Какой лучший способ подкачки большой Resultset -Java
currentlly я пытался узнать Java, GWT
спасибо!
PS: извините за мой английский.
Ответ будет зависеть от поведения ваших пользователей: как часто будет взгляд на странице 2, или на странице 10, или на странице 100.
Если они редко смотрят на стр.2, и не смотрите на странице 10 или стр. 100, то повторная отправка запроса может быть прекрасной.
Если они обычно смотрят страницу 2, часто смотрите на странице 10 и иногда смотрите на странице 100, тогда будет полезен частичный кеш: кешируйте первые 100 (или 200 или 300) результатов и только повторно отправляйте когда они пройдут эти результаты. Я бы, вероятно, сохранил кеш в сеансе пользователя, хотя вы должны подумать, если ваш сервер приложений кластер.
И если они всегда просматривают каждый результат? Частичные кэши по-прежнему остаются ответом, потому что вы не хотите хранить большие куски данных в памяти.
Обычно вы получаете только «страницу» из базы данных.
Допустим, запрос,
select * from mytable where column1="a";
даст 1000 записей. Затем получение страницы будет походить (MySQL):
select * from mytable where column1="a" limit 0, 10;
для страницы 1 (от 0 до 10), а страница 2 будет получен, как:
select * from mytable where column1="a" limit 10, 20;
и так далее. Если данные большие (1000 записей), но не огромные (1000 000 записей), вы также можете сразу предоставить весь набор данных и использовать javascript на странице. Это имеет дополнительное преимущество в том, что сортировка может выполняться на стороне клиента.
Поскольку у вас есть «GWT» в ваших тегах, я предполагаю, что ваше серверное приложение запущено в Google App Engine (GAE).
Один подход заключается в ваш первый запрос получить все результаты, хранить их в БД, показывают первые 20, а затем пусть следующая/предыдущая ссылки тянуть подмножества хранимых данных из БД. Вы должны помнить, что удалять эти результаты из базы данных при сбое сеанса пользователя!
Другой подход - получить все результаты на каждом просмотре страницы, но пропустить результаты до тех пор, пока вы не нажмете желаемое подмножество в 20 и не выведете только те из них.
Я думаю, что с GAE под, то второй подход будет работать лучше, если ваш запрос не может вернуть более 1000 результатов, которые GAE не позволит вам получить в одной транзакции.
+1 для комментариев к движку приложения ... Я предположил, что GWT просто используется в качестве интерфейсного для обычного приложения-сервера – kdgregory
Если вы не можете использовать подход на основе кеша из-за ограничений памяти, используйте подход на основе запросов. Отрегулируйте предложение WHERE в вашем поисковом запросе, чтобы явно выбирать данные на основе той страницы, которую запросил пользователь. Этот подход требует, чтобы вы передавали дополнительную контекстную информацию взад и вперед по запросам на странице.
Один из подходов - выбор страниц с использованием логических идентификаторов строк (или первичных ключей), которые ограничивают страницу и определяют каждую строку в наборе результатов.
Скажите, что у вас очень простая таблица с числовой последовательностью идентификаторов строк. Если вы показываете 100 строк на странице, и пользователь запросил страницу два, вы бы настроить ИНЕКЕ следующим образом:
select col, col2 from my_table where
row_id > 100
and row_id <= 200
order by rownum asc
можно кэшировать/извлечения записей в веб-слой, бэкэнд слой (например, EJB) или уровень базы данных (как последний «лимит» или оператор row_id). который вы должны использовать, зависит от вашего требования (как говорит kdgregory).
Наиболее популярным является их кеширование на веб-уровне с использованием сеанса.
Если вы используете JPA (который работает довольно хорошо на GAE), вы можете постраничной набор результатов, используя
Query#setFirstResult(int startPosition)
Query#setMaxResults(int maxResult)
Эта статья может быть полезной: Paging large data sets with a LazyList
LIMIT недоступен во всех диалектах SQL, и в зависимости от структуры запроса это может быть очень неэффективным - движок должен выполнить полный запрос, а затем применить лимит (хотя MySQL имеет оптимизацию). – kdgregory
Если вы используете MySQL с достаточно большим кэшем запросов, это не так дорого, и он неплохо справляется с большим количеством клиентов (за счет процессора, если кеш заполнен). Основываясь на данной информации, я не могу думать ни о чем лучше, за исключением, может быть, отдельной динамически созданной таблицы, которая потребует много отказоустойчивого кода очистки. – extraneon