Замена лидирующего подстановочного запроса в Lucene

Question

У меня есть приложение, которое ищет в индексе совпадающие штрих-коды с неизвестным префиксом, который может существовать или не существовать.В настоящее время приложение использует ведущий подстановочный знак в WildcardQuery для учета префикса, однако это, очевидно, вызывает проблемы performance .Я рассмотрел использование ReverseStringFilter, но он использует TokenStream, и я не уверен, как бы я использовал его в этой ситуации.

Вот очень простой пример того, как это в настоящее время реализовано, нодолжен дать вам хорошее представление о том, что происходит:

BooleanQuery allBCQueries;
BooleanQuery bcQuery;
for( barcode : barcodeList){
  bcQuery.add( new WildcardQuery( new Term('barcode', "*" + barcode)), Occur.Must);
  allBCQueries.add(bcQuery, Occur.should);
}
BooleanQuery result;
result.add(allBCQueries, Occur.Must);

Затем результат используется для поиска в индексе.

Есть ли способ исключить ведущий шаблон для повышения производительности?

Answer 1

Как я уже говорил в комментариях, идея состоит в том, чтобы использовать ReverseStringFilter , который эффективно восстанавливает токены и вместо штрих-кода "123123" создает токен "321321".Это означает, что эти запросы с неожиданным префиксом могут быть переписаны.

Вместо barcode:*123 мы могли бы использовать запрос barcode:123*, который был бы гораздо более эффективным.

Добавление документа с пользовательским TokenStreamна поле довольно просто:

final Tokenizer token = new KeywordTokenizer();
Document doc = new Document();
token.setReader(new StringReader(value));
doc.add(new TextField("barcode", value, Field.Store.YES));
doc.add(new TextField("reverse-barcode", new ReverseStringFilter(token)));

Таким образом, мы применяем токенайзер ключевых слов (например, без токенизатора) + фильтр обратной строки, сохраняя исходное значение

Я провел некоторое тестирование с1 миллион документов, заполненных случайными штрих-кодами (например, long в моем случае) и обратным способом, получил преимущество приблизительно 30% , при этом предоставляя точно такое же количество результатов.

Можно найти полный пример есть