Веб-пользователи, которые ищут слишком много данных

Question

У нас в настоящее время есть поиск на нашем сайте, который позволяет пользователям вводить диапазон дат. Страница вызывает хранимую процедуру, которая запрашивает диапазон дат и возвращает соответствующие данные. Тем не менее, многие наши таблицы содержат от 30 до 60 метров строк. Если пользователь введет диапазон дат года (или большой диапазон), база данных остановится.

Есть ли какое-либо решение, которое не предусматривает ограничение времени поиска? Пейджинг уже реализован, чтобы показать только первые 500 строк, но база данных все еще сильно пострадала. Мы не можем установить жесткое ограничение на количество возвращаемых результатов, поскольку пользователю «могут» понадобиться все из них.

Answer 1

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

Вы хотите начать с самых последних дат в порядке убывания и с самых старых дат в порядке возрастания.

Answer 2

Мне кажется, что это дизайн, а не техническая проблема. Никому не нужны миллионы записей данных на лету.

Вам придется задать себе несколько трудных вопросов: есть ли другой способ получения людьми своих данных, кроме Интернета? Есть ли лучший способ попросить фильтрацию? Для чего именно эта информация нужна пользователям, и есть ли способ обеспечить такой уровень отчетности вместо того, чтобы извергать все?

Пересмотрите, что именно нужно и нужно пользователям.

Answer 3

Индексируйте ваше поле даты и заставляйте запрос использовать этот индекс:

CREATE INDEX ix_mytable_mydate ON mytable (mydate)
SELECT TOP 100 *
FROM mytable WITH (INDEX ix_mytable_mydate) 
WHERE mydate BETWEEN @start and @end

Похоже, что оптимизатор выбирает FULL TABLE SCAN, когда видит большой диапазон.

Не могли бы вы опубликовать используемый вами запрос и план его выполнения?

Answer 4

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

Похоже, вы говорите, что не можете запретить пользователю запрашивать большие наборы данных по деловым причинам. Я не вижу никаких технических способов обойти это.

Answer 5

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

Answer 6

Не знаю, какие из них возможны

1. Использовать поисковую систему, а не базу данных?
2. Не разрешать очень общий поиск
3. Кэшировать результаты популярных поисков
4. Разбейте базу данных на фрагменты на отдельных серверах, объедините результаты в вашем приложении.
5. Выполнять несколько запросов с меньшим диапазоном дат внутри страны

Answer 7

Распараллелить, и положить его в оперативную память (или облако). Вы обнаружите, что если вы хотите получить доступ к большим объемам данных одновременно, rdbms становится проблемой, а не решением. Никто не делает визуализации, использует rdbms.

Answer 8

Как вы реализуете пейджинг?

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

Answer 9

Как физически структурированы данные вашей таблицы, то есть разделены, распределены по файловым группам, дисковому хранилищу и т. Д.?

Используете ли вы разбиение таблицы? Если нет, вы должны изучить использование выравнивания разделов. Вы можете разделить ваши данные по дате, например, для каждого года.

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