Paginated search ... производительность сильно ухудшается после N записей?

sql-server performance full-text-search

112 просмотра

2 ответа

Я просто попробовал следующий запрос на YouTube:

http://www.youtube.com/results?search_query=test&search=tag&page=100

и получил сообщение об ошибке:

К сожалению, YouTube не предоставляет более 1000 результатов для любого запроса. (Вы просили результаты, начиная с 2000 года.)

Я также попробовал поиск Google для «теста», и хотя он сказал, что было около 3,44 миллиарда результатов, я смог получить только страницу 82 (или около 820 результатов).

Это заставляет меня задуматься о том, что производительность начинает деградировать с разбивкой по страницам после N записей (особенно интересно с ROW_NUMBER () в SQL Server или аналогичной функцией в других системах БД), или это делает YouTube / Google по другим причинам? Конечно, маловероятно, что большинству людей нужно будет пройти первые 1000 результатов для запроса, но я бы предположил, что ограничение специально внедрено по какой-то технической причине.

Затем снова Stack Overflow позволяет вам просматривать страницы по 47k: https://stackoverflow.com/questions/tagged/c?page=955&sort=newest&pagesize=50

Автор: Jake Petroules Источник Размещён: 17.05.2019 03:24

Ответы (2)


1 плюс

Решение

Да. Высокие смещения медленны и неэффективны.

Единственный способ найти записи в смещении - это вычислить все записи, которые были раньше, а затем отбросить их.

(Я не знаю ROW_NUMBER (), но будет LIMIT в стандартном SQL.

SELECT * FROM table LIMIT 1999,20

)

.. в приведенном выше примере первые 2000 записей должны быть извлечены первыми, а затем отброшены . Как правило, он не может пропустить вперед или использовать индексы для перехода к правильному местоположению в данных, потому что обычно должно существовать предложение WHERE, которое фильтрует результаты.

Можно кэшировать результаты, что, вероятно, делает SO. Поэтому на самом деле не нужно вычислять большие смещения каждый раз. (Большинство поисков SO - это «маленький» набор известных тегов, поэтому его вполне возможно кэшировать. У произвольного поискового запроса будет много версий, которые могут быть пойманы, что делает его нецелесообразным) (альтернативно это может быть использование некоторой другой реализации, которая позволяет произвольные смещения)

Другие места, занимающиеся подобными вещами http://sphinxsearch.com/docs/current.html#conf-max-matches

Задняя часть теста envolope:

mysql> select gridimage_id from gridimage_search where moderation_status = "geograph" order by imagetaken limit 100999,3;
...
3 rows in set (11.32 sec)

mysql> select gridimage_id from gridimage_search where moderation_status = "geograph" order by imagetaken limit 3;
...
3 rows in set (4.59 sec)

(Произвольный запрос выбран так, чтобы не использовать индексы очень хорошо, если индексы можно использовать, разница менее выражена и сложнее видеть, но в производственной системе, где много запросов, разница в 1 или 2 мс огромна)

Обновление: (для отображения индексированного запроса)

mysql> select gridimage_id from gridimage_search order by imagetaken limit 10;
...
10 rows in set (0.00 sec)

mysql> select gridimage_id from gridimage_search order by imagetaken limit 100000,10;
...
10 rows in set (1.70 sec)
Автор: barryhunter Размещён: 30.12.2011 04:00

0 плюса

Это предложение TOP, предназначенное для ограничения количества физических чтений, которые должна выполнять база данных, что ограничивает время, которое занимает запрос. Представьте, что у вас есть 82 миллиарда ссылок на рассказы о «Японии» в вашей базе данных. Что, если кто-то спросит «Японию»? Все ли 82 миллиарда результатов действительно будут нажаты? Нет. Пользователю нужно 1000 лучших релевантных результатов. Когда поиск является общим, например «тест», невозможно определить релевантность. В этом случае YouTube / Google должен ограничить объем, который был возвращен, так что другие пользователи не пострадали от общих поисков. Что быстрее, возвращая 1,000 результатов или 82 000 000 000 результатов?

Автор: brian Размещён: 30.12.2011 03:48
Вопросы из категории :
32x32