которое заканчивается здесь» «Некоторое длинное предложение,

Поиск точных совпадений при игнорировании пользовательских тегов

24 просмотра

1 ответ

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

  • «Некоторое длинное предложение, <custom-tag attr="value" />которое заканчивается здесь»

  • «Некоторое длинное предложение, <custom-tag attr="value" />которое заканчивается <custom-tag-2 attr="value2" />здесь»

  • «Еще одно длинное предложение, <another-custom-tag attr="value" />которое заканчивается <another-custom-tag attr=value />здесь»

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

  • «Некоторое длинное предложение, regex(<[^>]*>?которое заканчивается здесь»

вернет первый документ, и

  • «Некоторое длинное предложение, regex(<[^>]*>?которое заканчивается regex(<[^>]*>?здесь»

вернул бы второй документ.

Это то, что я мог бы достичь с Lucene 3.x ? Я даже рассматриваю возможность перехода на бета-версию Lucene 4.8, если это оправдано.

Как кто-нибудь имел дело с чем-то подобным? Есть ли подводные камни, которые я должен рассмотреть?

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

Автор: pelican_george Источник Размещён: 08.11.2019 11:02

Ответы (1)


1 плюс

Решение

Лучшим вариантом (в любой версии) является создание TokenFilter, который распознает тег / регулярное выражение и пропускает их из потока токенов.

Кстати: я считаю, что «хорошо» никогда не хранить поля (возможно, за исключением поля «идентификатор». Затем сериализация объекта в двоичное поле. Это отделяет «индекс» от «данных». Есть некоторое преимущество в скорость поиска и требования к IO

Автор: AndyPook Размещён: 16.01.2017 01:48
32x32