Как ограничить результаты поиска Lucene документами, содержащими не менее n слов?
Я хотел бы ограничить результаты поиска документами, содержащими как минимум токены / слова n, т.е. набор результатов должен содержать документы как минимум с токенами 100. Я пытался написать собственный LeafCollector, но API не кажется интуитивно понятным. Прежде чем погрузиться глубже, я хотел спросить, возможно ли это вообще, и если да, может быть, кто-нибудь предоставит краткое доказательство реализации концепции, чтобы я начал работать.
Вот то, что у меня пока есть, логика должна быть в методе collect, насколько я понимаю.
public class CustomCollector extends TopDocsCollector<ScoreDoc> {
protected CustomCollector(PriorityQueue<ScoreDoc> pq) {
super(pq);
}
@Override
public LeafCollector getLeafCollector(LeafReaderContext leafReaderContext) throws IOException {
return new LeafCollector() {
@Override
public void setScorer(Scorer scorer) throws IOException {
}
@Override
public void collect(int i) throws IOException {
}
};
}
@Override
public boolean needsScores() {
return true;
}
}
@IvanMamontov Я не сохранил статистику, сколько слов содержит каждый документ, поэтому, насколько я могу судить, запрос невозможен. В рамках моей бакалаврской диссертации мне нужно проиндексировать ~ 300 ГБ данных, я создал индекс, и теперь мой руководитель говорит, что он хотел бы рассматривать только документы с> 100 токенами. Я пытаюсь снова проиндексировать 300 ГБ данных только из-за этого небольшого требования, поскольку для создания индекса потребовалось довольно много времени.
Производительность запросов не так важна для моего варианта использования.
Вы можете индексировать количество слов в каждом документе во время индексации, а затем запрашивать это поле. Это сработает, не так ли?
@darcula Да, я этим и закончил. Я подумал, что, возможно, Lucene хранит такую информацию по умолчанию, и не хотел снова создавать индекс, потому что это заняло много времени.
@Buddy Это кажется труднодостижимым в Lucene, потому что он использует инвертированный индекс в качестве базовой структуры данных. Он хранит термины как ключи, а документы как значения. Вы ищете документ -> его условия.
Сборщик - не лучшая идея - это структура данных с учетом сегментов, и вы должны учитывать переключение сегментов, вы пробовали логическое значение, если запрос с минимальным значением должен соответствовать lucene.apache.org/core/7_3_0/core/org/apache/lucene/util/…? Не могли бы вы подробно объяснить свой вариант использования?