Здесь есть несколько вещей, поэтому давайте начнем с типа поля:
<fieldType name="text" class="solr.TextField" />
.. это на самом деле не определяет полезный тип поля.Для этого вам нужно подключить токенизатор и пару фильтров.Токенайзер разбивает текст на токены, и именно токены создают совпадение.Это называется цепочкой анализа.
<fieldType name="text" class="solr.TextField">
<analyzer>
<tokenizer class="solr.WhitespaceTokenizerFactory" />
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
Токенайзер Whitespace разделит «foo bar baz» на три токена: foo
, bar
и baz
.Любые запросы будут делать то же самое и соответствовать токену для токена.Вот почему вы получите совпадение, даже если поиск будет bar baz foo
, а не той же последовательностью, что и ранее.Обычно вы также хотите присоединить по крайней мере LowercaseFilter
, чтобы получить поиск без учета регистра - и любые другие фильтры в зависимости от варианта использования для вашего поля и домена.Создайте несколько полей для разных совпадений и взвесьте их отдельно, чтобы получить оценку документа, наиболее подходящую для ваших пользователей.
Без этой цепочки анализа, я полагаю, вы в действительности получите то же поведение, что и строкаfield.
Тогда подстановочные знаки - если подстановочный знак присутствует, вся цепочка анализа пропускается.Это означает, что использование подстановочных знаков при поиске в тексте, как правило, является плохой идеей.Он не будет делать то, о чем вы думаете, если только вы не пытаетесь сопоставить один токен (поскольку токенайзер будет пропущен при наличии подстановочного знака).Так что вам придется делать это с осторожностью, и вы, вероятно, будете чаще сталкиваться с «почему это произошло».
Альтернативой является использование NGramFilter, который разбивает каждый набор букв.одним словом (foo
становится f
, fo
, foo
, o
, oo
и o
) на отдельные токены.Обычно вы хотите делать это только при индексировании, поэтому используйте отдельные цепочки анализа для своего поля (вы определяете это с помощью параметра type
в конфигурации - если тип не указан, эта же цепочка будет использоваться для индексации и запросов.
Причина, по которой рекомендуется использовать подстановочные знаки префикса (*foo
), заключается в том, что проверка подстановочных знаков префикса обходится дороже по сравнению с проверкой подстановочного знака подстановки (foo*
). В случае с постфиксом вы можете просто выполнить итерацию поиндексируйте с foo
и продолжайте, пока не дойдете до того, что не начинается с foo
, в то время как для *foo
вы должны эффективно просматривать все термины в индексе, поскольку нет отсортированного порядка, который отслеживаетони в обратном порядке.
Введите Обратный фильтр подстановочных знаков - этот фильтр делает то, что он, в дополнение к обычным токенам, также индексирует обратный токен (или только обратный токен).Затем фильтр вызывается при запросе, а также обращается к токену запроса - эффективно индексируя oof
,а затем вместо этого запросить oof*
внутри.Таким образом вы получаете ускорение сохранения индекса, отсортированного для этого поля, и вам не нужно просматривать каждый токен.
Этот фильтр меняет токены, чтобы обеспечить более быстрые запросы с подстановочными знаками и префиксами.Токены без подстановочных знаков не меняются местами.