Запрос solr shingle, соответствующий токенизированному полю ключевого слова

Я использую Solr 5.5, и у меня есть проблема, которую я надеюсь найти здесь.

У меня есть поле, которое я создал, используя следующие настройки:

<field name="exactName_noAlias_en_US" type="text_exact_query_tokenized" indexed="true" stored="false"/>

<fieldtype name="text_exact_query_tokenized" class="solr.TextField" positionIncrementGap="100">
       <analyzer type="index">
            <tokenizer class="solr.KeywordTokenizerFactory"/> 
            <filter class="solr.LowerCaseFilterFactory"/>
            <filter class="solr.ASCIIFoldingFilterFactory" preserveOriginal="true"/>
         </analyzer>
          <analyzer type="query">
            <tokenizer class="solr.WhitespaceTokenizerFactory"/>                    
            <filter class="solr.LowerCaseFilterFactory"/>
            <filter class="solr.ASCIIFoldingFilterFactory" preserveOriginal="true"/>
            <filter class="solr.ShingleFilterFactory" maxShingleSize="10"/>
         </analyzer>
    </fieldtype>

Это поле может иметь значение, например: «Джастин Бибер».

И мое ожидание следующее:

Для запроса «Художник Джастин Бибер — подросток-сердцеед» я бы хотел, чтобы он соответствовал этому документу. И такие запросы, как «Художник по имени Бибер Джастин — канадец» или «Имя Джастин так распространено», не должны находить соответствия.

Я вижу, что использование обработчика запросов по умолчанию «/ select» не находит совпадения, когда я выдаю запрос «Джастин Бибер», даже если это точное совпадение. Но в качестве поля по умолчанию для RH '/ select' было установлено другое поле, поэтому я попытался создать еще один RH, используя приведенный ниже завиток:

curl http://localhost/solr/performer/config -H 'Content-type:application/json'  -d '{"add-requesthandler" : {"name": "/exactName","class":"solr.SearchHandler","defaults":{ "echoParams":"explicit" ,"rows":10, "df":"exactName_noAlias_en_US", "q.op":"AND" },"useParams":"x"}}'

Он создал RH, который я хотел, но мой запрос все еще не соответствовал требуемому документу.

Пожалуйста, предложите решение этой проблемы.

Это снимок экрана с экрана анализа.

Ниже приведен фрагмент раздела «отладка» ответа на запрос: «/exactName?q=exactName_noAlias_en_US:Justin%20Bieber&wt=json&indent=true&debug=true»

"debug":{
    "rawquerystring":"exactName_noAlias_en_US:Justin Bieber",
    "querystring":"exactName_noAlias_en_US:Justin Bieber",
    "parsedquery":"+exactName_noAlias_en_US:justin +exactName_noAlias_en_US:bieber",
    "parsedquery_toString":"+exactName_noAlias_en_US:justin +exactName_noAlias_en_US:bieber",
    "explain":{},

А ниже приведен фрагмент раздела «отладка» ответа на запрос: «/select?q=exactName_noAlias_en_US:Justin%20Bieber&wt=json&indent=true&debug=true»

"debug":{
    "rawquerystring":"exactName_noAlias_en_US:Justin Bieber",
    "querystring":"exactName_noAlias_en_US:Justin Bieber",
    "parsedquery":"+exactName_noAlias_en_US:justin +searchKeywords_en_US:bieber",
    "parsedquery_toString":"+exactName_noAlias_en_US:justin +searchKeywords_en_US:bieber",
    "explain":{},

А ниже приведен фрагмент раздела «отладка» ответа на фразовый запрос с /select RH: «/select?q=exactName_noAlias_en_US:"Justin%20Bieber"&wt=json&indent=true&debug=true

"debug":{
    "rawquerystring":"exactName_noAlias_en_US:\"Justin Bieber\"",
    "querystring":"exactName_noAlias_en_US:\"Justin Bieber\"",
    "parsedquery":"MultiPhraseQuery(exactName_noAlias_en_US:\"(justin justin bieber) bieber\")",
    "parsedquery_toString":"exactName_noAlias_en_US:\"(justin justin bieber) bieber\"",
    "explain":{},

А ниже приведен фрагмент раздела «отладка» ответа на фразовый запрос с /exactName RH: «/exactName?q=exactName_noAlias_en_US:"Justin%20Bieber"&wt=json&indent=true&debug=true

"debug":{
"rawquerystring":"exactName_noAlias_en_US:\"Justin Bieber\"",
"querystring":"exactName_noAlias_en_US:\"Justin Bieber\"",
"parsedquery":"MultiPhraseQuery(exactName_noAlias_en_US:\"(justin justin bieber) bieber\")",
"parsedquery_toString":"exactName_noAlias_en_US:\"(justin justin bieber) bieber\"",
"explain":{},

Ниже приведен запрос и соответствующий раздел отладки с экранированными пробелами в запросе:

select?q=Justin\ Beiber&df=exactName_noAlias_en_US

Отлаживать:

"rawquerystring":"Justin\\ Beiber",
"querystring":"Justin\\ Beiber",
"parsedquery":"+((exactName_noAlias_en_US:justin exactName_noAlias_en_US:justin beiber)/no_coord) +exactName_noAlias_en_US:beiber",
"parsedquery_toString":"+(exactName_noAlias_en_US:justin exactName_noAlias_en_US:justin beiber) +exactName_noAlias_en_US:beiber",
"explain":{},

exact-match tokenize solr shingles
person oveflown    schedule 08.09.2016    source источник
comment
Вы смотрели на вывод на странице «Анализ» на странице «Администрирование»? Это позволит вам вводить как проиндексированный контент, так и запрос, и видеть, какие токены генерируются с обеих сторон, и получаете ли вы одинаковые значения с обеих сторон. Для отладки предоставление поля по умолчанию или полей запроса в URL-адресах обычно проще, чем изменение или добавление обработчиков запросов.   -  person MatsLindh    schedule 08.09.2016
comment
Да. Я вижу именно то, что хотел в этом инструменте. Но я не вижу такого же поведения, когда я выдаю запрос через http, используя /select RH или пользовательский '/exactName', о котором я упоминал выше.   -  person oveflown    schedule 09.09.2016
comment
Не могли бы вы включить результаты этапа анализа? Также помните, что любые изменения в индексной части анализатора потребуют переиндексации этого документа.   -  person MatsLindh    schedule 09.09.2016
comment
@MatsLindh, я включил скриншот анализа для примера запроса. И да, я переиндексировал свою коллекцию после внесения изменений в конфигурацию.   -  person oveflown    schedule 09.09.2016

Ответы (2)


arrow_upward
0
arrow_downward

Отладочная информация parsedquery для последней записи показывает, что вы ищете в двух разных полях: одно — это поле, которое вы указали, другое — это поле поиска по умолчанию, которое вы установили ранее. Поскольку ни у одного из них нет ни одного токена с содержимым, которое вы ищете в каждом поле, вы не получите попадания. Это также является причиной того, что ваш анализ показывает совпадение, но вы не получаете совпадения при поиске — фактический запрос не совпадает с тем, который вы указали для страницы анализа.

+exactName_noAlias_en_US:justin +searchKeywords_en_US:bieber"
 ^^^^^^^^^^^^^^^^^^^^^^^         ^^^^^^^^^^^^^^^^^^^^

Первая запись показывает, что вы ищете два токена, а затем запрашиваете пересечение этих двух наборов документов — поскольку ни один из них не содержит этого единственного токена, вы не получите совпадения.

Поиск exactName_noAlias_en_US:"Justin Bieber" может дать вам ответ, который вы ищете.

person MatsLindh    schedule 09.09.2016
comment
Я пробовал это, но все равно не повезло. Я включил раздел отладки такого запроса в исходное сообщение. - person oveflown; 09.09.2016

arrow_upward
0
arrow_downward

Чтобы использовать черепицу, вы должны запретить синтаксическому анализатору анализировать запрос и применять оператор по умолчанию там, где есть пробел. Это можно сделать, убегая от пробела. Возможные запросы:

  • q=exactName_noAlias_en_US:(Джастин\Бибер)
  • q=Justin\Bieber&df=exactName_noAlias_en_US
  • q=Justin\Bieber (если в вашем обработчике определен df)

Несколько дополнительных примечаний:

  • есть несоответствие в именовании полей - в вашей конфигурации вы определяете поле «exactMatch», вы определяете поле по умолчанию «exactName» и запрашиваете «exactName_noAlias_en_US»
  • вам не нужен новый обработчик запросов для переопределения df - вы можете указать это в своем запросе
  • вам не нужен df, если вы явно указываете имя поля
person earnau    schedule 16.09.2016
comment
Спасибо @earnau за ответ. Боюсь, это все еще не работает так, как я ожидал. Я включаю отладочную часть и запрос в исходное сообщение. - person oveflown; 16.09.2016
comment
Да - ИЛИ - это оператор по умолчанию, поэтому забыл упомянуть, что его необходимо установить, чтобы он работал. - person earnau; 17.09.2016