lucene запрос размер- это этот масштаб? запрос для '1 ИЛИ 2 ИЛИ 3 .. ИЛИ N'

Question

Предположим, что у меня есть lucene запрос 'id1 ИЛИ id2 ИЛИ id3 ... idN'. Насколько хорошо этот масштаб увеличивается по мере увеличения N?

Ситуация, на которую я смотрю, будет похожа на тех, кто выполняет текстовый поиск по продуктам в своей корзине покупок, но у них могут быть сотни или тысячи предметов в корзине покупок. Пользователь хочет выполнить текстовый поиск по всем продуктам в своей корзине покупок. Могу ли я сделать текстовый запрос по всем доступным продуктам, а затем ограничить элементы, возвращенные с помощью позиции OR идентификаторов продуктов в своей корзине?

Answer 1

Максимальное количество предложений в булевом запросе по умолчанию 1024. Вы можете увеличить этот предел. Тем не менее, будет штраф за выполнение. Полагаю, это было бы эффективно, если бы вы использовали фильтры.

Answer 2

В вашем запросе есть ограничение на количество булевых операторов.

Answer 3

Как @Shashikant Kore упоминает, что ограничение по умолчанию равно 1024.

Если у вас очень большая коллекция текстов, вы можете посмотреть на реализацию MoreLikeThis - она ​​использует некоторые аккуратные эвристики для генерации репрезентативного запроса из вашего содержимого.

Answer 4

Использовать FilteredQuery во время поиска. Его конструктор принимает запрос и фильтр. Создайте запрос с того, что вводит пользователь (посмотрите на QueryParser). Создайте фильтр из списка идентификаторов продуктов (посмотрите на TermsFilter).

Answer 5

Как уже некоторые люди уже ответили, существуют практические ограничения. Однако, если вас интересует теория, нет никакой разницы между выполнением кучи OR'd терминов по сравнению с одним термином с множеством возможных результатов. Если p - количество проводок (пары term/doc), которые соответствуют вашему запросу, и вы хотите найти наилучшие совпадения k, запрос будет выполняться в O (p log k). См. Статью Дуга Space Optimizations for Total Ranking.

Если у вас есть q запросов или OR в сочетании с t членами в вашем общем индексе, это будет фактически что-то вроде O (q log t + p log k), но для большинства приложений p log k будет доминировать над тем, что , (Эта формула исходила из того факта, что для поиска потока проводки требуется время t t, и вам нужно сделать это один раз за период запроса.)