Ответ 1
Предпочтительно использовать фильтр-запрос по обычному запросу, если это возможно.
FilterQuery может использовать FilterCache, что будет большим увеличением производительности по сравнению с вашими запросами.
У меня есть индекс продукта Solr размером 1 миллион. У меня также есть целый набор фильтров пользовательского интерфейса, таких как категории, вкладки, диапазоны цен, размеры, цвета и некоторые другие фильтры.
Правильно ли, чтобы q выбрал все (q=\*:\*)
, а все остальные фильтры в fq? Пример:
fq=(catid:90 OR catid:81) AND priceEng:[38 TO 40] AND (size:39 OR size:40 OR size:41 OR size:50 OR size:72) AND (colorGroup:Yellow OR colorGroup:Violet OR colorGroup:Orange ... AND (companyId:81 OR companyId:691 OR companyId:671 OR companyId:628 OR companyId:185 OR companyId:602 OR ... AND endShipDays:[* TO 7])
Для меня все, от категорий до companyIds, от цветов и размеров и т.д. - это просто фильтры. Любая проблема в производительности в будущем с таким подходом? Должен ли я поместить некоторые из запросов в q, какие из них?
Спасибо,
Предпочтительно использовать фильтр-запрос по обычному запросу, если это возможно.
FilterQuery может использовать FilterCache, что будет большим увеличением производительности по сравнению с вашими запросами.
Я бы рассмотрел следующие пункты о поле, чтобы решить:
Некоторые примечания о # 3: по моему опыту у меня был большой индекс, который каждые несколько секунд заполнялся новыми документами, а autoSoftCommit - несколько секунд. Во время мягких коммитов был открыт новый искатель, который стал недействительным для кэшей. Итак, что действительно происходит, коэффициент попадания фильтра почти всегда равнялся 0. Я могу сказать больше: я выяснил, что первый запуск запроса фильтра дороже, чем запуск запроса со всеми условиями фильтра, перенесенными на "q" вместо "fq" . Например, мой запрос занял 1 секунду с 5 фильтрами (без кеша) и 147 мс, когда я переместил все условия "fq" в основной запрос с помощью "И". Но, конечно, когда я остановил обновления индекса, те же запросы фильтра заняли 0мс, потому что использовался кеш. Так что это то, что нужно учитывать.
Также несколько других вопросов для вашего вопроса:
Надеюсь, что это поможет.
Как я использую q и fq. Я применяю полнотекстовый поиск по q и всем фильтрам на fq. Допустим, у вас есть поле ключевое слово, что вы будете иметь полнотекстовый поиск с полями, как определено в вашей схеме с помощью copyField
<copyField source="id" dest="keyword"/>
<copyField source="category" dest="keyword"/>
<copyField source="product_name" dest="keyword"/>
<copyField source="color" dest="keyword"/>
<copyField source="location" dest="keyword"/>
<copyField source="price" dest="keyword"/>
<copyField source="title" dest="keyword"/>
<copyField source="description" dest="keyword"/>
Мой запрос будет выглядеть как
/select?q={keyword}&fq=category:fashion&fq=location:nyc
/select?q=jeans&fq=category:fashion&fq=location:nyc
Как было предложено digitaljoel, если вам нужно запросить несколько полей, тогда было бы лучше использовать несколько fq (см. выше запрос) вместо использования AND и OR с q
Примечание: в моем случае q по умолчанию используется ключевое слово поля, определенное в файле solrconfig.xml
<requestHandler name="/select" class="solr.SearchHandler">
<!-- default values for query parameters can be specified, these
will be overridden by parameters in the request
-->
<lst name="defaults">
<str name="echoParams">explicit</str>
<int name="rows">10</int>
<str name="df">keyword</str>
</lst>