Расширенный поиск Дизайн больших объектов

Question

Я ищу несколько советов. Я недавно закончил проект, в котором унаследовал какой-то ужасный код. Я запустил приложение, но можно с уверенностью сказать, что есть ряд проблем с производительностью и дизайном, особенно с расширенными функциями поиска. Теперь меня попросили сделать очень похожий проект, но гораздо большего масштаба. У меня есть возможность создать гораздо лучшую модель предметной области с нуля и создать гораздо лучшее приложение в целом. Вопрос в том, как лучше всего реализовать расширенный поиск?

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

Текущее решение использует два обязательных поля для возврата списка объектов, которые я затем фильтрую и удаляю на основе любых необязательных значений формы. Затем я выбрасываю отфильтрованный список в кеш и прикрепляю идентификатор сеанса пользователя. Затем на каждой странице результатов у меня есть Html.Helper, который отображает ссылки на страницы, использующие подход Take (). Skip () в списке, полученном из кэша для отображения 10 результатов.

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

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

Answer 1

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

Большие запросы SQL могут быть значительно медленными, сложными для настройки и сложными для отладки. Если расширенный поиск является основной функцией и имеет множество сложных бизнес-правил, рассмотрите возможность реализации поиска как часть вашего ORM. Кроме того, интеллектуальный поиск будет способствовать использованию ORM.

Загрузка большого количества крупных объектов в память может сказаться как на производительности, так и на масштабируемости. Если пространство поиска велико, тогда подумайте об использовании SQL для поиска.

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

Должен ли поиск выполняться в реальном времени? Если нет, то рассмотрите гибридный подход, при котором объекты индексируются в непиковое время. Бесполезно искать слова с низкой релевантностью, такие как «или», потому что «поиск в перефразированной версии объектов может привести к счастливой среде».

Удачи и веселья!