Lucene (.NET) Рекомендации по структуре документа и производительности

Question

Я индексирую около 100 миллионов документов, которые состоят из нескольких строковых идентификаторов и примерно сотни числовых терминов. Я не буду выполнять диапазонные запросы, поэтому я не копался слишком глубоко в Numaric Field, но я не думая, что это правильно, выберите здесь.

Моя проблема заключается в том, что производительность запроса быстро снижается, когда я начинаю добавлять критерии OR к своему запросу. Все мои запросы имеют конкретные числовые термины. Таким образом, документ выглядит как StringField: [someString] и N DataField: [someNumber] .. Затем я запрашиваю что-то вроде DataField: ((+ 1 + (2 3)) (+75 + (3 5 52)) (+99 +88 + (102 155 199))).

В настоящее время выполнение этих запросов на моем ноутбуке занимает от 7 до 16 секунд. Я хотел бы убедиться, что это действительно лучшее, что они могут сделать. Я открыт для предложений по структуре полей и структуре запросов: -).

Спасибо

Josh

PS: Я уже перечитал все другие обсуждения производительности люцена здесь, а также на вики Lucene и при ясном воображении ... Я чуть дальше по кроличьей норе, что ...

Answer 1

Поскольку вы упомянули, что вы выполняете конкретные числовые запросы, а не запросы диапазона, я не предлагаю вам взглянуть на очень быстрые запросы числового диапазона в Lucene 3.0.

Полагаю, по твоему описанию проблема в скоринге. Когда у вас так много вложенных логических запросов, оценка становится все более сложной. И оценки, являющиеся числами с плавающей запятой, арифметика медленнее. Если вас не волнует оценка, хорошей идеей будет написать пользовательский Collector . Вы можете увидеть пример, в javadoc, который я связал, чтобы написать свой собственный.