Я получил отличный ответ от Уве Шиндлера, позвольте мне опубликовать его здесь.
Если вы не кэшируете фильтры, запросы будут выполняться быстрее, как ConjunctionScorer
в Lucene есть оптимизации, которые в настоящее время не используются для фильтров.
Фильтры хороши, если вы их кешируете (например, если у вас всегда одинаковый доступ
ограничения для конкретного пользователя, которые применяются ко всем его запросам). В
в этом случае фильтр выполняется только один раз и кешируется для всего
запросы, а затем пересекаются с набором результатов запроса.
Если вы хотите только, например, случайным образом «фильтровать», например переменным числовым диапазоном
как ограничивающий прямоугольник в географическом поиске, используйте запросы, запросы в большинстве
случаи быстрее (например, Range Queries и аналогичные вещи, называемые MultiTermQueries
- внутренне также реализованы тем же алгоритмом BitSet, что и
Фильтр - на самом деле это всего лишь Фильтры, обернутые в Scorer-impl). Но
Оценщик, который ANDs запрос и ваш «фильтр» запрос вместе
(ConjunctionScorer), как правило, быстрее, чем код, который применяет
фильтр после поиска. Это может улучшить некоторые возможности, но в целом
фильтры в Lucene - это то, что больше не нужно, так что
уже были некоторые подходы, чтобы сделать фильтры и запросы одинаковыми, и
вместо этого тогда можно будет также кэшировать запросы без оценки. Это сделало бы много
кода проще.
Фильтры могут принести огромное улучшение скорости с Lucene 4.0, если они
подключен поверх IndexReader для фильтрации документов до скоринга,
но это еще не реализовано (см.
https://issues.apache.org/jira/browse/LUCENE-3212) - Я работаю над этим. Мы
может также сделать фильтры произвольным доступом (это легко, поскольку они являются битовыми наборами), что
может также улучшить фильтрацию после запроса. Но я бы тогда тоже сделал
Запрашивает частично произвольный доступ, если они могут его поддерживать (например, запросы, которые
основаны только на FieldCache).
Уве