Эффективная фильтрация/поиск

Question

У нас есть размещенное приложение, которое управляет страницами контента. Каждая страница может иметь несколько настраиваемых полей и некоторые стандартные поля (временная метка, имя пользователя, электронная почта пользователя и т. Д.).

С потенциально сотнями различных сайтов, использующих систему - что является эффективным способом обработки фильтрации/поиска? Сделайте вид сетки, который вы хотите сузить. Вы можете фильтровать по определенным полям (userid, date), или вы можете ввести полнотекстовый поиск.

Например, «все страницы, начатые с userid 10», были бы довольно быстрым запросом к базе данных MySQL. Но такие вещи, как «все страницы, начатые пользователем, чей идентификатор пользователя равен 10 и соответствует [некоторому поисковому запросу]», будут сосать против базы данных, поэтому он подходит для поисковой системы, такой как Lucene.

В принципе, мне интересно, как другие крупные сайты делают такие вещи. Используют ли они поисковую систему на 100% для всех типов фильтрации? Смешивают ли они запросы к базе данных с помощью поисковой системы?

Если мы используем только поисковой системой, возникает проблема с временем задержки, которое требуется для отображения нового/обновленного объекта в индексе поиска. То есть, я читал, что не очень удобно обновлять индекс сразу и делать это партиями вместо этого. Даже если это означает каждые 5 минут, пользователи будут запутаны, когда их недавно добавленная страница не будет немедленно указана, когда они просмотрят простой список страниц (скажем, поисковый запрос категории «5»).

Мы используем MySQL и внимательно изучаем Lucene для поиска. Есть ли другая технология, о которой я не знаю?

Моя мысль состоит в том, чтобы предложить простую страницу фильтрации, которая использует MySQL для фильтрации по основным полям. Затем предложите отдельную страницу полнотекстового поиска, которая представит результаты, похожие на Google. Это единственный способ?

Answer 1

Solr или grassyknoll предоставляют несколько более абстрактные интерфейсы для Lucene.

Это сказало: Да. Если вы являетесь главным сайтом, ориентированным на контент, обеспечивая полный поиск по вашим данным, есть что-то в игре, кроме LIKE. Хотя индексы FULLTEXT от MySql не идеальны, в промежуточный период это может быть приемлемым заполнителем.

Предполагая, что вы создаете индекс Lucene, связывание документов Lucene с вашими реляционными объектами довольно просто, просто добавьте хранимое свойство в документ во время индекса (это свойство может быть URL-адресом, идентификатором, идентификатором GUID и т. Д.) Тогда, поиск становится 2 фазной системой: 1) запрос Проблемы в Lucene indexies (Отобразить простые результаты, как название) 2) Получить более подробную информацию об объекте из реляционных магазинов его ключ

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

Answer 2

Не сбивайте MySQL так легко!

Реализуйте его, используя базу данных, например. выберите с «like» в where-clause или что-то еще.

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

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

Answer 3

В случае, если вы хотите использовать MySQL или PostgreSQL, решение с открытым исходным кодом, который прекрасно работает с ним Sphinx: http://www.sphinxsearch.com/

Мы с той же проблемой и с учетом Сфинкса и Lucene в качестве возможных решений.