2009-09-15 3 views
1

Я знаю, что есть несколько тем в Интернете, а также на SO, относительно индексирования и выполнения запросов в Lucene, но мне еще предстоит найти вопрос о том, стоит ли (или если да, сколько ?) создание полезных нагрузок будет влиять на производительность запросов ...Производительность полезной нагрузки в Lucene

Вот сценарий ...

Скажем, я хочу, чтобы индексировать коллекцию документов (в любом месте от 100К - 10М), и каждый документ имеет подраздел, который Я хочу иметь возможность искать отдельно (или, возможно, ранжировать выше, в зависимости от того, найдено ли совпадение в этом разделе).

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

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

Спасибо!

EDIT: Я ценю альтернативные решения для моего сценария, но в случае, если мне нужно использовать полезную нагрузку в будущем, есть ли у кого-нибудь замечания относительно исходного вопроса о производительности запроса?

+0

Посмотрите на Compass (http://www.compass-project.org/), он делает этот вид высокопроизводительных слоев на вершине Lucene намного проще. – skaffman

+0

Спасибо за предложение, я буквально только что наткнулся на Компас сегодня днем, так что хорошо знать, что я могу быть на правильном пути. Я постараюсь сообщить, если мне повезет! – jeremyalan

ответ

1

Решение для учебников, которое вы хотите сделать, это индексировать каждый исходный документ как два поля: один для полного документа, а другой для подраздела. Вы можете увеличить поле подраздела отдельно либо во время индексации, либо во время поиска. Сказав это, вы можете прочитать о полезной информации о Lucene здесь: Getting Started with Payloads.

+0

Спасибо за подсказку. Это то, что я сейчас делаю, я просто подумал, что может быть лучший способ. Знаете ли вы какие-либо ссылки, на которые вы могли бы указать мне, что поддержит ваше требование? – jeremyalan

+0

Вы можете попробовать: http://www.lucidimagination.com/Community/Hear-from-the-Experts/Articles/Optimizing-Findability-Lucene-and-Solr и http://www.manning.com/ hatcher3 / –

0

Ваш прецедент не подходит для целей полезных нагрузок - мне кажется, что любая полезная информация будет излишней.

Полезные грузы прилагаются к отдельным вхождениям терминов в документ, а не к документам/терминам. Чтобы хранить и получать доступ к полезной нагрузке, вы должны использовать смещение термина «возникновение» в документе. В вашем случае, если вы знаете смещение, вы должны иметь возможность рассчитать, в какой секции находится термин «вхождение», без использования данных полезной нагрузки.

Более широкий вопрос - это эффект полезной нагрузки на производительность. Мой опыт заключается в том, что при правильном использовании реализация полезной нагрузки занимает меньше места и быстрее, чем когда-либо ранее применявшийся метод обхода. Наибольшее влияние на дисковое пространство будет, если вы в настоящее время используете Field.setOmitTermFreqAndPositions (true), чтобы уменьшить размер индекса. Вам нужно будет включить позиции для использования полезных нагрузок, что потенциально увеличивает индекс.

Смежные вопросы