Как улучшить производительность Solr?

Question

Как мы используем Solr: Мы храним документы 7K с атрибутами 3k, прикрепленными к одному документу в solr. Каждый атрибут индексируется на solr, чтобы включить поиск/сортировку по этому атрибуту. Мы извлекаем данные из solr на основе критериев поиска/фильтра с атрибутом 400+, прикрепленным к одному документу. Поэтому, когда мы пытаемся найти какой-либо текст в solr с 1 атрибутом (путем установки fl = "projectId"), для отображения результата на solr-консоли требуется едва ли 1 секунда, что отлично.

Однако, если мы попытаемся получить атрибут 100+ для тех же критериев поиска (который вернет строку ~ 100 * 3 * нет совпадающего документа (~ 50) из документа 7K с атрибутом 4K), это займет ~ 20 секунд. Но нам нужно получить атрибут 400+ с согласованным документом, он занимает много времени ~ 90 секунд, раньше он сбой из-за outOfMemoryError, который мы исправили, увеличив размер ОЗУ и размер кучи JVM.

синхронизация данных Mysql с Solr: В настоящее время мы используем MySql БД в качестве первичной базы данных и сервера Solr в качестве вторичной базы данных. Мы ежедневно синхронизировали данные mysql с сервером Solr. Мы также обновляем сервер solr всякий раз, когда мы обновляем любой атрибут в Mysql DB.

Использование данных результата solr в приложении: Панель инструментов приложения будет содержать документ с предварительно сконфигурированными столбцами (атрибутами) пользователя. Пользователь может применять критерии поиска/фильтра, чтобы заполнить требуемый результат на своей приборной панели. Поэтому наше приложение пытается получить данные с критериями поиска/фильтрации с сервера solr, обратившись к нему.

Мы пробовали много вещей, таких как увеличение размера кучи, размер оперативной памяти и отсутствие процессора, но не повезло. Данные с каждым днем ​​растут, что вызывает множество проблем. Он работает с небольшим количеством проектов или небольшим атрибутом, но всякий раз, когда мы пытаемся извлечь больше атрибута, это требует слишком много времени, когда-то он разбился.

Я не уверен, правильно ли мы используем индексы?

Может ли кто-нибудь предложить лучший/альтернативный подход? Спасибо заранее.

Answer 1

Вместо того, чтобы получать 400 полей для каждого документа, вы можете вернуть только «идентификатор» каждого документа, а затем получить эти документы из MySQL, который является вашим постоянным хранилищем.

Так для примера, если вы получаете обратно 25 идентификаторы документов за поиск, в приложении вы можете получить 25 докторов из MySQL (может быть сделать параллельный вызов)

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

Answer 2

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

Другой способ - использовать фильтры широко.

Если вы можете включить часть запроса в фильтры (fq), что, вероятно, увеличит производительность на хорошем уровне.