Lucene ищет имя файла, используя WordDelimiterFilterFactory

Если я ищу toto.pdf, для поиска будет создан токен «pdf», который индексирует некоторые данные, включая имена файлов.Lucene ищет имя файла, используя WordDelimiterFilterFactory

То, что я хочу, в соответствии с индексированной файла:

MySupercool123girlfriend.jpg

И чтобы быть в состоянии Какискать это с:

supercool 
supercool123 
123 
girlfriend 
jpg

Так по индексу довольно легко, чтобы иметь возможность использовать WordDelimiterFilterFactory так, что некоторые токены создаются, например:

my 
supercool 
mysupercool 
mysupercool123 
supercool123 
123 
girlfriend 
jpg 
girlfriend.jgp 
etc...

Дело в том, что во время поиска я делаю не знаю, что я должен делать.

Если я использую WordDelimiterFilterFactory во время поиска, MySupercool123girlfriend.jpg будет соответствовать даже с toto.jpg, потому что в обоих случаях создается токен jpg. toto.jpg не должно быть в списке результатов на всех, так что это не решение для меня, чтобы иметь оба результата с соответствующим одним, имеющим лучший забив

У вас какие-либо рекомендации для индексирования и поиска имен файлов?

источник

2013-02-13 Sebastien Lorber

вы уверены, что 'toto.pdf' соответствует' MySupercool123girlfriend.jpg'? Потому что я уверен, что не вижу или 'toto' или' 'pdf' в MySupercool123girlfriend.jpg'. –

правильно, я имел в виду toto.jpg –

Для этого конкретного примера ваша т.е. если поиск для MySupercool123girlfriend.jpg, и вы хотите, чтобы это вернуть только те документы, которые всю строку в нем, вы можете сохранить copyField, скажем, по имени filename_str, чей FieldType является string. Строковые совпадения гарантируют, что вы получите точное соответствие. Это может быть поиск «точного соответствия» на первом уровне.

Однако, я предполагаю, что вы хотите найти 123girlfriend.jpg, чтобы вернуть документ, содержащий MySupercool123girlfriend.jpg. Вы можете выполнить поиск этого уровня на 2 уровне. Начиная с Solr 4.0 вы можете сделать поиск регулярных выражений, как

q=filename_str:/.*123girlfriend.jpg/

(Это регулярное выражение запрос должен также работать для filename самого поля, если вы используете preserveOriginal=1 в WordDelimiterFilterFactory во время индексирования.) Иначе вы можете сделать leading wild-card search, который работает в более ранних версиях Solr.

Если вы хотите MySupercool.jpg соответствовать MySupercool123girlfriend.jpg, то я думаю, вам придется вручную делать работу DelimiterFilterFactory и построить регулярное выражение запроса, как

q=filename_str:/.*My.*Supercool.*.jpg/

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

источник

2013-02-18 02:52:40 arun

Выполнение подстановочных/регулярных запросов довольно медленное Нет? Хорошо, поэтому в конце нет простого решения для этого, я думаю. –

Думая немного больше о вашей проблеме, я думаю, последний комментарий, который я сделал о разделении имени файла и расширение и хранение их в отдельных областях должно помочь вам устранить много o f false, даже без каких-либо изменений. – arun

Мы можем сделать это, просто искали более легкое решение, не разбивая данные перед вставкой или создавая собственный анализатор/фильтр. –

Можете ли вы придумать какой-либо смысл для вашего варианта использования DisMax mm?

См http://wiki.apache.org/solr/DisMaxQParserPlugin#mm_.28Minimum_.27Should.27_Match.29

Э.Г. мм = 100% и "MySupercool123girlfriend.jpg "будет соответствовать только именам файлов, в которых есть все [" my "," supercool "," 123 "," girlfriend "," jpg "].

Вы можете найти несколько менее строгих, но все же дающих релевантные выражения результатов. см http://lucene.apache.org/solr/4_1_0/solr-core/org/apache/solr/util/doc-files/min-should-match.html

источник

2013-02-18 20:21:42

Я видел эту функцию, но не могу ее использовать, потому что мне нужен строгий результат, потому что мы должны сортировать результат по дате создания, а не по подсчету. Таким образом, наличие примерно 20% может оказаться неприемлемым для нашего usecase и будет больше похоже на хакерское решение, которое может дать или не дать хорошие результаты. –

Возможно, вы сможете: a) отключить tf и idf в вычислении счета путем реализации пользовательского сходства (см. Http://stackoverflow.com/questions/13825170/ignore-tf-idf-at-query-time-in-solr) и b) сортировка по счету desc, timestamp desc. Таким образом, у вас были бы строгие совпадения, сначала отсортированные по timestamp, затем совпадения без 1-го семестра и т. Д. Или вы можете просто сортировать по результату, но увеличивать последние результаты (см. Http://wiki.apache.org/solr/SolrRelevancyFAQ#How_can_I_boost_the_score_of_newer_documents) –

точка на самом деле заключается в том, чтобы сначала сохранить порядок отметки времени и не использовать пользовательский компонент. Мы можем использовать пользовательский компонент в будущем, но на данный момент я просто хочу иметь готовое решение. Спасибо, в любом случае –

Lucene ищет имя файла, используя WordDelimiterFilterFactory

ответ

Смежные вопросы